Dear Past Me - Spot On

In November of 2010, almost four years ago, I wrote a post describing what I thought at the time was the inevitable future of MMO's.  The original post was taken down when I changed blogging sites, but digging through my writing archives, I managed to find it. It was written back in a time where I actually wrote all of my stuff offline, and then published it online - crazy, right? This week, we learned that Blizzard has canceled their most ambitious MMO project to date - Titan. There's been quite a bit of press this week speculating that this move marks the end of the MMO as we know it. I don't necessarily disagree.  I won't say the MMO is dead, by any means - but the nature of it, is changing. You need look no further than Destiny to see where the genre is headed.

And looking back at the post I wrote four years ago, I think I got pretty close.  What do you think? Here's the original post, unedited.

Destiny - The Good, The Bad, and the Ugly

So it was just a few weeks ago that I was promising I'd blog a bit more often, and here I am already slacking off. Let's remedy that this morning by talking a bit about what I've spent most of my recent time playing - Destiny. There's already been plenty said and written about the game, so my summation will quite likely reiterate some of those other opinions, but I've put enough time in on my own to feel I can at least talk about the parts of the game that I've played.

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!

Lightning Strikes! Again!

Yesterday kicked off the next event in Final Fantasy XIV's one year anniversary round up - which sees one of Final Fantasy's most cherished characters - Lightning, visit the world of Eorzia.  Similar to the other anniversary events, this is a repeat event as well - it first came around in November of 2013, so technically I suppose it should be called Lightning Re-strikes.. or maybe Lightning Strikes Returns Again.. or.. something. Now as I've mentioned before I'm not terribly well versed in Eorzia lore, but I am a fan of the Final Fantasy series, and was quite familiar with the lore of this character. I wasn't playing FFXIV at the time this event came around the first time, so I was really looking forward to participating in it this time. And let me just say, if you're a fan of franchise crossovers and of seeing your character participate in events side by side with a signature series character - the event does not disappoint!