Thursday, December 12, 2013

Game #8: "Monster Farm"

A week ago we started making game #8 "Monster Farm". It's a cross between DragonVale and Hay Day. An isometric freemium farm where the player breeds and grows monsters. Yesterday one week was up and it was time to publish the game. We didn't. Instead we decided to make an exception and take two weeks to develop this game.

This genre turned out to be more architecturally complex than the others that we tried. My prior architecture that I used for the last five games was not flexible enough, so I had to make a new one. After a whole week of development all I have to show is the isometric grid and the shop menu.

I spent two days implementing the isometric projection and the camera with scroll and zoom. Then I spent three more days implementing a data access layer. The lack of a standard framework with these features in Corona really slows down development. Every game reads and writes data, no? In a year or two once I have a library of well architectured and tested modules for data access and other common features, I will spend my time writing game logic, not middleware, developing games 2-3 times faster. Not yet though. The data access layer that I got now lets me write a lua data file "factories.lua":
Entry{ id = "factory_01", image = "monster_01", name = "Blue Monster", cost = 100, description = "Huggable and Lovable.", time = 10000, size = { i = 1, j = 1 }, center = { x = 0, y = 8 * 3 }, recipes = { "recipe_01", "recipe_02" }, animations = { name = "default", start = 1, count = 20, time = 1000 } }
Entry{ id = "factory_02", image = "scary_02", name = "Red Monster", cost = 200, description = "Scary One.", time = 12000, size = { i = 1, j = 1 }, center = { x = 0, y = 8 * 3 }, recipes = { "recipe_02" }, animations = { name = "default", start = 21, count = 20, time = 1000 } }
Paired up with the data file is the model class "factory.lua". Elsewhere I can access this data with:
Factory = require("factory")
for f in Factory.find{ cost = 200 } do
The find method returns an iterator over all Factory objects with cost = 200. If you know Ruby on Rails, you will recognize what I am trying to do here.

So now we have another week to get this behemoth into some semblance of a game. Hopefully that's enough time. By the way, Liza is making phenomenal progress learning and making isometric art; it's beautiful! Will show in a week.

Wednesday, December 4, 2013

Game 7: "Tower Defense" released

Today we completed game 7 out of 10. It's a tower defense game with whimsical art, where everyday characters such as the punk, the local beauty queen, and the bum must defend their neighborhood from the alien invasion. Featuring an Elvis impersonator. Here is a video:

I am releasing the code into the open source. The art and the sounds are for your personal use only.

When we started this whole project 2.5 months ago, I wrote a list of game genres that I wanted to focus on. One of them was tower defense that I very much wanted to create but put at the end of the list as a very hard genre to attempt only after we practiced on the easier ones. I remember thinking then that I have no clue how to even approach making a tower defense game.

Fast forward to now. Tower defense turned out to be one of the easiest games to make. There were no difficult architectural or algorithmic problems. Neither did it need a lot of code or special tools or libraries. There were several interesting nuances:

How do you design a level for a tower defense game coordinating between the artist who draws and the developer who lays out the locations and the paths? We drew a sketch of the paths on a napkin, then Liza drew the whole level in Illustrator, then I specified by hand the locations for the towers and the alien paths (the code has a helper debug function drawPaths(), uncomment it to visually see the paths). This would get old very quickly beyond a couple of levels, so for a full game I would make a level path editor first.

I continue to learn Lua and to refactor my code base. I looked at two libraries, Coat and Middleclass, that implement the missing OOP features such as inheritance and mixins. Mixins in particular are useful for common functionality such as Viewable for display objects and Persistent for stored objects. After studying the third party libraries for a bit, I wrote my own mixins just because it was so easy to do in Lua. Right now what I am missing the most in Lua is an ORM layer. There is Coat Persistent and Rocket Lua, but the former is alpha and the latter is not maintained.

Another piece of game dev that I learned this week was the particle generator and manager. I was going to use Particle Candy, but the Internet was down the whole day and I couldn't download it, so instead I wrote my own, and it turned out very easy to do.

Liza has progressed enormously as well. She animated six characters in Flash this week, in addition to drawing the UI and the level map. Just to think that only a few weeks ago she took a whole week to animate one ninja.

Wednesday, November 27, 2013

Game 6: "Adventure Game" Released

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.

Monday, November 18, 2013

Game #5: "Word Origami" Released!

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.

Monday, October 28, 2013

Game 5: "Word Origami"

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!

Thursday, October 24, 2013

Where is all the open source Art?

Code - side:
The world pretty much runs on open source software, - Linux, Apache, MySQL, Memcached, ... the list is endless. Almost every company with any meaningful tech is using some open source software. Some of the best software developers invest countless hours of their time into open source movement; it's a point of pride for them.

Art - side:
The open sourced art is pathetic! It's a tiny selection and of poor quality. Whenever you see open sourced art, such as on, there is almost invariably a demand to put the name of the artist in the credits. If your average website had to put in the credits the names of all the contributors to all of the softwares it's using, that list would thousands names long.

WTF is going on? Do software developers in general have generous hearts, while artists have poor hearts? Do software developers live in a world of abundance where sharing is the norm, while artists live in a world of scarcity where hoarding is the norm? Do software developers earn so much for their work that they can afford to share, while artists are paid so little that they need to squeeze every last penny out of their art? Is there some systemic issue at work here? I would like to understand what's going on here.

Monday, October 21, 2013

Game 4: "RunJumpDuck" released!

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 :(

Monday, October 14, 2013

Resources: Source Code, Art, FX, Editors, Sound

This will be an updated page with links to free or inexpensive art and sound game assets.

Learning Corona:

Level Editors:

Game 3: "Oog" Released

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.

Monday, October 7, 2013

Game 3: "Goo"

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...

Sunday, October 6, 2013

Game 2: "TV Slots" released!

Alright! And we are done with game #2 - "TV Slots". This game was harder to make for both of us, took the whole 7 days. Here is a video:

We are releasing the code into open source. Enjoy! :)

I ran into two challenges while developing this game:
  1. 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.
  2. 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.

Wednesday, October 2, 2013

Fonts for games

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.
Great looking fonts too!

Also useful discovery are these lists of fonts that come with iOS:

Monday, September 30, 2013

Game 2: +1 week

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.

Tuesday, September 24, 2013

Game 2: "TV Slots"

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...

Sunday, September 22, 2013

Game 1: "Hatch a Dragon" released!

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...

Tuesday, September 17, 2013

Hello World


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.

The rest should be easy... )

Sunday, September 15, 2013

Game 1: "Hatch a Dragon" >> Game Design

Let the game begin!

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.

The Beginning

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! )