GameDevBlog

One of the Best Management Books I’ve Read Isn’t A Management Book

I’ve done an official “improv” class once in my life, at a roleplaying game convention, because improv theater is popular with the circles I play in, where we focus on making up stories as we go, playing characters, and improv gives us techniques that help make that whole process work. So that’s what led me to the grand-daddy of improv books: Impro by Keith Johnstone.

When I read the book, though, it didn’t just give me useful tactics like “yes, and…” to aid in collaboration but it changed the way I look at the world. I actually forget if “yes, and” in particular came from this book, which I read many years ago and gave away my copy of, so this “review” is going to be based on my very fuzzy memories and probably highly inaccurate, but I think Keith Johnstone himself would approve. If you want a fresher take I’ve written about it before (and forgotten I had) but I do have some more, management related, things to say about it, ten years later. That it's stuck with me this long has got to mean something!

My big takeaways from this book mostly revolved around criticism. The first big takeaway was that humans tend to engage in tiny (or not so tiny) status games. One of the improv games Johnstone suggests is one where the players play characters who are trying to play “Just above” or “Just below” the other characters’ status. For example, one player might say, “I Just finished reading Crime and Punishment.” The other player might then say, “That’s my favorite book!” A high status play – not only have they read it, they’ve read it multiple times. Or they might then say, “But I just look at the pictures.” Lowering their status.

Once I was introduced to this idea I started seeing these micro-status-games everywhere. Take your typical code review. We put up our code for review and we say we’re looking for feedback but really we hope that we’re just going to get the Looks Good To Me and be able to merge our code and move on. And then somebody tells us, “This bit concerns me, it’s pushing state from what might be a different thread. It’s hard to reason about.” There’s the status play – they’re raising themselves up a bit, showing how smart they are, and at the same time lowering us a bit, pointing out something we didn’t think of. Doesn’t mean they’re wrong (I have often been that guy), and they didn’t do it just to feel good about themselves (at least not consciously) but still the status transaction is there. Then we get defensive, tell them why we did it that way, why in this case it’s perfectly safe (maybe we know it’s not called by another thread) and more performant, try to get our status back on the same level as them. At one level it's two people debating what’s best, but at another level it’s one upping each other. (I have a bunch of tricks and techniques I sometimes use to mitigate the one upping part of code reviews … but often forget to use them. Maybe because it’s human nature to try and keep my status on par with others. Those tips and techniques might make a good blog post of its own. Stay tuned! Hopefully I’ll keep this up.)

Criticism is just one form of status play. It can be anything from telling someone where I went on vacation to mentioning how well my daughter did on her AP tests to, well, blogging. (How arrogant of me to think my opinions are worth sharing!) Reading Impro didn’t stop me from playing these micro-status-games but it made me excruciatingly aware of them. And it also made me aware of having the games played on me, whether intentionally or no—before, if somebody said something that made me feel a bit tongue-tied, I probably wouldn’t have known why, but now I can often identify it. “Ah, my status is threatened. When they gave me that unsolicited offer of help I felt inadequate at this task.”

(For more on status threats in the workplace check out David Rock’s Your Brain At Work, another one of the best management books I’ve read. And that one really mostly is a management book.)

My other takeaway from Impro was more about criticism directly. I’ve mentioned that before, as well, and not sure what to add here. I’ll just say that for the most part Johnstone was against it which came as a shock to me because I had always thought of listening to criticism as how we grow. Writing a book or making a game, to me, was a process of shitting out a first draft and then letting people give notes and acting on those notes until it’s “good.” To hear Johnstone say that critical teachers are bad teachers, that they make people fear failure, that they drive people to stop creating entirely—it both surprised me but also resonated as I looked back on my own life and realized the damage criticism had wrought. With Spider-Man 3, which I quit a year into the development of after killing the feature I most cared about—killing it was my decision, yes, but was it a good decision or did I kill it because the negative criticism, made in the spirit of improving the feature, scared me off with fear of failure?

So after reading that I flipped and became super-avoidant of both giving and taking negative criticism. I went too far the other direction, to be honest. Since then I’ve been trying to find the right compromise and am still working on it, but I default to, when in doubt, not criticizing and not asking for feedback. Which has been part of my management strategy previously but I've ramped it up. I have more to say on that topic too – but that will have to wait for another post.

On that note – have any feedback on this article for me?

When to assert

I recently checked in some work to the main branch and in certain corner cases asserts would fire, so this topic is fresh in my mind. Though nobody has pointed direct fingers I can't help but feel like I'm being blamed for breaking the build, a message that goes beyond "kill the messenger" to "stop having these naysaying messengers in the first place" - and while not all of the assertions that fired were due to true faults, a couple of them were real logic errors, so I stand by them as mostly good things to have around.

I used to use the term "brittle" to describe good software, in that it would break when somebody coded something wrong, usually with a nice clear callstack. In most of my old code, dereferencing a nullptr wasn't the mistake of the function doing the dereferencing - it was the fault of the code that passed a nullptr in in the first place. After discovering one of these issues I might thread assertions through the code trying to find out when and why that thing was null, and catch the real mistake, frex:

