Ideas
I knew from the start that no matter what the theme was I was going to create a simple clone of the game I’m currently working on. This is obviously not the spirit of the competition, but I really wanted to see how people responded to the basics of my game, since I only have the gameplay systems in place but no design yet (i.e. there is no win/lose condition, no goals, no story, no graphics, …). This is the current version of the game and displays what I thought to be a very interesting system:
Basically, you can create new weapons/attacks by combining the most basic elements that make up an attack. So, in the case of the video above, the two basic elements are projectiles and areas. Projectiles can deal damage, fork (vertically or horizontally), pierce through enemies, reflect on walls, slow enemies, and so on… Areas can deal damage, slow enemies, explode, …. If you combine an area with a projectile, the area will be bound to the projectile’s position (or if it has an explosion modifier, then the area will explode once the projectile comes in contact with an enemy or a wall) and they will both apply their modifiers separately. The main idea is that you can combine all modifiers between projectiles and areas to create new and amazing attacks. Since I really like the idea of combining things, naturally I thought that this would make a great feature in whatever game I created. I’m not sure if I’m entirely wrong or not, but the competition helped me explore some of the issues with it.
Execution
In the first 24 hours I got most of the combinations working with only a few bugs left. I devoted the second day entirely to creating the actual game rules, additional touches and fixing bugs. The rules of the game were simple (or so I thought): you can create whatever weapon you want by combining different modifiers; each modifier has a cost, such that if you go for the most OP weapon ever it will cost you more; the more your weapon costs the bigger your score gets over time; the goal is to kill all enemies while maintaining the lowest score possible.
Back then I should have realized that if it took this many words to explain the basics of the game, it probably was too complicated. But I didn’t. Anyway, I managed to implement this whole deal and this is what the upgrade screen looked like (you can also see the game on the background):
What Went Wrong
The game was too complicated. Usually games have scores that are one layer removed from the things that happen in the game: if you kill an enemy and your score goes up, there’s one level/layer between game action and score number. Ideally you want your game to have no such layers at all as the player should experience the rewards and punishments directly, not through a point system. My game had a three layers deep score system (weapon cost leads to higher score increase rate leads to higher score)! With so much abstraction it’s not a surprise people didn’t understand it!
On top of not being intuitive, I didn’t spend much effort into easing the player into the game. I pretty much said: “here, take all these and have fun!”. A better approach would have been to have the player unlock different modifiers as enemies are killed, or have the player start with all modifiers possible and gradually remove them (which would be really on theme). There are a number of other ideas that would have worked better than just giving the player everything and letting him decide what he should use or not.
Technically, the game was too complicated for two days. While I managed to make it work, I should have had more time to polish it. Adding some neat shaders, playtesting, maybe trying for a better graphical presentation? I don’t know, I just felt like it would have been better if I spent less time working on the gameplay system and more time polishing. 50/50 for each is definitely not the way to go, I think.
The game looks bad. Again, I’m not an artist (at this point I’m feeling like I should spend some time learning how2pixelart) so I’m relying on squares. Many people can make it work. I’ve played lots of great games that also use only basic shapes (especially this LD, given the theme), but somehow I just don’t have the skills to do it like them… I need to work a lot more on my presentation!
While I was more prepared than in the last LD, I should have prepared even more this time. A lot of the first day was spent building a system that I could have build in half (or maybe less) the time. Since I decided to use box2d I spent a lot of time rewriting some wrappers and basic box2d stuff. I should just really make all this into a library somehow. I also didn’t really have a way of making music. Luckily, I was watching quill18’s stream and saw him do it, so I just copied it. He used atrk-bu.py + SchismTracker. I also didn’t read my previous “What Went Wrong” list beforehand. I repeated some of the same mistakes because of that.
What Went Right
I managed to finish the game as I had it in my mind. Again, lists worked to great effect. Although this isn’t that remarkable at this point, since I can probably, technically, finish a lot of 2D games I can think of in 48 hours. The problem lies in polishing and on game design. It’s hard because it’s super highly impossible to remove yourself from being a creator and putting yourself on the player shoes. You can’t possibly realize if something is gonna work or not unless you have some experience.
On that note, I also learned a lot of lessons! I explored some paths and failed, but I definitely have more experience now. Which leads me to…
Lessons Learned
If your game can’t be explained in a simple sentence, there’s *probably* something wrong. It doesn’t mean that it won’t work, it just means that it could be simpler. Also, people won’t read text. Don’t expect them to.
Presentation matters a lot. People will not feel compelled to play your game if the presentation isn’t amazing. This sounds obvious when I say it but it’s easy to forget. You’ve worked so hard on all aspects of your game that sometimes presentation feels secondary, but it is one of the most important things you can focus on. Don’t forget it!
Fail often. Suddenly the advice from Edmund McMillen in the video below makes so much sense. Only through failure you’ll have enough experience to know what works and what doesn’t. This further increases the value of things like One Game A Month and Ludum Dare itself. Make lots of games so you can learn a lot!
Community
The LD community is usually super fair and nice about their comments. I’ve mentioned previously how sometimes it gets too nice (i.e. feedback isn’t really feedback, it’s just people saying what they liked about your game, even though they may have disliked way more things), but there’s nothing I can do about this. Most people do try to give valuable feedback so it’s not so bad.
The one issue I’ve noticed on this particular LD was the cheer number of people who simply didn’t understand what they were supposed to do in a game. I’ve mentioned in the previous section how people don’t read text. That’s okay, sometimes I don’t really read text either and just jump in to try to play the game. But some games are really simple to understand and still a lot of people don’t seem to get it. A great example of this is 0 by Cosmologicon, which had this exchange in its comments section:
I’m really surprised that game developers have this much trouble understanding some simple games. I can’t really imagine what it’s like to release a game for real for thousands of people, only to have a huge number of them simply not get what they’re supposed to do. And it’s really annoying to play games that hold your hand too much too. So I guess, again, it’s a matter of experience in knowing how much should be explained and how much should be left as exploration to the player.
Conclusion
This was a great experience. I certainly learned a lot of stuff and took from this LD way more than from the previous one. If there’s one thing I should remember is that I should release more games. Of course, I’m just not gonna release some shitty games just because, but it helps to set deadlines (say, 2 months) so you have to experience having to cut stuff and having to work with what you have. Hopefully I’ll have more experience and I’ll be more prepared for the next one! See you there! Or not, I mean, any one of us could die at any point… That would certainly decrease our game making abilities.
see the real world).
OK, let’s just get this one over with. It’s dumb, but I laugh every time I play it. I promise that my other mentions will be less silly.
