So i completed my first ludum dare and i learned a lot. trough my “failure” so here are the lessons i learned in hope that i an whomever reads this will not repeat them.

1.Gamedesign should have been done ahead of time
Though i did have an idea it’s important to work trough a few ideas beforehand, especially when it comes to planning.
The main error i did was that i had like two hours at the start of the compo to shoehorn in the theme into an already existing idea and thereby making it too bloated.
The original idea i had was this helicopter sim in where you fly around shooting guns and rocket creating majestic explosions, destroying buildings.
But then came the theme “evolution”, i paniced and made up a story about a small mars probe that suddenly gained sentience and had to evolve itself by collecting parts from other probes sent to destroy you in order to survive.
What i should have done was to come up with a handful of base ideas that could each fit a few the final 20 themes, then plan each of them so that i the game will be made in time and that i know what kind of pieces i need beforehand.
Really if you have done the planning correctly all you need to do is follow the plan and do exactly as it says.

2. Keep up the phase
Anything not critically important  that takes more than 1 hour is not worth doing, seriously, i spent two hours on collision detection three on the terrain and at least 4 on making the bullets fly properly, not to mention setting up  the enemy spawning system and so on.
Now while reinventing terrain generation and collision detection is all fun in itself, that’s at least five hours i could have spent coding the AI, upgrade system and making more 3d models, all of which i now never got around to.
So note to self, next time if my toolkit cant do it or if i have to invent it, it’s not going to end up in the game at all.

3, Finish the game the first day.
After the first day i had my probe running around, terrain generated, camera working, collisions working and so on, that is to say not that different from the final product.
You will probably need at least 5-6 hours at the end to tidy things up and make it presentable which leaves you with like half a days worth of coding the second day, that is not a lot of time to code major parts of the game, not to mention if something goes horribly wrong and you have to spend time fixing it.
So if the game is not functionally finished the first day it will probably not be at the end of the second day.
If you do it that way you will have things to add instead of having to cut things from your design, not to mention more time to polish.

4. KISS
As in Keep It Simple Stupid, my game idea turned out to be pretty complicated, i mean there is a reason why a majority of games are 2D and pretty low fi.
And while i think i could have completed it properly given two more days, it should really have been done after the first one.
I think that if you want to keep it simple enough then imagine making an NES game with all it’s limitations.
So next time it’s either going to be a proper tile based 2D game or something like it.

5. Practice makes perfect
I have to say that i was pretty unprepared for this, although i once made a simple game in six hours this was compleetly different.
Before next time I’m going to attempt to train myself making a specific game type in a single day and you should too because that’s really what you have to work with, if it takes any longer than it’s not going to work and your design is too complicated.

6. Make sure your tools and procedures are up to date
I spent over an hour attempting to export a 3D model to an OBJ file, turns out that my modeling software doesn’t really agree with me that texture-coordinates are important, they are BTW.
What i should have done is make sure that i had a firm grasp on how to do the export properly.
Second mistake with the 3d models was that it utterly refused to export normal values which i also thought was important, so i had to go into a second application to generate those, in the end that was unnecessary since i didn’t have any lighting anyway (see, there goes the importance of planning again).
Third tool mistake was terrain generation, generating a flat plane with some random bumps in it shouldn’t be a problem, but it is if you have to do it from scratch, in the end i could just as well have made another 3D model and loaded it, but no i had to try to make it free roaming.
Well that failed and i was down another few hours and i was left with an impressively complicated construct using geometry shaders and a heightmap.

7. Choose your platform wisely
I chose windows using openGL and c++ which is pretty much the ultimate default choice for any game development.
That is for general game development, Ludum dare on the other hand is different beast altogether.
Don’t get me wrong, windows and c++ is really great, powerful and supreme in most regards, it’s also the platform i am mostly familiar with.
But it does have the slight problem with system bloat and you needing to basically code for every eventuality and hardware combination, which is good if you want to make a great game, but not in 48 hours.
So for the next one i might have to take the plunge into java or html5+webGL, either way it will have to run in a browser.
I’m just saying if it runs there it will run anywhere and i don’t have to worry as much about strange bugs popping up on other peoples systems.

8. Make it fun not good
Great gamedesign prioritizes fun, my initial game design idea was also fun, but not once i had to cut it down to size.
Always start with a very simple idea and work yourself up from that.

So those are the main lessons i learned, but on the bright side i did learn a lot of what my toolkit really needs for the next few versions, and that is really what i set out to do in the first place.

This entry was posted on Thursday, August 30th, 2012 at 5:33 pm and is filed under LD #24. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.