void foo(shared_ptr<Thing> myThing)
{

    // this is how we used to do not_null before we had not_null

    assert(myThing != nullptr);  // this assert has value because it can catch the problem sooner

    … a pile of code here…  

    // no point in asserting !nullptr here, it'll crash nicely for us anyway

    myThing->doAThing();

}

 

void outerFoo(shared_ptr<Thing> myThing)

{

    assert(myThing != nullptr);

    … a pile of code here …

    foo(myThing);

}

Which was great when working on shrinkwrap or one-version games, and even fine with my recent roblox work because I could turn around a fix in an hour or two if there was a common failure. With Minecraft, where it can take days, weeks, sometimes even months, to get a fix up I learned pretty quickly that my old ways wouldn't fly anymore. We needed to be "robust", not "brittle." 

Still, catching bugs early is a good thing, so I like to promote the idea of "brittle and robust" - the example here is we assert that a pointer isn't null, but then we handle the possibility anyway. This is from the old classic Writing Solid Code (though I forget if they called it that.)

void foo(shared_ptr<Thing> myThing)
{

    … a pile of code here…

    assert(myThing != nullptr); // brittle in debug/test builds. Maybe it sends telemetry in production

// but, assuming we're not worried player/customer data is corrupt, we handle the case and soldier on, so our players/customers don't hate us:

    if( myThing )

    { 

    // also it allows devs/testers to keep working when they encounter asserts rather than being paralyzed

    }

}

