Game #6 - Adventure Game - is done! This is our first original game, inspired by an iOS hit game Device 6. Making an original game is hard. It's like trying to find your way from the middle of a desert, no landmarks, all directions looking the same. In retrospect a great game seems obvious, but finding that right set of features is hard. We spent many hours discussing the plot, the puzzles, the art style, and there was often no way to know how well something works without building it and testing in a prototype. That takes a lot of time. Our productivity was one day of effort to make one minute of gameplay, the lowest of all the games we made.
Here is a video:
I am releasing the code with an open source license. The art and the sounds are for your personal use only.
We wanted to make an atmospheric adventure game and sound is very important for creating the atmosphere. We used Audacity software to record and edit the voiceovers and the sounds. Syncing the voiceovers to the text was hard, I got it only approximately right. Doing it well would require special files formats like those used for subtitles.
The organizer in me was not happy with this game. Everything is a one-off: each puzzle appears once, the special effects appear once, there is little that can be factored out into general classes or routines. The code does not have the beauty of simple elegance. But it works, and at the end that's what matters.
Game #5 - Word Origami - is done. In fact, it was done two weeks ago, but then my laptop broke, and notwithstanding all the virtues of living on Bali, replacing a Mac turned out to be a long affair.
We had a great time developing this game, and it's one of the games we eventually want to polish up for the full release. Here is a video:
As before, I am releasing the code with an open source license. The art and the sounds are for your personal use only. There were three parts to making this game: the UI, the board creation and the multiplayer. For UI Liza did a fantastic job coming up with an original design. We started with a boring looking variation on Ruzzle and iterated on it every day to make it beautiful. It can still use a few more iterations, but we are really happy with how it looks already. On my side, coding so much UI wasn't as tedious as I imagined. I reused quite a bit of code from our prior games, - the camera module, the scenes architecture. This is a general pattern, in every subsequent game I reuse more and more modules from prior games, to the point where some kind of general game architecture is starting to emerge. I have wondered why is there no framework for Corona that does for games what Rails did for web apps? As for the board creation, there is secret sauce to it. If you compare other games in this genre such as Scramble with Friends to Wurdle, you will notice that the former has good boards with lots of words that are fun to play, while the latter has poor boards with few words. The secret is in the board design - it looks random, but it isn't. If you are curious how to do it, you will have to study my code :) I wrote a short Ruby script to generate good boards with lots of words. And that brings another point - word games live and die by the quality of their dictionaries. A day of googling showed that there are several public domain dictionaries, including the official Scrabble dictionary. The most popular public domain dictionary among word games seems to be ENABLE2K. The last moving part we needed for Word Origami was the multiplayer piece. This is our first game with multiplayer so there was a lot of learning for me. There are a number of options available: iOS/Android game centers or Parse and others of its ilk or DIY server. The built-in game centers are the easiest to implement, but I wanted a cross platform solution. So I took Parse out for a test drive. It went well, in less than an hour I got the game to load a board from the server. But then I started implementing the full enchilada with the user signup, login, match-making and didn't finish by Sunday (so the demo and the source code don't any networking code). It would take a few more days to complete the multiplayer code. So far Word Origami turned out to be our favorite game. One day we want to come back to it and take it all the way to a commercial release.
Last week we took the week off. Even doing what we love 12 hours a day gets exhausting after a month. So we read, rode our bike and chilled. Easy to do on Bali.
Today we started our 5th game. It's going to be a Boggle style word game. The challenges are finding a good word list, creating good game boards from it and the networking code. The rest is mostly UI work.
The word list was especially worrisome since it's completely out of our control. We need a high quality, large word list that's in public domain. So I spent a few hours googling and found not one but several good word lists. In fact, most of the word games use one of these word lists - ENABLE2K by Alan Beale. Scrabble's official word list is also in public domain!
Also not infrequently lately I've been getting into "the flow" while writing a game. "The flow" is this state of being where everything is lucid and easy. Read the book by Mihaly Csikszentmihalyi for more info. This means that I am becoming proficient enough in Corona SDK, and that was one of my goals for this project. Me happy!
And we are done with game #4 - "RunJumpDuck". We tried to make a martial arts style platformer this week. It was MUCH harder than expected. By far the hardest genre we attempted so far for both of us. So what we have now at the end of a week is not a game yet, it's a prototype. Here is a video:
I love platformers and they seemed easy to make. Man was I wrong. Five days into the this game I had nothing to show, and Liza had nothing to show. We were both banging our heads at the buggy, poorly documented, awkward softwares and tools. But let me start a few days before that.
Last Monday we sat down to brainstorm the game design. There are a few good platformers in App Store, such as League of Evil and Fancy Pants. I really like the avatar action in Fancy Pants, so I wanted to make a platformer with similarly evocative movements and precise controls. The level design we decided to do using tiles, because we could iterate on them much faster than if using hand drawn levels. And given my martial arts background I wanted to have a martial arts theme.
One obvious question is how to design levels for a platformer. For our previous games, all level design was stored in the code. But for this game that wouldn't work, - levels are big, varied, with lots of unique details. So I needed a level editor. There are a few options: LevelHelper which reportedly is very buggy, another editor only for Windows, and the open sourced Tiled. Not much to choose from, Tiled was really the only option. But Tiled has poor documentation, and on the Mac obtuse and buggy UI.
So I made a level in Tiled that is saved as xml or json. But the game needs to read in this data, display it, move the camera, etc. No way I could write all this code in a week. Thankfully when using Corona SDK there are a couple of options here as well: Ceramic Tile Engine and Million Tiles Engine (MTE). The former is open source (awesome!), beta release, while the latter is inexpensive, proprietary, also beta release but more fully featured. I went with MTE for its features. The engine is nice, the developer very responsive in the forums, but it's still a beta quality software with an occasional bug and sparse documentation.
It took a couple of days to get my first attempt at a level to display on the phone. And just when I thought things would get straightforward and easy, they got MUCH harder:
A platformer needs physics to simulate the dynamics of the game. Some folks write their own physics engine, but I thought why waste time when a great physics engine Box2D is bundled with Corona? ... In a couple of days I would pulling my hair out in frustration at Box2D. Here is a sample of issues I ran into:
There is a fundamental flaw in Box2D that sometimes can abruptly stop a polygon (e.g. an avatar physical shape) sliding on smooth surfaces (e.g. ground) made of several tiles. Took two days to solve. I posted the solution here.
Avatar needs different physical shapes in different postures, eg. walking versus sliding. Changing shapes midway can make the avatar fall through solid ground. Solution requires very careful positioning of physical bodies in relation to each other.
Flickering tile edges because of scaling. Solved by extruding tiles by 1 pixel, and completely redoing the tilesets and the level map.
Fully testing the game in the simulator using the mouse is impossible. And hooking up key events to the simulator on Mac requires a paid subscription to Corona Pro.
...
All of these are well known problems in making a platformer. But as a new comer to the genre, these were a little too much to solve in just one week.
These were my woes this week. Liza had just as many of her own:
Art for a tiled platformer consists of three parts: a tileset for levels, UI and avatar/NPC spritesheets. Way too much for one week. So we decided to buy the level tileset and the UI, while Liza focused on learning to animate characters. It's a story of obtuse, poorly documented software. She tried two inverse kinematics animation softwares: Spine and Flash. Both sucked. Out of seven days she spent five fighting the softwares, and only two animating.
I love the white ninja that Liza animated. And this is her first try at animating ever! There are many more animations she did that are not shown in the video above. I hope they will see light one day.
So in the end I am impressed that we were able to put together even a basic prototype. But the full game would take a few more months to develop.
P.S. And I can't post the source code because I am using proprietary engine MTE and licensed tilesets :(
Game #3 is done! It was a lot of fun to figure out the physics for it, the bodies, the joints. I am amazed at how interesting the game play becomes with the addition of physics. It really makes for emergent gameplay. Here is a video of it:
As usual, I am releasing the code into open source under MIT license. The art and sounds are for your personal use only (I would love to release these into open source too, but bits and pieces of them were bought from the stocks, and come with their own licenses, and I would have no idea how to untangle that legal mess, so for your personal use only.)
I didn't find this game particularly challenging to make. Corona SDK and the physics engine Box2D do all the heavy lifting. Man, I feel like a spokesperson for them; I am not, really :)
I used Physics Editor to get the polygonal shapes for the hilly ground. Good tool. And we also use Texture Packer made by the same folks.
Liza learned a ton this week. She did all the glorious animations of Oogs frame by frame! Great personality in the little creatures.
We are both looking forward to making a full physics puzzler out of this prototype. The World of Goo was an inspiration for this game, but there is a lot of unexplored gameplay left that would make for a few more amazing games in this genre.
Today is Monday, and we kicked off the development of our third mobile game. This time we want to make a physics puzzler. This genre has some really excellent games such as Angry Birds, Cut the Rope, Where is My Water, Contre Jour.
We sat in the cafe early morning today discussing different original ideas for the game design, and none of them clicked. But we both really like blobby things, they are fun to play with. So we decided as a learning experience to make a clone of an amazing game - World of Goo.
As of right now, I know almost nothing about building physics games. Gooey physics is particularly challenging because it is so deformable. Actually, I don't know if a game like this is even possible in Corona SDK. And if it's possible to make in a week (not the whole thing obviously, just a couple of levels). We shall see soon enough...
I ran into two challenges while developing this game:
Getting the reels scrolling realistically. The basic idea is to place two copies of each reel on top of each other and scroll both downwards. When the lower part scrolls below the viewport, translate it above the upper part (so it becomes the new upper part and the old upper part becomes the lower part). Easier said then done. I spent a couple of days getting all the scrolling working well.
The reel design. This is a whole science in itself. There are folks selling software to analyze reel design for unlisted prices, I imagine in tens of thousands of $$$. Our design:
I continue being impressed with how easy it is to make games with Corona. Seemingly hard things are just trivial. For example, midway through the week, we had an idea for a simple action game based on physics. It took all of two hours to make a prototype, including reading a tutorial on making physics games )
I am noticing that a lot of the code is replicated from game to game: level selectors, player data, game data, UI, load screens, iap, experience, stars, etc. I can see how in a few months I will end up with a generic game template that takes care of all the boilerplate.
To make our game look better and uniform across devices, we want to use a nice embedded font. It's easy to do with Corona, just add the font file to the directory and specify it's name in a config.
The problem we just ran into is acquiring the fonts. I didn't know much about typography until now. Well it turns out there are thousands of font designers the world over making beautiful fonts and charging ludicrous prices. The first search yielded font shops selling fonts for $1,000-$10,000 per app. Who would ever buy these?!? The value that a great font adds to the game is, say, 5%. So to justify these font prices, the game must make $20K - $200K. There are very few games earning that much.
So a heated conversation about the craziness of this world later, we returned to google to find several collections of free fonts. God bless the open source.
We've been traveling in Singapore the whole last week. I thought we would have plenty of time to work on the game, but Singapore is just too interesting to miss the opportunity to explore. So we're going to push off the release of game #2 until next Sunday. We are still keeping to 7 working days/game.
Yesterday we started on our second game, - casino slots. As with the first game, our goal for now is to learn the various components of mobile games. The slots will be a freemium game, so I will need to figure out in-app purchasing and server side code. Also the animations and the math for slots are quite interesting.
The theme will be TV Slots. Slots inside TV, in a channel. Uhm, yes, something like that...
It's Sunday, the first week is up, and our first game is done! It's match3 with the basic gameplay, animations, levels, sound, settings. Here is a video of the gameplay:
All in all I am amazed at how much of a game it's possible to create in just a week. On Monday I knew nothing about mobile app development, knew nothing about Corona SDK. Liza knew nothing about Illustrator and Flash. And just six days later we got a full featured game on our phones.
With this game, I focused on covering the full range on features that a game needs, instead of drilling into one. I also tried to write solid re-usable code, which brings me to the first major insight:
Lua is a trivial language to pick up, but a hard one to write good quality code. For me, coming from web dev with Ruby, Rails, MVC, Lua code is just a mess. I used two open source match3 projects for learning Corona and Lua:
Most of the samples I ran into are just a mess, - global variables, spaghetti code, all code in one file. Lua just naturally lends itself to messy code. Which means that anything beyond a simple game would be a problem to write and maintain. I tried hard to write well organized code, but it's still miles away from the cleanliness of Rails.
My second insight is just how different game event driven programming is from sequential web dev. I am still trying to wrap my head around it. I wish I could study a really well done source code for some Corona SDK game, but I haven't found any yet.
We are very excited about getting our first mobile game on our phones! Tomorrow the second week starts, and the second game. I wonder what genre are we going to choose...
After day and a half of downloading/installing/configuring, got my first app "Hello World! again" (but of course) on my Android phone. This is really exciting!
Liza meanwhile drew her first ever Flash drawing of a dragon hatchling for our game.
For the first game we picked a very simple genre - match-3. My goal for this week is to get my feet wet with Corona SDK, and Liza's goal is to draw something, anything really (lol, she's never done this before). So we picked a game with very simple design. But of course I wouldn't want to miss the opportunity to learn more about game design, so our little match-3 game will have a twist to it, a dragon twist :)
This is our game design doc, done in a couple of hours in a coffee shop today.
I am contemplating spending a few years developing mobile games. Seems like a fun thing to do. Always have loved gaming...
I am going to start with a deep dive. Inspired by 180 websites in 180 days my plan is to make 14 mobile games in 3 months. That's one game a week. The games will span across several genres including a platformer, a point & click adventure, a physics puzzler, a tower defense, a farm, a casino, ...?
One of my goals is to sample and learn different technologies for making mobile games. Based on some preliminary research, I want to try out Corona, Flash, Unity and native code. I might try all four, or might stick with one, we shall see.
I am lucky to have my partner Liza join me in this adventure. She will handle the art and the sound for games. For her this is as much a novel experience as it is for me, if not more.
Our goal is to make a hit game with a 100 million downloads earning a cool $1,000,000 a day... ha ha... that would be a miracle of Divine intervention... Frankly, if someone told me they are attempting to make 14 games in 3 months, I would call them crazy! )
