Entry

With the weekend behind us there’s finally enough time to write about our dev journey. Before hand we had chosen our technology stack: libgdx and Scala. Both were relatively new to us so, with a hard lesson learned during LD#24, decided to keep the game simple. We started the first morning brainstorming some ideas, such as a factory-simulator with 10s cycles and various running games. We settled on recreating an old classic with a new twist: gauntlet with a timer.

The pure basics were already laid out, but it still took an entire day to get familiar enough with the tools to get a solid foundation up. Some place holder graphics were scribbled into place. At this point there was nothing except a map and the player movement, with collision detection almost working :). No complete images survived this stage, the earliest screenshot I had stored already has final floor texture.

Crude wall assets, early weapon and player character

Day 2 continued with more of the basics getting set up: level transitions, loading, enemy logic, item pickups. We kept experimenting with the game play the entire time, tweaking variables and assets pretty ad hoc. The code quality also took a slight nose dive with “getting it done” taking priority. Before turning in for the night I had taken a stab at implementing the enemy movement, with poor results:

Experimenting with the UI

We quickly wrapped up major missing functions during the third day. We hadn’t yet decided if the game would feature random levels and never end, but decided against it. We implemented some auxiliary features such as the red potion to boost weapon damage, and spent the last hours before submission on level design and packaging the product. The video below is from early Monday, testing video capture.

It would definitely been nice to document the development process more to see the evolution of the game and our process. We did generate a video of the code changes in the git repository using gource. Documenting the dev process is something for us to work on when entering more competitions.

The finished product feels like a game, an aspect we especially wanted to concentrate on, with good controls and a clear progression. The goal of the game should maybe be more evident, and the lack of music and quality sound effects are something we should see to in future endeavors . All in all we are pleased with how it turned out, and how much we learned while making it.

Two days down, one left. We’ve used a lot of time on the project structure and coming onto grips with our technologies (scala+libgdx). But the game is taking form slowly.

Above is the result of late night coding, when it would most likely be better to just turn in for the night :).

So after a sleepless night we managed to package the game and enter the LudumDare Jam. All in all we are satisfied with what we put together, though looking back we could have prepared more with getting to know our tools better. XNA is a relatively painless way of creating games, although limited to Windows and Xbox.

We came up with the premise pretty quickly, cutting a few ideas early (creature breeder with arena battles, procedurally generated Metroidvania) due to scope and style. We decided on evolving the character itself. By collecting items in the world the mechanics for controlling the character would change, and the way you interacted with the environment would change with it. One example of this would be how at first you could only breathe in water, and later only air. A lot of this we ultimately didn’t have time to implement.

Due to time constraints the final dragon form was cut from the game, as well as several intermidiate forms (e.g. fins for better swimming, another pair of limbs for wall jumping and running). One of the key issues we had was time management. We had a lot of ideas, yet didn’t take into account how much time would be eaten up by learning things on the fly and tracking annoying issues. Also putting effort into things finally cut from the final build can be a little frustrating. Case in point the running cycle for the planned second final form:

Running cycle for a wingless dragon

So what lessons did we learn?

• Manage your time! Complete critical tasks first, leaving polish for the last day.
• Cut features aggressively and early. This helps with the first as you are concentrating on things that are going into the final build.
• Take the time before hand to practice the different aspects and pipelines of your chosen framework.

Most of these are very familiar to us from reading others postmortems from previous dares, but I guess some things you have to experience to actually know them. Now we have a much better picture of how much work can be done in 3 days, which should help manage the process in future compos.

Take a look at the finished game and let us know what parts we did well and what we could have improved.

Since the progress on the actual code is harder to show on a blog, here are a few art assets I’ve doodled up:

One form for our intrepid hero

On the code front we’ve got tiles, collisions and entities mostly done, next up loading maps of the levels.

So, after bouncing around some ideas of a breeder simulator and some other ideas, we landed on making a Metroidvania style of game. The idea being “evolving” a single organism by adding abilities, until you become a dragon. Cause dragons are the shit. One of us is working on the code and the other creating assets. With only a few hours behind us we already feel like we’re making good progress.

The idea in a nutshell

A repeating dirt tile

Two brothers from Finland, going to join in the Jam. Planning on using XNA for the development.