Unity3D At Home Project - Day 12 - Explosions and Stuff!

So first apologies that this next update took a little longer. First - Thanksgiving. And second, and this is more to the point - but ran into quite a few problems working through the next pieces, and it took longer than I would have liked to get everything working the way I wanted it to. And there are still issues, but it's time to post an update! We've got quite a bit to cover in this one, so let's get to it!

Unity3D At Home Project - Day 11 - Weapons & Effects

So now's the point of the project where we roll up our sleeves and really start to dig in. I talked about all the ways in which our design space can go in last week, and about constraining your execution as much as possible. But even so, we just have a heck of a lot to go and build. I've got a lot of ground to cover in this blog alone, and we're still only about half way through implementing a single weapon. So let's get to it!

Unity3D At Home Project - Day 10 - From Simulation to Gameplay

So this is a bit of an interim post, where I just talk about game developery things, without having done real work on the game itself. As such, it's likely to turn into a rambling diatribe that no one actually gets to the bottom of, but there's a process that happens here - it's really important - and one of the reasons I'm doing this blog as I make this game is to share the things I've learned from fifteen years of game developement. So here goes.

Unity3d At Home Project - Day 9 - Twistin' by the Pool

So this week is a story about getting sidetracked, about building things you didn't expect to build, and that sometimes it's exactly what you need to do, and sometimes it's exactly what you want to avoid, and of course there's no easy way to tell the difference.

Unity At Home Project - Day 8 - Sound Effects

First, I have to start off with stupid things I do. This morning, I blew almost the entire morning trying to find a good plugin, piece of javascript, whatever, to allow me to imbed code snippets into blogger. Sadly, while my C# is strong, my javascript is weak, and though I found several alternatives, I was at every turn foiled in some way or another. Two hours later, I'm no better off than I was before, but out two hours of my time. I'm still fuming about it, so I just had to put a quick rant up. I'm sure I'll tackle the problem again, or maybe use a GitHub gist.

In the meantime, let's talk about this week's goal - getting some sound effects on our walking mechs. Again, my original goal was pretty simple - get an engine sound, and some walking legs sounds on the mech, and that's pretty much it.  Of course, as we'll discover, even the most simplest of goals can be fraught with peril!

Unity3D At Home Project - Day 7 - Walking with Robots

So it's time to move into the next phase of our project. We've done some simple experimentation, and dabbled in some of the core pieces of a 3rd person action game. We created terrain, texturing hills and mountains, and learned about how trees & foliage work. We got a character controller and a camera controller to allow us to drive a character around. We mapped some animations to a simple biped, and learned about the animator controller. And we established simple multiplayer support, connecting a client to a host, and letting two players run around the world together.  But none of this is giant robots fighting each other, which is our goal. So with our base pieces in place, it's time to say goodbye to Unity-Terrain project, and start working with giant robots.

Unity3D At Home Project - Day 6 - Multiplayer

So as you've probably come to realize the "Day" in the title really isn't significant. I could be "Issue", or "Section", or "Chapter" if you like. It's really just a way for me to designate each subgoal within the project.  And that's really important - subgoals. When you're making a game, the entirety of the game itself can be incredibly overwhelming. Menus, scores, multiplayer support, weapons, animations, the list goes on and on and on. And a lot of times you're going to be thinking - what next? How do I get it all done?

Your ability to compartmentalize your game into sections - and more importantly - systems, is going to be one of the most valuable skills for you to develop. Pick out a specific section of the game, decide what the goals are for that section, and implement it. But all of the pieces of the game are intrinsically interconnected. And most pieces build upon some other piece. Which is why it's not only important to decide which section you're working on, but what order are you going to build the sections of your game. For instance, I wouldn't spend a huge amount of time focusing on building a level in my game until I had a better grasp on the gameplay - because those things are going to shape level design.

Unity3D At Home Project - Day 5 - Unity Update & Version Control

