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