How to play test networking in Unity

One of the very basic challenges I ran into when developing networking for our game was play testing. In a non-networked game, the dev cycle is: make changes, run the game, make changes, run the game, all happening fast from within the Unity editor. You cannot do the same for a client and server game because you cannot open one project twice in Unity. Do you have two separate projects one for client, second for server? That's not so great if they share code. Do you build the server into standalone and run the client from Unity editor? That's not so great if your build time is in minutes. Instead I use folder synchronization together with folder conventions. But lets start at the beginning. The following applies to Unity on Mac. My guess is Windows setup would be similar.

The first challenge is getting two instances of Unity to run at all. If you just double-click on Unity app a second time, it will always switch to the already running instance. So, create a shell script start_unity.sh:

#!/bin/bash
# start_unity.sh
/Applications/Unity/Unity.app/Contents/MacOS/Unity

Also in Unity, enable Unity -> Preferences -> Always show project wizard. Now when you run start_unity.sh it will start another instance of Unity.

The second challenge is opening the same project twice in Unity. That's not possible. But you can duplicate your project and open it in another Unity instance. Now if only we didn't have to manually copy the project and restart Unity all the time. So, create a shell script sync_client.sh:

#!/bin/bash
# sync_client.sh
rsync -avz --delete server/Assets client

The folder structure is:

myamazinggame

  -- server

  -- client

  sync_client.sh

The main Unity project is in server folder. Create a fresh new Unity project in client folder. Run sync_client.sh and open client project in another Unity instance. So now you got two Unity instances, running identical project, one from server, second from client folders. In my workflow, I make manual changes only to the server project, including editing client code and adding client assets. Then I sync the client project with sync_client.sh. This workflow is almost as fast as for non-networked game.

You might have some libs on the server that would break the build for the client (eg. database access dlls will fail the build for iOS). In this case put all server specific assets into Server folders (doesn't have to be just one):

myamazinggame

  -- server

    -- Assets

      -- Plugins

        -- Server

      -- Scripts

        -- Server

  -- client

  sync_client.sh

And modify sync_client.sh to:

#!/bin/bash
# sync_client.sh
rsync -avz --delete --exclude=Server/ --exclude=Server.meta server/Assets client

Now the sync to client folder will skip all Server folders.

New game released - Conversation with Death

Conversation with Death is a short visual novel made for IGF competition.

What happens after death? The perennial question. Instead of wondering, how about you hold a conversation with death. If you get that far, that is.

The game is inspired by an amazing short story. The reward for winning the game is learning the story name and the author (no, not me, I wish! :)

Play in the browser, Unity3d web player required.

The game was made in one week by me and Liza. We needed a break from our main slots game project, and talking philosophy is a good counter-balance to talking casino :)

Just the two of us worked on this game, and it's kind of like a spontaneous love child made in one week. We would REALLY appreciate your feedback on it! Please leave it in the comments below, or if you have a Reddit account on our post there.

One month into the development of Good Slots, a Unity3D mobile game

It's been one month since we started developing Good Slots, - our first major mobile game in Unity3D. It's a casino slots game, and more or less follows along the lines of the prototype we built in one week in Corona last fall. But prototype is one thing, and a commercial game is a whole another story.

A tile for one of the slots. Guess what's the theme? :)

It took just three days to replicate the Corona prototype in Unity, but then the pace ground to a turtle's crawl. If I was an experienced C# and Unity developer, this whole month's effort would've taken just a few days. As things stand now there are many many technologies I need to master to make this game happen. Here is a look at them:

C#: a nice language. Last time I touched a C type language was a dozen years ago that left me with a bitter taste from mallocs and pointers. Since then I've only coded in dynamic languages like the yacky PHP and the awesome Ruby so going back to compile time is a ... change that takes getting used to. Each language (computer or human) has its own flow to it, and it takes time to grok it. I am certainly not there yet with C#.

Unity3D: I love this game framework. A while back I took a Graphics and Game Programming class at Stanford University. The final project was to develop a 3D game with OpenGL, without any game engine. Man that was a low level coding mess! Never again! Even compared to Corona (which is great btw), Unity is noticeably more powerful.

Toolkit2D: Good Slots is a 2D game. Unity3D has 3D in it's title not for nothing. The good folks at Unity did release a 2D workflow recently, but it's lacking some features for working with multi-resolution sprite atlases. Unity also doesn't have a good GUI framework. Toolkit2D offers both, and is a breeze to use. (I did look at the other major GUI packages for Unity, eg NGUI, but at the end none really stood out, and Toolkit2D covered all of my needs.)

StrangeIoC: One of my major gripes with Corona was the lack of a coherent game architecture. Throwing everything into a home baked game loop is asking for a disaster. Unity itself is only slightly better. Placing code in random scripts or in monolith GameObjects will lead to a maintenance nightmare. I searched everywhere for ideas on making a coherent game architecture, and I found one! StrangeIoC with MVCS . Yeah, that's a strange title :) It's based on dependency injection, and I had no idea what that was until last month. Took me about a week to learn and convert our game to StrangeIoC, and now it's finally well organized and coherent.