So wow, it's been a few weeks since my last update. Let's see, first I am pretty much swamped at work, and unfortunately things are only going to get more swamped. And there was a trip to Boston for three days to attend the Unity Unite conference. But that was a good thing, because coming back from Unite I feel re-invigorated about Unity development in general, and had a host of even more things that I wanted to try and do.

So let's refresh. Currently, our At Home project is still mind numbingly simple. We have a brain dead camera controller, we have a character controller, and an animated bipedal humanoid. We've created some terrain, set up a skybox, and laid down some grass & trees.  It looks like something, but it's far from being a multiplayer robot-shooter, as promised! So along those lines, the next step I think is to set up multiplayer for the project. Support for multiplayer is going to create an entirely new infrastructure layer for the entire project, and just about everything else we do will sit on top of it. So it's best to get it in and set up early, and the start building on top of that.

But before we even go that far, I had a little prep work to do. I needed to do two things - one was upgrade to the latest version of Unity, and the other was to set up some sort of revision control.

Unity Upgrade
So why upgrade? This is actually a bit of a departure for what you would do in a commercial project, so I can't necessarily recommend it for your own work. Typically in a project, you might upgrade once or twice during the early stages of development, but pretty soon you want to lock in on a specific version, and stay with that. Why? Because each time you upgrade the engine, you introduce the possibility of new errors, new changes to the way things behave, and in general it's a level of instability that you have to deal with. So you have to weigh the cost of dealing with whatever instability the upgrade brings against the value of whatever features it provides. And as you get further into your project and get closer to shipping, the cost of any instability, no matter how slight, is usually not worth the risk.

Unity's Cloud Services

But because this is an experimental project, and the whole point of this project is to learn about and play with some of Unity's most recent features, I've decided that for this project, with each new major version they release, I would I turn, upgrade to it and roll it in. So as I was currently at 5.1, and they'd already released 5.2, I needed to upgrade. And 5.2 brought a whole host of fun new things, most notably the integration of all of their cloud services directly into the editor. So things like Analytics, Cloud Builds, and yes, even some of the multiplayer stuff, can all be accessed directly from within the editor.

Remember what I said about Upgrades?
So yes, even though this was an upgrade of only a single sub-version, and my project  literally consists of only stock assets from Unity, after upgrading to 5.2, there were issues. All of the trees in my terrain suddenly had blocky leaves, and I was getting errors from SpeedTree about invalid materials. Now these are just stock assets, I  didn't set them up, and I don't know jack about how they work. So a little bit of google-fu later, I learned that all I needed to do was revisit each material in turn, and click the "Regenerate Material" button for each asset, and resave the scene. That did, in fact fix the problem, and shortly our project was back to normal, and now running under Unity 5.2. But just tracking that problem down and getting it fixed took the better part of an evening. So caveat emptor - do not take any engine upgrade lightly.

Version Control
I'm not going to dedicate much time in this blog to describing what version control software is, or why you need it. There are a ton of guides out there, and every piece of software has it's own collection of beginner's tutorials. Linked below is a very nice overview and introduction, if you're not terribly familiar with the concept. I will though add this thought. Even if you're a one person team, working on only a single game - you need version control. It shouldn't be considered an option, or a nicety. It should be considered mandatory. And here is why.

Even if you're a single person working on a project, version control software gives you the freedom to try dangerous and experimental things with your code. To go down an alley just to see if it pans out. And if it doesn't, you always have the previous version of the code to roll back to. And this is really important.

So as we were about to add the multiplayer layer to our game, and this is going to significantly increase the size of the project, I decided now was the time to get some version control for our project set up. And the first, and probably most difficult decision to make, is which software to use. For me, initially it wasn't even a question. I'm a Perforce guy, going back for years. Just about every project we've built at Robot (and Ensemble before) used Perforce. And when I spent two years working on my own project at home, I had a Perforce repository set up. It works, I'm familiar with it, it's free - just get it in and working.

