New Build –

Build is out – lots of new stuff! Been a pretty productive couple of weeks, considering that life has been pretty busy lately. My goal is to keep pushing builds out every 2 weeks.

Here’s a video update:

…and as always you can check out the latest webplayer.

Some cool technical stuff happened. Here’s an overview of the progress that was made:

Entity Generation Code

Whenever a new item (deemed ‘entity’ in my code – I guess from Half-Life modding experience..) is added, there were a ton of manual steps that had to be done:

  1. In Unity, create a new prefab for the object
  2. In Unity, add a special behavior for the object – this held two pieces of information: a short for the network ID, and a string for the “network model” – which is a shared class that is cross-compiled between the client and server. This is the “model” of the object – containing the data that needs to be persisted across the wire.
  3. On the server, create an entity object, that exposes a “Type” parameter, which matches the type in Step 1.
  4. Implement necessary client / server logic…

So I guess that doesn’t sound too bad. But what about when we want to create a bunch of objects (so that the world will be more populous and not the barren, sparse terrain it currently is?) In addition, there are a bunch of properties that need to be kept in sync between the client and server. For example, in the old system, if I change the size of an inventory item, I had to change it in two places – in the client, and in the server. Even worse, if I forget to keep those in sync, it ends up creating difficult to troubleshoot bugs. Lastly, sometimes there is “metadata” about an object that doesn’t change, and both the client and server should know about (ie, the network model to use, the name of the object, etc).

Because of the pain points I was starting to hit, it seemed like a good time to do some work to improve the system. The way I addressed this was as follows:

  • Create a single source of truth: Entities.xml
  • Generate the client-side instantiation code from this
  • Generate the server-side instantiation code from this

Here’s some example XML for one of the weapons:

And then the Unity output:

And the Server output:

A little ugly, for sure. The transform is done using the T4 Template Tool, which is a useful tool for doing any sort of this code generation. Luckily, the code is pretty simple – and the advantage of only having to edit a single “source of truth” seems worth the tradeoff. The XML parsing strategy I’m using allows for “templates”, which enable creating lots of entities with minor variations.

Client / Server AI System

Another part of the project that got some love was the AI system. Previously, the AI I had implemented was purely on the client side.

When I started moving it to the server,, there were a lot of interesting trade-offs to consider. For example, at what level do I keep the state sync’d?

  • Do I sync the animation frame of the NPC?
  • Do I sync the exact position of the NPC?
  • Do I simply sync the state and target, and depend on the AI working the same on each client?

Each level has different trade-offs. Keeping the animation frame in sync between the client and server seemed overkill, with little gain, so the client is purely responsible for managing the animations. The last option, seemed too loosely coupled, and could create diverging state between the client and server. Keeping the positions in sync seemed like the best way to go.

The way I ended up implementing this was sending down the current goal entity and the distance. The client would run the logic to “chase”, modulating the speed based on how close it is to the current goal entity vs. how close it should be based on the last server update. This seems to work pretty well so far, and clients tend to see a consistent picture. Although the position of the monster might not be exactly accurate, it shows the correct relation between the target and the entity. It seems to work pretty well, so far, although there are a couple issues that need to be worked out. For example, the server doesn’t care about the rotation – it models the entities as a sphere that can attack in any direction. However, the client has a sense of direction, so while the entity is spinning to face the player, it is a bit out of sync.

A few other pieces…

  • Made items respawn – the coins respawn quickly, and the monster respawns approximately every 10 minutes!
  • Made the monster lootable – right click on the monster to get loot (if you’re the one who killed it)
  • Some inventory bug fixes, and added support for combining stackable items
  • Some networking bug fixes, and additional tools like ‘fakelag’ to simulate high latency conditions
  • Some UI tweaks (title of NPCs)

…and next steps:

I’m planning on dividing the work into month-long “sprints”. For this September sprint, I’m planning on tackling some built up code debt and doing some infrastructure work:

  • Server logging
  • Incorporate powershell scripting interface for the server, for faster debugging
  • Replace PhysX with BEPUPhysics on the client, to fix performance stuttering
  • Track some connection-related statistics (bytes over wire, packets received, packets sent, etc)
  • Fix some networking bugs (buffer length issue)
  • Fix Connect/Disconnect (they are currently run on another thread)
  • Implement an interest management strategy. For this sprint, just something grid-based
  • Implement partial entity updates – right now, the entire entity state is always sent, even if it hasn’t changed
  • Implement connection sequence – right now, players are spawned as soon as the TCP connection is created

Thanks for checking out the blog!

Posted in Uncategorized | Leave a comment

New Build – – Multiplayer!

Lots of updates! I posted a video update here where I gloss over some of the new features:

I didn’t go into a lot of details, just a tour of some of the new functionality. The biggest milestone is the addition of the client/server (as well as a master server, to keep track of available hosts). Here were some interesting considerations I made in the past week?


I know from experience that implementing a networking layer is a lot of work. My friend and I in college made a networked first-person shooter in XNA, without the help of a library like Lidgren. We didn’t really know much about networking at the time, so we implemented a few no-nos (a reliable TCP layer + an unreliable UDP layer – not really a good setup for the way traffic management is handled). However, it worked, at least for a LAN, and did what it was supposed to.

Later, I had some great experiences with the Lidgren library. This library had everything you needed to set up a client/server game – complete with various levels of UDP reliability (unordered/unreliable, unordred/reliable, ordered/unreliable, ordered/reliable) – so you had a lot of options! In my ideal world, I’d use UDP, as it allows for better real-time processing.

That being said, I want the game to be easily playable in the browser. I want to keep the barrier to entry to playing ExoCraft really low, by allowing players to always load up the latest version in the browser. UDP is simply not an option for the Unity-hosted webplayer. So, I’m turning to TCP, and so far its been pretty straightforward. It is so important to turn off Nagle’s algorithm for TCP, though! The most common complaint with TCP is that it sends slowly or unexpectedly, and this is actually by design – TCP wants to be as efficient as possible, so it batches up data before it has enough to send. This means that small packets won’t get sent immediately. For things like web sites, this is beneficial, but for things like games this is a hindrance. Once that is off, I saw decent performance – I think good enough for my game (which won’t be a real-time twitch FPS like Counter-Strike).

Any libraries to make my life easier?

I wanted to check out and see if there were some libraries to make my life easier, in terms of implementing this. Implementing a networking solution takes a lot of time, there are lots of corner cases, and if someone has already done the groundwork and can make it easier, it might be worth looking into that solution for time-savings.

I looked at the following solutions:

Out of SmartFox Server and Photon Server, Photon seemed the closest to fitting my needs. However, when I downloaded the SDK, there was no solution that I could “just run”. I was able to get the photon server running easily – but there wasn’t a Unity project that integrated with it that worked out of the box (I was trying the island MMO extension). I was able to get the WinForms interest management app they provided working – but this wasn’t so useful for me. I realized I was spending more time debugging than I would if I just had my own code, so I decided to skip out on Photon for now.

Starting from scratch….

So then I worked on my own TcpClient / Server setup. Luckily, I had some code I used for a previous game project that had the basics – and also had some other nice things like using a RecyclePool for Packets to keep the garbage collector at bay. However, it was still a lot of work to get the bugs ironed out.

Also, the architecture I ended up choosing was XNA + .NET for the server, and Unity for the client. This is interested because both XNA/.NET and Unity are in C#, so there are potentials to share code (which is what I planned on doing – so for example I wouldn’t need two inventory container solutions – I could hopefully cross-compile between the platforms!). This actually worked out pretty well – I keep my Mono projects open in visual studio, and can compile them to check for errors – I still have to run monodevelop to build the Mono dlls, though, to copy over to unity.

The tricky things in sharing the code are slight differences – for example, XNA has a Vector3 class that has .X, .Y, .Z (uppercase), while Unity’s Vector3 has .x, .y, .z (lowercase). I currently handle these with a few #ifdefs – luckily they are not too numerous.

