10 Games in 3 Months: Wrapping Up

This is it! We've done it. We finished our project 10 Games in 3 Months ...

... in 7 Months :)

In all fairness we really did spent exactly 10 weeks developing 10 games, one week per game. The rest of the time other personal and professional demands insisted on their priority. The project was incredibly interesting and educational. I mean I can say now that I've made 10 games. Cool.

I want to summarize some of my learnings from the project:

• It's not hard making games, even the complicated looking ones, and a lot of fun.
• The actual complexity of making a game is very different from the perceived complexity. You won't know the actual complexity until you try to at least make a prototype. For example, a platformer turned out to be much harder than I thought, while a tower defense turned out to be simpler.
• A good well motivated team of two partners can be more effective then a team of eight employees. And for me it's a lot more fun making games myself then managing a game studio.
• There is a lot of room in the market for great games. The vast majority of mobile games are crap, even among top ones. I have installed hundreds, but only a handful are great.
• With experience, game design turns from Voodoo to problem solving.
• A game engine saves so much time. My leverage using one is at least tenfold. Both Corona SDK and Unity3D are excellent value.
• Luck and talent are overrated. It's easy to pick up game coding, game art and game design. While mastery will take years, many simple and fun games can be made by beginners.

Game #10: Released

We finished "Game" #10 where we switched roles, with me making the art and Liza writing the code. We ended up not packing up our work as a game, instead packing as much learning as possible in this week.

I loved learning 3D art and playing with Blender. So much fun! Here is the model I made:

I made this critter by following a 7 hour tutorial. The funny thing is that I thought to complete the tutorial in two days. Instead one week later I only made it through half of the tutorial. So much was virgin ground for me and exciting to experiment with. The critter for example has a toon shader I designed myself.

Liza meanwhile went through three Unity tutorials, and even published one online.

To wrap up, switching roles was an awesome idea. We have a much better appreciation for each other's work. And now we are ready for the next phase of our project...

Game #10: "Space Shooter"

Today we are starting our final Game #10. This time we are doing something very different, switching roles. Liz will be writing the code and I will be making the art. The idea behind the switch is that by understanding each others workflows we will work more effectively as a team.

Our goals are quite simple. Liz is going to learn the basics of Unity by making 3 tutorial games. I am going to learn the basics of Blender by making a new ship and new asteroids for the Space Shooter tutorial game. I expect this to be fun but difficult. Even using the pen tablet isn't trivial. I would love to spend more time learning to make art and the art tools (Illustrator, Clip Art Studio), but for now a week is enough.

Game #9: "Run" released

It’s been 4 months since my last post. A long time… We had to pause the project for family reasons. A week ago we got back into it, and I have game #9 to show! But first, whatever happened to game #8?

Well, we invested two weeks into that isometric farm game, and had almost nothing to show for it, all the work was on the infrastructure level. I got the isometric camera done with zoom, scrolling, panning, as well as the shop and the factory UI a la Hay Day. That’s it. That was two weeks. Crazy slow. On the art side, Liza drew some very nice isometric tiles and buildings.

Moving on, we have long planned to try making one 3D game. Corona SDK isn’t good for 3D. So a couple of weeks ago I installed Unity 3D, watched a few official tutorials (they are awesome), and last week we kicked off Game #9, an infinite runner a la Boson X (my favorite infinite runner). Today Game #9 is done and you can play it in the browser or watch the video:

As usual I am putting the game into open source. It uses a few assets from Unity standard assets and sample assets.

So how does Corona SDK compare to Unity 3D? I like both a lot, and I have bought the Pro subscription to Corona for $600 a while back. That said, I think it’s really no contest for my purpose of rapidly developing a variety of games in a tiny team. It's all about leverage:

• Both platforms publish for mobile devices. Unity in addition publishes for the browser, standalone (Mac, Windows, Linux), as well as several consoles.
• Corona uses scripting language Lua which is fine for small projects but I found it cumbersome for anything larger. Unity uses C# which is a full featured OOP language.
• Unity has an amazing GUI that makes development much faster.
• Unity has many essential primitives build in, like camera, lights and shadows. This saves a lot of time.
• Unity has a better developed ecosystem with tons of cheap extensions through their Asset Store. This saves a lot of time.
• Unity can do 3D or 2D games. Corona only 2D games.

Again, I really like Corona, but in Unity I can develop games much faster, and spend less time with the code and more with the game design.

Just like I with code, Liza had a crash course in 3D art. A week ago she installed Blender and jumped into tutorials on sculpting, rigging, skinning, animating. The creature in the game is fully her creation. Here it is from the front:

Working in 3D is fun! For example, we didn't make the run and jump animations you see in the game. These came with sample assets from Unity. Turns out in 3D, animations are created for skeletons. So once a character is set up with a humanoid skeleton, any humanoid animation can be applied immediately. Wow. Or checkout Mixamo, - thousands of models, thousands of animations. I feel like a kid in a candy shop :)

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.