But Perforce through me a curve ball this time, and in so doing, it opened up an opportunity for me to branch out a bit. (See what I did there?  Jeesh.. programmer humor.. it's the best) See, the latest version of Perforce's software - Helix, puts its evaluation copy inside of a VM machine appliance. And, quite frankly, its a huge pain in the ass, and is a terrible barrier to put between their software and someone who just wants to try it out. The first thing you have to do is download and install some other piece of software - Oracle VirtualBox, or an equivalent, to host the virtual machine. Then you download their 1.2 GB appliance, and import the appliance into their virtual machine. Which means now you're running a virtual machine, a server inside the virtual machine, and that has to run continuously on your server computer - which is probably also your development computer. But to make it worse - for me, it just flat out wouldn't work. I got everything installed and set up correctly, but try as I might, the browser and client software simply couldn't see the server. And after three full mornings of jacking with it, including rummaging through firewall settings, installing on two different machines, etc., I had lost all patience to mess with it a moment more.

So my next thought was, well screw the evaluation VM appliance, let's just install their production server, and set it up.  But then I thought.. wait a minute.

So as I've said, I've been a Perforce guy since day 1. But there are of course a ton of other solutions out there. And I've dabbled with Git, and SVN on a few other, previous occasions, but never really given them much of a try. And I kept hearing on the wonders of distributed revision control, and more importantly, seems like everyone is hosting a project on GitHub these days, so maybe now was the opportunity to learn something more about these, and set this up in the cloud. So that is what I - somewhat begrudgingly, I have to admit - did.

Git & GitHub
So you can just set up plain 'ol Git on your host machine, and host your own local repository, and check software and code directly in and out locally, if you wish. And if you do so, I can assure you it will be no less arcane. Typing cryptic command line commands into Git Bash will have you feeling like your Neo and it's gawddamn 1995. I kept expecting the command line cursor to suddenly start typing on its own to tell me to follow the White Rabbit.

But the GitHub site has a desktop client you can download that does a nice jot of hiding Git's squirrelly commands away from sight, and lets you set up a local repository, and keep it in sync with the remote repository at GitHub. One detail to know about GitHub, and this is an important one - the free GitHub membership only allows public projects. So unless you want to pay, your entire project will be downloadable and viewable to the public at large. I understand that if you don't want your project to be public, BitBucket provides a suitable, online repository that is private, and supports up to 5 collaborators.

So with a relatively short amount of time (a few hours, in total), I had my repository set up, and my Unity project hosted within it. I made a few small changes and tested some commits, and everything seems to be working swimmingly.

And that's that! Not only do I now have version control set up for my project, but I've made it publically available for you to download and peruse, which is in keeping with my desire to make this project more open. I'll provide a link below directly to the repository.

Next time I'll get back to work on the game itself, and hopefully the next blog you read will be about how successful or not I am with integrating multiplayer directly into the game.

Some useful links:

The Unity3D At-Home Project on GitHub
The increasingly inaccurately named Unity-Terrain project on GitHub

Introduction to Version Control
A really nice overview of version control.

Basic Git
If that's your thing.

GitHub Windows Desktop Client
Providing a nice interface between GitHub and your project

Beginner Unity Basics #20 - GitHub and Version Control
And excellent, concise tutorial for setting up your Unity Project on GitHub from Frosty Gaming. Good stuff.

Unity At Home Project
The Master Blog Page for the At Home Project

Unity3D At Home Project - Day 4 - Basic Animation

Busy weekend, busier week, but I did manage to sneak in a little bit of time on Sunday to play around with simple animation, and to get our avatar animated.

Unity3D At Home Project - Day 3 - Basic Camera Controller

So I finished off Renaissance Coder's character controller tutorial (you can find it here) with implementing a basic camera controller.  And by basic, I mean really basic. You give it a target, and it slaves its position to the target, plus an offset that you give it. For orientation, it just interpolates from its current orientation to that of the target. Even though it was a fairly small piece of code to write, I still learned a few interesting things, and had some hiccups.

Cool Things

Mathf.SmoothDampAngle
This does rotational interpolation for you. You give it a source value in radians, a destination radians, and some time values that determine how fast you want the function to interpolate towards your destination. It returns an updated angle, and also modifieds a turn velocity float that you can use in successive updates.  Really handy function.

LateUpdate
I'd forgotten about LateUpdate, but this is an update function that occurs each frame after normal Update and all of the FixedUpdates. By updating the camera position and rotation in this function, we ensure it happens after the other updates.

Hiccups

My initial offset for the camera position had the sign of the Y offset reversed, which placed the camera somewhat inconveniently underground. While cool and interesting, wasn't exactly the effect we were going for.

The other thing I noticed immediately after my first test was that the camera was still facing straight ahead - not actually looking at the player. The tutorial had mentioned an X-tilt factor, but had failed to ever actually hook it up and use it. I converted the value to radians, applied the rotation to the target's X rotation (which is always straight ahead), and then used the editor to adjust the value until  we got to something close. What was interesting was that when I changed display resolutions, the amount of avatar in the camera field of view changed. Which goes to show you the kind of BS you actually have to deal with when building a real camera.

You can see the functional camera below.

Notice my gravity quotient is way way too low, so when I go sailing off the tops of hills, I only sort of gently float back to ground over time. Also notice even the leaves of the tree have collision, lol.

What next?
Well I'm not 100% sure. The camera controller is functional, but only barely. There's no orbit control, and there's no collision. But building a robust camera controller can be a pretty dark rabbit hole - correclty and intuitively handling camera collision is a non trivial task.  So I could leave the controller alone, and move on to animation. But by the same token, the current camera is by no means near adequate, so we'll have to see.

Unity3D At Home Project - Day 2 - Simple Character Controller

So the  Standard Assets pack comes with a 3D character controller right out of the bag. And it's fairly functional - does everything you want it to do.  In fact, it's actually a little more complex than I want for first pass.  Their 3rd Person character controller contains separate components for the Controller, an Input Controller, a Camera Controller, and an Animation component, and contains code to handle interactions between all of those.

I'm trying to put pieces together piece by piece, so what I really wanted, to start with, was just a very simple character controller. Renaissance Coders YouTube channel came to the rescue, with a great, nofrills character controller you can code up in literally about 20 minutes.  You can find their tutorial here.

This allowed me to get a simple, functional character controller up in the afternoon, and I completely understand all the pieces. I also added a capsule collider to my avatar mesh (Ethan), so he would collide with the trees as I moved him around.  Once I added the capsule collider and set it's offset appropriately, I could turn on gravity on the RigidBody.  

One other interesting thing I learned here was that you need to freeze rotation on the rigid body in all three axis. The first time I tried to move poor Ethan, he fell flat on his face, and then I could only move him up and down. We have zero tie-to-ground code here, so if the unit runs up against the tree, for instance, it only slowly moves back down to the ground, based on gravity.

This controller is super simple, and there's a billion lines of code to write here for it to become an game-ready controller, but it fulfills our purpose of being able to move the unit around.

Here's a video:

Unity3D At Home Project - Day 1 - Terrain

I wanted to start with a simple terrain, using stock assets. Worked my way through a three-part tutorial, creating and sampling along the way. Stock assets provides a nice small sample of terrain textures, trees, and grasses. Very limited, but enough to play with.

Terrain was created, and I played around with the height tools, and foliage creation tools. Biggest disappointment was that I see no way of doing height-limited painting. I'm sure there are some third party tools that provide that, but it was a nice default feature in Torque.  I dropped in Ethan, the stock character, for reference.

I also created and set up a light procedural skybox. Options are available for three different kinds of skybox, but the stock assets sadly don't provide any skybox-ready textures.

Ethan - Lost in the Weeds!

Unity3D At Home Project - Introduction

So, I find myself at a curious point in my professional career. By now, you probably know (or should) I'm a game developer. I work at Robot Entertainment, where I get to work on some pretty fantastic games. Right now, I am the Project Lead for the dashboard. The dashboard is the application you use to launch the actual game. It handles all your inventory, your decks, provides access to the store, etc. In short, it's a pretty darn big project in and of itself, and its written entirely in Unity. As I've been working on it for over 15 months now, I've become pretty proficient in Unity. But, the dashboard is an application. And while it's got some very game-like aspects to it, it is not, strictly speaking, a game in and of itself.

Balance of Power

One of the most frequent, and yet toughest decisions any developer has to make throughout the course of a project is the evaluation of new tools and tech for some particular aspect of your project. This is especially true for the indie developer, where your resources for building the tech yourself may be quite limited (ie., you), and yet the funds for licensing the tech may also be rather limited. I got to thinking about this the other day as I was going over the list of licensed tech we're using in our current project at Robot, and it occurred to me, as I've been making these kinds of decision for both small and large projects over the past ten years, maybe I could put together a list of some of the criteria I've accumulated over the years.

The New Shiny
It used to be that licensing middleware for your game was an extremely expensive process, so for many small shop developers, the costs of licensing alone made the decision an easy one. If you wanted a pathing solution, then you studied up on the latest algorithms, and you went and implemented it. If you needed blended animation trees, you took whatever bare bones your engine gave you, and you built your API on top of that. And if your artists had to live with editing XML files to set up the blends, well so be it.  But these days the process has been hugely democratized, and it's not uncommon for the aspiring developer to feel like a kid in a candy shop when looking through the Unity Asset Store.  So many tools! So many packages ready to go promising everything you need to get your game up and running! And they're all so affordable! I'd like one of each please!

Well hold on one second there Tex. Before you plunk down another $65 for another set of editor extensions, lets spend a few minutes thinking about your project's real needs. And furthermore, the ramifications to your project once this system is integrated in.

How far along are we?
Make no mistake - the best time to integrate third party solutions to your project is right at the beginning of the project. And the further along you are in the project, the less useful - and doable - this becomes. This is because each system you integrate into your project is going to set up chains of dependencies. Not only are you going to build code that is dependent upon this system, but other systems that may already be implemented might have to be modified to account for the new system. This is especially true in all-in-one kinds of packages.  Things like "The complete MMO toolkit" or "Everything you need to make an RTS".  These things are called starter kits for a reason. They define core game systems, and the expectation of those systems is that you're developing your project around that core game system. So if you're already rolling with a game that has functionality in place, integrating a core system like that can create far more problems than it solves - especially if you're integrating a system only because you want some key piece of functionality from it.

For example - say you have this fantastic idea for a game where you run around and shoot other players, you take their stuff, you go back to town and trade their stuff in for better stuff, and you go out and do that some more. And you can level up.  You find an excellent FPS starter kit that not only has a fully scripted character controller ready to go, but also includes an inventory system. Sweet! Then you see an Action/RPG system with experience points, and abilities, and level up mechanics that you also want. So you pull that down to get those systems. Then you realize that you need to save and retrieve store inventories in a central database, so you pull down and integrate a database retrieval system.  Well now guess what you have. Both the RPG/Action system and the FPS starter kit provide fully animation character controllers, but neither of them know about, or work with each other. But only one of them works with your inventory system, and the other only works with your level up system. And neither of them know about database system you've integrated. And furthermore, the database system has its own inventory managment system, that would be nice, but neither of your character controllers are set up to use it.  In other words, you've got a real maintenance nightmare on your hands.

For those reasons, it's best to make some of these decisions as early in the process as you can, especially the more core the system is.

Use but don't integrate
In the above scenario, I would start with the database serialization system, as this is a core part of your game, and just about every other piece in the game is going to depend upon it and use it. I then would perhaps purchase the FPS starter kit, and set it up in it's own separate, clean project. I would examine how they set up their character controller, and how their using their inventory. But in my original game project, I'd implement my own character controller using the methods I learned from the starter kit. I'd then build my own inventory system built on top of the database serialization system already integrated, using the techniques I learned from the FPS starter kit. I'd then repeat the process for the Action/RPG system. I wouldn't use their character controller at all (I've already gone one you see..) but I'd install their system and learn enough about it to see how they implemented their level up mechanics, and then build my own systems in my game using my technologies, but their methods.

