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
    print(f)
end

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.

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.

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.

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.

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

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.

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.