Moving!

Hello everybody.
I'd like to let everyone know that I'm moving my blog. I will stop posting blog entries here, and instead post them up at my company site MoPhoGames.com
You'll notice the site appears somewhat unfinished (for instance, some pretty but unrelated stock art in the slides). That's because I'm no good artist, and I would really need graphic designers to make those slide images (also if you'll notice, I have a Hiring page because I'm looking for team members to fulfill basically everything I can't do - which is everything but programming)

Anyway, I will not be posting here anymore. If you want to continue following please refer to mophogames.com instead.

Oculus VR: FPS Integration Challenges

So I just got my shiny new Oculus Rift developer headset the other day. It is difficult to keep my jaw from dropping to the floor while using it - it truly is a sea-change moment as Valve is predicting.

I got started right away on getting support working in my game, which isn't really an FPS but definitely takes place from a first-person perspective and features guns (so it kind of is an FPS I guess, but doesn't focus solely on shooting).

Early on in the development of my game (before I had even considered Rift support), I decided my game would not have crosshairs. I feel that ADS-style aiming is where FPS games are headed, and it's deprecating the need for crosshairs. Hell, DOOM didn't need crosshairs - and if you think about it, DOOM basically took place from an ADS-perspective for the whole game (which is why it didn't need crosshairs).
It also gives gun attachments new meaning. In games like Call of Duty where you have crosshairs while hipfiring, they have to intentionally nerf the usability of the gun while the user isn't aiming down the sights. This has always annoyed me to no end - that if I aim down my sights, my shots magically line up, but the moment I don't hold the gun up to my face, my shots fly wildly around like my character is drunk.
Since there's no crosshair, I don't have to deal with this. The incentive to use ADS is that, well, you can see where your shots are going. It's something that anyone can just pick up and understand. The incentive to use a Holo Sight is that you get a handy crosshair painted onto glass instead of using the weapon's iron sights, the incentive to a laser pointer is that you can see where the gun is pointing from hipfiring, etc. It ends up feeling more realistic and more understandable because we're not just throwing stats at the player - we're showing the player that for instance aiming with a sight is objectively easier than iron sights, and infinitely better than hip firing, without having to explicitly tell them.

And now comes the problem. In your standard 2D monitor mode, the FPS is lined up smack in the middle of the screen.
This is a problem in VR. Want to see the problem first hand? Grab a paper towel tube, and aim down it as if you were firing a gun. You'll immediately notice that it's line up with one eye (probably your right eye, but maybe not if you're left hand dominant), and your other eye is either squinted or closed entirely.
Now try lining up the gun with the bridge of your nose instead. That's basically what lining up the gun smack in the middle looks like in VR, and causes significant eye strain.
It turns out, what you actually want to do in an FPS is pick an eye, and align the gun with that eye. By default this is probably the right eye, but you will also want to give players the option to use their left eye.

It's worth mentioning that this doesn't matter with motion controls such as the Razor - since the user will be doing the aiming rather than letting the game align the gun.

Thoughts on uLink and TNet

During the development of my game, I've been using Tasharen Networking for multiplayer (by the developer of NGUI). But now I'm looking at moving my game over to a much more well-known (and much more expensive) framework, uLink.

Why would I move from a $60 framework to a nearly $800 framework?
Simply put, my project has outgrown TNet.

Actually, it had outgrown TNet the moment I added multiplayer, but I hadn't realized it until I started working on interest management. Area of Interest is something that, it turns out, TNet is fundamentally not designed to handle. Nor are authoritative servers.
TNet is meant to act a bit like a self-hosted Photon Cloud - your clients connect to a server, players create and join "channels" (which are basically rooms), within each channel there is one single host, etc. There's really a lot of similarities to be drawn there. It's designed for the server to act as little more than a middleman for players to connect to each other.
That was a mistake on my part - trying to force TNet to act in a way it was not intended. To be fair it helped me develop my multiplayer logic (which will remain largely intact in the move to uLink) but the creator (Michael Lyashenko) actively discourages using TNet as a dedicated server.
The limitations became glaringly obvious when I tried to add AoI. This required ripping out TNet code and hacking in the concept of player scope. Days later I'm still hacking away with no end in sight (after coming close several times, I'm currently left with a game that doesn't even remotely work). It's taking valuable time away from working on the rest of the game.
So it's time for uLink. Unlike TNet, uLink was designed for this kind of stuff. In fact, MuchDifferent (the company behind uLink) set a Guinness World Record for most concurrent players in an FPS game - a nearly 1,000 player match between team Man and team Machine. uLink is designed for authoritative servers, and optimized for performance. Granted the 1,000 player match also used other technologies besides uLink (likely load-balancing tech like Pikko), but nonetheless uLink still remains my best option.
And that is why I dumped $800 on an indie UnityPark Suite license.

Progress of my game

Figured I'd post a little bit on how far I've come in my personal project. I'm not sure what to call it yet (Alien Skies is the working title but may and probably will change).
After so long researching and playing with open-world type setups in Unity, I've determined that terrain streaming is nigh on impossible in Unity without rewriting the terrain engine itself - everything takes FOREVER to do, from modifying the heightmap, to adding trees, to even culling the terrain (with many terrain tiles with trees on them, performance dropped whenever the camera frustum changed). It's not very optimized, unfortunately, and is one of those things that needs tons of work in future version of Unity.
Therefore I'm sticking with a naive one big terrain approach. Seems almost too naive to work, then again Operation Flashpoint, Arma 1, and Arma 2 all got away with it (terrain streaming is new in Arma 3). DayZ is using the Arma 2 engine, which means the entire world is loaded at once (although pieces of the world are likely disabled to reduce the rendering burden). So I'm sticking with a fairly small world (10km per side), no streaming, with culling masks to disable rendering of distant objects (which are assigned to various layers which affect the distance at which they cull, so small objects are culled sooner than large objects).

After settling on this, I finally got to working on actual gameplay. I set up a Trello page for myself so I could keep track of my progress, and a Git repository on BitBucket so I can check it into remote backup and eventually share it with people.
This being a multiplayer game, I had to evaluate what I would use for networking fairly early on. At first I was dead set on buying uLink. Then, after evaluating the actual features uLink provided I realized that I already owned Tasharen Networking which provides much of the same functionality I'm actually going to be using, with a little extra effort.
I also had to make a little build tool for myself, to make server builds of my game (which I need to do quite frequently). This was easy enough - the tool adds SERVER to the list of scripting defines, ensures that a special ServerStartupScene is the startup scene in the build (this scene automatically loads up the map and starts a TNet server instance), builds a standalone player, and then reverts those changes. I have build tools for both Windows and Linux, so I can just pick Build Windows or Build Linux Server and have a ready-made game server.

Gameplay-wise, I actually spent a lot of time working on the singleplayer prototype before adding multiplayer. I'm nearly to where I was before adding multiplayer now, which includes:
- GUNS! Player can equip guns from their hotbar. They can fire the gun with LMB, and shoot with RMB.
- Loot and inventory. Players can move items between hotbar and inventory, and between loot box and inventory/hotbar. There's also a handy Take All function (which actually means "Take as many as possible")
- Alien( capsule)s. Aliens currently spawn in mobs MMO style, which I'll eventually change to a kind of random dropship encounter (which sounds better? aliens popping in before your eyes, or dropships unloading an alien squad before your eyes?). They have a fairly simple behavior tree, which causes them to wander, or upon seeing the player alert nearby allies and start engaging/pursuing. If there's no line of sight to the player, aliens will pathfind to player, otherwise they randomly strafe back and forth while firing in bursts. They also lead targets (broken in multiplayer, but will be fixed soon enough), which makes their bullets very tough (almost impossible) to dodge at close range.

I've been hearing things about Rust and DayZ being chock full of hackers, so I've been very careful during the addition of multiplayer to keep things server authoritative. Using items is server authoritative (server calls Use method and sends back the results), looting and inventory (dragging and dropping sends message to server, which handles the actual drag-drop and sends the results back), weapons (equip weapon is server authoritative, sending results back to player, as is weapon firing - no entity rewinding so players will have to lead targets, but I think I'm OK with that)
My next task is to work on movement in multiplayer (and I'll make THAT server authoritative too! ain't nobody gonna be noclipping or super jumping).
And then?
I have no idea. More content? Team recruiting?
I'll see when I get there.

Keeping Track: Trello for Game Development

If you haven't heard of Trello, it's a free service which provides what boils down to a fancy to-do list.
In Trello, you have different categories. By default, these are To Do, Doing, and Done. You can also add your own categories.
To each category, you can add Cards. These are individual items, like say "Fix the sink" or "Buy milk". You can also move cards between categories (you might move a card from To Do to Doing, and then later from there to Done).
Trello also has a handy collaboration feature - multiple people can work on the same to-do list (or "Board" as Trello calls it).
As it turns out, despite being designed as a generic to-do list, Trello doubles as a fantastic project management tool.
You can create an "organization" in Trello, to which you invite other people, and then create a board private to that organization. You add as many categories as you need, and then use cards to keep track of tasks that need to be done on the project.
For instance, in my current project I have 5 categories: To Do, Bugs, Fixing, Doing, and Done. To-Do is for new features that need to be implemented, Bugs is for problems that need to be resolved, Fixing is for bugs which have been resolved, Doing is for features which need to be implemented, and Done is for any tasks which have been completed.
Even though I'm working alone (for now), I've found it immensely useful for staying focused and on track. Many times in the past have I tried working purely from memory, and I can say it almost never works. Keeping a list of things to do means I'm never sitting there trying to figure out what to work on next (and meanwhile losing the drive to work on the project). I add stuff to the To-Do list any time I think of something, move the next task to Doing, knock it out, move it to Done and immediately pick my next task.

Could I have done this with sticky-notes or a notepad? Sure, definitely. But Trello is arguably more convenient and paper-friendly ;)

Just Write A Game

When developing a game you're passionate about, sometimes you turn into a perfectionist. Hours of googling are sunk into researching shiny bits of tech that don't really matter. There comes a time when you need to quit obsessing and just write a game.

Just this last week, I became utterly obsessed with the thought of huge-scale worlds. ArmA of course was a big inspiration, supporting absolutely gigantic maps of 50km or even 100km, far eclipsing the size of games like Skyrim. This is made possible because ArmA is based on a military simulation engine, which was designed for accuracy and huge scale and uses double-precision to represent coordinates. I don't get this luxury out of the box in Unity, but I wanted it so badly I sunk hours and even days of research into fighting Unity to get what I wanted. Floating point origin, terrain streaming, and even customized builds of third-party physics engines - nothing was out of the question to me.

I never even came close to completing my research and testing, and haven't even come close to creating a semblance of a game with it.

I realized that I needed to put down Google, and actually write a goddamn game.

I mean, hell, 32-bit floats give me 10km away from origin. That comes out to a usable world space of 20km (from -10km to +10km on each axis, if the world is perfectly centered around origin) before precision issues kick in.

That's huge. It's nearly the size of Skyrim (actually 37km, but approximately a quarter is hidden behind invisible walls and artificial barriers). It's bigger than Chernarus from ArmA/DayZ, which as far as I know is 15km x 15km. For a mostly on-foot multiplayer survival game, that is massive.

Even if I could have enormous 50km maps, what would I fill it with? Big stretches of the map would end up barren, leading to a huge but boring world. Small, but interesting, worlds are better than huge, and boring, ones.

So I need to just stop worrying and start writing something productive.

The importance of custom-built solutions

It's only been somewhat recent that we've seen a massive surge in game development middleware. It used to be, not long ago, that games were entirely custom-built from the ground up. These days you can find an off-the-shelf product for nearly every task in game development, and you might even wonder where you would be without them.

But sometimes, you have a use-case so wierd, so uncommon, that there's just no product for you. You've tried everything, from the industry-tested AAA products to the backwaters-of-the-internet open source solutions, but nothing works.

And that's when you custom-build it.

I just recently encountered this while developing an open-world game project. The problem? How to make my AIs intelligently navigate a huge open world with pathfinding.

At first, as anyone would, I thought to myself, "There's such a HUGE number of pathfinding solutions for Unity. This should be a piece of cake!".

And that's where I was partially wrong. Yes, there's lots of them, but not a single one of them designed for even marginally big game worlds and also in my budget.

My first try was Unity's own pathfinding, basically a port of Recast. It failed right out of the gate, since it couldn't even export the scene data to be voxelized within a reasonable length of time.

My second try was Aron Granberg's pathfinding. I never had much luck with this one in the past, but I gave it another shot. Still no luck - it's grid generator seemed to have severe trouble generating a graph for such a large terrain.

Eventually I realized I needed something highly customized to my needs - something I wouldn't be able to solve with money. Time to break out the elbow grease and the thinking caps.

The problem here is that my world is designed a bit like Arma 2. There's a big 10km^2 island, upon which are various buildings which can be entered. Said buildings will NOT be separate zones, but luckily will be fairly simple (just a few rooms and hallways, not more than a couple stories, etc).

I figure I can divide this into separate graphs, which are somehow linked: A grid graph for my outdoor area, and a waypoint graph for my indoor areas. These will be linked with special navigation nodes (which I'll call "offmesh links" for lack of a better term).

My outdoor grid graph is simply generated based on the terrain's heightfield and "occluder boxes" (which I would use to punch holes in the terrain navigation grid). One really nice property of A* is that it does not explore much more than it needs to - so if my AIs are only chasing nearby opponents, even with a huge world there's still a fairly light workload on the pathfinder. I've also decided that I will not make the grid fine-grained enough to represent trees - it would take up a hell of a lot more memory than I would like, and I can just stick in some simple obstacle avoidance to navigate around trees. I've found a 512x512 grid represents my terrain quite nicely then, if I don't care about trees. I also added a cutoff to the pathfinder - if it explores more than 1000 nodes, it simply quits. This number is large enough that the AI can pathfind halfway across the map (I specifically tested this), but still small enough that if the AI tries reaching an unreachable island it will exit out long before it exhausts the search space.

One thing I needed was to make my pathfinding algorithm as generic as possible. To that end, I created interfaces for INode, IGraph, and ICostEstimator. A node has a position in the game world, a G and H cost (I don't really care about costs for traversing individual nodes, but that would be trivial to add), a graph it belongs to (entirely optional - for instance, offmesh links are technically INodes but do not belong to a graph), and neighboring nodes. A graph simply contains nodes and can locate the node nearest a particular point. A cost estimator estimates the H cost between a given node and the goal node (currently implemented are Manhattan and Euclidean).

Waypoint nodes have explicit neighbors - baked at design time by raycasting to waypoints in the same graph. Grid nodes, on the other hand, have implicit neighbors - these are calculated on the first request and cached for subsequent calls.

My waypoint graph also has a bounds property, which represents the extents of the graph. This is used in order to locate the nearest INode to a given world position - first all waypoint graphs in the scene are queried to check if their bounds contain the point. If one does contain the point, it is queried for the closest waypoint. The terrain grid is also queried for the closest point (which is found by quantizing the point and converting this to a 2D grid index). Whichever of the two points is closest is chosen.

This is used for two purposes - one, for pathfinding (first the start and end nodes are located, then pathfinding is performed), and two, for offmesh links.

Offmesh Links as mentioned before are a way to link my grid and waypoint graphs together. An offmesh link is a special type of node with exactly two neighbors. On startup, these neighbors are located by finding the nearest nodes to two points, and then the offmesh link is registered as a neighbor with both nodes (and therefore becomes a shared neighbor of both). By, for instance, placing one side of the offmesh link inside a building, and the other outside the building, the inside one will locate a waypoint, and the outside one will locate a grid cell. These two are then linked together via a shared neighbor. These nodes would be placed, for example, at the entrances of a building. The nice feature is that they don't care which type of nodes they link, so it's entirely possible to link two grid cells (for example, if there's a teleporter). If I wanted, I could also associated extra data with an offmesh link such as an enum of what type it is (for example, I could specify that a particular offmesh link is an elevator, which the AI would respond to by waiting for the elevator to arrive, getting in, waiting for the elevator to arrive at the appropriate floor, and getting out).

It took me two days to accomplish all of this, but it was well worth it. I added some extras as well, such as multithreaded pathfinding (all pathfinding work is offloaded onto a separate worker thread) with callbacks for when a path request is serviced. Pathfinding is reasonably fast, and agents can not only pathfind a fair around the world, but they can also pathfind in and out of buildings. None of this could be provided in a third-party solution, but was fairly quick to accomplish and fits my needs perfectly. It's also pluggable, which means I can reuse it in other projects and extend it (for instance, by adding navmesh support).

And that's why it's important to custom-build stuff - because when you're making a game that few others dare to attempt, you've got no choice but to build it yourself.