The thing is, this kind of implementation is going to take much longer. You are essentially using the 3rd Party tools to learn from, and then building your own systems. But in the end, what you have are game systems that you are fully aware of exactly how they work (because you built them), and a game project as a whole that has fewer competing dependencies. In the long run, your project is going to be much better off for it.

How key is the component to your gameplay?
So obviously our game would be the absolute best game if we built every single piece of it - because then we know every single piece, and can fix, change, or modify all the pieces. But for an indie developer, time is money, so the truth is you may need some of those systems, and there simply isn't sufficient time to learn and re-implement. This game needs to ship! So another key question I ask myself is whether or not I can consider this component a commodity in my game, or is it a key foundation in my game. For instance, let's return to the example I started above. In this game, there are animals roaming the wilderness, and their sole purpose is to serve as targets for players to kill, and get experience. These animals have to roam around, attack players, and die. For those needs, I would absolutely license a pathing (and AI) solution, implement it as soon as possible, and never look back. My game isn't about animals pathing, or making incredibly smart decisions. It's about the fun players have in shooting them and looting them and getting bigger guns to shoot bigger versions of them.

But say my game is about the animals themselves - they are cunning foes that sneak up on players, have their own survival agendas, and roam about searching for and finding food, and the players can serve as that food if need be. Now the game is much more about the animal's behavior itself. In this case, I would build my own AI systems. I might use a low level mesh pather, but everything on top of that I would build.  

