{"author_name":"EnigmaBlade","cat":"LD #24","comments":[],"epoch":1346481180,"likes":0,"metadata":{"p_key":"51562","p_author":"EnigmaBlade","p_authorkey":"15076","p_urlkey":"87256","p_title":"Evoquarium \u2013 A Post Mortem Analysis of Design and Development","p_cat":"LD #24","p_event":"LD24","p_time":"1346481180","p_likes":"0","p_comments":"0","p_status":"UPD5","us_key":"15076","us_name":"EnigmaBlade","us_username":"enigmablade","event_start":"1345766400","event_key":"12","event_name":"LD24"},"text":"

\"Evoquarium<\/a><\/p>\n

 <\/p>\n

 <\/p>\n

 <\/p>\n

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.\u00a0 After finally giving in to myself at the last minute, I decided to give it a go and do the best I could.\u00a0 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.\u00a0 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.\u00a0 Nevertheless, I would give Ludum Dare a 10\/10, would do again.<\/p>\n

The Game<\/strong><\/p>\n

For those who haven’t played the game yet, you can find it here<\/a>.\u00a0 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.<\/p>\n

I have also continued development to greatly improve what I finished with at the end of the competition.\u00a0 You can find this new version and and watch for new updates coming out daily on my website<\/a>.<\/p>\n

The Design<\/em><\/p>\n

When initially designing the game, I had went through a couple ideas before setting on the current one.\u00a0 The first idea, which is still one of my favorites, was to make a game based around some concepts in Flatland<\/a>, specifically the concept of the number of sides on a shape.\u00a0 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.\u00a0 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.<\/p>\n

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, \"\"<\/a>and continued on my idea generation to come up with a much simpler design.\u00a0 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.\u00a0 In some ways, the current design reflects some of my original ideas.\u00a0 Most prominently, you are a simple shape with a certain number of sides who travels through a world and evolves by killing enemies.\u00a0 The basic mechanic for evolution of your character also carried over from my original idea.\u00a0 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.<\/p>\n

The largest idea I wanted to focus on is exploration.\u00a0 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).\u00a0 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.\u00a0 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.).\u00a0 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.<\/p>\n

I also wanted to give the game a somewhat retro arcade feel.\u00a0 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).\u00a0\"\"<\/a> 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.\u00a0 The style did cause some problems during development, which I’ll discuss later on.\u00a0 The audio was also an important element to the style of the game.\u00a0 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.\u00a0 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<\/a>).<\/p>\n

The Development<\/em><\/p>\n

To develop Evoquarium, I decided against the use of my own custom LWJGL-based engine in favor of Slick2D.\u00a0 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.\u00a0 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.<\/p>\n

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.\u00a0 With Evoquarium, however, I decided to try and overcome my artistic limits and create something with as little art as possible.\u00a0 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.\u00a0 The character rendering, which uses no external sprites or textures, was probably the most time-consuming part in development.<\/p>\n

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.\u00a0 The system works by using Slick’s \"\"<\/a>primitive rendering methods to draw to an off-screen image, which is then resized 2x and rendered to the screen.\u00a0 Although a very simple idea, implementation took much longer than expected.\u00a0 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.\u00a0 Each entity in turn uses two different images, one for the filled portion of the character and one for the outline.\u00a0 It is with this creation and storage of multiple off-screen images that all my problems were created.\u00a0 \"\"<\/a>I quickly learned that the creation of an off-screen image (FBO) takes a good deal of time, even for small images.\u00a0 My solution was to create a “bank” of these images before the game starts and continuously recycle their use for storing shape image data.\u00a0 This solution is present in the competition version of the game, which is very noticeable by the long load time.\u00a0 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.\u00a0 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.<\/p>\n

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;\u00a0 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!\u00a0 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.\u00a0 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!<\/p>\n

The Lessons Learned<\/strong><\/p>\n

I learned quite a few things from this experience, both in game design and programming in general.\u00a0 Here’s a short list of some of those lessons:<\/p>\n

    \n
  1. Come up with a bunch of different ideas and weed out the ones that are too complicated for the time given.<\/li>\n
  2. Learn the framework or library you are using before you start development.\u00a0 I spent the bulk of the first night getting used to using Slick, which could have been avoided.<\/li>\n
  3. It’s probably better to cut back on some of the prettification to focus on developing gameplay to a better state.<\/li>\n
  4. Lern 2 draw<\/li>\n <\/ol>\n

    I can’t wait to make another game for the next Ludum Dare in December! \":)\"<\/p>","time":"September 1st, 2012 1:33 am","title":"Evoquarium \u2013 A Post Mortem Analysis of Design and Development"}