Posts Tagged ‘asteroids’
My first Ludum Dare entry, and the second game I’ve ever made! I’ve decided to go for a game with very simple mechanics, but is difficult as hell to win. While most people chose to go for a minimalistic art style, I’ve decided to keep the controls (only up/w and down/s) and actual gameplay minimalistic instead. It seems extremely impossible initially, but after awhile you get the hang of it.
You control a spaceship that you move up and down to avoid getting hit by asteroids. Minimalistic yes? You have 5 seconds of small numbers of asteroids, then 60 seconds of full on walls of asteroids before another 5 seconds of calm if you make it that far. If you make it through all that, you can beat the game in a mere 70 seconds. Trust me, it isn’t easy. I swore profusely while testing the game.
You are the first test rocket to escape earth’s gravitational field! Unfortunately, the snarky people who made the rocket never made any way for you to turn the thrusters off, forcing you to have to dodge your way through an asteroid field.
I wrote the game from scratch in Java, using knowledge from my previous game to help me. I followed similar code for things like the game loop, the sound loading and playing, and the resource management. Coding was done quite fast as I already knew how I should structure the engine, and I hard coded a lot of things to make the progress faster. I though this was a great decision in the end to avoid over optimisation as it really helped me pump out the code quicker and leave me more time for the other things.
The most trouble I had in this project was deciding what game to make, then actually starting it. Once I actually made some progress and knew where I was going with it, I flew through it quickly. I am really proud that I managed to make it in the designated 48 hours.
So now that Ludum Dare #23 has finished and the dust has settled, I guess its time to write a post about the post mortem and give some insight into my experiences with making a game in 48 hours…
Here is a diary of the major milestones of my 48 hours highlighting interesting points of my development:
I rushed head first into creating my voxel engine, I was pleased with the announcement of the ‘Tiny World’ theme, it seemed as if this theme was perfect for what I was creating… My mood was great!
Still driving ahead with the voxel engine, encountered a few problems with how the triangles and meshes are rendered, so had to go back and improve my rendering engine. Spent a good portion of these hours optimizing how triangles are pushed to the renderer and adding support and features for mesh rendering with display lists and vertex buffers.
Started playing around with different configurations for meshes/chunks/regions… came up with some interesting implementations of how a voxel world could look (sphere worlds, cube worlds, trees). I made sure to leave all configuration/ideas in the code so that I could easily come back to anything which worked.
Added support for cubes/voxels with different textures. Using a texture atlas to store the different textures. i.e. (grass, stone, wood, magma, etc) This would be important since I wanted to make a world that could be modified by using different cube types.
Towards the end of day 1
Hit a wall with regards to what my final outcome was going to be… I did have some original ideas relating to a flat, cubed world with tress and houses that you walk around and do stuff as a player, but nothing really inspired me in that respect without completely ripping off minecraft functionality (which I did NOT want to do).
So I went to sleep and hoped to come up with some neat ideas in the morning.
I woke up with renewed vigor and some thoughts about a different direction that my game could take. I decided to make it more abstract and not have a player in the world or have any direct user control, instead focus on world destruction and voxel effects.
Day 2 general
The bulk of day 2 was taken up coding effects and voxel related gameplay. I created asteroids and a layering system for my planet, exploding blocks and effects of asteroids crashing into the planet. The vaporize and terraform effect was actually something which came about accidentally, but I liked how it looked so decided to keep it in and make a gameplay mechanic for it.
This period was pretty crucial for me, I was rushing and coding gameplay elements really fast, I had a feature idea and once I got it working I moved onto the next thing on my mind. Asteroids, world vaporize (terraform), exploding chunks of the world, world rebuilding. I needed to make a full game cycle so I decided to add a timer that would ultimately drive the gameplay (destroy the world within the time limit).
I had finished the gameplay that I wanted. Next came the hard part of making it usable and playable. Having a lot of functions that are bound to keyboard keys is no good when you want other people to play your game and enjoy it.
I started to code the game flow:
Start menu –> enter game –> game timer –> score screen –> restart.
Added basic HUD and menu. i.e “Press SPACE to start/restart” and a scoring system.
My plan for the scoring system was going to be more complex with multipliers and additions for which super moves you used, but I didn’t have the time to make this work, so stuck with a simple score and time multiple.
The HUD and user interface needed work, I added these features faily easily but they were basic and static. So I started working on timings and polishing the interface. Flashing “Press SPACE to start/restart”, score screen with accumulating score. Timings and delays on the game flow to add additional polish. For example when you destroy the world, the score screen doesnt instantly popup, it has a time delay, or when you press to restart the game, the game waits until the world is rebuilt before allowing player control and starting the time. etc. This polish and attention to the small details is what makes your game stand out and feel like a proper experience, rather than a load of features cobbled together.
This last hour was mostly taken up with preparing a release package, zipping up the projects and source and testing to make sure a download of the source and executable would build and run, etc… Faily boring stuff but it does take time. I noticed a problem with absolute paths in my Visual Studio project, so had to rebuild a whole new project solution to fix this… luckily my project solution didnt contain too many header and cpp files.
I tested my package, uploaded it and then created an entry on the Ludum Dare website… then sat back and had a rest.
My entry can be seen here:
WHAT WENT RIGHT:
- Had great momentum from the start – I was able to put off the design and gameplay decisions till much later, since I had a lot to code from the start, having decided on a specific rendering engine.
- Used my own personal engine – Since I was using my own 3D/OpenGL engine, I knew exactly what I could do and how to do it.
- Voxels and cube art is great for programmers (and anyone who isn’t an artist) - Art was always going to be a problem for me, but creating stuff in 3D mitigates that problem slightly and creating stuff purely with voxels actually looks great with NO art whatsoever (See minecraft )
- Got lucky with the theme – Seriously, I couldn’t have chosen a better theme for a voxel based game if I tried. if the theme had been something like ‘Evolution’ or ‘Discovery’ or some other abstract concept then I don’t think my game would have turned out half as good as it did!
- Got involved with the LD community – I really enjoyed looking at the other users entries on the LD website and also posting my own progress and hearing feedback and comments from the community. Nothing is more rewarding that seeing other people’s efforts and encouragements from the community.
- Self documentation – I think I did a pretty good job on documenting my progress, taking screenshots and uploading videos to youtube. I even enjoy looking back myself now and seeing the progress that I made during the 48 hours.
WHAT WENT WRONG:
- Gameplay – I left most gameplay decisions until the 2nd day. After I was happy with my rendering and voxel engine I actually spent a good hour or so scratching my head as to what to do next.
- Focusing too much on the rendering/engine – I was torn between wanting to make a really optimized re-usable voxel engine, and adding in gameplay features. At one point I had to physically stop myself adding voxel engine features and rendering optimizations to force myself to think about gameplay and mechanics. I could have quite easily spent the whole 48 hours making a voxel engine…
- Trying to do too much – I had far too many ideas that I wanted to try out and not really having a clear design goal or making any gameplay decisions at the start meant that I was fragmented when I wanted to start making something that would be playable.
- Memory leak! - I found a major bug (memory leak) in my voxel particle renderer about 8 hours before the compo was due to end. I was leaking memory quite badly when creating and destroying particle effects that I HAD to fix. This took up about 2-3 hours of valuable time towards the end of the 48 hours.
- Basic user interaction - It is really hard polishing a user experience, so I ended up just putting a couple of buttons in for the special moves, not the most elegant way of coding gameplay features
- Sleep! - Don’t even bothering thinking that you can work solid for 48 hours, it is just not possible. It’s counter productive to lose ANY sleep and even just trying to do one all nighter is going to be detrimental to your progress. Yes you are going to probably stay up later than usual and once you are in the zone its hard to leave things to go to sleep, but if you are staying up into the early hours of the morning and going to sleep before it gets light outside, I would say you are doing something wrong.
- Prototype FAST - 48 hours goes really fast, if you are spending a lot of time on a feature or idea that just doesn’t seem to be working, move onto something else. Don’t waste time flogging a dead horse.
- Know your tools/code/engine – Since you are going to be creating something SUPER fast and with no time to spare, you really need to know what you are using. It helps if you know exactly what your engine is doing, right down to the individual function calls and rendering details. You will spend far less time fixing bugs, debugging code and trying to figure out what is going wrong if you know your engine/code inside out.
- Make decisions before the competition starts - I think I can attribute a lot of my success to this point. Since I was prepared before the theme announcement and was ready to start programming the instant the 48 hours started, this helped me a *lot*. I could have took this EVEN further by making some gameplay decisions first as well as deciding on the style of my game.
- Make the theme work for you. – (This is related to the previous point) Already have an idea of the sort of game you are going to make and then just adapt it to suit the theme… It is no good having no idea about what you are going to make and just trying to come up with a game that perfectly suits the theme. You will waste valuable time thinking and designing when you could be coding!
- Polish what you have – Personally I think that a well polished, smaller scope game that does a few features really well, is much better than some attempt at a game that has lots of features but doesn’t implement any of them particularly well. LD is a time to create something small that shows off something cool in a neat little package, not create the next big blockbuster.
Overall I had a blast making a game in 48 hours and taking part in my first Ludum Dare. I am pleased with my final outcome and even surprised myself with what I made. I now have a 3d voxel engine that I didnt have before I started the LD48 and don’t doubt that I will be using and improving it from now to create even better voxel games.
Thanks for all the support guys and see you next time.
So here is my finished entry for LD #23.
I managed to do most of the stuff what I initially planned. I didn’t code all the gameplay elements that I wanted but in the end I figure out that 48 hours is not a lot of time for a game with big scope, especially if you make a voxel engine for the best part of the first day!
Here is a video showing off my game playing:
I will be doing a post mortem post soon and trying to capture a lot of the stuff that is still fresh in my mind.
Overall I had a great time and will definitely be entering future Ludum Dare compos.
Just a quick test to see how collisions and blocks exploding will work…
Considered doing something for the compo, but kept getting into other stuff (fun stuff, important stuff, interesting stuff) so time ended up running out. I decided to make a mockup screenshot instead, of something weird that could have been. Maybe. Anyway, behold:
Oh, I also happened to make an asteroids game during the compo… didn’t mean to do that, but technically I guess it could have been an entry. Not quite weird or unexpected perhaps, but at least it’s asteroids. Windows-only.
Now where’s the Inquisition game? Me want play!!!