(I used to be a strong advocate of fatal asserts, which made sense for my small co-located team at the time - you got an assert you could probably go grab the coder and wrote it and say, 'hey, your assert caught a problem, what's it mean?' - but on the ginormous distributed all-over-the-globe team I'm working on now it's simply untenable.)
But I've just realized that the term "brittle" is mostly considered pejorative by engineers these days so I was casting about on Twitter for a better term https://twitter.com/happionlabs/status/1441914044856766465 and the winners were "fault intolerant" and "fault evident" - I could imagine "fault intolerant" meaning it intentionally crashes, which is something you could well want to do if you're worried your MMO state may have become corrupt and you do _not_ want to save player data at that point, whereas "fault evident" might be error messages that get sent to telemetry but we still try to be robust to it, or tolerant of the fault.

Now part of me wants to just make that the new rule of thumb: be fault-evident but fault-tolerant if you're not concerned about data corruption; be fault-intolerant if you are. That would jibe nicely with the dominant philosophy in Writing Solid Code, which was one of my favorite programming books; it leveled me up as a coder overnight.

Writing Solid Code is filled with fault intolerant ideas - for example, they make it a habit to initialize memory to a garbage value in debug builds so you won't accidentally forget to initialize data and accidentally rely on that uninitialized memory being zero - code that works fine most of the time (because uninitialized memory tends to usually be zero). I got into an argument with a fellow coder about it once - he wrote an allocator for his game that initialized everything to zero for him, even in production code. I wanted to change it to the garbage value so I'd 'remember to initialize'. To me, not initializing a variable was a mistake, and I wanted to catch that mistake. But for him, forgetting to initialize a variable to 0 in a heap where it's initialized for you? No longer a mistake. Modern high-level languages tend to do things his way. It would be a misnomer to call his system "fault" tolerant because it was no longer a mistake to forget to initialize variables - it just worked - the system was designed so what used to be a fault was no longer a fault. What should we call that? Fault Forgiving? Let's go with that. If you have a better name let me know.

I can't help but notice that those high-level languages that make us so much more productive than bad old C++ tend to be fault forgiving- forget to initialize variables? It's not a fault, you probably just wanted it to be 0 anyway.. Not strictly controlling object lifetime? It's not a fault, the garbage collector will clean it up when there are no references left, that subsystem that refers to an object we no longer care about can harmlessly act on it for all we care.

But we can't just go crazy and always undefine things as faults. For example, even with garbage collection or smart pointers there are plenty of cases where when we access data that we didn't intend to it's a real logic mistake and we should have been fault intolerant/evident. At which point we can start using our assert() (and maybe expect() macros to be modern) again. 

So I'm writing some code. I get to a point where I have a choice of making it fault intolerant, evident, or completely robust. So I ask myself if it's really a fault. A recent example was passing this in closures to callbacks in a network handshake function. I could imagine a case where the user cancels the operation, or halts or suspends the program, and the original object that would be passed in is not there anymore. We could attempt to make the code robust to that by not deallocating the original object until we're sure any callbacks referring to it are dead - getting rid of the "fault". I could also imagine a callback accidentally firing twice: that no doubt would be due to a coder error or mistake, something unintentional, but … do we care? Do we really want to define that as a mistake? If we define these failures as "not mistakes", as "not incorrect", and protect ourselves, perhaps with a shared or weak pointer to the object we're referring back to, our users have a good experience, we have a lower burden on the coders, but maybe we do have some corner cases or states where things have truly gotten bad and we wish that the fault was more evident.

A situation more recently, that shows how subtle the choice can be - we have a situation where the game's behavior is determined by an A/B test. The A/B test choice is determined by a website. I made it fault intolerant at first by defaulting to an invalid choice and asserting if it was invalid when we got there. That's clearly a mistake - we have an expression on our team - "Asserts are not error handling" - and here race conditions, the website being down, the computer being down, could all mean that by the time the code needs to know whether it's doing A or B it's too late, a legit error that can happen in the wild is not being handled robustly. But the problem here isn't so much with the assert; it's with the bad default. So this is a situation that needs fault tolerance/forgiveness.
But right next to that variable for whether the website is telling us A or B is a variable for whether our QA team wants to override the website's choice. That variable is set by another system in the code. It looks something like this:

ChoiceEnum settingFromWebsite = ChoiseEnum::Default; // needs to be fault tolerant
bool localOverride = false;
ChoiceEnum localSetting = …?; // should this be ChoiceEnum::Default or ChoiceEnum::Invalid?

(Really we could eliminate that variable entirely and query the other system, inject it as a dependency and "pull" instead of "push", but, well, we didn't, for expediency. But I digress.) 

In code like this -

if( localOverride )
{

    actOn(localSetting);

}

and we get there and localOveride has been set and localSetting hasn't, that is likely a coder mistake (which could maybe have been avoided with std::optional but I digress again) that we want to catch. So, for that situation, this is the right choice:

ChoiceEnum localSetting = ChoiceEnum::Invalid;

…

if( localOverride )
{

    assert(localSetting != ChoiceEnum::Invalid);

    actOn(localSetting);

}

Going back to the original issue that spawned this idea for a post: fault intolerance and fault evidence will often have false failures. We'll assert on something that was actually okay - this goes back to saying "it wasn't really a mistake." But if they at least sometimes catch real problems they can still be worth it. Rust's borrow checker is kind of an example here: we've been living with being able to have different objects both refer to a third object and both make state changes to that third object willy-nilly. Most of the time it's okay. I don't like it, it makes the code hard to read and the system impossible to reason about, and we have to expend a lot of QA resources to test it thoroughly and we still can never be totally sure it functions 100% properly in the wild…but usually it's okay. Rust prevents us from doing that, at compile time, even though most of the time it's fine. Rust is treating a lot of use cases that didn't use to be considered faults as faults! The opposite of fault tolerance/forgiveness. But quite possibly worth it, to protect us from whole classes of possible bugs. (And since these intolerances are at compile time not as much of a burden as an assert or other runtime check.)

And yet another subtle distinction: nondeterministic asserts, ones that pop up occasionally due to race conditions or uninitialized variables (that's why we have to initialize to DEADBEEF or garbage values still) or state that's impossible to reason about are as bad as nondeterministic (aka flaky) unit tests. Like a unit test that fails every once in a while, an assert that pops up every once in a while in hard to pin down situations will be ignored, the boy who cried wolf. We used to have one in Minecraft that stuck with us for several years that flagged a possible performance issue but which didn't do any real harm and was rare enough that we eventually undefined it as a fault and passed a log message and some telemetry instead. 

All in all, it would be nice if there was a simple rule of thumb like "Be brittle+robust: use lots of asserts but also put in guards for when they fire." that I could write a pithy article about…but there's not. We want to ask ourselves if the fault is something that could naturally occur in the wild no matter our best intention or if it's really a developer mistake. We want to ask ourselves if we want to consider that "mistake" to truly be a mistake or just a harmless unintended consequence. We want to ask ourselves if we can catch some real bugs/errors early and if we're willing to put up with the false positives to do so. 

The system we're working with will affect our decision as well: I know studios that strip asserts completely out of publish general audience builds, as described in Writing Solid Code; but I also know there's at least one studio who leaves asserts in, and fatal, in publish servers to guarantee an exit before accidentally writing corrupt data. Minecraft Bedrock has a middle ground: asserts halt (but usually can be continued from) in our QA and dev builds; they're gone from general audience publish builds; they still exist and fire telemetry in preview and beta builds. So we can be more lenient about leaving intermittent assertions in than some other studios.

In general I'm going to keep erring on the side of having too many asserts than too few. I'll get it wrong sometimes but can always course correct after that failed build verification test.

A Little Trick For Avoiding Negativity Bias In Performance Reviews

Because of my previous post about feedback and the comments (on twitter and off) I sat down to write this blog post and then remembered I'd already written it. Thank you Google for finding it for me again.

Won't be too long before I find myself doing performance reviews again, giving and receiving. Hopefully I'll be able to fit my technique into the system. I'm loving the Minecraft team so far; for the most part they run it like I want a game team to be run; so I'm optimistic that performance reviews won't be like carpet bombing.

 

My Year In Positive Psychology 3: Notes on Creativity, Inc and Feedback

Continued from Part 1 & Part 2.

So now I'm on to Creativity, Inc (I may be consuming these faster than I'm able to blog about them) and - back the truck up! Pixar's CTO invented the z-buffer!? Why, he must be the same Catmull of Catmull-Rom splines! Respect!

I'm enjoying the book a great deal both as storytelling and as an advice column but there is of course no cure for werewolves here - a lot of the stories sound very similar to corporate game development. "No matter what we try our movies always suck at first and we have to go through hell in order to fix them." I was particularly horrified by the story that, during the Toy Story 2 hell, a Pixar employee forgot to drop his kid off at daycare on the way to work one morning during the Toy Story 2 hell, left him in the car, and the child was unconscious by the time he remembered. Would that employee have made the same mistake if he wasn't overworked? No way to know for sure, but just imagining the possibility is terrifying.

That said, it's clear they're trying and I just checked Pixar on Glassdoor and it does seem like people are happy there. (4.0. So, it's not Microsoft, but it's pretty good. On that note, this was my first week at Microsoft! I am stoked.) 

What really makes me think is the section on critical feedback. I have a troubled relationship with criticism. I thought it was essential up until I was in my forties (in fact, back when I ran a creative writing workshop in Venice I assumed everyone was there because they wanted the gut punch of brutal criticism and had a 'no defending your work' rule. Membership dwindled to a fraction of its former glory under my enlightened leadership. Go figure.) and then started to get tired of people telling me the myriad of ways my games could be better or I could be a better person... more ways than I could ever possibly address! And when I read Johnstone's Impro, where he rails against criticism as a destroyer of art and killer of babies, it resonated with me deeply. Yes, having an art tutor in middle school was why I stopped making art. Yes, instead of working on my novel for ten years until it was 'perfect' I could have written a half dozen novels and one of them was likely to be just as good as that 'perfect' one and surely would have sold more copies. Yes, there is only a slightly-above-average chance that even addressing someone's criticism will actually make a product better. Yes, we wouldn't have abandoned the stealth gameplay from Spider-Man 3 that IMO presaged the Arkham games if internal critics hadn't pounced on it too early.

And to top it all off it just hurts. It is not fun, and if you fill your days with it it probably means your days or not fun. I unfortunately forget which of the books I've read lately mentioned it--perhaps it was The Happiness Advantage?--but there's also some negative literature about performance reviews, those days that come once or twice a year where we shit on each other and the whole company needs to spend a few days recovering from the morale hit. Cerny talked about the 'stench of failure' that can affect projects that are revealed too early. Wow, I can just go on about it, can't I? Side note: my girlfriend and I pretty much have a tacit keep-your-mouth-shut-when-you-want-to-criticize-unless-it's-absolutely-essential understanding and we've been together for years, drama free. Best relationship ever. :)

And then Ed Catmull comes along and says that at Pixar, their brain trust of executives that candidly points out flaws in their movies is absolutely essential and one of the key ingredients of Pixar films. 

Huh.

It clearly works for Pixar. 

So what's up?

There are a few things about the brain trust review at Pixar that Catmull talks about that have been missing from the criticism I'm familiar with. Catmull acknowledges that criticism causes a possibly instinctual defensive reaction and that can make soliciting criticism like a trip to the dentist: necessary but painful. 

I'm going to have to re-listen to the chapter, but some things stood out to me that are different about the Pixar way. 

• One thing was it is trusted peers giving the criticism, not necessarily bosses. (Obviously Lasseter is in charge and involved in these meetings but he's earned it, yeah?) These are other successful movie-makers; not a bunch of executives from Activision HQ who have never made a game before on a strafing run to say 'ur combat sux.' 
• Another thing is that the creator knows the criticism is coming and can not only 'clench up' but gets to choose what they submit for criticism. They're not ambushed with 'hey, we need to talk to you about your level which we pulled down from perforce and tried last night without you knowing' or whatever.
• The creator gets to make some disclaimers beforehand. "This isn't ready, I know this still needs work, but this area I think is ready for judgment." So time isn't wasted beating any already dead horses. I bet this is more important than it sounds. When I get criticized for something I already know is wrong I feel this nearly uncontrollable urge to point out 'yeah, I know that needs work' to rebalance the status equation.
• It's understood that it is a process to make the product better, not a warning shot prior to cancellation. The product is being protected.
• Perfect world it's a criticism of the work and not the person but that's easier said than done. I think we probably need constant reminders of 'you're awesome' and to paraphrase Jake the Dog, 'dude, sucky work is the first step to sorta good work.'

So I think I'll let some criticism back into my life. Hell, I'll have to now that I don't work for myself anymore. But I will try my damnedest to remember the above stuff when giving criticism, and when receiving I'll try to guide the critical along the same path. "Would you like feedback on your criticism?" :)

New Release Blues

You can get the new build at http://energyhookgame.com if you don't already have it. This build has gear customization (adjust the speed of your jets, the parameters of your energy hook, and more); new animations (hold X+Y to get at the third midair trick now); and leaderboards, so you can throw down. For now, you can grab whatever screen name you want, though I will be resetting things later when we get closer to Done. 

With the latest release I wanted to not only get every stretch goal to a first draft state but also polish glaring issues - janky animation in particular. (Especially since James Zachary has been doing some work and there's no excuse any more.) 

It's taken all week! I started cleaning stuff up on Monday, sweeping up dead leaves, so to speak, and have finally gotten to the point where I can push a release that doesn't suck.

This last glitch that I was cleaning up today was one for the books. The lighting in one of my levels looked really blown out - but only when I played the build, not when I played it in the editor. After much experimentation, I realized that if I went to the level from the front end, it had the problem. After looking at various lighting and camera and graphics settings and wondering what could be bleeding from one level to the next, I got fed up and started deleting objects from the front end, hoping it finally would go away.

The offending object? ParseInit, the object that handles the leaderboard API. 

But it wasn't Parse's fault. At some point, I somehow accidentally dragged the front end's directional light into the ParseInit object. Which is persistent. So the directional light was in every level. (It looked a little bad in some of the levels, but was particularly painful in the Misty City.)

Whew.

I'd also discovered that my lighting and shadow quality had ... drifted. Just didn't look as good as it used to. Maybe I applied some changes to a light prefab, or the camera, or something. Don't know.

All in all, I think Unity could use some way to lock your objects and prevent them from being changed once you have them at a state where you feel they're done. Sort of like taping down knobs on a mixing board - you don't want to accidentally bump them and mess things up just a little, because you might not notice until much later and be at a loss what got messed up.

And, just for giggles, this is the checklist I follow when I'm trying to get a build together:

Release Checklist

1. Does anything need its lightmaps redone?

2. Check log and update version number +1. Apply changes to prefab.

3. Set quality to normal.

4. Save project & exit Unity (just to be safe.)

5. If currently using NGUI Easy, delete and switch to NGUI Pro

6. Build windows

7. Test:

   1. PC

   2. Oculus

   3. 1st & 3rd person modes

   4. registering for leaderboards

   5. mainmenu leaderboards

   6. level coverage

8. If testing fails, fix & go back to 3

9. Once testing is solid, add changes. Commit changes

10. Build linux (universal)

11. Change Input for Mac: InputMac -> Input

12. Build & test on Mac (have to build from Windows so we have the lightmaps)

13. Switch back to Windows OS

14. Zip separately and share with Humble on Google Drive (this portion takes me hours because of my slow upload speeds - good to do at night)

15. Wait for them to get in there

16. Announce to: in-game news page, blog, forum, mailing list, facebook

 

It only costs a few hundred dollars to create an LLC? Really?

With Torpex, it cost thousands what with Bill and myself talking with lawyers and creating our 'pre-nup' so to speak. So ... that's what I thought it would cost to do it by myself, too.

Turns out it doesn't. In Washington, you can do it online for $200. (I'm sure there are a few more fees on top of that but still.)

I should have made Happion Labs an LLC a long time ago!

Jamie Fristrom, sucking at the business side of game development since 2005.

The Best Game I've Made In Seven Days And Lessons Learned

I heard about the Ludum Dare 7drts just a couple days before it happened and said, "Why not?" After checking on Facebook to see if people who are avidly waiting for Energy Hook would be pissed off, asking my wife if she could maybe do a little extra childcare that week, I committed.

What came out at the end?

Orchammer 1944: Nazi elves want to exterminate us Orcs, and we have to fight back with hammers and tanks. A session takes a couple minutes - the whole thing takes a couple hours. 

I've done quick games before, but of all the games I've made in a week or less, this is the best.

So what did I learn?

Livestreaming Makes Me Very Productive

I livestreamed most of my work. You'd think it would be a distraction, but livestreaming works even better than Stay Focus'd and Rescue Time at getting me to focus. As long as someone is watching me, or even might watch me, I stop reading e-mail, using social networks, and even put off going to the bathroom. It's the benefits of pair programming without having to spend a second programmer on it. It makes me want to stream my work on Energy Hook much more frequently, and I wonder if it scales - could every member of a larger studio stream at the same time?

"Yes, And..." Gets Things Done

Improv theater has a thing called "Yes, And..." which I learned about from my tabletop RPG playing and these books. The idea is a lot of us have a tendency to shoot down ideas that aren't ours. It's our first reaction. A book on parenting sensitive children that I read even has a name for it: 'bad first reaction' - anytime somebody suggests something the default is to say no. That's my daughter, and me, but thanks to my tabletop RPG playing I'm learning to get over it. I look back at ideas I shot down during my videogame career and ask myself, "Why did I shoot that down? It would have added to the game and in its absence it wasn't like something rushed in to fill the void and make it better." 

I did a lot of Yes, And... over the last seven days. I started with an existing RTS framework. The people watching the stream gave many suggestions and feedback and I believe I incorporated most of them - and in particular, Mark Nau gave me the title, and a document on his ideas for the macro game - which I didn't finish to his specs but I feel it turned the game from something I could enjoy for 5-10 minutes into something I could enjoy for 2-3 hours.

I Almost Can't Ask For Feedback Too Early

It's super-tempting to say, "I know this has problems so I'm going to fix them before showing it to people." After all, what's the point? They're just going to point out the problems I know I already have and I'll be like, "Yeah, yeah, I know."

So there's a couple of problems with that logic:

1. Nothing's perfect, so if I wait until I've fixed all the problems I'll be waiting forever.
2. Their problems aren't my problems. Yes, I'll find out a bunch of stuff I already know, but I'll also find out stuff I didn't know, and I may even get permission to not fix things I think I should fix - it helps me prioritize.

Make A Game ASAP

It was tempting to scope my game so that the first playable isn't ready until day 6 or 7. Instead, again at Mark Nau's advice, the first thing I did after I had the tech up-and-running was make a game out of it by adding some creeps and giving it a win and lose condition. That way I was able to ask for feedback on Day 3.

Do Looks Matter? Why Yes, They Do

I could have made the game with the existing art in the framework and some cubes and spheres and just worked on game mechanics all week, but instead decided I wanted to spend at least a day on art so I'd have something at the end that looked finished rather than prototype-y. I let people vote on my ideas for the look - and the votes were pretty split, with the "Ed Emberley" style winning.

I wasn't totally consistent about it, and ended up with some outlined orthographic 3d pieces mixed with some Ed Emberleyish 2d pieces but pretty happy how it turned out, and want to do an RPG with a similar look in the future - like pixel and voxel art I think a look like this has its own charm, is super-easy to produce, and opens up lots of opportunity for modding and customization - without being tired, like pixel and voxel art. In the future, I'd model the characters in a 3D package instead of using bitmaps.

Also, by choosing a look, the game really started to take shape. Once I knew there'd be Ed Emberlyish humanoids, I knew there'd be orcs. But there were also tanks. Tanks and orcs? Why, it's a WW2 - fantasy mashup. And then Mark suggested the title and I knew what the game was. Though it was a day later that I realized it made more sense for the Elves to be the bad-guys.

And, this is a no-brainer - while I might wish that people could appreciate a game by simply looking at its abstract math, they don't. Going by the 'number of twitter / facebook comments' metric as an index of a game's remarkability, the new look drove a lot more interest in the game. 

Google First, Asset Store Second

When looking for plug-ins, code, whatever for Unity, there's a lot of stuff out there that people haven't bothered to put in the asset store. I went straight to the asset store for RTS technology and wouldn't even have found what I ended up using if it wasn't for Twitter. Googling also got me the blood splatter tech I used.

What Went Wrong

I lost most of the first day by starting with a framework that, after getting it up and running and making some progress, I decided I simply didn't like. Though I'm not sure if this is an example of What Went Wrong or if I did the smart thing in abandoning that package and switching to the other one. The only real way to evaluate whether you like some middleware is to work with it for a while; if you have two choices there's something to be said for switching mid-stream just to see what you're missing. Could I have had the foresight to realize that the first package wasn't for me? <shrugs>

In the final analysis, this game is pretty cool for a gamejam but isn't going to set the world on fire, as it is. Which is fine ... expecting every gamejam to produce a Tower of Goo, Receiver, or Canabalt would be silly ... most of us will go our whole lives without a gamejam of that caliber ... (but I can wish, even though I've already been lucky enough to come up with one pretty cool game mechanic in my life.) When I do another game jam, I wonder how I can tap into something deeper, go more creative / innovative, mine that undiscovered country where crazy things like Starseed Pilgrim and Tower of Goo come from - or if it's really a numbers game, where I have to make a lot of shots on goal to finally come up with something truly remarkable.

Valve's Not Utopia?

(Note from later: I'm embarrased that I've written this now, because when reading the PC Gamer article I managed to gloss over the link to the interview itself and spent time writing this rebuttal when I could have listened to the actual podcast. http://jenesee.com/?p=941 I should know better. Listen, then speak, Jamie. I'll leave the article here anyway, for what it's worth, which might not be much.)

My thoughts on this article - http://www.pcgamer.com/2013/07/08/valves-flat-structure-contains-hidden-layer-of-powerful-management-claims-ex-employee/ - don't really fit into a tweet, I've discovered.

Really, the surprising thing is that we don't hear more stuff like this from disgruntled ex-Valve employees. When someone doesn't fit with a company that has a strong culture, they get squeezed out, and of course they feel bitter. Studies have shown that ostracism causes actual physical harm. 

Heck, I interviewed at Valve and didn't make it and still have a little PTSD from the whole thing, with flashbacks and triggers and everything. One day I might get up the guts to blog about that...and Valve won't come off blameless. Of course it's easier and feels better to blame the ostracisers than yourself, and to lash out.

But Jeri isn't the only one who has been let go from Valve. Why haven't others bitched? I can't help but notice Kim Swift no longer works there. I wonder what the story there is?

Really, when you think about it, it's amazing that there are so few detractors. 

As for the substance of her complaints - some of the things she says are just out there, like "I don't think it works" - that was probably taken out of context, because Valve clearly works by almost any definition of 'work' I can come up with, whether it's profit, revenue, employee retention, being the company Gabe Newell wants it to be, whatever.

And there's the 'you get more bonuses for working on the more profitable titles' thing - lots of companies out there do that, like Activision and Ubisoft, and it definitely has issues - but it's hardly a problem unique to Valve. Could they do better? Probably. They could do worse, too.

The real issue seems to be that she expected it to be utopia, a perfect democracy where everyone would get equal say. Once you get rid of titles and bosses you might hope for a level playing field. Of course that's not what happens - as long as you have three people you have politics - and in a perfect world the quality of the idea would win out no matter who said it but that's never how it works in reality.

This is a common problem when you're promised a democracy. There continues to be inequality in status and power despite the steps taken to address. It happened in some feminist circles in the seventies; it happened at Gore Associates; it happens in the weird GM-less role-playing games I play (we've done away with the power-mad GM but still some people manage to hold more narrative authority than the rest!) 

So maybe she'd like to go work at a company with a hierarchy, and then it wouldn't be "high school" anymore, because the people with consolidated power would have highfalutin titles like Executive Producer and Vice President and everyone would know where they stand and not suffer the brutal disappointment of discovering they're a D-girl/guy when they thought they were an associate producer.

But she's kind of throwing the baby out with the bathwater. In a company with a hierarchy, the labels are one of the main tools they use to consolidate power, and often somebody who doesn't deserve it has the high rank and hundreds of reports and the poor clueless shmucks who are actually making a product and get half their good ideas trampled on and manage to sneak the other half of their good ideas in somehow, actually creating revenue for the company despite their so-called superiors...sorry, went off on a tangent there, where was I?

My point is: it's High School everywhere. My own high school - Miramonte, in Orinda - had what was basically a teenage sorority called the "Bobby Soxers" - like highfalutin' job titles, it was a way to make one's status official - and people literally killed over it. You're never going to get rid of status comparisons, but you don't have to exacerbate them.

So, sure, status still exists at Valve. And some people may have some undeserved power that they've acquired by networking / seniority / whatever rather than by having the best ideas. But at least they don't have the frickin' titles.

And I suspect most people there are pretty glad about that, which could be why this is the only disgruntled employee news item I've ever seen...

Mistakes To Avoid When Going From AAA To Indie: The Movie

Here's a cautionary tale on Indie Game development from Matt Gilgenbach. Some people think that - particularly with console development - you'll get out of it at least what you put into it. Not so - my experiences with Schizoid and Matt's experiences with this say otherwise. There's no sure thing in indie game dev.

http://www.gdcvault.com/play/1017963/Obsessive-Compulsive-Development-Retro-Grade

And it also goes to show migrating from AAA to Indie is harder than you might think. It is almost a completely different sport, seems like. 

A couple possible 'mistakes' that Matt didn't call out explicitly (or if he did, I spaced at that moment) that it's easy for us ex-AAA people to fall into:

Why are you writing your own engine? 

I did this with Schizoid and with the Richard Garfield game that endlessly chased publisher funding to no avail. Oh yeah, and Sixty Second Shooter. With Schizoid and Sixty Second Shooter it was arguably the right call, because it let me have "first game with such-and-such tech" PR stories, but who can say for sure. Anyhow, my own internal logic went something like this - and maybe Matt shared it: "This is a really simple indie game. Therefore it'll be easy to write our own engine." And then later, when we decided to add awesome post-processing shaders or network play or this that and the other already solved feature, it became a burden. (And another thing that led me down the path is it's also fun to write your own engine.) But you have to ask yourself: are you a game developer or an engine developer?

Obviously there are plenty of hugely succesful indie games out there where they wrote their own engine, so it's hard to say making your own engine is clearly a mistake, but you also have to wonder - would given succesful indie game X *not* have been succesful if they used a pre-existing engine?

What's Your Relationship To Feedback?

I have a difficult thought to articulate here. It's not cut-and-dry. I keep rewriting this paragraph as I think about it. As indie developers showing our work to people, whether it's just youtube videos or alphas or showing it off at conferences and contests - we're going to get more feedback on our work than we could respond to in our lifetime. That can be murder on a perfectionist. A lot of people-on-the-internet complained about the graphics in my first trailer for Energy Hook, and since I've became perhaps overly concerned with making it look better, even though the game isn't supposed to be about the graphics, it's about the gameplay. The graphics are supposed to be a means to an end and while I'd like them to look distinctive and consistent and not bad it's certainly a mistake for me to waste time trying to compete in that arena. And yet I have been anyway.
On the other hand, a place where feedback can be really beneficial is when there's some feature or fix that I think might be important - and none of the players I show the game to seem to notice. There can be a massive time savings there as I punt on the feature or fix that nobody cares about. Matt might have saved some serious time not working on things if he resisted the temptation to add features that nobody asked for?
So, you need feedback, not just to find out what you should fix but also to find out what you don't have to fix. But some stuff that feedback says you should fix - you shouldn't. And that's the really tough part. How to decide. Maybe asking- "Is this going to be one of my actual players or is this just a random internet troll who isn't going to play my game anyway because he just wants the next CoD?" -is a good place to start...

And speaking of feedback, I'm looking for more. I'm selecting just a few people to look at an early pre-alpha build of Energy Hook to figure out what I should fix before showing it to journalists before the Kickstarter. If you'd like to, and have a few hours to play it and write up some thoughtful, specific feedback, comment here or send me an e-mail ([email protected]) and I'll put your name in the hat. Let me know what kind of computer you have and whether you're a mouse/keyboard or gamepad sort of person.

Unity 3D And Teamwork: Adventures In Source Control

You'd think with a name like "Unity" it would be easier to use on a team. I've heard people complain about Unity's source control capabilities before but always assumed they were solvable if we used something external that had binary file locking, like SVN or Perforce. (Or even SourceSafe, shudder.) 

Once I tried to synchronize work with Paul, though, I realized it's not so simple. Turns out that Unity doesn't respect the read-only flags on your files. So even if your source control package sets your binary files to read-only while someone else has them locked/checked-out ... Unity will let you go ahead and modify the files anyway.

The read-only flag is how I've made sure team members don't bash each other's changes ever since we first used SourceSafe with Die By The Sword at Treyarch in 1999. Unity is the first tool I've used that doesn't seem to respect the flag. 

Because of this, it seems like everyone I've talked to who uses Unity on a team has their own set of voodoo for dealing with this stuff, whether it's "whiteboard checkouts" or just living with the occasional collision.

So, after Googling and searching Unity forums and spaces for answers fruitlessly, I contacted them directly, and they sent me a plug-in. (EDIT: forgot to include the script. Here it is: RespectReadOnly.cs )

I haven't tried it with Unity Free but it partially works with Unity Pro. It's intended to be used with Unity Team, which is an additional $500 and out of my price range, where it will grey out things in the inspector you shouldn't be able to edit. But even without that, it won't write over readonly files and with a little modification (which I did) it will protect you.

So hopefully they'll work on this more and roll it out for those of us not using Team, because it seems weird to me that we should pay an additional $500 per seat for a single function. If you're using Unity with someone else, or plan to someday, please vote up the issue - I just used all my votes on it - so we can all work on a team easier sooner.

A System That More Or Less Works

In the interim, here's our source control policy and system. This is what we do, and you could do it too, or use it as a starting point. It took me a lot of trial and error to get here, so hopefully this will save other people some time.

I'm certain I spent more time working out our source control system than I actually would have spent redoing work after collisions between me and Paul. Whoops. But I've been a source control enthusiast ever since 1999; old habits die hard. By the sword.

Anyhow, my loss can be your gain.

So:

We use Unity Pro. (This is such a good deal. You get so much: static batching - i.e. much faster render times; postprocessing effects; and more, all for $1500 / person. Even if you're just a hobbyist it seems worth it - hobbyist photographers spend more on their camera equipment, yeah?)

We use Edit->Project Settings->Editor->Mode->Meta Files and Asset Serialization->Force Text. This means we don't have to lock our prefabs. Our experiments with simultaneously editing prefabs on separate machines turned out great. 

We put the RespectReadonly.cs file (below) in our Assets/Editor directory. That makes it go.

We use Unfuddle hosting and SVN. (We tried Assembla and Perforce, which was a tooth-grinding ordeal, and Assembla and SVN, which kept disconnecting in the middle of large checkins.) Under a gig Unfuddle is free, although we expect to hit that ceiling soon, and it almost never makes you have to think.

Because we've set External Source Control, we don't need to check in the Library directory. And none of the individual files (.sln, assemblies, etc) in the root directory need to be in source control - they get generated by Unity if needed. 

So it helps to figure out how to ignore files with SVN. It's kind of tricky with vanilla command-line SVN, but SmartSVN on the Mac and TortoiseSVN on Windows have some built in extra stuff that makes it easier. (On SmartSVN you can right click on a folder and go to Properties->Ignore Patterns and ignore things like LightMap*, Library and .DS_Store. TortoiseSVN has tsvn:needs-lock.) We also don't bother adding the LightMap files. These are things we'll generate on a more as needed basis, and don't want to use up the depot space with them. 

We set svn:needslock on our .Unity and binary files (.fbx, .dae, .jpg, etc). SmartSVN makes this easy - in Project->Settings->Locks set "needs lock" for binary files, and make Binary Files include *.Unity.

And then we could add and commit our files. (With SmartSVN, if you've forgotten to set "needs-lock", it's pretty easy to set a bunch of files en masse: set it to show files from subdirectories and filter on the extension you're looking for, select all, and set it.)

And once it was all in there, the hard part was over. We can now get the latest revision and work on things in Unity. If we're changing scene files and binary assets, we also Lock them so nobody else is working on them at the same time. 

Even if we both need to work in the same scene at the same time, it's doable as long as one of us is only changing prefabs.

Hope this helps other people, so they don't waste as much time as I do. Good luck! And if you have any questions I'm happy to answer.

Side Note: Why Not GIT or Mercurial?

You may ask, "Hey, Jamie, why not use the new hotness?" I used Mercurial for sixty second shooter, and appreciate it, but (so far) GIT and Mercurial are not intended for file-locking, and file-locking is the number one reason I want source control right now.

Having a history of changes is nice. Being able to make tinier commits to a local repository that I then push to the master server would be nice, but is pretty far down on my priority list. Preventing Paul and myself from accidentally working on the same scene file simultaneously is huge.