devlog four - Ludum Dare #29 Postmortem

For Ludum Dare #29 (Beneath the Surface), I made a little thing called Infantile Oceanic Feeling.

I'm going to say that I failed to make a game. I submitted something, but it definitely wasn't a game! So here's a breakdown of what I did well, what I didn't do so well, and what I'll do the next time around.

(The following instagrams have nothing to do with the sections they appear in.)

What I Did Well


I've been incrementally improving my personal base project with every project that I do. It's a framework I call Skeleton, and it serves as a springboard for all my game projects.

It ties together a number of different tools that I use for work, and sets up a generic architecture that I like to use for my games. One of the tools is a procedural mesh class for simple shapes, like quads and wedges. Another is a "Settings" tool, which is a system that acts as a project-wide repository of variables and functions. The values are stored in prefabs and instantiated whenever called upon in a scene.

There's also a library of pre-written simple scripts, which include things like a screen wrapping script, a simple rotation script, an HSB color script, a script that handles the instantiation and parenting of new objects, etc. Being able to simply drag and drop a pre-existing script makes development that much faster. Even if I could simply rewrite any of those scripts fairly quickly, the time saved by not having to adds up.

In addition, Skeleton comes with a basic hierarchy setup, because I've found that I tend to prefer organizing my scenes in certain ways, in terms of gameobjects with game logic scripts, gameobjects I consider the "stage", and menu and hud objects, which I generally put in the same scene.

I can't say that Skeleton represents the cleanest, most efficient, or safest way to develop a project, but it's fast and getting faster. And with each new game I try and make the scaffold a little better, whatever the flaws of the moment are.


In this particular project, that incremental improvement has really shone through in how my tweening and animation scripts are coming together. I was able to fix some major bugs and improve the architecture of that particular subsystem quite a bit during this game jam.

What I'm doing, in essence, is creating a much simpler (though less extensible) version of iTween for my personal use. It allows for a lot of one line animation commands that use the Penner ease types and uses polymorphism to cover all my usual use cases. Again, sacrificing general use for speed in implementing things my way.

I'm also constructing an easier to use Lerping class that takes a lot of unnecessary keystrokes out of Unity's current lerp function calls.


I think Infantile Oceanic Feeling did a fairly good job of wrangling colors.

I had a base rainbow palette of seven colors (chosen by varying hue, but keeping saturation and brightness the same, which works like magic as always), and made heavy use of color interpolation between neighboring color nodes on that palette. I liked the dynamic but subtle variation that created.

I think it was particularly effective when those neighboring color nodes were used in single entities. For instance, the petals that drop from level to level explode in radial bursts, but each burst is limited to a set of colors found in the lerping from one color to a neighboring node.

Cool Random Algorithms

Doing a game in a simulation genre, where the particular lifeforms all have different behaviors and appearances, meant that I got to experiment with a bunch of different self-contained systems.

So I got to work on a number of neat little things. A flocking algorithm for the fish, a fractal algorithm for tree growth, lots of sine-style animation for waves. It was pretty fun messing with all those things.

I also got to work a little on player interaction details, which I'm finding to be more and more important in my game development philosophy.

What I Did Poorly

No Game Idea

This was the major issue with this particular Ludum Dare experience. I spent far too long unsure of where my project was taking me.

This was absolutely the reason I didn't finish a game, and I think it was due to not spending long enough brainstorming. I did spend an hour thinking up different ideas, but I shouldn't have stopped once I had an idea that I liked. Nor should I have assumed that an hour was long enough.

I had stated to myself that I'd plan things for an hour, and run with the best of what I had after an hour. What I should have said was brainstorm for an hour, and then brainstorm for however much fucking longer it took until I had a skeleton of a game design ready.

Not Enough Thought re: a Simulation Game

Once I did decide on doing a simulation style game (maybe a day and a half in...far too late for what I had in mind), I then spent far too little time planning out exactly what I'd do with the elements of the simulation.

This isn't the first simulation game that I've tried to do during a game jam, and I have yet to actually complete one. However, each time I think I have a better idea of what I'm getting at.

I think my main issue is not designing tight enough individual behaviors and interactions. I should worry less about how the whole simulation is going to work out, and spend more time tinkering with the individual components of the simulation. Then, sit back and let the complex systems come about emergently.

And in order to do that, I should think a little bit harder beforehand about what I want those individual components to be.

Case in point, in Infantile Oceanic Feeling, I never defined abstract components for, say, a thing that could be eaten or a thing that absorbed energy. Everything was essentially separate and/or I was using cannibalized pieces of lifeforms for use in other organisms that needed a similar feature.

So, on the spectrum of planning versus doing, I am currently far too into the doing side and need to pull it in a little bit.

Put Off Fundamental Parts of the Game Loop

Now, I actually wasn't too bad with this. I started getting the little menu/tutorial/application flow in fairly early, and polished it off well before the deadline.

However, I neglected to concentrate on game flow. I didn't connect the disparate parts of what I did develop into a cohesive experience.

During the development of a game, it's always tempting to start developing any one subsystem and then just go wild polishing it or experimenting with it. I think that I often went down that rabbit hole, and neglected to make certain that I had something that stood on its own, as a game.

Too Little Separate Scene Development

After Ludum Dare was over, I kept tinkering with my fish flocking algorithm (which hadn't made it into the game). At one point, however, I decided it would be easier to just work with it in a separate scene.

Of course, when I tried to do that I found that there the architecture was a little too tightly coupled to the game script and other associated scripts, and it required a bunch of refactoring to get the fish flocking working independently.

In the future, I'm going to make it a point to focus on adding subsystems in piecemeal, and making sure that they can run independently, to a degree, in separate scenes.

What to Prepare for the Next Jam

A handful of takeaways:

1) The singleton heavy architecture that I use (with the prefab Settings all being singletons, and the main game class being a singleton with a bunch of referenced controller scripts) is very convenient, though not without its dangers.

However, writing references over and over in getters is kind of annoying. So I'm making a class that derives from MonoBehaviour ( calling it DreiBehaviour ), that will hold cached references to things like transform, rigidbody, renderer, etc. as well as to the settings and controller scripts.

Also, cleaning up the animation and lerping helpers.

2) For the next game jam, you do not execute until you've got a solid game plan. You don't need a stupid game design document, but you do need a more detailed document than just a collection of one prettyrejected game ideas.

3) The application flow development timing went well, and I got that finished. The game flow, on the other hand, was definitely lacking. I need to tweak that tendency to dive too far into polish.

Granted, it is important to have good looking things in a game, but they should never come at the cost of a game.

4) I'll also make sure to practice more separate scene development.

Andrei Marks

Read more posts by this author.