The worst bug that I had to handle was this nasty issue where I’d get duplicate packets, or lose packets, or get duplicate packets. The way it reproduced for me was during test, when I’d type a chat message, sometimes I’d lose the message, or sometimes it would show up twice. It was really bizarre, and I spent a long time trying to narrow down if it was a client issue or a server issue, with not a lot of luck. I was really confused because I thought it might be at the TCP level – but this kind of stuff isn’t supposed to happened with TCP! I ended up tagging and logging the packets based on their location in memory, and it turned out that the packets were being re-used immediately by the RecyclePool once the RecylePool ran out of memory. So in some cases, an existing packet would be overwritten (if it was re-given out by the RecyclePool before being processed). Both the client and server use this shared code for managing packets, so this could happen during either send or receive – which is why it is impossible to isolate the culprit, since either the client or server could be at fault. Once I fixed this bug, things worked great :)

There are a few more issues I need to work on with the networking:

  • Handle large entity updates
  • Handling oversize incoming packets

…and eventually, some things I’d like to add to the server:

  • Interest management – only send entities close by
  • Delta updates – the infrastructure I’m using supports this, but I need to keep a track of the deltas for each client, on the server

This post has gone long enough, but I also implemented the following:

  • Moving the inventory code to a shared place – compiled into both client & server, so that they respect the same inventory rules
  • Set-up all the entities to be networked
  • RPC + Chat System
  • FakeLag diagnostic tool to simulate high-latency situations

Some stuff that’s coming in the next update:

  • A networked, huntable monster + spawn points… hopefully along with the ability to get loot
  • Consolidated XML based network entity infrastructure (will talk more about this in the next update)

I really need to get some gameplay here so that there is stuff to do in the world!

I also had the pleasure of playing a beta version of Astralis(video) – developed by some friends of mine – had a blast playing it, and I highly recommend checking it out when it gets to the XBLIG store :)

Posted in Uncategorized | Leave a comment

New Build – – Inventory System

Over the weekend I added a basic inventory system to the game. This uses a drag-and-drop inventory system along with quick slots that will be familiar to RPG games. This can be accessed using ‘I’ during gameplay. There are a few minor bugs with it that I put on the backlog:

  • Weapon bobs while moving the mouse around
  • You can move the selected weapon out from the quick slot, but it doesn’t get unequipped
  • The hover indicator on the UI for the inventory panel stays when leaving the panel

In addition, there are some items that I’d like to add shortly:

  • Have a “world” representation for the inventory objects – right now, you can’t drop/throw them, and I’d like to do that
  • Consequently, there’s no way to pick things up from the world right now – so I’d like to add that soon!
  • Be able to “loot” fallen enemies – have them have their own inventory container
  • Implement stackable items
  • Implement dragging onto world objects

Overall, the development for this feature was pretty straightforward. I had a lot of code in XNA for managing UI – basic input handling, panels, containers of panels, etc, and porting that over to Unity was fairly straightforward. There were some things to get used to (like the GUISKin / styles concept in Unity, as well as other things like controlling depth of objects – for example, the item being dragged should be drawn on top of everything else).

