Post-mortem: One of a Kind

Posted by (twitter: @ddrkirbyisq)
December 21st, 2011 10:03 am

Well, the dust has settled, so it’s time to do the good ol post-mortem writeup for my game, One of a Kind.

I actually have quite a bit I want to say, so I’ll probably be splitting this into two separate posts.  This one will have the basic what went right and what went wrong and what I learned, etc., while the other one will be longer, more ranty, and more of me expaining my development process, how the game came about, and some comments on the levels, art, and music.

Anyhow, without further ado:

What went right

Choosing an easy-to-use framework.
Although actually deciding what to use was a whole separate issue (more on that in “what went wrong”), once I settled on using C# with, coding went really smoothly for the most part.  I just really like coding in C# with Visual Studio…it’s fun, there’s nothing that bugs me about it, compile times are super-quick, it makes a lot of sense, and when I screw up and run into a crash, I can debug it in almost no time flat.  It’s just a really nice language to work with.  Granted, I haven’t worked with other things like Python, Flixel, Unity, etc etc much so I don’t know about the other things out there, but I acn say for sure that I’m super-thankful that I chose C# over C++ with SDL, which was another option I was considering.  I’m sure that I would have just run into some stupid thing that would take me a long time to debug, or I’d have to think really hard about how I want to structure my game engine and who takes ownership of the allocated entities and you can’t delete them yet because they still need to do things, blahblahblah.  It’s just simpler in C#.  One small caveat is that I hadn’t actually used before this, but luckily it turned out to be really straightforward (90% of the time, at least), and despite the somewhat lacking documentation (compared to vanilla SDL, at least), I was able to do just fine.

Messy Coding.
Now, don’t get me wrong here…I am a programmer who really, really places code elegance above almost all else normally, but when it comes to Ludum Dare, that totally just goes out the window.  The trick is to know what you can make messy and what you should refrain from making messy.  Most things you can safely get away with making messy because you know you’re not going to have to look at that code again.  But things that you -will- have to work with again, shouldn’t be quite as messy.  In any case, I had a whole bunch of public static variables, and even worse, I just intersparsed a bunch of them throughout the class, probably right before the function that uses them.  So it looks kind of terrible, but it streamlined the process and I think I struck a very happy medium where I didn’t go overboard on messiness to the point where it caused any issues.

Mood and atmosphere.
When I saw the theme “Alone” I knew that it was more of an atmopheric theme, and didn’t really give you any game mechanics or anything right off the bat.  And I knew that making a 2D platformer would let me create the mood I was going for, so I did that.  After that, it didn’t take much brainstorming to come up with the core mechanic that would fit the theme.  In any case, even at that point I already kind of had a vision in my head of how the game would look, feel, and sound (this was probably heavily influenced by The Company of Myself).  And everything including the art, music, even the narration of the instructions, was informed by this mood/atmosphere goal.  In the end I think this is the area where my entry shines and it all came together really well.

Time Management.
It was a great feeling to be a couple hours away knowing that all that was left was basically just some more levels, packaging, and some finishing up.  I already had my concepts in, my gameplay in, and even the music and sound and art style was all in.  I had even already programmed the ending in–I just needed a way to trigger it.  So there wasn’t any real rush to finish any features when it was coming down to the wire.  I also found that it was nice to work on level art and such other things while you were stumped trying to come up with new puzzles or mechanics, so you wouldn’t waste time.

What went wrong

Oooh boy.  Yeah, getting this thing distributed was (is?) way more of a pain than I would have liked.  It’s not like my usual C++/SDL setup where I know exactly how to make things work on Windows, Linux, and OSX with the least amount of additional dependencies.  This is C# with Mono, which…well, is already just asking for trouble in the first place.  Even my windows build ended up requiring the .NET framework, so I had to recompile using Mono, and even after that I stupidly forgot to include a .dll file.  The Linux and OS/X battles were much tougher to wage, and even then only partial victories have been won.  I guess I can see why web entries are so popular.  Anyways, the bottom line is that even though I knew that C# with would run in a development environment on all three platforms (I tested that as my bare minimum requirement for choosing the language), I hadn’t had any experience distributing using this framework, so that was a pain.  Of course, I could have figured it all out earlier, but…

Being unprepared.
…I didn’t because I came into things just totally unprepared.  My initial ideal plan was to do a warmup game the weekend before LD, use that to decide how good of a framework C# with actually was, and figure out how to port it to Linux and OS/X.  If it didn’t work out well, I might even have tried to make a test game in pygame, as that was another one of my possible choices of framework.  Unfortunately, real life, christmas letters, finals, and everything else happened, so I was stuck not having had time to do any of these things beforehand.  I had -barely- done enough work to decide that C#/ was a “potentially okay” way to go.  On the plus side, I had done some good reading and thinking about fixed timesteps and framerate stuff, so I didn’t waste any time during the actual compo thinking about that (I ended up using a fixed timestep, and not limiting frame rate…I don’t think lets you use vsync).

Puzzle design.
This is the one that had me banging my head against the wall.  One bad thing about coming up with a new puzzle concept is that you have no idea how interesting or not interesting it is, and you have no idea what kind of puzzles are even possible, let alone how to design good challenging ones.  So I definitely spent long chunks of time just trying to think of puzzles that I could create using the base mechanic.  And I think this is the weak point of my entry too–although the puzzles aren’t bad, they aren’t -good- either.  I think my friend said it well when he said there were never any “aha!” moments; it was more just going through and deciding what to do next.  I liked the fact that I came up with the reflection concept, but unfortunately that was so late in that I couldn’t really flesh it out with more levels.

Overall, how did I do?  Fantastic.  I’m super-pleased with my end result, and really happy that I was able to actually make a 2d Puzzle Platformer with this kind of style.  It matched my vision almost perfectly, and is just really good at cohesively establishing a mood.  And I love how polished everything in my game is–it doesn’t look like it was just thrown hastily together with simple placeholder art.

What did I learn?  hmm…well I learned how C#/ tends to work…easy development, “possible” to run cross-platform but really more difficult than you probably want it to be.  Next time perhaps I’ll try a web game…


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]