Before now, I had never participated in Ludum Dare despite hearing so many good things about it, especially over the years I have been following Notch’s development of Minecraft. After finally giving in to myself at the last minute, I decided to give it a go and do the best I could. I had a great overall experience getting back into game development after quite a long hiatus (over a year) of developing various tools, which are mostly for League of Legends players, and other GUI-based projects. The 48 hours I spent making Evoquarium were filled with some of the most fun, tense, and stressful moments I have had in quite a while. Nevertheless, I would give Ludum Dare a 10/10, would do again.
The Game
For those who haven’t played the game yet, you can find it here. It’s an arcade-style asteroids-type shooter where you evolve yourself with dropped “evos” to change various aspects of yourself in order to survive.
I have also continued development to greatly improve what I finished with at the end of the competition. You can find this new version and and watch for new updates coming out daily on my website.
The Design
When initially designing the game, I had went through a couple ideas before setting on the current one. The first idea, which is still one of my favorites, was to make a game based around some concepts in Flatland, specifically the concept of the number of sides on a shape. The idea was to continuously evolve the world around to a more “perfect” state, which means increasing the number of sides a certain shape has, an idea core to the social structure of Flatland. The enemies were to be more “perfect” shapes than you, while your goal would be to break through the existing social barriers by evolving yourself and the environment around you to be equal or more perfect than the current set of enemies, possibly even to the point of evolving out of the confines of the 2D space and completely shattering the social shackles of living in a world like Flatland.
But alas, I decided the design was waaaaay too ambitious for 48 hours as well as being unable to come up with core mechanics, such as the evolution of the environment aspect, 
and continued on my idea generation to come up with a much simpler design. I eventually settled on the current and very basic design: you run around a map, shoot enemies, and pick up their dropped evos to evolve yourself to the traits the killed enemy had while living. In some ways, the current design reflects some of my original ideas. Most prominently, you are a simple shape with a certain number of sides who travels through a world and evolves by killing enemies. The basic mechanic for evolution of your character also carried over from my original idea. However, contrary to the thrown out ideas, there are a couple that I came up with specifically for the new design, although not all of them got added or finished in the 48-hour competition version.
The largest idea I wanted to focus on is exploration. I have always found the exploration of large and new worlds to be extremely fascinating and full of excitement (one reason why I am so passionate about space and space exploration). In regards to game design, I wanted to encourage exploration of gigantic randomly and dynamically generated maps, and where each time you start up the game you get a new experience. My current focus of development is to create regions of the map that may affect your character in some way (such as decreasing movement speed or damaging over time) as well as generating enemies that have some specific trait in common (such as fast movement, health, shooting speed, etc.). Each region would also contain a mini-boss at the center (which is actually incredibly hard to find) to hopefully give a few mid-point goals for the player before facing the still unknown final boss.
I also wanted to give the game a somewhat retro arcade feel. The gameplay is very basic, top-down, and feels a lot like Asteroids (which I played on my calculator in high school ALL THE TIME). 
The graphics are also very simple: they’re pixelated and contain a lot of different colors, although keeping each toned down to keep the feeling a little modern. The style did cause some problems during development, which I’ll discuss later on. The audio was also an important element to the style of the game. Although I used the tools everyone else used for sound effects (in my case Bfxr), I feel they fit really well with the rest of the design. For the music, I wanted to emphasize the feeling of being only a small entity in the large world, so I found a piece of deep and ominous music that I think perfectly fit what I was going for (note: I did not make the music, I found it on this wonderful website).
The Development
To develop Evoquarium, I decided against the use of my own custom LWJGL-based engine in favor of Slick2D. Before the competition, I had only barely used Slick once before abandoning it to create my own engine (which was a hard decision to make), so I started out knowing almost nothing about the specifics on how to use Slick. Although this obvious drawback slowed down development in the beginning, I was eventually able to get going rather quickly with only a few minor hiccups down the road.
Because I am a programmer, I have almost no artistic abilities with images or sounds, so when developing games, I always lack in the all-important artistic categories. With Evoquarium, however, I decided to try and overcome my artistic limits and create something with as little art as possible. The final competition build of the game only used three images, sized 2×2, 4×4, and 12×12, and were used for the two different sizes of pickups and the bullets. The character rendering, which uses no external sprites or textures, was probably the most time-consuming part in development.
The character rendering system was designed to create a n-sided shape with consistent pixelation at any size without the use of external textures or sprites. The system works by using Slick’s 
primitive rendering methods to draw to an off-screen image, which is then resized 2x and rendered to the screen. Although a very simple idea, implementation took much longer than expected. Not knowing exactly how the continuous rendering of primitives would affect performance, I originally developed the system to create and store pre-rendered off-screen images for the player and each enemy. Each entity in turn uses two different images, one for the filled portion of the character and one for the outline. It is with this creation and storage of multiple off-screen images that all my problems were created. 
I quickly learned that the creation of an off-screen image (FBO) takes a good deal of time, even for small images. My solution was to create a “bank” of these images before the game starts and continuously recycle their use for storing shape image data. This solution is present in the competition version of the game, which is very noticeable by the long load time. It was only after the competition ended that I realized the system only needed one off-screen image which could be drawn two by the player and each enemy at render time. This fix to the system greatly decreased the loading time of the game and the possibility of a number of serious bugs and memory issues down the road.
After releasing the game, I feel that I was not able to accomplish what I had originally planned for the game, but did a fairly good job for the 48 hours I was given; never got to make a good non-developer looking UI nor did I get the chance to expand on the idea of exploration, but everything else looks great! I have gotten great feedback and have fixed a lot of the problems people were having: turning speed too high, attack sound effect volume too high, etc. I look forward to getting even more feedback on how I can improve this game and any others I may attempt to make in the future!
The Lessons Learned
I learned quite a few things from this experience, both in game design and programming in general. Here’s a short list of some of those lessons:
- Come up with a bunch of different ideas and weed out the ones that are too complicated for the time given.
- Learn the framework or library you are using before you start development. I spent the bulk of the first night getting used to using Slick, which could have been avoided.
- It’s probably better to cut back on some of the prettification to focus on developing gameplay to a better state.
- Lern 2 draw
I can’t wait to make another game for the next Ludum Dare in December! 
