UNet: Working with Unity Multiplayer

Recently Unity 5.1 was released. The key feature of this release was a new revamped networking system. The idea was to make networking accessible to non experts. So a couple of days ago I thought I'd give it a go. I made a new branch in source control and got started.

Initial results were promising. It takes just a couple of lines of script to make get the players to spawn on the network and only pay attention to their own input. The new type NetworkBehaviour is pretty much a MonoBehaviour that plays nice with the network. Its got some cool little helper members that make networking easy.

So I moved onto the water. My assumption was this would be just as simple. Convert a few scripts to NetworkBehaviours. Add a couple of components and then be done with it.

Unfortunately its not quite that easy. The water design in Pond Wars uses some reasonably involved physics. Its basically a series of rigidbodys bound together with spring joints. There is a bug (duly reported) in the networking system that means joints on objects already in the scene are ignored for network objects.

The solution was to switch the water over to procedural generation. Fortunately I had an editor script to do that. Connecting up 200 joints by hand wasn't my idea of a fun time. So I converted that script over to a NetworkBehaviour and problem solved, right?

Not exactly. Unity networking still had a few more curve balls to throw at me. Joint configurations aren't passed over the network. Thus each client was trying to run its own simulation, and getting conflicting results. NetworkBehaviour came to the rescue again, if its not the server, delete the joints.

The network also didn't play nice with the parenting set up. This was kind of critical to rebuilding the mesh. No good having a bunch of colliders running around if the player can't see what is happening. I settled this by having each collider register itself with the water when it turns up in the scene.

But its finally all come together. Its still pretty hacky, but I'm now convinced getting multiplayer running is plausible.

Check out this screen shot.

Making YouTube tutorials

So for the past few months I've been making YouTube videos, teaching people how to do things in Unity. Its been pretty fun. One of my videos is pushing twenty thousand views. In total the channel view count is above sixty thousand. Not massive stats by any means, but nothing to be ashamed of either. I thought I would share some random thoughts on making the videos, in case anyone else is thinking of getting into it.

Process

First thing I do is make the project. I do this with no recording, just getting the code right. I figure out all of the little bugs. This dummy project then becomes my reference during recording.

Actually recording the video is not hard. There are a bunch of free screen recording tools that will capture what you are doing as you do it. I use a free tool called Screen Recorder, there are a bunch of other tools out there as well.

Once the video is recorded I edit it for visual content. The idea here is to cut out as much wasted time as possible. This includes compiler errors, times where I flip back to the dummy project,  straight out mistakes and the like. Unless you are specifically teaching about debugging, there is little point to showing people the wrong way to do things. I typically cut more then half of the recorded footage at this point.

Then I record the sound. I try and record the sound in a single sitting, otherwise the volume gets off. This would not be an issue in a real recording studio, but in my lounge its often a challenge to get a consistent distance to the microphone and ambient conditions each time I record.

Finally I upload the video to YouTube, and post about it in as many places as I can. This typically includes all of the places where Unity developers hang out, including the forums, answers and various Facebook groups.

Tips

For anyone wanting to make YouTube tutorials, here are some of the tips I'd pass on

• Keep your videos short and to the point. Edit out as much stuff as possible. Viewers don't want to spend an hour watching if half of it is you fixing compiler errors.
• Plan ahead. Don't make any coding decisions during recording time.
• Record audio separately. Coding in C# and talking in English are both activities that require focus. Doing both at the same time will slow things down.
• Keep each video focused on a single task or principle.
• Initial views are your responsibility. Once you get enough community engagement YouTube's search and sharing features will take over. But getting the first few hundred views is your responsibility. Push your videos everywhere.
• Pick topics that are commonly asked for by the community, but haven't been done properly. New features are often a great target. For me it was the UI tools in 4.6. I was engaged in using these tools since the beta was first released. I had valuable knowledge that other people were interested in learning.

Monetisation

If you are in this for the money, I've got bad news for you. My average earnings have been around $2 per thousand views. If we assume these rates are consistent for Unity tutorials, this means that if the official Unity channel were monetised, it would have brought in $40,000 across the last six years. I don't know about you, but that's certainly not enough of a wage to cover my living expenses. And the official Unity channel is by far the biggest tutorial channel for Unity out there.

And I probably should finish this off with a link to my channel. Happy watching.

New game alert: Tree of Life

So with Pond Wars up and earning a solid 10 cents a month, its time for me to move on to my next game.

