Hand of Fate -- Deck-Building Roguelike with Real Time Combat

A lot of indie games distill a well-known concept to its essence, and throw in a twist. Being a small company--generally without many resources--that's how you manage to ship a tight, awesome game experience on a small budget. Hand of Fate is a game that largely succeeds at this mission.

I first saw Hand of Fate at PAX East 2014 on the expo hall floor and got to talk to one of the developers for a short period and play a demo build, and it looked super promising. The premise hasn't changed since, and the game released almost a year later, February 2015.

The dealer table. You can see the "dungeon" on the table itself, and I'm about to make a decision regarding The Altar encounter. Note the token at the bottom means if I succeed, I'll get more cards at the end of this scenario, win or lose.

Said premise is relatively simple. You're playing a game of chance and skill with the mysterious "Dealer", for stakes that are initially unclear. The game itself is a dungeon crawler of sorts, except your "dungeon" is made up of random cards from an encounter deck you put together, plus a few of the Dealer's own cards depending on the scenario. The other deck you put together is the equipment you potentially have access to. When you get equipment cards, they get pulled from your deck and handed to your character to equip, so you can choose what arsenal you want available.

You get access to new cards by successfully completing encounters, so while you're playing each individual game, you're expanding and strengthening the cards you have access to as a whole. This is a fantastic way to encourage you to put new encounters in your deck rather than always relying on early, safer encounters. Each scenario has your character starting from scratch, but the ability to stack your deck with useful weapons and not including earlier equipment provides some level of indirect character advancement.

Deciding what equipment I want in my deck for the next scenario. Equipment marked "new" I don't know the effects of until I actually collect it in a scenario.

All scenarios so far have involved killing some champion of the Dealer--usually a beefed up variant of the enemies you tend to see in that level, i.e.: bandits, ratmen, lizardmen, and so on. Combat itself is a bit too simple--if there's one place in the game where the developers' tight experience falls down a bit, it's combat.

