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.