An interesting learning curve when working with Unity was the notion of the “Immediate UI” – vs the “Retained mode UI”. I’m going to spare the details for another blog post (a decent introduction to the concepts is in this stackexchange post: Immediate GUI: Yay or Nae?, but coming from a WinForms / HTML world (in addition to the previous UI systems I’ve worked with, like VGUI in Source, and systems I’ve developed myself for games), I was used to the “Retained Mode” world. There are some things I like about Unity’s immediate UI – it’s very fast and easy to prototype, and very transparent. However, for complicated interactions like Drag-and-Drop, the stateful nature makes it very cumbersome to try and track in immediate UI – instead, its much easier to delegate pieces of the complexity to objects instead of trying to deal with it all in one place, which the immediate mode UI tends to gravitate towards.

Posted in Uncategorized | Leave a comment

New Build – Adding some AI…

New Build for 7-21-2013 – added a few features this weekend:

  • Made the weapons shootable – the Ultimate FPS Camerahelped save a ton of time! You start out with a rifle, but there are a few others – you can cycle through with 1, 2, 3, 4
  • Added crouching (‘C’) and running (‘Shift’)
  • Put in some sound / muzzleflash effects
  • Added health for both the player and the monsters
  • Added a particle effect for when the monster is damaged
  • Added some initial UI pieces
  • Built some AI for the enemy – now it chases, the player, and can attack.

I spent the most time this weekend on the AI – I added a planning infrastructure, which does 3 things:

  1. Selects a target – this could be an enemy to attack, an object to pick up, or a friend to escort.
  2. Selects a plan based on the target – for an enemy, this might be attack or retreat, based on various factors like the health of the creature. For a friend, this might be move closer or give an object.
  3. Executes the plan using a series of actions. For attacking an enemy, this might just be MoveToTarget and then AttackTarget

Right now… the first two steps are really boring. The target selected is always the player, and the plan selected is always attack. However, I think that this should provide a good platform for extensibility. Having an interesting AI to work with while the player is exploring the world is going to be very important in making the game fun.

In terms of next steps, I’m going to be looking into a couple of things:

  • Setting up an inventory system – initially, I’m going to start with just a few quickslots. Eventually, this would build into a full inventory system, where you can loot the monsters in the world or trade with other characters.
  • Improving the procedural generation – the framework I put together for the procedural generation is a good starting point, but its tough to tweak and add biomes right now. I’m going to work on improving the tools so that the procedurally generated world can be a bit more interesting to explore

Here’s the latest build:

Posted in Uncategorized | Leave a comment

First Post – Not even close to being a game yet..

Very first build…. Not much to do in the world, yet :)

Features implemented so far:

  • Endless procedurally generated terrain
  • Biome system based on rain, temperatures (although there are only two biomes, so it’s not very interesting yet!)
  • First pass on vegetation
  • Added in an initial creature near where you spawn – there are currently only one, but eventually these will be procedurally generated as well
  • Added a weapon for the player – just for show for now :)

What I’d like to go for is an open-world adventure game, that is dynamically generated, but has elements of building sprinkled in. I’d like to add vehicles that the user can customize in interesting ways, and the ability to mold the environment with structures. Obviously, there is a long way to go until all those features make it in!


Posted in Uncategorized | Leave a comment


For about the past 6 months, I was working on a spaceship building game called ExoCraft:

I was using the XNA framework, along with some great libraries like BEPUPhysics. The goal was to create a spaceship building game, and be able to pilot and adventure with ships that the player’s creations. Things were going pretty well – there were a lot of neat things you could do to build your ship, and engines and ship systems were working.

However, I hit a block in terms of the game – I couldn’t really figure out how to wrap it up and package it into someting that was fun. It was pretty fun to build a ship, and fly it, and especially destroy other ships… The building, though, felt awkward – it was hard to build a real ship out of the blocks, and I wasn’t sure how to fix it. There were some great features in it that I was really proud of – the interactive consoles, for example.

Another issue is that my free time has been very limited lately – so it was difficult to make progress on a few hours every weekend. I’d often be spending my time taking deep dives and debugging low-level shader issues (which I enjoy troubleshooting and tweaking), or some complicated physics issue. Although I enjoy these sorts of problems, it wasn’t the best use of time in terms of actually getting a game out the door.

So I decided to take a break from that project, and try a new approach. I started learning Unity – which is really great and allows you to focus on the game. I was able to port a lot of my XNA code over relatively easily (like the voxel engine I wrote), and surprisingly it performs faster in Unity than it did in XNA – presumably because Unity implements some optimizations like culling and batching that I hadn’t gotten around to adding in XNA. So overall I’ve pleasantly surprised by Unity’s features. There were certainly some learning curves but I’m feeling more and more comfortable with the tools.

Instead of working in a box in 6 months, and getting stuck, I think a better approach to build a fun game is to get a release out early and (hopefully if people see this…) get great feedback on it, to stay motivated on the project, take it in a fun direction.

Thanks for visiting !


Posted in Uncategorized | Leave a comment