You get thrown into a real-time arena, and you have actions bound to buttons. Melee attack, Counter (if you have a shield), Stun, or Dodge Roll. Enemies seem to only be able to attack one at a time (and they swarm you if they're not attacking) so short of traps you're not dealing with having to dodge or counter a bajillion attacks constantly. In fact, if you get into the rhythm of just hitting melee attacks until you see a counterable attack prompt on screen, you can pretty much get out of most fights unscathed. Eventually you get access to "artifacts" that have limited uses that give you abilities, such as poisoning an enemy, or healing. Some weapons also come with on-use powers--a sword I found had the ability to spray frost and freeze enemies it touched, which was super useful.

I would suggest using a controller if you play on PC. I haven't tried using the keyboard and mouse, but it's definitely built with console in mind. Combat probably wouldn't be nearly as easy if I had to use a keyboard in this instance.

Real time combat arena, though this one is basically just navigating a maze of traps for treasure.

Mind you, I'm still relatively early in the game; the first 1/3rd completed. As you defeat scenarios, the game beefs up the enemies and gives them new attack patterns and abilities. Traps have started appearing in the combat arenas, which make blindly dodge-rolling a bad idea. Some arenas are nothing but traps, and you have to get through them all to get to the treasure, which was pretty neat. And most bosses have abilities that aren't counterable, so you just end up dodge-rolling away, though a quick stun might be helpful depending on the boss.

The one thing I do want to touch on is the aesthetic of the game. The dealer table is amazing. The dealer himself is fairly expressive for a character that's mostly covered, and his voice actor is amazing. The writing is really on point, too. The first time I ran into an encounter, I figured out how to get a shield out of it if I didn't have one. The second time I ran into it, the dealer quipped, "You just put that encounter in for an easy shield, didn't you?" Little things like that which make it feel so much more immersive. The visuals of the table and the cards are on point, as well. Given the simplicity of the game's setting, it really afforded the developer time to polish that primary environment and it really pays off.

I could watch the cards float around each other for a very long time. Hypnotic and quite pretty.

Also, I really appreciate the developer putting in a setting to turn off the spider that sometimes would appear on the table. As an arachnophobe, I thank you from the bottom of my cowardly heart.

I've played about 3 hours of the game so far, and I'm really impressed. I've been having an absolute blast. I highly recommend picking this one up.
#HandOfFate, #Indie, #FirstImpression

Blizzard and the Mythical Man Month; Or Why WoD is a Transitional Expansion

Alternative Chat had an interesting tweet the other day which spurred a conversation as they are wont to do, trying to figure out "what's wrong with Warlords." It's no secret that a vocal portion of the player base is pretty unhappy with the dearth of max level solo content in WoW currently.

So, yeah I worked out what's wrong with Warlords. A systematic failure to actually produce consistently playable content outside raiding.

— Licensed to Alt (@AlternativeChat) July 25, 2015

The first half of Mists of Pandaria can be seen as sort of the closest to what the WoW team want to achieve: rapid content releases. Having a non-raid patch leap-frogged with a raid patch worked really well, not to mention that each patch was pretty meaty. 5.1 brought in a slew of new dailies, story missions, and scenarios. 5.2, Isle of Thunder, Dinosaur Island, and Throne of Thunder. 5.3 was happy invasion land in the Barrens, and while a little thinner content-wise, was still engaging (plus the Brawler's Guild). 5.4 brought Siege of Orgrimmar and Timeless Isle. Content-wise, by most accounts it almost came too quickly, leaving us with over a year of empty space between Mists and Warlords.

Compare that to Draenor, and post-leveling content has been extremely sparse. Twitter integration, and a selfie camera which "was a fun side project for one designer and one programmer, coming in on the weekends to make a cool toy to go with Twitter integration." Tanaan Jungle, which I actually quite enjoy and has provided a good framework over Timeless Isle in my humble opinion. Timewalking, which most of the tech existed back in Mists. Finally, Hellfire Citadel, which--aside from problematic story moments (as usual)--has been an excellent raid.

So what's the deal? Why is Warlords flailing where Mists actually turned out quite well (ignoring the Lost Year)?


The Mythical Man Month

I postulate that this is the transition expansion. Blizzard is ramping content creation up: they mentioned that they increased the team size by 40% at the end of Mists, and were working on another 40% increase in size from there. Basically, they've nearly doubled the size of their team. I'll talk mostly from the programming angle, but to a large extent this still applies to other disciplines.

At my old job, we tripled the size of our team overnight. Went from about 20 developers to about 60. I was in charge of educating them and bringing them up to speed, so I can tell you with first-hand experience that this is an immense task, and comes at (an extreme) cost to general productivity for the team as a whole. And it has little to do with how good or bad the developers are in general. In fact, almost every developer I worked with when we brought on the new folks were incredibly smart, passionate, and knowledgeable people.

No, the issue with exploding your team size is much more basic than strictly skill sets, and yet far more nuanced than mathematics can describe.

There's a book, sometimes known as the "Bible of Software Engineering," called The Mythical Man-Month. This book is basically required reading for project managers (and if it's not, it should be). The basic premise of the book is the following:

Adding manpower to a late software product will make it later. -- Brooks' Law

The book itself goes into the myriad reasons why this holds true, but the primary reasons are it takes time for new employees to get up to speed, and more employees means an exponential increase in lines of communication


Onboarding New or Transferred Employees

By far, the biggest short term cost is getting all these new folks up to speed. Each team has their own processes, their own tools, their own hierarchy, their own codebase. Established employees know the history of the product, and they know the bugs, quirks, and odd spots in the code. An established programmer might know intuitively that if they change something in the animation engine, for example, that they may need to double check the sound because of how those two systems might be intertwined in that particular product.

Think of it this way: let's say you were brought on to write a book set in the World of Warcraft universe just after the events of Warcraft III, but you knew little about it aside from, "I've heard of Warcraft." Sure, you know how to write a decent story, you know English, and are decent at self-editing. So you have the skill set, but you don't have the context.

You'd need to research what lore already existed around the subject, you'd need to make sure what you wrote could sit in the timeline correctly without accidentally introducing minor bugs (like getting Jaina's eye colour wrong), or worse, accidentally introducing things where you'd have to retcon entire chunks of the story to make fit. The Warcraft lore universe is massive. And you don't really know your way around.

So instead, you get the basics from someone who knows everything inside and out, and you pester some folks for questions because you're still not sure if you got the details correct. The experienced employees take time out of their day to fix your mistakes and guide you through your work, so not only are you really slow to start with, but your work impacts the efficiency of the experienced employees.

This is absolutely true for programming, art, or design, among other disciplines as well. For programming in particular, one spends a lot of time coaching the new/transferred programmers. That's not to say the time is wasted. Eventually those newbies will become productive team members on their own, but adding them to the team can and will reduce that team's throughput in the short term.

And note, short term can mean anywhere from 3 months to a year. Depends on the complexity of the product. Even experienced, senior programmers coming into an existing codebase can take upwards of 3 months before they're productive enough to work without someone established looking over their shoulder (or bailing them out of trouble). It's not that they aren't smart or accomplished; it's that they just don't know the source material well enough yet to not accidentally goof up without realizing it yet.


Doing the Math

If we assume that for each new employee, it reduces existing team throughput for an established employee for an average of 50% for the first 3 months (which in practice is a conservative estimate, from what I've seen), then having a team increase in size by 40% means you're looking at reducing overall individual throughput by about 20%. And no, these new employees aren't contributing enough to overcome that throughput loss, at least not in the first few months. They're often making mistakes and bugs that the more established employees need to compensate for (aka negative contributions).

And of course, from there it's not like it spikes to 100% efficiency, either. You'll have a gradual ramp back to 100% efficiency, but ideally you'll be at greater than 100% relative to the old team size eventually.

But it's never that easy. First of all, it's only the most experienced transferred employees who'll ramp up in only 3 months. But often, they're pretty independent by that time. No, generally for the average programmer it seemed that about 5 - 6 months was required before they could do work largely independently (assuming they're doing stuff that isn't isolated). For really fresh out of school employees (brand spanking new), ramp-up takes about a year, usually. Sure, they'll make features, but they'll be pretty bug-ridden and still need a lot of guidance.

The other gotcha here is that often the established employees doing the education will be the ones with the most experience in the code and/or product, which means that you're actually taking a bigger than 20% overall hit.

Let's say a programmer with 10 years of experience is about four times as productive as a programmer with 2 years of experience. Interestingly, Brooks mused that a good programmer was 5 to 10 times more productive than a mediocre programmer, and that fits in my experiences as well. If you're using your super productive people to teach the new folks incoming, then that 20% hit might actually be closer to 40% because not every employee is equal.

So by adding a bunch of folks, Blizzard would have tanked their individual throughput anywhere from 20% to 40%, depending. And they did it twice by doing two major hiring waves (because chances are, the people who did onboarding to begin with probably were tapped to do it again the second time).

That all doesn't take into account the re-structures Blizzard would've had to perform--that many new/transferred people means new managers, new communication structures, and so on. Those alone generally tank productivity as the rank and file try to figure out what's going on and educating their new leads on what they've been doing. It also doesn't take into account the standard "forming; storming; norming" that would occur when introducing that many new people onto the team, which would also exacerbate the ramp-up time.


The Lost Year of Mists

So when can we as consumers expect the fruits of Blizzard's labours here? It takes a while for content to work through the pipeline. While it looks like a bunch of stuff happened last second on the PTR just before Warlords was released, you can bet most of that work was planned months in advance (and then iterated on later). Art assets had to be completed, game systems programmed, server tech vetted, the entire thing QA'd. We knew they were working on Tanaan as "early" as before Warlords launched, so what we have today was started probably at least 8 months before the patch was released.

The lost year of Mists was quite likely half a write-off from a production perspective. I don't know when they'd have done the second surge of new employees, but it would've reset the clock on the productivity dip.

Which would explain why Warlords felt so anemic. Leveling was amazing, Garrisons was a lot of "content", but most of it is random/programmatic. It likely was more programmers and designers than art--which makes it pretty attractive as the programmers probably needed something to do while everyone else was building the Draenor continent.

But the daily hubs? Even Celestalon Watcher said they were half-assed. Flight wasn't a thing, so that'd have reduced the load on the art/design team for building the continent (which they're paying the deferred cost now, hence why flight is delayed). No scenarios. Proving Grounds literally just got adapted to the scaling tech.
Edit: Whoops, Watcher == Ion, Celestalon == Chadd.

The Next Expansion

But we know they were already working on the next expansion even before Warlords shipped, so I think we'll probably see an expansion announcement at Gamescom. We'll also likely see a beta server ready to go by Blizzcon in my opinion.

Honestly, software takes a long time to make, and organizations take a long time to readjust--especially ones as large as the World of Warcraft team. So while people may be getting antsy about Blizzard's ideals of an annual expansion at Gamescom in 2013, they're probably only now getting to the point where the hiring and training they've done will become visible to us consumers.

Blizzard lost a lot of ground, and Warlords likely suffered because of these huge organizational changes. But the engine should be primed and I'm looking forward to seeing what the next expansion brings. Blizzard has a lot to (re)prove, and hopefully they'll be up to the task. #WoW, #GameDesign, #Expansions

[IndieDev] Unity3D: Things I Wish I Knew A Year Ago

I figure it's about time I started compiling a list of the quirks, tips, tricks, oddities, etc. around programming in Unity3D. Bits and pieces of knowledge I wished I had when I started Eon Altar. Note this may get pretty technical, but forge on ahead if you want to know more!


Don't Override Update, LateUpdate, or FixedUpdate

Update and LateUpdate are something that's called every frame on each Unity GameObject, if they have the methods defined (FixedUpdate is called every physics step, which happens multiple times per frame). Unity is using Reflection to determine if your GameObject implements these kinds of methods, and keeps a list of things to call in behind the scenes as far as I can ascertain.

So what this means is that if your object has a method called Update implemented with the signature void Update(), then Unity will call Update. If it doesn't have Update, there's no overhead.

Now, when we introduced our pause system, we wanted to prevent Update/LateUpdate/FixedUpdate from running on a large subset of our components (> 90%) while the game was paused. The natural thing to do of course is implement Update on the base object, then implement a different overridden method for the actual object that the base class called, and just not call the new method if the game is paused.

You will be tempted to do this. Don't. It's a trap.

The problem with this is that you've now introduced a bunch of extra calls of Update/LateUpdate/FixedUpdate. In our case, once I had profiled it, it was a good extra 6000 - 8000 calls a frame. This caused an immense amount of overhead because we pretty well more than quintupled our calls. It tanked performance significantly.

So don't. You want to, but don't. It might be better to go the interface route, and define interfaces for the pattern you want, but you'll still need to implement the rest of the code that you wanted on each declaration of these objects. Messy, messy, messy.


OnTriggerEnter/Exit/Stay Get Called Even When Object is Disabled

For most Unity methods, like Update, FixedUpdate, and so on, many of these will not be called if your Component or GameObject are disabled. By default, calls like GetComponentinChildren won't look in disabled children (but this behaviour can be overridden by passing a bool to one of the overloads of the method). Clearly Awake and Start get called no matter what, but generally, disabled GameObjects don't do much of anything.

However, OnTriggerEnter, OnTriggerExit, and OnTriggerStay all buck that trend, which means that even disabled, your trigger Colliders are effectively active. Mind you, it's probably less of a hit on perf overall to not have to recalculate the physics spatial trees anytime you enable or disable a Collider, but I admit, this piece of behaviour threw me off completely. I'd have expected them to ignore calls like Unity does for everything else.


(Unity 4) Dynamic Trigger Colliders Should Have Rigid Bodies

Okay, I actually knew this straight out of the gate because Unity documents this pretty specifically, and I've had to implement a physics engine in my University days, but I've found almost nobody seems to get this, and your designers can do a lot of performance damage if they're not careful.

Trigger Colliders come in two flavours: static, and dynamic. Static means they shouldn't move. I don't mean like rarely move, I mean never move. Ever. Dynamic Colliders can move. If you attach a RigidBody to a GameObject that has a Trigger Collider, you've now made the trigger dynamic, meaning Unity expects it to move.

Under the covers, PhysX does a bunch of optimization for static vs. dynamic triggers. Static are faster at runtime and take less memory, because PhysX (and thus Unity) never expects them to move. Optimizations and assumptions can be made. When you do move them, however, you force a recalculation of the spatial trees PhysX has built under the covers, which is an extremely expensive operation. This can and will tank performance. Even a single static Collider moving means a massive recalculation, so you need to be vigilant.

The easiest way to keep your designers or other programmers from making this mistake? Have Awake enforce a RigidBody on Collider scripts you think will ever move. Then, even if someone forgets, as long as they're using your script, it'll ensure the mistake can never be made.

Note, as per the link above, Unity 5 doesn't suffer this issue, because they now treat static Colliders the same as dynamic. It's a bit of a let down because those of us who do know how to handle this issue don't get the performance benefit anymore, but given Unity says the static Collider issue is one of the top 3 performance issues in Unity games, I don't really blame them for taking that choice away. Still, it'd be nice to have a compile-time setting that let us pick the old way.



Unity's Network Model is Wonky

Short version, for a multiplayer game, Unity's networking model is really strange. Well, not so strange if you're just making a basic shooter or something, but for what people consider normal Server-Authoritative models, Unity's APIs are awful.

What have these APIs wrought?

Long version: http://talarian.blogspot.com/2015/05/indiedev-unity3ds-networking-in-depth.html



BroadcastMessage is Convenient, but Terrible

Again with the reflection. BroadcastMessage basically takes a string, and then tries to call a method of that name on every sibling Component and child Component. This is really convenient, because you can do things like tell all your children to Initialize, or things of that nature.

The issue, however, is that you don't get linker benefits (no autocomplete, won't show up as someone calling the method on the callee side). You may accidentally call something you weren't expecting--if I add a script to a child Component that is called Initialize, but wasn't expecting it be be called via BroadcastMessage, could have issues there. You also pay a performance cost, because reflection is never cheap.

Basically, BroadcastMethod is super lazy. I personally much prefer to be explicit about these things because nothing is more frustrating than hitting BroadcastMethod in the code, then not realizing what Components could possibly be called unless you're at runtime and have breakpoints on every Component you have in the game with that method name.


Coroutines Aren't Great Solutions

Unity boasts a feature called Coroutines, which are really just C# Iterators with more interesting yield statements. In C#, Iterators/yield statements are pretty powerful syntactic sugar. Unity uses the yield return to determine the next time it should call Next on the Iterator (basically, when to continue to coroutine where the yield left off). For example, you could yield return null to have it pick up the next frame, or yield return WaitForSeconds(2) to have it wait for 2 seconds before continuing.

This would be great, except coroutines have some pretty peculiar behaviours. First of all, if the MonoBehaviour that started the coroutine is disabled or destroyed, the coroutine stops, and you'll never know it did until a bug crops up. Destroyed makes sense, disabled is really annoying because you need to realize it stopped and start it manually on the next enable. It just looks like it never returned from a yield statement.

Coroutines are sort of like asynchronous operations, except they really aren't; they're completely synchronous. But you end up treating them a lot like asynchronous operations which can actually get you into a bit of trouble in terms of excessive complexity. Also, you're not saving anything on the main thread. You're divvying up your job into smaller pieces across many frames, which is great, but it's still all happening on the main thread, just like Update.

Finally, nesting coroutines is a total pain to get correct. I wouldn't recommend it if you can avoid it. If you think you have to nest coroutines, you should probably have another look at your algorithm, it may be more complex than required.

Frankly, anything that can be done in a coroutine can also be done in an Update statement (or LateUpdate if you want to wait for the end of frame). Coroutines can be great if you're careful with them, but sometimes I wonder if the pitfalls around MonoBehaviours are worth the trouble.


Prefabs Linked in Scene Are Loaded Into Memory

Prefabs in Unity are basically premade building blocks. An example might be an enemy visual (mesh, textures, skeleton) in totality, which we can then say later, "Hey, give me the visual for the turtle," and grab the prefab.

There are two ways to access these prefabs: you shove them into a folder (any folder) called Resources, and then use Resources.Load to get it into memory; or you just link the prefab in your scene.

However, when you link the prefab in your scene, as soon as that scene loads, the prefab is loaded directly into memory. It's not on demand, it's as soon as you've loaded the containing scene.

This isn't the worst thing if you're cognizant of it. Things like some textures, meshes, spell effects, etc. you may want to load with the level. But if you're naive about how you've built your levels, you may be in for a world of hurt when you start crashing the Editor because all of your textures, meshes, music, level data, and so on start breaking the 3 GB mark in memory--noting that all resources in the Editor are basically double to triple in footprint they normally would be in a standalone player; they're raw, and if you're running the game, you have the game instances and the Editor instances.

In hindsight, this one makes perfect sense. But it wasn't something we realized at first.

---

That's all I'll put for now, but I'll probably add more as I come across them over time. My Unity posts tend to show up in search results fairly often.

Are there things about Unity3D that threw you for a loop? I'd love to hear them! #Unity3D, #IndieDev, #EonAltar

Life as an Indie Dev - 1 Year Later

Just over a year ago I left my "cushy" job at Microsoft as a software engineer in the Office division to follow my passion: video games. Technically I've been at Flying Helmet Games for a year and 2 weeks, but who's counting? So far it's been an absolute blast, an absolute slog, and absolutely worth every moment.

The Vancouver Studio

As a quick refresher, I've been doing the work from home thing while the rest of the studio generally resides in Vancouver, BC. For most of the project, I've been working on a team of 3 programmers, along with a number of other engineers (sound, animation), artists (concept, environment, creature, cinematic, etc.), designers (level, system, writer, etc.), QA, and more.


What We've Been up To

Over the past few months we've put out a trailer, put up a Steam Greenlight campaign (and got greenlit in 6.5 days!). Our producer took the game to E3 at the Media.Indie.Exchange (MIX), an indie after party for E3. We've been doing a little streaming on Twitch.TV--Wes, our media/QA guy, managed to get the couch, the game, and 2 phones streaming simultaneously, which is really cool. The game is looking really good, our systems are all generally in place and now we're into the polish and bug fixing phase.

It's definitely been an interesting ride. I've learned so much about game development in general--though not all of it is flattering to the game industry, but that'll be a post for another day. However, that being said my coworkers are very smart and talented folks, and just working with them has allowed me to pick up all sorts of knowledge. We've made some missteps--as any project generally does--but damn have we put together some awesome stuff in just over a year of production time (they started a couple months before I was brought on board).

At the beginning of April our lead programmer left to work for a large company, though I don't blame her one bit. With a family to support, and a new born child, it's quite difficult to justify working on a startup. But with her departure, that elevated me to lead programmer, and I have been ruling the code base with a velvet glove and an iron fist. Actually, probably mostly the iron fist.


Crunch

As we've gotten closer to release, the pressure has ratcheted up significantly. The dreaded "crunch"--massive overtime--reared its ugly head severely. For the period of April through May I worked at least 80 hours a week. It wasn't pretty, but there was a lot of fairly mechanical work to get through that didn't necessarily require a lot of brainpower.

A while back, Kotaku ran an article about crunch time in the game industry, and our producer/director/Idon'tactuallyknowhistitle Ed Douglas gave them some pretty candid information about the why and how we got into the situation we had found ourselves in:

Early in a game cycle the skies are blue and anything is possible. As you get closer to final everything you have to trim, simplify, remove, feels like failure. You also have an optimistic perspective on what can be done in any given schedule, so you over-scope. What they call ‘technical debt’ builds up, and you have more and more features to maintain and fix when it comes to the end.

In a perfect world a game is built on a ‘Minimal Viable Product’ model, where each feature works nicely on its own, and is enhanced by features around it. Although we give internal lip service to this method, to be honest to ourselves we do not do it. We’re making a complex (for us) RPG, with a huge number of moving parts. No feature works in isolation, and nothing can be cut without massive ripple effects throughout other systems. Here, we were overconfident, didn’t scope properly, and now have a huge number of features with lots of bugs to fix and a hard deadline coming up.

We’re completely independent which means we set our own release date, but it also means that when we’re out of money, that’s it. We’re not EA where we can shift resources from studio A to help studio B for the last few months. The only way to finish is to crunch. To ask people who did not commit to the features in the game to spend the evenings, their weekend, their family time, digging us out of this ‘technical debt’ we’ve incurred. Now they’re critical path in getting a game worth shipping, and if they don’t do it they know the game could fail. It’s the absolute worst position to put someone in and it’s shameful that I did it.

As Ed suggests, we've had to fix some of the technical debt we've incurred (which reminds me, he told us he'd give us that whole letter since Kotaku only printed part of it). I'm certainly not the only employee affected by the technical debt, but for me, that's been the entirety of June and July.

Some of that was setting up an automated build system--we haven't an actual build engineer, so we've had QA/IT run builds manually. That couldn't stand, so I sat down, re-learned bash scripting after not touching it for a decade, and put together some build scripts. We still build our handsets manually, so there's some work left to be done and it's a far cry from an actual fully automated build system, but we're in much better shape these days and don't need to babysit and manually perform the steps to build the game anymore.

Another few pieces have been required features for shipping that we just hadn't gotten around to yet, like crash logging and analytics. Requirements for shipping, certainly, and not something we can ignore, but they weren't critical for unblocking designers, artists, or other engineers. Leaf features, making them naturally fall to the bottom of the pile, which honestly is how we got into this mess of required features not being done in the first place--not giving engineering enough time set aside to build the infrastructure, rather having us all support design directly through most of the project.

Finally, we've had some major features that required complete re-writes--part of that technical debt. When we built our handset reconnect logic and our save system, the ideas behind them were good, but in practice turned out to have some intractable technical issues. And when I say intractable, I mean by redoing it, I increased the speed at which reconnect and save would occur by upwards of 30,000% in some scenarios. No, that's not a typo.

We hadn't put in the QA time nor the engineering time to really dig into those systems until recently, and I spent half of June re-writing reconnect, and half of July re-writing save. But again, to a certain extent, those systems were leaf systems. Not having them working didn't really block anybody from doing their job, so the priority on them got pushed down.

That being said, I've cut my hours down to something much closer to a normal 40 hours per week. There's absolutely no way I could ship features as complex as reconnect and save at the required quality if my brain was fried and I was just burnt out in general. And taking that time for myself has paid off, because those features are a lot less buggy than any of the work I did during the crunch period. It's also kept my enthusiasm up a fair bit. I'd say I'm sorry to my coworkers, but I'm really not sorry at all. I did what I needed to do to ship awesome code.

There'll be a time when we need to do a postmortem, and figure out where exactly we goofed, but I don't think any of us are under any illusions about what some of those goofs are. And we're all guilty to an extent. Ed puts all the blame on himself--and to be fair, he deserves a fair chunk--our individual departments could have pushed back a lot harder than we did. We were the ones handing out estimates, and telling him what was possible, what might be possible, and what was highly improbable.

It goes back to nobody wanting to ship a crappy game, so instead we hiked up our enthusiasm and went at it. The perils of working in a somewhat creative field. It didn't sink us, though, and that I attribute to a lot of hard work from a dedicated team that believes in what we're building.


Working Remotely

There's the upside to being indie and being remote. And the new lead programmer. I have the absolute freedom to do my job. Yeah, okay, crunch is complete balls, but if I really don't want to do it, I just don't do it (like I'm not doing it right now as we speak). But I'm getting the job done and done well if I say so myself--and no Ed, I'm not fishing for compliments, nor apologies for that matter :P

Being remote means I'm out of sight, out of mind for both parties. I don't get into what I heard called "sympathy crunch"--where I'd crunch because others are crunching--and it also means I can do what I need to keep myself healthy and happy. Let's just say there's been a few times where I've napped in the afternoon rather than work, though I made up that time later in the evening because, well, I really want this project to succeed. On the other hand, not having AC these past couple of weeks has been awful, so the folks in the Vancouver studio had it lucky on that aspect. Coding in 95F is pretty horrendous. On the other other hand, nobody's around, so pants are optional.

I have visited the Vancouver studio a few times, so it's been good to see people in person when normally they're faces on Google Hangouts and text in Slack. Sadly, visiting now is difficult because my work laptop's hard drive died so I'm tethered to a desktop machine. Still, there's a lot to be said about meeting folks in person.

The group playing our E3 build.

Visiting the studio was good when I became lead, as well. One of the issues in my mind with our release is that while most of our studio was localized, the two senior programmers (the old lead and myself) were elsewhere, either across the country or across the border. Our junior programmer basically was left to the devices of the designers and artists. I feel like I wasn't able to provide enough guidance because of that distance once I became lead. Though, all things considered, he did a good job. I've no complaints there, I just feel it might've been even better had I actually been on site.

Also, I'm going absolutely bat-shit insane because of the lack of meaningful contact. People suggested going to coffee shops but that's just background noise--annoying at best, distracting at worst. I need folks around who I can talk about the game, about the craft of programming and design. The team's been pretty great about discussions in Slack so I get some of the office chatter, but it's still no substitute for actually being there. On the other hand, I get way more work done at home then when I visit. Open floor plan, blech.


Conclusion

We're wrapping things up in some aspects on our side, and still ploughing ahead in others. I think we have more convention plans upcoming, so look out for that, and our plans on Steam are full steam ahead; look out for something there soonish, too!

It's been great, and is going to continue being great. I've a good feeling! #Personal, #IndieDev, #EonAltar

[WoW] So, confession, I actually enjoy Tanaan Jungle

Back in Mists of Pandaria, the final patch brought us the Timeless Isle--a compact zone filled with mobs, rares, treasures, jumping puzzles, and loot. I didn't mind Timeless Isle so much, but it felt cramped. You could get from one end of the island to the other in about 2 minutes, maybe 3. With the sheer number of people in the zone, some days it was difficult to tag the monsters you wanted because there was just too much competition.

But aside from that, I enjoyed searching for the treasures, and many of the mobs weren't difficult to kill if you were decent at understanding their patterns. Toads, tigers, turtles, and so on. It was also well-designed in the fact there were places that you could go if you were low ilvl to get gear until you could tackle the higher ilvl stuff. Timeless Coins as a currency was a good call, as well, because it gave you something to collect, obtain. You could set your own goals. Timeless Isle was a pretty good demonstration on what progression in a single zone could look like.

Enter Warlords of Draenor. Tanaan Jungle is basically Timeless Isle 2.0. The major differences this time around are the zone is much bigger (easily about four times as big), with actual dailies/missions to help guide your experience and give you goals if you don't want to make your own. Objective zones were basically ripped from their previous dailies, and I don't mind them. I like waltzing in, wiping out a swathe of enemies, breaking their things, and killing their rares. And with some treasures that may regenerate daily, even if you get all the static stuff, there are till things to search for.

Tanaan certainly isn't a small zone. In fact, it's large enough to have plenty of empty space delineating each sub-zone.

For me, I pretty much only run a single character these days. I get to Tanaan, I pick up the first set of dailies, complete them, grab the next set, complete them, and I'm done in about 45 - 60 minutes. This is about the perfect amount of time for me to play on a mostly daily basis. On top of that, that gives me a fair bit of progress on all 3 Tanaan reps, and usually dumps about 15k Apexis Crystals into my coffers (seriously, Apexis rains in Tanaan). It would make it quite easy and quick to gear up an alt, if I chose to go that route. But even with Heroic BRF loot, I could still get some upgrades in Tanaan Jungle with the 20k Apexis Upgrade token.

If solo stuff isn't your thing, I can see why Tanaan would hold no interest. If you didn't like the more free-form play that Timeless Isle brought, you'll probably dislike Tanaan (though it has more structure, so perhaps not). Tanaan is pretty much ignorable though if you raid, aside from the Legendary Ring stuff. I've nabbed most of what I need after about 10 days of play in terms of resources though, which I personally don't think is terribly onerous.

My main has so much oil that I'm getting anxious that America might invade.

— Manech (@MichaelJPetty) July 9, 2015

Granted, some raiders seem to resent being forced into any solo content, and while I definitely prefer group content myself, I don't think asking folks to play some of the game outside of instances is necessarily a bad thing, but I know that's an unpopular sentiment amongst the mythic raiders I follow on Twitter. Almost to a person they seem to detest being asked to do single-player content it seems. Either that, or they're just really loud about it. And that's okay. Some things are just not everyone's cup of tea. In days past you were forced out into the world to get materials for your raid. Farm for potions, food, flasks, enchanting materials, so on and so forth. With most of that handled by Garrisons or the AH these days, nudging people into non-instanced content has to be dealt with in another manner.

Killing orcs. Well, fel orcs this time. Haven't killed fel orcs since TBC!

That being said, Tanaan does rub me the wrong way in some ways. It doesn't really forward the story very much. Granted, that's pretty much all of 6.x's post-100 content in a nutshell, but I've done 4 out of the 6 Tanaan story weeklies, and they're super short and don't tell a lot.

Rares mostly don't seem to scale HP fast enough to survive very long--outside of the 4 pseudo-world bosses, which have a metric butt-tonne of health--which makes seeing them and running after them a difficult proposition at times.

And World of Warcraft's tapping system for monsters is extremely antiquated, and Tanaan exacerbates it. Pretty close to every other MMO out there allows for multiple people to tap a monster, but WoW still only allows that for rares/big monsters. This presents a problem in the more popular daily areas where there aren't enough spawns for people to share. Or they up the spawn rate and people get overwhelmed. At this point I'm still not sure what the reasoning is for WoW to maintain their ye olde tapping tech. It feels bad because instead of cooperating with folks, I'm competing with them. It makes me want to find an isolated corner filled with my own targets. That's the exact opposite of what they're trying to encourage, no?

Overall, I've enjoyed my time in Tanaan. I think it's an excellent evolution of the Timeless Isle design. I've loved exploring it, and I think the rewards come in at a decent enough pace to make it worth my time now that my exploration phase is largely done and I move into the farming phase of the content.
#GameDesign, #WoW

Missing the Target--A Discussion of Accuracy in Game Systems

A staple of most RPGs--be it pen and paper like D&D or video games like Final Fantasy Tactics or World of Warcraft--is the concept of accuracy. Accuracy is often used as a small means of injecting variability in your experience, or a way to temper the effects of skill. But missing sucks. Nothing is more frustrating than playing a game and missing over and over and over again.

Over the weekend, I had some friends of mine playtest Eon Altar. One player was Marcus, our tank, and she expressed frustration that she couldn't hit anything. I believe the direct quote was, "Blocked? Fuck you! Half my shit ain't landing!" From what I could tell watching, she wasn't really wrong. We checked Marcus' stats after, and he had the correct values, so therefore should have approximately 75% to hit enemies in the first level.

Our desktop wallpaper for Marcus. He's our tanky character.

The Effects of Missing Over Time

Of course, with any randomness comes the opportunity for it to fall outside the curve over short time periods. The more attacks you make (samples), the closer to the actual curve you'll probably get. When you only make 3 or 4 actions per combat, missing 3 out of the 4 attacks sucks. It's not super likely, but it's also not unlikely (~5% chance to miss at least 3 attacks of 4 at 75% accuracy). It's quite plausible that our Marcus player had hit upon that 5% over and over again.

Your memory is also tainted by the fact that humans tend to remember negative results far more often than positive if they're all of relative equal intensity (known as negative bias), so even if Marcus was only hitting half the time or less (~25% chance per set of 4 trials), it would likely be perceived as worse than it actually is.

Alternatively, when you look at a game like World of Warcraft, if you have a 5% chance to miss, but you're making anywhere from 30 to 40 attacks per minute, that 5% gets forgotten pretty quick. It's not a high frequency event, nor is it devastating because you have so many actions. Compare that to D&D, where often you're looking at 25% to 50% chance to miss on each roll of a d20, and you only have 3 - 8 rounds of combat.

Such high variability may cause balance issues, as well. A group that is lucky might blast through a level because they just crit everything. Also see: top parses for WoW. Here's an Enhancement Shaman who's one of the top DPS parses for Mythic Gruul. Note their abilities have crit percentages of 33% to 45%, despite the character only having 20% critical strike. Take enough samples, and eventually you'll have outliers.

On the flip side, a group might struggle immensely because they got unlucky. Everybody missing a lot, taking excessive amounts of damage because they're getting hit more often as well.

With sufficient variability, it becomes difficult to predict the outcome of a combat or a level. This is both good (because having to readjust tactics on the fly is where some of the fun of combat comes), but it's also bad (because as a designer, the experience becomes more difficult to control).

But is that a bad thing overall? Having a lucky (or unlucky) streak makes for interesting stories. In D&D the time where a group roflstomped the villain because they had a streak of criticals. Or the other time they barely escaped with their lives because they couldn't hit the broad side of a barn. Players love both of these stories. Games where the experience goes off the rails tend to be quite memorable.


Mitigating the Extreme Negatives of Accuracy

There are also other techniques one can use to dampen the effect of accuracy. Every time you consecutively miss, get a cumulative bonus to hit. This helps reduce the effect of unlucky streaks (as eventually you'll hit for sure). Granted if players know this is in effect, they can game it--"I missed twice, my next hit will hit for sure, time to use my big attack!"--but on the other hand, how many folks "game" luck that way anyways? "I've missed so many times, I HAVE to hit next time, it's so unlikely to miss again." Encoding it into the game might not change behaviour at all.

Another method is to still give some sort of effect when you miss. D&D 4th Edition does this with Daily powers. When they miss, they generally still do half damage and have weaker forms of the effect it would normally cause. Missing still sucks, but at least you haven't completely wasted a very limited resource.

Finally, you could just boost the accuracy of players. If you only have a few events per combat, rather than having a 70% chance to hit, maybe a 90% chance? You'll still have unlucky streaks, but they'll be less likely.


Designers Beware

Missing is frustrating. You as a player feel impotent, and when you only have a few actions a combat, each miss has a massive impact on your play. As designers, accuracy is a very easy tool to introduce variability in game play, but we also need to be careful. Balancing fun in this case is very subjective.

Overall, game designers needs remember this: the fewer events, the more variability. The more events, the more likely your event results will mimic the probability curve. When building a game with few events, variability drives the game experience. Whether that's something you want is a question only you as the designer can answer.
#GameDesign, #EonAltar