Parse.com: Our game, although single player, has major server components to prevent hacking: all the data and game logic are stored on the server. There are many other benefits to a server based game: I can tweak any game parameters in real time, analytics is easy, adding social features is easy. But developing server side is a pain in the ass, and wastes time better spend refining game mechanics. I certainly wasn't going to set up servers, build in scalability, replication, and the rest of the infrastructure. So Parse.com comes in to save the day. Except it's still a pain in the ass, albeit a smaller one. For the last two weeks I've been learning and building the data layer. There are just so many parts to it: a data admin module, storing data, retrieving data, batching server calls, local caching. Add on top user authentication and authorization, Facebook connect, the myriad edge cases. Argh... This is just stupid! Why isn't there a plug and play module for this? Every other game dev is writing code like this. I would easily pay a couple hundred dollars for this module.

That's my one month of effort. The data layer will take another two weeks to finish. And then there is more:

Error Logging: A must have, there are bound to be client errors that I would miss otherwise. Might use Loggly or Airbrake.

Analytics: A must have, these games are perpetual works in progress, and I need visibility into player behavior. Might use Mixpanel or Swrve.

Facebook posts: Distribution will be the #1 challenge for us, so anything to help along is a top priority.

So the first two months of the project will be spend building the ecosystem for the game, and only then I will implement the actual game mechanics. I've chosen such development path on purpose. I am focusing on the riskiest parts of the project first. All of theses technologies are new to me, and I have no idea how much effort it takes to implement them. Also, the whole ecosystem is fully re-usable for future games. Contrast that to the casino slots game mechanics that is well known and tested by hundreds of existing apps (except our innovations :)

Can a team of two, starting from zero, create a Top 10 Grossing iOS game in 1 year?

Now that our project "10 games in 3 months" is done, where do we go from here? Making these 10 games was never an end in itself for me, but only the first step in a larger plan. Back in the Fall I posed a challenge to myself: “Is it possible for a team of two people, with no previous experience in mobile gaming create a Top 10 Grossing iOS game in 1 year?” With a million of developers around the globe competing for these ten coveted spots, that seemed like an interesting challenge.

We designed a plan to get us there. Since we knew nothing about making mobile games, the first phase was to rapidly get up to speed. That’s what “10 games in 3 months” was all about. The second phase was to pick three most promising games, focus on each one for two months to build it up to commercial quality, then release each in the Canadian app store. In the final phase we then pick one game to focus on for the remaining three months with a worldwide release.

Last week we started the second phase.

The first phase was extraordinary useful showing me which games have the potential to reach the Top 10 within our time frame. Some, like mid-core strategy games would take too long to develop. Others, like word puzzle games, don’t monetize well enough to ever reach the Top 10. Another group, like match-3, is so full with great games that it’s hard to come up with an innovative game design. We needed a genre that can be done in two months, monetizes extremely well, one where we have a lot of good innovative game design ideas. Several genres fit these requirements, with Casino Slots fitting the best.

This is actually funny. I don’t play virtual slots. I find them boring, lacking any thought. Honestly, I wouldn’t even call one a game. I don’t ever play in casinos either. So how can I design and create a game that I have no interest in?!?

This was one of my biggest lessons from running a game studio in Kiev. The perspectives of a player and of a game designer are very different. As I player I would never touch a slots game. As a game designer with the goal of making a Top 10 Grossing game, it’s intellectually challenging and emotionally satisfying to design a game that can win the race. As a game designer I am playing a meta-game that makes it easy for me to spend hours a day playing and analyzing dozens of slots games.

For the next two months we are making Casino Slots. I am developing it in Unity. Liza decided to hire a freelance artist to help her create the tons of art the game requires. I am very excited about making this game. As late comers to the market, with no prior experience making slots games, it’s obvious that competing head on with the existing top slots games is a losing affair. So instead we have taken a fresh look at slots games, asking ourselves the question: “What would the slots game be like that’s *fun* to play for general audience?” The answers led us to make many innovations to the genre. It’s a bet we are making on the innovation vector; seems fitting when developing a casino slots game.

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.

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

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 Behance.net, 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.

Question:

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.

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

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:

• A huge collection of links to tutorials and sample code #1
• A huge collection of links to tutorials and sample code #2 (older, with some outdated links)
• Corona templates for a dozen full games (including a really nice Cut the Rope app; $)

Art:

• Block Buddies (20 animated characters, $)
• 2D Game Art for Programmers (some free art and lots of tutorials showing how to make art)
• Lost Garden (a variety of free assets)
• Graphic Buffet (a variety of assets, so-so quality, $)
• 700 fantasy themed sprites
• Cartoon Solution (lots of awesome characters ready for animation)

FX:

• CBEffects (open source particle system lib for Corona)
• Particle Candy (effects creator/lib, $)
• Moving sunbeams

Sound:

Level Editors:

• List of free level editors
• Corona SVG Level editor (convert any Inscape vector .svg into physics objects, including freeform curves, $$)

Algorithms:

• Easing functions

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

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.

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.

http://www.google.com/fonts/

http://www.fontsquirrel.com/home

http://www.fontspace.com/popular/fonts

Great looking fonts too!

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

http://iosfonts.com/
http://www.droidfonts.com/  (another link)