Tuesday, April 8, 2014

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.

Monday, April 7, 2014

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

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

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!