In other words, it's important to identify clearly what your game is about. And if your game isn't about some core piece of functionality, and out there is a company that makes its entire business building that functionality, then if you can afford it use it. Prime candidates for this are systems like sound and music, pathing, UI, and database management. For these kinds of systems, it's quite likely your engine already has built in solutions for those, and if so, and they fit your needs, by all means use them. But even if your engine doesn't, these kinds of things are considered the wheels of game development - and you know what they say about wheels and re-inventing them.

Don't start over!
From time to time, you will come across solutions or third party systems that are so enticing you will be tempted to completely throw out everything you've done so far just to make use of that system. No seriously. It's a huge temptation. Your own project is looking messy, with many cross dependencies, many overlapping technologies, and tools from three different kits, along with your own hodgepodge of scripts and half-implemented (but functional) pieces. And along comes this kit in the asset store that does everything you need!  It has data serialization, and a character controller and an inventory system and a level up mechanic and it's all super clean and neatly integrated and each piece talks perfectly to the other and you think to yourself that is the answer! To heck with this, I'm buying that and starting over using that and this time my game will be a paragon of efficiency and robustness and still fun to play!

I cannot emphasize strongly enough that in almost every single situation, this is the wrong decision to make. The number one killer of games getting finished is the temptation to throw it out and start over cleanly. Here is the truth of it. Game development is messy. It always starts off clean, and with the best intentions, but in in twenty years of shipping games, I've never shipped a single one, large or small, that didn't ship as a giant jumbled collection of the hacks and bailing wire and tissue paper systems that make the game shippable. It's just the nature of the beast. If you've made progress on your game and it's doing things and you're liking what it does - even if it's not the prettiest code in the world and would make your 2nd year CS instructor cringe, keep going!

No easy choices
The truth is, the decision to integrate a licensed piece of 3rd party tech into your project, versus creating your own solution, is never an easy one. Each case is unique, and has to be evaluated on its own. But hopefully this gives you at least some general guidelines to use to help you make that decision. How far along are you in your project? How many dependencies will this create for other systems? Will integration of this system create overlaps of technology from solutions already implemented? How core is this technology to the foundation of your game?  These are at least some of the questions you should be asking yourself before you plunk down another $100.00 for the best skeletal animation system ever.  And hopefully, with some of those questions answered, you can make better choices about which systems to use, and which ones to build.  In either case, good luck with your projects!