8 takeaways from inspiration dave

Edited on 8/10 to prove this is me!

My platformer was sort of finished in early March, but it took through yesterday to get it sponsored, do some fixing and finally release it. I learned a few things, most of which are, well, obvious, I think. Maybe you can glean some insight from this too.

1. Do a mockup of your game’s graphics. While I did a few of these, I never did a very serious one.  You’ll be able to tell whether your player is too small, how everything fits together visually (for the most part, sans gameplay). In any case, this will prevent problems like I encountered with the character being too small in the final game. And having to zoom the game in, but getting some ugly aliasing because there was no fitting power of two…oops. The best (well, not really) comment I’ve received is “this is like looking at a burnt muffin.”

2. Put out demos, and often. No one’s gonna steal your fucking source code from a demo when you’re unknown. I was a little paranoid on that, but I shouldn’t have been. (I’m paranoid in general, but that’s different..) Letting people give you constant feedback creates a nice loop where you can find out if a certain game mechanic won’t work, and before it’s “too late” to change because it’s become so embedded into the game itself. Anonymous (relatively) feedback is incredibly helpful. I had trouble with the game design for the levels. Standalone the levels are okay but the goals are sometimes not very well thought out – w.r.t. what exactly the player should be doing, the disparity in unlockables and needed skill, etc. For example, you can’t unlock things (except the normal set of 27 levels) unless you collect all notes and do a speed run simultaneously. Perhaps I should have put a tier in between – one for between beating the stage, and getting the time medals.

3. MAKE YOUR FRIENDS PLAY MORE.     And watch.  And then make them play more. You’ll learn a lot about what works. I did this, but not enough. You have no idea how much I’m groaning now, watching friends struggle through some stages, comment how they didn’t realize a feature existed, etc. I think this applies to well, any game’s postmortem for a newcomer.

4. Work longer on the music, even throwing away something if necessary. I was surprised at how hard I found it to throw away a track that wasn’t really 100% working. Rationalizing it with “Well, I spent 5-10 hours on that song…I should move on.” Annoying music pisses people off. Granted, I’m relatively new to writing music, but I’m learning how to get better in this respect. Perhaps more planning is in order? I would sort of just spit out a tune and do a few tiny iterations on that. Sometimes it worked, sometimes it didn’t. I should have let the songs “sit” more.

5. Plan, and then abstract the fuck out of your game loops (within reason). I think this goes without saying, and also stems in part from me being relatively new to programming as well. Inspiration Dave, by all means, was a disaster in some regards. Often I’d go “oh I need to add a text box” and just stick it in the loop, decreasing readability. The more you hard-code behavior, the worse. I still ended up doing this with the tutorial graphics. This created a massive pain in the ass when it came to moving stuff around. Of course, there’s always overkill and over-optimizing, but I think I’m reaching a decent balance with current stuff.

6. Suck it up and learn a map editor/scripting thing.   Goes without saying.  Anything that can be automated should be automated. The most hilarious thing was the Ludum Dare version of Inspiration Dave, where I hardcoded the pills/notes. For ID, I got around to coding in spikes, doors, pills, and notes for inspiration dave. But I would have benefited from a better way to script the world map, treasure boxes in the hut, and level entering logic. All of that was hard coded, and it was a disaster. Especially the world map. Coding what arrows to show up, which world map markers were visible, where to move to…yuck. Thankfully, I am doing this full throttle in my current project and it’s working quite nicely – no hiccups (yet). It’s just a little bit of unpleasant bookkeeping, and then everything’s all better!

7. Make the first tileset count, or at least plan to iterate. I would get lazy and draw some tiles , then not revise them. Anything gets better with a little revision. And with tilesets, well, obviously, it really counts. That’s what you’re looking at all the time. Maybe I’ll study up on more effective tilesets for the future.

8. Define an abstraction that allows user-driven controls.  This isn’t that hard to do, and it makes a HUUUGE difference. Definitely putting this in any future keyboard related games. Big problems were handedness issues (which were taken care of but perhaps not obvious), and rollover issues with keyboards not being able to detect certain pairs of simultaneous keypresses. I tried to cover most of my bases, but really it would have all been simpler to define some way for the user to specify what keys bind to what actions (after giving them a default.)

8.5 MAKE SURE THE KEYPRESSES DO WHAT THEY SHOULD. INCLUDE A “CANCEL” BUTTON FOR MENUS THAT IS OBVIOUS.  Speaks for itself. Nothing like “now how the hell do I get out of this menu…” to kill the mood, huh.

9..  Criticism is awesome, and appreciated .  This is related to point 2. But, really, the thing we all want the most is honest criticism. It’s kind of hard to find this type of criticism.. As you make stuff more and more you get used to it and it kind of becomes a natural cycle of being able to improve, when others comment on what flaws you can’t see (especially with bugs…). This applies to any sort of creative form, I believe. We become so entrenched in something we made that it is hard to see issues with it and so forth.

Inspiration Dave, finally finally done.

Done as in released on the interwebs for real. The past 2 months have included sponsor branding/ads – first time I’ve done it, zooming in the game because it looked too small earlier, playtesting it way too many times, fixing a difficulty curve, crushing edge-case bugs of hell, fixing some glitch with the scores, and removing that performance issue.

But it’s over. Time to move on. Well, I have already been moving on, but in full 😛

I think I’m going to go do homework for the time and deal with everything later. Hope it gets frontpaged on NG and passes judgment on Kongregate x__x

May expand this to talk about more later, but this is a milestone for me, even if the game doesn’t do very well. Because it’s F-I-N-I-S-H-E-D.


If you some how got to this blog without seeing the game, play it here and help it get out of judgment hell on Kongregate: http://www.kongregate.com/games/Seagaia/inspiration-dave


or give it a vote at NG!



Or discuss on reddit.



Well, this is embarrassing.

This is a story that happened today…after using Flixel, an AS3 game framework, for a good number of months.

So, garbage collection in flash/as3 or whatever. AFAIK, garbage collection is an algorithm object-oriented programming languages implement in order to free up memory that had been allocated earlier. In some ways, a more friendly alternative to the malloc/free of C we (maybe) all know an dlove.

Flixel works in these objects called “FlxStates” which, in some ways, act as things you can stick objects you want to display in. Say I switch from a menu to the world map, which are both modeled as FlxStates. I had naively assumed that in doing so, Flixel  would have marked all of the objects I added to it as null in its call to the FlxState’s destroy(), so that they would be freed from memory by the garbage collector. To my surprise, today I pop open the code for FlxGroup (the class FlxState extends)’s “destroy” method and…

public function destroy():void {}

oh, shit.

For some reason since memory management isn’t so explicit (see: C programming language) in as3, I somehow assumed that flixel would deal with the marking of  things as null, but this is behavior that has to be customized.

Using a framework, really the only things that I allocate that AREN’T added to the FlxState are arrays of strings or whatever. So it was just a straightforward exercise of null’ing the objects in the FlxState one by one when switching states.

And that fixed everything…more or less. Before, at least 20-30 MB were being allocated whenever I entered a stage, some of that being freed (or reused? not sure) when I re-enter stages. Of course, that adds up over time, although on full one-sitting test plays I never noticed a problem. Probably because we’re so spoiled with memory nowadays… 🙂

Anyways, a game I had worked on for a few months now runs a few FPS faster than I ever thought it could. Luckily, this didn’t cause too much problems with the game design I made while playing it slow.

So, rookie error. But better late than never, right?