I've been toying with the idea of a Book of Mormon themed game for a while. The game won't be overtly religious, this is an exercise in making a entertainment product rather then a missionary product. Fun is still the main objective. But instead of zombies or aliens or the like it would be Nephites and Lamanite. The initial idea was an RTS describing the various battles from the war chapters in Alma. You've got generals, heroes, resource management, diplomacy. The backdrop is all there for an EPIC strategy game.

And there is the crunch. One man can't do EPIC with all capitals in between work, family, church and everything else that is this thing we call life. epic maybe, but not Epic or EPIC.

So my next idea was an infinite runner. These are pretty easy to build. Trouble is its almost two easy. The coding behind these games is pretty straight forward. The games get their appeal from content. Mostly in the form of art work. If Pond Wars taught me anything its that I should avoid games that rely on heavy art work.

But an infinite runner got me thinking heavily on the Tree of Life theme. Its one of the most iconic stories from the Book of Mormon. Every primary kid grows up knowing about it. And while its full of religious symbols, the actual content is not that religious. At the face value the story is simple. There is a tree. There is a path leading to the tree. Lehi is attempting to get people to the tree. There are a variety of environmental hazards (rivers, mists of darkness) preventing this objectives. This is all starting to sound like some backwards tower defence game.

So that's what I'm building at the moment. A sort of reverse tower defence game, where the objective is to build towers to help the critters reach the end. And you loose points for critters that don't make it. There will be some RTS elements thrown in as well, you'll be able to send out units to help.

One core mechanic I'm keen to include will be a light/darkness. Mists of darkness will actually prevent you from seeing what's happening in game. Critters will also be affected by darkness, with reduced line of sight and movement speed. Units like prophets and pastors, or buildings like temples, will all provide light to dispel darkness.

The other core mechanic will be faith. Critters with high faith will stay firmly attached to the iron rod, no matter what they can or can't see. Once they loose faith they will tend to wander at random and be subject to the various environmental hazards. Prophets and missionaries will increase faith, as well as buildings like chapels.

I'm currently working on prototyping the light/darkness system. Look forward to seeing a demo of this system soon.

Pond Wars

So I'm relaunching Pond Wars. This time the game is being distributed free. Play the game. Share it with your friends. Tell everyone you know. And comment here or send me an email if you have suggestions.

About the game

Pond Wars is a simple two player game. Each player takes control of a ship and attempts to destroy the other player. The game is designed to have two players on a single keyboard, in the style of classic games like mortal combat or wacky wheels. Player fire cannons at each other in an attempt to sink the other ship. The twist is that player can't aim. As cannon balls hit the water they create waves. Players must time their shots to the movement of the waves to aim their shots.

Where can I get Pond Wars?

Pond wars is playable online at Kongregate
You can also play it online on Facebook
Download Pond Wars for PC 
Download Pond Wars for MAC

This game is so awesome, I want to pay for it!

If you liked Pond Wars and want to give something back, share the game with your friends. Spam everyone on Facebook. Share screen shots and videos of the game. Send the game to reviewers. Write blog posts about it.

And above all, have fun playing the game!

Don't monetise your games: Response

So, the game development community has been abuzz with this blog post. The basic premise is this "New developers should not monetise and should instead focus on building their craft and reputation". There has been a lot of hate for it, but I think the post is right on the money. Here's why. My first game Pond Wars was released a few months ago. I spent a lot of time figuring out how to site lock it so no one could steal the code. I spent a lot of time searching for ways to place ads within and around the game. I even refused to release it on Facebook because I didn't get a share of Facebook's ad revenue. I signed up for a bunch of different ad networks. 62 cents later I was sitting wondering what went wrong. Ultimately what I missed was traffic. The game just did not get enough plays to generate revenue. All of my focus on monetisation had distracted me from making the best game I could make. There were areas of the game I knew needed polishing, but I'd spent that time developing a way to place a banner ad on the screen if it played in a webplayer I didn't have a revenue share agreement with. I'd ignored ninety percept of the casual games market by not deploying on Facebook. I'd ignored the desktop avenue. All for a measly 62 cents. After reading this article I'm currently in the process of rewriting the game. I'm striping out everything related to monetisation. Its surprising how deep monetisation gets enmeshed in a game. When its done I'll be rereleasing it in every format I can get away with. Sure, I won't make a cent. But I don't think losing out on 62 cents will break the budget. And this approach seems far more likely to let me earn dollars into the future. When I get to the point that I can guarantee my games will actually get played, then I'll be back to consider monetisation. Until then watch this space, I'll be releasing a version of Pond Wars for desktop and Facebook totally free in the near future.