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

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