That’s the latest game I’ve finished. We had to rush some bug fixes at the end which cost us some sound effects, but we’ll be updating it this week with the right stuff. The game won’t be any different really, so go ahead and give it a try.
Here are a few thoughts on the game and its development. I list some “lessons to be learned” at the bottom, so feel free to skip down to that.
The Thief Game with Thief Jumps
I just put up a blog on “jumps.” You’ll notice in this one I used a double jump (with stiff vertical acceleration). Originally, I was designing a game about a thief so I was aiming for the sense of high speed and agility that one would expect from such a game. Right after I had the mechanics figured out and finished programming the “attack dog” bad guy, it was decided that the thief idea was a no go. Sometime later it became The Breakfasat Club. So the basic gameplay idea and the attack dog character were both meant for a thief game and everything else was tossed in when the game’s story was more ambiguous. Hopefully I succeeded in creating the sense of crispness, speed and agility that I was aiming for, even though the game’s story didn’t end up adhering to that. . . .
But hey, that’s why we need some games at places like Sokay. And if you want to see LG embrace more “games for the sake of games,” please let them know it.
Playing with Interface
I ended up having way more development time than I first expected, but I was never quite sure when I’d have a deadline plopped on my lap. Because of that, after I finished with the mechanics and level designs, I focused on streamlining the game’s interface. This is the first time I’ve had the chance to play with that aspect of design and I liked it a lot.
I tried to make sure that anyone that didn’t want to waste time reading instructions, menus or watching cutscenes wouldn’t have to (because that often bothers me). I also never liked moving back and forth between the mouse and keyboard when I play a keyboard based game so I gave every menu a function that would go off if the player just hit the space bar. I realized that was a mistake on the start page because players can launch the game, then open a new window and check e-mail or something. If they start typing and hit space, that will initiate the game. I’ll probably update the game with that fix and make a habit of creating start pages that can only be left by a mouse click.
With other LG games, we’ve found that no one reads instructions pages before playing, but if you don’t read them you won’t know what’s happening. That led me to the exclaimation points ala Mario World.
Oh and I also popped in a little cursor timer that you hopefully won’t notice. If you leave your cursor still for about 10 seconds, it’ll turn invisible. When you move it again, it will reappear. I did this because I always hate having the cursor in front of my games, whether I’m playing them or watching others do it. It was a real nice way of removing the cursor without annoying a player that was trying to use the mouse.
I think the only real interface function I had no time to implement was an options menu that could change the controls. I actionscripted a foundation for one, but never built the menu itself. The game’s simple enough that it’s fine without configurable control schemes, but I’d have liked to have the experience of building one and finding out how many people actually use it.
This game was the real test of my Liberty Engine, as I’ve so proudly named it. You might notice that in levels 4-1 and 4-2 there is a bit of slow down. It only shows up on some machines (pretty much only Macs) and on some the level even freezes. If you restart the game, the level will work just fine.
I believe this is because the levels are exceptionally huge (big enough that they went beyond Flash’s max length and width) and the game uses attachMovie to drop in hundreds of objects. I assume that the second time through the player’s computer cached enough of the game that it loads things in more easily and doesn’t freeze.
This form of the engine is a good example of some of its capabilities, but it’s a very inefficient form. While working on this game, I also worked on a level editor that can really push things along in development. It still needs some updates, but I’m hoping it will be able to offer unlimited level sizes and object numbers (by generating levels based on actionscript rather than vector images).
The only thing that allows the engine to run at all is the fact that everything that could be turned into a PNG image was converted into one. The backgrounds of each level are actually large, tiled PNG images. We couldn’t use one big image for each level because after images get too big, they freeze crash. The way it’s operating right now though, the images are always present on the stage, which is pretty inefficient. I could have removed them when they weren’t visible, but that was tossed aside like a lot of other possibilities in the name of completing the game on time.
I also implemented a sound manager created by my fellow LGer, Tom of EndGameRadio. Nice little class file that allowed all the sounds in the game to be easily actionscripted, which I believe made the game run much more smoothly. I’ve had sound issues with flash in the past, but this time implementing it was easy as pie and didn’t slow anything down at all. Thanks Tom.
Lessons to be learned: Use PNGs for everything you can, try to actionscript all your sound, watch your vector count, don’t get too close to flash’s max dimensions, use a loader system to spread your attachMovie’s over multiple frames (even just a few), expect Macs to run flash much worse than PCs do (even really good Macs), large games will load slow once and fast everytime afterward (thank you cache), INVEST IN INTERFACE (it may seem boring, but it’s half the player experience), oh yeah and set enterFrame to undefined whenever a MovieClip isn’t going to be doing anything anyway.
So that’s that for that. I’ll have to come up with a whopper for the next project.
-Christopher J. Rock