My first LD, what I’ve learned

Posted by (twitter: @OhGodMikeW)
April 23rd, 2012 1:52 pm

A long time ago when I was a little kid, I was fascinated by games.  I still am, but I think it’s safe to say that if games hadn’t entered my life at such a young age I might not love games like I do now.  Maybe it’s because of this that I’m so drawn to the indie game scene.  Most indie games are very reminiscent of the older generation of games that they usually spark a nostalgia factor in my heart when I play them.

Despite that, I was only drawn to indie games very recently.  Before about a year ago, I would spend my time playing around with big name engines such as Source or UDK and I would dream of some day working with a huge team on an AAA title.  Things have changed.  I still want to work on games, that much is true, but indie games have really started to cling to me and it seems like I’m falling in love with making these mini adventures and being able to really be as creative as I want.  I’ve yet to really break away from using big 3D engine suites, but I plan to soon.

I learned of Ludum Dare when #22 was going on through this guy who gets really really drunk and reviews 100 of the games.  I checked out the website, played a few of the games, and that’s where my addiction started.  I ensured myself that I would join the next competition, and here I am.  Since this was really my first time making a small game like this, and not some sort of mod for a pre-existing game, there was a lot to learn.  A lot more than I thought, at least.  It was a massively fun and educating experience, and I’d like to share some of what I’ve learned to you guys.  Some of this you may know, some you may not.  Either way, it’s always good to review and keep fresh on things.  So here goes.


Brainstorm, even if you already have a great idea

When I started my project at 9pm on Friday, EST, and I saw the theme of Tiny World, my world froze.  “Tiny World? What the heck am I going to do with Tiny World that isn’t super cliche?”  I was stuck on this problem for a while.  I took out my sketch book and my whiteboard and started to jot down any ideas that came to mind, even if they were really crappy ones.  Sometimes, ideas would overlap and I found I could combine a few to make a slightly better, albeit also not-so-good idea.  But, after about 5 hours of on and off brainstorming, I came up with an idea that I thought was it.  The deal breaker.

It wasn’t until after I had started prototyping my golden achievement of an idea that I realized the worst thing a game dev can come to realize.  My game wasn’t fun.  Actually, it was beyond not fun.  It was grueling.  If I can’t stand my own game, how will other people ever have even the slightest chance of liking it?  So I took a deep breath, moved all my coding to my “old code” file, and went back to the drawing board.

This is an important thing to realize: Your first ‘good’ idea usually won’t be the best.  If it helps, think of a few good things and sleep on it.  Come back to it, see if you like it.  If you say no, brainstorm more.  If you say yes, brainstorm more.  The more ideas you have, the more you can put how ‘good’ your idea will be in the scope of others.  Don’t spend too long on this step, but don’t stick to an idea that you’re not 100% sure of, either.



This is usually ingrained in most programmers heads, whether you’re writing a game or an operating system.  Surprisingly, however, some people don’t know about this approach.  The key to easy breezy beautiful programming is to start off small.  Build your game in the least amount of code and resources you can first.  This is called prototyping.

Say you’re making a platformer, and you have all these crazy ideas about the graphics, sounds, transitions, and more.  You’re head is bursting with ideas.  You just want to jump right in and start coding the cool stuff, right?  Well, don’t.  It can get confusing fast and if you somehow mess up one of the basic, core fundamentals of, say, jumping on platforms, you may get bugs that will then carry over to every other facet of your game.

Now, let’s say you start off small and building only the barebones.  You made a box that can move and jump and detect collisions.  Good! You now have the core of a platformer, and not only will it be super easy to add in auxiliary functions in order to make the game even cooler, but you can even save the code you have as a template for future platformers you might want to make.  Even if you scrap this entire project and want to start fresh, you can start from your ‘basic platformer’ code and go from there instead of re-writing everything because your platformer code is lost in a jungle of unorthodox, unordered functions.  You just saved yourself a bunch of work!

