Sail the open seas and earn your fortune Play Online
About Alamantus GameDev
Alamantus GameDev is an independent game development studio run by one guy named Robbie Antenesse and whichever friends he can rope into helping him. The earliest recorded activity by Alamantus GameDev was March 3, 2013, marking that day as the beginning of the tiny studio. Robbie has years of experience working with Game Maker and has been working with the Unity 3D engine since 2014.
We aim to make as much of an impact in the game development world as possible, spreading the gospel of game development accessibility by talking openly about how to develop video games, passing along whatever advice we can find, and acknowledging the importance of women’s presence in video games by making one of our goals to have a female lead in the vast majority of games it produces.
Alamantus GameDev is still pretty new, but we’re learning, and we’ll keep getting better and better until the day we die.
Saturday, October 13, 2018
This also applies to game development or coding in general! People like @neilmakesgames are always doing something, and his games are always getting better!
I’m hoping to get back onto a project soon, myself, too!
I was looking into the Godot Engine again because it looks really nice and I want to try it out, and I came across a collection of videos comparing Godot with Unity. The person who made that comparison video made a follow-up video a couple of months later with a short but important message about game development in general, and I’d like to share it as a reminder to you all.
TL;DW: The game engine you use doesn’t matter, as long as it works best for you and you can make the game you want to make.
I use Game Maker a lot and there’s a lot of stuff I read about it being bad. There’s aspects of it that I don’t like (such as exporting), and there’s engines that have aspects I like better (I love how UE4 allows me to customize individual actors following their blueprint in its presentation), but there’s enough there that works for me and my way of thinking and wanting to do things that I’m happy with it.
Like with different GDEs and different programming languages, different art styles and different religions, no engine is a be-all-end-all tool for communicating a game idea, but a different set of perspectives on approaching it. I think this is why people initially get so strongly attached to a GDE or a game development method when they do click, because they align with their way of thinking so well that to insinuate it doesn’t work for everyone can feel like a personal attack. “If you don’t think like I do than you’re an idiot” is the whole attitude I get from folk like that.
All of it does take a great effect on how a game turns out and other important factors, but game development is full of thousands of compromises. “Are you willing to take on an engine’s existing features in spite of not having complete control over every aspect?” is just one of them. So I can’t imagine how much more that varies when it comes to how one wants to organize hundreds of different assets and scripts, and how they all come together and how versatile or restrictive they are.
I think the best advice is, if you want to get into game development but one engine/approach you’re using doesn’t work for you, go try something else. It might feel like starting from square one but various disciplines carry over and the new environment will give you a different perspective. You might stick with it or go to something else but I think understanding what process is most efficient/enjoyable for you when developing a game (something that can take months to years) is the most important consideration when choosing an engine.
I was looking into the Godot Engine again because it looks really nice and I want to try it out, and I came across a collection of videos comparing Godot with Unity. The person who made that comparison video made a follow-up video a couple of months later with a short but important message about game development in general, and I’d like to share it as a reminder to you all.
TL;DW: The game engine you use doesn’t matter, as long as it works best for you and you can make the game you want to make.
Difficulty in games is a pretty hotly-contested subject.
The most recent hullabaloo came about from this article on a “skip boss” button. Many are vehemently against the idea. Others loved it. A few fell somewhere in the middle. My opinion? It depends on the game. A “skip boss” button itself might not be a good idea, but maybe an optional invincibility mode is (Nintendo games used to offer an invincibility star if you died too many times, or there’s the old school godmode cheat). Ideally, this is tied to bonus points, or score, or achievements, or unlockables–but I digress.
Here’s what I want: better difficulty options for all kinds of players. We can have our cake and eat it too, if we just spend some time thinking.
First things first: not all games need difficulty options. For some games, difficulty is integral to the experience. Dark Souls is a common example: its core gameplay loop is built entirely around its difficulty, and the experience would unravel if it was too easy.
But I’d argue most games aren’t built around difficulty.
Enter difficulty options
The standard approach is a decision between some variation of Easy/Normal/Hard at the beginning of the game. Normal might be the developer-intended way to play the game, Easy is for those who want to relax after a hard day’s work, or for little kids, or for those who want to experience a story, or for those who just aren’t very good at games (and that’s ok, by the way). Hard is for those who want an extra challenge and maybe extra achievements or unlockable secrets.
But we need better difficulty settings, because there’s a problem with Easy/Normal/Hard: it’s an uninformed choice.
Uninformed choice is a bad choice
In other words, when you ask the player if they want to play on hard mode, what does that mean? More HP to enemies? More complex AI? (ha, right) Cheating AI? Fewer powerups? More XP needed to level up? You don’t know until you actually play the game, and sometimes even then you aren’t sure. The player has to guess what they’re getting themselves into.
This isn’t good choice.
Sure, you might know you generally prefer Easy mode, and for most games that offer these options, it ends up working out. But we can do better!
Informed difficulty settings
First, let’s tell the player what’s going on. Some games explain what different difficulty modes mean. This is a much better version of Easy/Normal/Hard. For example, Shadow Warrior 2:
If you’re going the traditional Easy/Normal/Hard route, add these descriptions. Inform your players’ choices. Tell them they’ll take 50% less damage and get more healing items. I enjoy the personal touch here, reiterating that Easy Mode is a perfectly valid way to play.
(Another good example of this is Baldur’s Gate: Enhanced Edition. Check it out! Even though I usually like a challenge, I’m unashamedly playing on Easy because AD&D 2 is freakin’ brutal.)
This is a good choice, because players now have an understanding of what they’re getting themselves into. But guess what? We can do even better–we can give the player control!
The ideal: custom difficulty settings!
Keep Tourist,Easy, Normal, and Hard modes, but also display a list of more granular difficulty options beneath–these granular options can get highlighted and switched on when a particular difficulty mode is selected. The player can choose one of the basic options, or create a Custom difficulty–perhaps even save custom difficulty profiles if there are a lot of settings.
The mockup below isn’t perfect (I got tired of placing each individual letter), but it’ll give you a general idea. Also these are not options for The Waking Cloak (though some of them might be).
Some things I might change even here: I didn’t highlight which individual settings get counted as Easy/Normal/Hard as they were selected. And I’d like to add a better description for what each option does, especially for players who’ve never played the game before. I also considered some kind of indicator for whether a setting counted as very easy, easy, normal, hard, or very hard, like a colored underline–green for easy, red for hard. There’s more, but the mockup should at least give you the idea.
Ideas for custom difficulty settings
Story/Tourist mode - just wander around and experience the story. No fighting.
Save types - player can save wherever they want, only at designated save points, or ironman (only one “suspend” save file, deleted on death).
Dungeon guide - a glowing “critical path” to guide players through dungeons. If you have this option on, you can still turn the guide on/off.
Skip boss button - display the skip boss button to optionally allow players to avoid them.
Enemy amount - fewer, normal, lots. Ideally on the “more enemies” settings, you’d have different types of enemies that force the player to think more critically
Enemy speed - movement, attacks, etc. Test those reflexes! This is a more meaningful, fun way to increase difficulty than just giving enemies more health. Bullet sponges aren’t fun.
Enemy strength - Also much more meaningful than bullet sponges. You can even have an instakill option.
Enemy health - some people like bullet sponges. More power to them. You can even have different options, like regenerating health.
Passive enemies - enemies are all still there, but they don’t attack you. Good for little kids or those who don’t like violence.
Healing hearts/potions - turn your ability to heal on or off. Want the harrowing feeling of no healing items out in the field? Go for it!
The main thing to keep in mind is that not everything will work in every game. Design difficulty settings around particular mechanics in your game. As we’ll see later, a driving game might have options that ignore hydroplaning to make things easier or manual shifting to make things more difficult. A stick shift mode wouldn’t work in The Waking Cloak, nor would survival mode make sense in a racing game.
Ok, so what’s the catch?
More settings means more testing. More options means more development time and more work. You need to decide which variables to expose. You need to program the game so that these variables can be exposed in the first place. You’ll need to spend more time considering completely different play styles.
You also want to be very careful to not lead players down the path of least resistance against their will. This is the thing I have against fast travel. Some people like it, and that’s fine. But to people like me, who enjoy the journey of walking around and exploring, it’s more like a temptation. From experience, I know I’ll enjoy the journey more, but once I start fast traveling, I always fast travel, and the game becomes a lot more shallow to me.
(There’s another principle of game design around fast travel–make walking around more interesting and varied. But that’s another discussion for another time.)
You don’t want to overwhelm the player with options. Analysis paralysis is a thing. Try to only reveal the options that are most meaningful to the player and the game’s mechanics. Walking the fine line between too few and too many options might be difficult.
Examples!
This isn’t a new concept. Plenty of games have implemented granular difficulty settings.
Way of the Passive Fist - four sliders allow you to choose your difficulty. This is nice and granular, allowing for all kinds of tweaks.
Darkest Dungeon - from Mark Brown’s tweet. I like that this explains that you’ll be changing the experience. Notice how the difficulty settings are linked very closely to game mechanics, like monster corpses or enemy crits.
Forza Horizon 3 - the description is nice, because that makes your choice even more informed. I also like that it’s clear that you get bonuses for harder settings. Again, notice how difficulty settings are linked to game mechanics, such as steering, ABS, and tire wear.
Invisible, Inc. - I’ve heard good things about the difficulty setting here! Once again, difficulty settings are linked to game mechanics. One review stated that choosing custom settings was letting the player try out game design, and I agree.
Hey, @starvingindie, great question! Thanks for asking :)
I’ve gotta say, I’m really enjoying Love2d right now.
Here’s a partial list of the frameworks and engines I’ve worked with in the past (in roughly chronological order), and my thoughts about them:
Akihabara
Akihabara.js - I made some demo programs with this, it’s what got me started on javascript gamedev. It got the job done, and taught me some stuff. Nice. The project has been dead for a while now. Don’t use this.
Impact
Impact.js - I made a lot of my javascript games in this engine. It’s very nice. It’s The documentation is well-written and nicely presented. It’s got most if not all of the features you need for making a 2d game in javascript, and now certain types of 3d games (though I never made one myself). The level editor is very good, as well.
It’s paid software and closed-source, so the community is kind of small but the forums were quite helpful when I used them. I’ve talked about my thoughts on Impact’s future elsewhere, so I won’t elaborate much on that here (since it’s closed-source, it’s future is uncertain, IMO). Impact is good, but I don’t recommend developers use this right now, when there are really good free alternatives out there.
Atom.coffee
Atom.coffee - I played around with this micro-library for a bit. This tiny framework is very much “bring your own EVERYTHING.” No documentation, no collision detection, no community, no plugins… Basically it saves you from having to re-implement input, sound, drawing to the canvas every time you want to start a new project.
Kind of fun for making little projects from scratch. Not for beginners.
Phaser
Phaser.js - I’ve played around with Phaser and made a few small projects, but nothing I’d call a full release. Another full-featured 2d javascript game engine, also with good documentation. Phaser has definitely taken over Impact’s market share and the community has a ton of plugins and tutorials and things. It’s very easy to get started with Phaser.
Playground (the game engine part of the pair) is a “some assembly required”-type of framework. It gives a lot of tools (with really good documentation) but is agnostic with regard to a lot of game-related things like “collision detection.”
It’s the sort of thing that an experienced developer won’t find problematic, but a beginner might. If you’re the type that just wants to build a game and not an engine, you might find this bothersome. If you don’t mind making an engine that does just what you want it to and no more, you might like this.
It’s still in active development and it’s open-source (MIT License). I recommend it.
PICO-8
PICO-8 - This is a “fantasy console” that uses very strict limitations to produce retro games. It says it uses Lua, but there are enough things added to and missing from the language that it really should say “it uses a language based on Lua.”
That quibble aside, it’s another fun framework that really makes you think about the limitations and work within them. I recommend it, but possibly not for beginner developers. I haven’t really made anything substantial in it, just some toys and demos. (I dabble in a lot of frameworks/engines. Are you seeing a pattern here?)
Game Maker: Studio
Game Maker - I made my most recent full (finished) game in Game Maker: Studio. The process was very interesting, to say the least.
I finished the project with kind of a love/hate relationship with GM. Certain things are really easy, like the built-in collision detection (why do I keep mentioning that? I guess because it’s on my mind from implementing it in my current game…) and movement along paths (and A-star). Certain other things are unnecessarily complicated, like fixing that weird bug that I never figured out where the NPCs would play their “tired” animation SUPERFAST, even though I’m pretty sure I set it to play slowly.
Anyhow. Game Maker has a ton of features, a pretty big community, a marketplace where you can buy plugins and things, lots of people who make tutorials (shoutout to @uheartbeast). The YoYoGames documentation for GM is… okay. Not great, not awful, just okay. Kind of difficult to navigate and not aesthetically pleasing, if I have to be honest.
My main gripes with GM are: horrible UI for their IDE, inability to get away from the drag-and-drop (even if you’re doing everything in GML), you can’t compile a game without entering their IDE (so you can’t do it all from Sublime and compile from the command line or whatever), you have to buy their modules to export your games for various platforms (and I’m cheap: I wouldn’t even be using Game Maker if I hadn’t got it on sale during that Humble Bundle), and the programming language it uses feels very slapped-together (worse than javascript in places) and not well-designed.
LÖVE
LÖVE
- I’m doing my current projects in LÖVE (or Love2d as it’s also known). I have to say, I’m really digging it. After coming from Game Maker where I would occasionally feel restricted by the engine’s built-in functions, it’s refreshing to come back to an engine where I can invent my own way of doing things. I guess I’m just a coder at heart or something.
Love’s got a great wiki for documentation, lively forums, and a lot of plugins. It doesn’t have as many written or video tutorials as some of the other languages, but it’s not hurting for them, either.
Love uses Lua (like PICO-8), which is a fairly easy language to learn. It has a few little “gotchas” for people coming from languages like javascript (like me), but it’s nothing insurmountable.
Again, being a cheap indie, I like Love’s zero-dollar price tag and open source nature (though I’ll probably never compile the engine from source, it’s nice to have the option). Bonus: It exports to a ton of different platforms at no extra cost :)
So to answer the actual question of “how do I like love2d compared to the other things I’ve used?” I have to say I like it better than a lot of them. I’m definitely glad I took the time to learn it and I’m having a lot of fun with it right now.
I highly recommend it to anyone who wants to make a game and doesn’t mind coding (or using someone else’s libraries).
Thanks again for the question!!
This is a great list! Thanks!
Thursday, April 14, 2016
Guess who just learned that JavaScript Arrays are not passed by value to variables!
This guy!
If you ever need to assign an array variable to another variable, it’s better to clone it with var newArray = oldArray.slice(); to create a copy instead of just referencing the old array!
Friday, April 1, 2016
External Source Control for Unity Projects
Hey there! So I decided to actually look up how to properly set up source control in Unity projects, and I found this documentation page:
It almost seems like they’ve never even heard of Git, but the concept is the same. Set your project to save meta data as text instead of binary and exclude the Library folder and then you’ll have minimal trouble sharing between environments! Yay! I had a lot of trouble when I committed the source on one computer and then pulled it from another, and this should help with that.
Here’s my .gitignore file if you’re interested:
Library/* Temp/ *.zip
This is NOT an April Fool’s Joke! I keep forgetting the day, but this is real and helpful!
Sunday, February 21, 2016
mrnelson007 asked: So I keep meaning to dabble with game design, even though I'm already really busy with other projects. Do you have any suggestions for how you might get started?
First thing when making a game: use tools. The thing about games is that they require a lot of ground work in order to get even simple things to work. Luckily you don’t have to re-invent the wheel here as there are plenty of tools that can help you hit the ground running.
What tool you use will depend on what game you are trying to make. Game Maker, RPG Maker, and Twine are all great tools that give you a good base while giving you enough freedom to be able to make something completely new. If you are comfortable programming then Unity is also good.
All of these tools also have a lot of tutorials and tutorial projects already made. See if you can find a tutorial for the game type you want to make, download it and start fiddling around with it.
You want to get to the stage where you have something playable as fast as possible. The stage where you have something working and you can play it and test it and get a good feel for how you want the game to play. Try things out and see what sticks. Most of my projects started out as something completely different but after playing them I find a certain mechanic or idea that pops up in the game is much more interesting and so I switch the game over to focus on that. There are plenty of tools and tutorials to help get you started and while it can be frustrating it is also a lot of fun.
Seriously though, start really fucking small. Almost insultingly small. A single mechanic, a single level, a single interaction. Once you have something then you can start growing it into a more fully featured game.
Github – If you create a LICENSE file in the root of your GitHub repo, it prompts you to choose a license template, and fills it in with relevant details.
I’ve felt very burnt out lately. I have projects I know I should be working on, but I just can’t seem to do so.
What do you guys do for motivation at times like these?
Motivation is fleeting. Discipline is required for when you feel burnt out.
I understand where you’re at, 100%. My current project is taking way longer than I thought it would, and longer than most of my previous projects. It’s very easy to get discouraged.
I work on my game every single day, even if it’s just a few lines of code or placing a few tiles on the map.
Don’t worry about quality or quantity, as long as you sit down and work on your project every day. Build the habit. Try not to miss any days. Don’t break the chain and don’t get discouraged. Keep your eye on the prize!
Saturday, January 23, 2016
Hey, celebrate with me! I’ve started developing Chompy! again after a long time of gamedev block! Yay!
It’s not much yet, but I was able to fix some important graphical problems with Chompy! I hadn’t noticed that the left side of his neck kind of jutted out before, so I fixed up the sprite so it aligns properly, but the cool part is the right side.
Before, you could see the upper jaw’s extension sticking out in front of her chest, but I finally figured out how to create a sprite mask that hides the sprite behind another invisible sprite of any shape! I used this Unity Answers post and its comments, but I had a really hard time understanding how to get it to actually work. So you get to benefit from what I’ve learned! Yay you!
In order to get sprite masking (hiding sprites behind another, invisible sprite) working, you need to create a new shader based on the Sprite-Default shader and the actual masking shader. You can find the default shaders in Unity’s download archive. I’m using Unity 5.2.3 right now, so I downloaded that particular shader pack—I don’t know if the other versions’ sprite shader is different or not.
So create the new shader for sprites that you want to be masked and copy and paste the Sprite-Default shader into it, rename the shader (at the top where it says ‘ Shader “Sprites/Default” ’, the text in quotes is the “folder/” and the name where the shaders are organized in the Editor), and edit the “Queue” line in the Tags block to say “Transparent+2″ instead of just “Transparent”. Then save it, create a new Material, set the shader to your new “Masked Sprite” one, and put that material on the sprite you want to mask.
Next, create the shader for the sprite that you want to use to mask things with the material you just made. I updated the code from that Unity Answers post I linked to above:
I’m not completely sure what the Pass of this shader does, but it effectively prevents the actual sprite that the material is attached to from displaying while technically outputting the sprite. The important part, though, is the “Queue” tag set to “Transparent+1”. What this does is it specifies which render order to draw in. The first sprite with the shader tagged “Transparent+2” will draw 2 draws before the regular Transparent queue. Then the mask’s shader with “Transparent+1” is saying “draw the mask sprite on top of the masked sprite that’s already been drawn, overwriting what’s there”. Then everything else that’s in the Transparent part of the queue draws on top of that. This draw order is only relevant to the sprite’s “Order in Layer”, so the masking sprite is only relevant to sprites in that same layer and order.
Anyway, once that shader’s saved, put it in a new Material and put that material on the mask sprite.
Now you can use it! Create the sprite GameObjects that you need—one to be the mask and one to be masked—and assign them their respective materials. Make sure that the sprites are on the same Sorting Layer and Order in Layer, then move the Mask sprite closer to the camera (i.e. adjust the Z coordinate so it’s in front of the masked sprite if you were to view it in 3D) and you can move it around the XY plane to mask your sprite however you need. If everything set up right, you should have yourself a masked sprite!
So, I’ve run into a conundrum. I’m getting to the point in my games dev cycle where I’m working on actual features and mechanics for the game. The question is, how much do I share, and how much do I keep hidden for the player to discover while playing the game.
Anyone have any advice on that front?
A great question indeed!
Your current game’s a metroidvania, right? I feel like you can show hints of things, like certain areas of the game you’re working on or enemies and concept art and things like that without giving away too much about how you’re going to encounter and use upgrades or reach certain areas.
Does anyone else have advice on this, experience that’s worked for you, or seen someone do it some way that worked well?
