Dan Cook has this great post about game design. I’m always arguing with people stating that game design is worth nothing, because to make a good game just a programmer is enough. You don’t need a game designer. But that simply ain’t true. Games exist as long as mankind. And people made games just with what they have. Some of them, like Tenet or the Mancala family are still played these days. Game design is not about technology. It’s about making games. Simple as that.
Things like this one make me happy. I love sketches. These come from Nintendo official website. But Chevy Ray Johnston has just opened this lovely Tumblr. I can’t wait to send something. Just let me grab my scanner.
So, it’s here. Santa’s Deadly Descent was officially published on friday, december 17th. It’s a pretty important project for me and for Urustar, because it’s the first real finished game we have made with flash. It’s still pretty small, and it has some flaws, but for the first time I feel it like a finished game rather than an experiment or a simple programming exercise. I learned a lot about Flixel and Flex while making it, and now I’m comfortable trying more complex games. So, this won’t be, I guess, the usual postmortem. I would like to tell how the project went from start to finish rather than the generic “what went right” and “what went wrong” bulleted lists.
So, a while ago I had this idea to make a free, simple game as an holiday gift for all the people following Urustar and encouraging me and my partners to do better and better. I was thinking about how I could do an infinite game, Canabalt style. I’m quite the newbie when it comes to coding, but I guessed that, whit the help of Flixel and its great community, I would have been able to overcome all the obstacles. To keep things simple I decided to use several predefined blocks that the code would randomly choose and append when necessary, thus generating the game world on the fly. I decided that the game could be about Santa falling down an infinite chimney, filled with deadly traps, and trying to survive as long as he can. My job in the gaming industry started as an artist, so I’m the kind of guy aiming to find a visual style as soon as possible. This sometimes gets in the way of my design process, and I’m trying to drive this urge in the right directions. I didn’t do a real design for this game. Since it was meant to be really small, I decided to make something playable as fast as I can, so to be able to change immediately everything I didn’t feel right. I would have started laying out Santa’s movement, so to develop gameplay on that. I wanted Santa to be a nasty guy for the player. Each time he touched the ground, he would have bounced on his ass, being slightly uncontrollable, and adding drama.
I fired up Sprite Something on my iPad and started drawing Santa’s base animations. This is a great app for pixel work, and the animation function is pretty handy to understand immediately if the frames combine well together. I really wanted my Santa to have a strong character even if somewhat lo-fi, so animation was essential.
After this, I just started programming Santa’s movement with a very simple level (which I imported from an early coding exercise). I had a quite hard time programming the bouncing the right way, and did a lot of tuning just to make him stop after two or three bounces. I added a jumping feature, so to hand some more control in the player’s hand. The movement was still not perfect, but just good enough to carry on building the infinite level mechanism.
But before starting with that I needed one more thing. A way to easily design levels using a visual tools, rather than hardcoding them. I picked up Tiled, which is a good editor and implemented the classes made by (…) to read the .tmx files (which are just renamed .xml) and convert them in a way readable by FlxTilemap, which is the class used to compose the levels. The same classes would allow me to add interactive objects in a similar way, so I used them for the deadly obstacles and for the bonuses, which I decided to add in order to make gameplay a bit more exciting.
Then I started creating the main engine of the game. I called it Infinite Jest. Like a jester, this class would get a random block (made up of three pieces: the tilemap, the bonuses and the hazards) and add it, at the right moment, to an array, simultaneously getting rid of the first block. This way the infinite level is always made up of just three blocks: one up above the player, the current one and another one just below, ready to be explored.
Another class would read the .tmx files and create an array from which the Jester chooses the blocks. Then, the information in the array are converted into tiles, which are the ones creating the entire game world. So, now I had a complete world. I designed a whole tileset and I gave the level editor to Marina and Alessandra. We did 30 different level blocks, tuned up them, created new tiles and new hazards, until we got what you can play right now. There was just one problem. Santa’s movement was terrible. The bounce idea didn’t match the level design, and it was overall not so good, because a lot of times the player would have to wait just to regain control of the character. So, we opted for a more traditional control, with a pretty sensitive jump control (basically if you just tap the button, you jump a bit, while if you keep it pressed you fly airborne. We wanted this jump to be quite superhuman, as like Santa having a magic boost. This would be our fuzzy control system I was looking for in first place.
Meanwhile, I had to deal with music and SFX. The music was pretty easy: just an electropop remix of my favourite Xmas Song, Deck The Halls. Garageband and a tiny little patience did the job quite well. As for the effects, I chose to keep it simple and go with CFXR, which is a little cute editor for 8-bit style sounds. Well, that was almost it. We kept doing level design and trying to tune-up the game the best we can (and we really missed the time to do some heavy testing with other users). Now, you can play our game here or on Kongregate if you want hi-score tables and stuff.
I’m making very small games. Games you can play for five minutes or so, and then stop and do something else. Why am I doing this? Well, the first answer is that I’m now pretty limited in what I can do. I ain’t a coder (though in these months I’ve learned Actionscript and I’m struggling with objective-C) and we’re having a though time in finding a good coder to hire for Urustar. People in Italy prefer dreaming of being the next Big Brother contestant, or maybe a soccer star rather than working in an indie team to make good games. The second answer is that I find more interesting to work on really small game ideas, to go back to old-style arcade games, to find the zero point of fun. For these reasons I really love works like Super Crate Box. Fast, immediate and impossibly clever. Kudos!
Having just started a small gaming company, the first thing I’m missing is to have a good creative space, a place where I can prototype, mess with stuff and so on. For now Urustar is located into a coworking space, but we hope we can soon move to a real office. And here I’d really love to have this creative area. First of all, let’s say that I’m pretty convinced about the importance of non-digital prototypes. I think game mechanichs deserve to be experimented outside the computer screen, and often touching things and combining them together is an excellent way to come up with new ideas.
In my dream space I would have:
All this, with a lot of colors (colored walls, wall stickers and stuff) and a stereo system to play funky music.
That would be really nice.