This approach will also save you from getting stuck in a ‘chain’.  You know what I’m talking about, because every programmer has done it whether they like to admit it or not.  Sometimes it’s unavoidable, but it’s something you want to avoid if able.  Getting stuck in a chain is when you write a function, realize you need another function, write that, realize you need another function or two for that function, and it keeps going on like that.  If you start writing “void GoBackInTime ();” before you write “void PlayerJump();”, you’re going to find yourself stuck in this problem quite a bit.  So save yourself a headache and prototype basics first, then build complexity later.


Use the language/engine/framework that works for YOU

A lot of newer programmers get stuck before they even enter the gate.  There seems to be this huge emphasis in the coding community on using the right type of programming.  This is a huge mistake, as many experienced people will tell you.  Back in the day, picking a language was a big deal because they weren’t quite high-level material.  One language would be used for one thing.  You wouldn’t usually see people using html to write a game back in 1990.  But this is 2012, and programming languages are much more advanced and able to do all sorts of different things.  The same goes for engines and frameworks.

Knowing this should clear your head.  Stop getting stuck on what’s right, and start using the one that you enjoy.

I was raised on ANSI C, so it was easy for me to decide to make the transition in to C++ and now in to C#.  I was very hesitant to do so at first, however, because a lot of people were pressuring me to code everything in Java because it’s ‘easier’.  So I sat down and thought to myself, “What’s better? Coding in a language I know well but may have harder syntax, or learning a completely new language and being unable to code as well as  I should?”  Easy answer.  I stuck with the C family.  To make this short, try out a lot things at first.  Pick what you like using.  Stick with it. Get good at it. Then it won’t matter what was the right choice’ was because you’ll be able to code whatever you want in the language you like anyways.  All that matters at that point is that you enjoy yourself.



Preferably let others playtest for you.  The importance of outside playtesting is massive.  Do you remember in middle school how you would write a paper, bring it in the day it was due, and the teacher would make you swap your paper with an other kid to proof read it?  Yeah, there was a reason for that.  When you write a paper and read it over, your brain often times skips errors because it already knows what you’re trying to say.  In other words, your brain replaces errors on the paper with what you meant.  It’s just how things are, and there is very little you can do to avoid that except for one thing.  Can you guess what it is?

That’s right, outside playtesters.  In my case, I went on a teamspeak channel that I often and posted a link to my game.  Right there I had about 5 people who have never even seen my game before ready to give it a go.  The feedback was immense.  Since they were new to the game and can focus only on playing it, they’re able to see errors and faults in my game that I had overlooked or haven’t even thought of.  You want your game to appeal to the people who play it, right?  Then why not give them the game and listen to their feedback.  It’s simple for the amount of feedback that you get, and people are usually happy to try out a game in the making.  It doesn’t take long to do, and you can do work while they’re playtesting.  Easy peasy.


I’ve learned a lot since in the 48 hours that I participated in Ludum Dare.  More than I could ever type in a single blog post.  These, however, are my main nuggets of wisdom so take away what you can from this.  I really enjoy this indie game dev scene, and I’m here to stay for a long time.  If you ever want to contact me and talk about game dev or anything else, my twitter is @OhGodMikeW and my email is mike @ superofficial .net.  For now, to end this post, I’m going to shamelessly plug my Ludum Dare entry.  Try it out, and give me some feedback good or bad!  Everything helps.


My entry is a point and click game called World Vacuum.  It’s a no-lose no-win game where the goal is to just get the highest score possible, and help out our friend Rick the cosmic deity of course.  Basically, Rick is in charge of putting together the physical portions of the universe.  He’s pretty clumsy and spilled all the tiny planets before they were ripe enough to be put out.  I like the idea that ‘tiny’ is relative.  Bugs may be tiny to us humans, but we’re also very tiny to, say, the Earth.  The Earth is tiny compared to the galaxy, and so forth.  So feel free to check it out and let me know how you like it!



2 Responses to “My first LD, what I’ve learned”

  1. Vilborg says:

    Sage advice. I’ll be sure to try out your game.

  2. spooks says:

    Great advice. especially “getting stuck in a ‘chain” this happened to me a bit in the past LD event. Lucky I was able to step back and figure things out before getting to lost in it (still sucked some hours away though)

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]