Game Design and Player Behaviour

There's a really great theorycrafting discussion going on in the WoW Twittersphere that was kicked off by a post that challenges how guide writers present information as "the only choice". Basically, given two choices that are fairly similar mathematically, by changing how you present said information, the general community opinion can swing significantly.

To anybody who studies communications and/or marketing, this fact should come as no surprise. But the more interesting aspect of the discussion was what Celestalon--a technical game designer on WoW--posed to the community at large:

Discussion Topic for the Day: What can we (Blizzard) do to help solve the problem described in this article? https://t.co/Wv7H0xwAWI

— Celestalon (@Celestalon) December 10, 2015

Many of the responses that came out of that boiled down to, "You can't, it's the community's problem." Which is a frustratingly unhelpful answer, and possibly flat out incorrect.

Game design, you see, absolutely influences player behaviour, in-game and out. There seems to be two schools of thought on the matter: design the game and let players interact with it and each other as they will; or design the game specifically to encourage players to behave in certain manners. When said like that, it sounds pretty clinical, but it's really not in practice.


Real-Life Examples

In World of Warcraft, and many other MMOs, to do group content you used to have to find and build a group yourself. You spent time (often a lot of time), gathered people, and hopefully managed to get through the content okay. Good players built up a reputation with other players on a server, and jerk players generally got shunned.

Enter LFD in the Wrath of the Lich King era, which took players from any server and threw them together in a random group to play the same group content. Less control over your group in exchange for a high level of convenience. This absolutely changed how players behaved. More people did group content because of convenience, but things like personal reputation mattered less because the pool of people to group with was orders of magnitude larger.

This was a case where the system was designed, but the influence on player behaviour was either not thought totally through, or deemed okay in balance with what the game gained from having such a tool available.

FFXIV evolved the concept keeping player behaviour in mind with further systems like handing out extra currency and experience to parties with a newbie in them, and commendations to hand out to others for whatever you wanted--good behaviour, great guide, awesome player, the rare dragoon that didn't die in the fire--and as such has helped FFXIV's community be nicer players (even if they aren't generally better players, but that's a different discussion).

In Eon Altar, we design around a very specific player experience--the couch co-op slightly competitive but mostly cooperative experience. Players play together as a group, but the game story and mechanics all subtly (or not-so-subtly) nudge players into competitive play styles. Friendly fire for AoE, real-time looting system where trading with each other is important, character agendas and secret quests/missions that may conflict with each other. Playing Eon Altar with friends is a very different experience than say, playing Goldeneye or Final Fantasy Crystal Chronicles with friends, despite all of them having heavy focus on local multiplayer.

The Eon Altar example I use very specifically because it shows that game mechanics and meta player behaviour are absolutely intrinsically linked. You can't just design something and say, "players will be players, yo." Can you imagine if we released Eon Altar in its current state online? Without having players be local and therefore with local social norms to enforce acceptable behaviour, the game would be troll city. That's not to say we don't have ideas, but it's clear because of that player behaviour component, the game would not translate well as-is to pure online play.


Simultaneous Insufficient Info and Info Overload

For Celestalon's issue of cookie cutter builds and people just wanting/requiring/taking a given choice suggested from the community, there isn't an easy answer. Some people like choices, others just want to be told, "this is the best option," because they don't want to choose or can't fathom the choices available.

But just because it's not easy doesn't mean it's not a worthwhile exercise. MMOs like WoW are complex beasts, and so much information isn't in the base game itself that gets built by the community at large. Other times some of the information is in the base game, but without any context from the designers and so the players are expected to come up with ideas themselves, to which a large subset turn to the community to make those decisions for them.

Some of the problems are that they're imminently calculable. When someone can say, "this talent or ability does 20% more DPS than that one," it's a no brainer, and a robust theorycrafting community will discover these quite quickly. Some of the problems are that the theorycrafting community gets something wrong, or right but heavily caveated and the caveat gets lost, and then you have this strange state where the community as a whole has a gospel that's factually incorrect.

But at the end of the day, you're in a group, and that group requires a specific minimum level of performance, therefore between peer pressure and mathematics, there's a heavy push towards conformity and the "correct" choice. If the designers won't--or can't--provide the information towards the players or even make some of their choices for them if the player opts into it, then the player will seek that information elsewhere. To be fair, even if the designers provided that information, the player might seek that information elsewhere, but is there anything the designers can do to reduce that need or requirement?


What to do?

If we're spit-balling, perhaps remove talents entirely, or making talents generally utility-only perhaps so there isn't a correct answer? Maybe provide default options--all passives because a player who doesn't want to think about the game will probably not play at a level sufficiently to use active talents to their maximum effectiveness.

If the designers can help solve or ameliorate this issue, it's a huge win for them because it means they're a step closer to interesting choices (or they've basically cut them from the game and no longer need to spend design time on them). But leaving it to the community to solve by itself probably won't solve anything.

Rather, they should use game design to help address the issue, and Celestalon's question probably stems from recognizing that. Heck, if they can "solve" it, you bet many other games would take note and follow suit. 

Rohan at Blessing of Kings has an interesting take on whether it's an issue to be "solved" at all.
#WorldOfWarcraft, #GameDesign

[WoW] Artifact Weapons as Alternate Advancement

There's a little consternation in the community on Twitter at least that Artifact Weapon advancement is ultimately dull. Eventually you'll get everything, and it won't even take that long.

@Drewbobmiller Not multiple patches. Most likely between 1 and 3 months, but we haven't finalized tuning on it yet.

— WarcraftDevs (@WarcraftDevs) December 1, 2015

As far as I can fathom, there's two primary goals about Artifact Weapons that Blizzard wants to achieve:

1. They want an alternate advancement method that goes beyond hitting level 110.
2. They want to reward people for playing a specific spec (or just playing their character in general).

When Blizzard moved to the current talent system--which works better at end game in my opinion than the old talents did--they lost that zing when you ding. Even if it didn't mean much in the grand scheme of things, choosing where you put your talent point as you leveled felt good. It made you feel like you had direct input on the growth of your character.

At the end of the day with respecs it actually didn't matter. At all, really. But it gave you a sense of steady progress and the illusion of choice, which might be almost as good as actually having choice.

Blizzard tried to return that to us in the form of Draenor Perks, but because they were random, it didn't quite have the same oomph. So with Artifact Weapons, Blizzard returns us to the benefits of the old talent system, but not tying it to levels means we can continue advancing beyond 110, adding longevity to the advancement system.

@ShamanGio You will eventually be able to unlock the entire tree.

— WarcraftDevs (@WarcraftDevs) December 1, 2015

Of course, in modern day gaming, there's no way they could lock you forever into specific choices, so you'll be able to unlock the entire tree eventually. This means that short of world first raiding, there probably isn't much "game" to deciding what you want first outside of, "Oooh, that sounds cool!" There's still an open question of respeccing your Artifact Weapon as you level it, but I'd be shocked if you couldn't reset the point distribution on it somehow.

If you're looking at Artifact Weapons as a way to add choices to your character and interesting Theorycrafting differences between paths, you're barking up the wrong tree, as that's clearly not what Blizzard intends for the Artifacts based on the info they've handed out. And once Legion is over? They can just bake the Artifacts into the specs baseline (or bits and pieces of them) and drop them for WoW 8.0.

The part that doesn't fit this is, of course, relics. This is where Theroycrafters will get to play mathmaker and determine which traits are the greatest for adding extra levels to. Of course, we might not get that much choice in the matter; do we know yet if relics will increase specific traits? Or subsets of traits that we can choose from? But it's a minor amount of customization, throwing TCs a bone if you will.

Overall, it's a nice alternative advancement system, but it's not nearly as complex as some folks wanted. But that's why we (ostensibly) have talents anyway. #WorldOfWarcraft, #Artifacts, #Legion

"Do I Sound Gay?" Documentary; Thoughts and Reactions

Today I'm going blogging off-roading for a bit because I watched an interesting documentary that I feel I need to unpack and analyze.

The documentary, "Do I Sound Gay?" has been on my radar for quite some time, and I was excited to hear it was on Netflix. After seeing it, it was definitely good, but also rather difficult to watch at the same time. Aside from a couple of content warnings--news footage where they show a gay kid getting assaulted, and a couple of censored porn scenes as examples of hyper-masculinity in gay culture--David's story was also largely my story.


The Gay Voice

There's a definite "gay voice" that acts as a flag or a tell for many people. Sometimes erroneously, but fairly often it's accurate. Listening to someone, it's easy to hear certain affectations that sound "gay"--at least in North American culture, more on that later. I'm damn sure I sound gay, given I've been asked a few times when streaming if I was (the answer is yes, duh).

In the documentary, speech academics talk about certain tells, such as elongated 'S' sounds; overly-enounced 'T' or 'K' sounds; the voice tone sliding up into a sentence, or ending up when more masculine voices end down. All of which now I can clearly hear in my own speech in this Archimonde N kill video (surprise, we downed Archimonde last night! hooray!).

Of course, there's the question of why do I care? And is it really a bad thing?


Self-Hate, or Valid Concerns?

It's easy to dismiss the documentary early on as David being a self-hating gay--many of the reviewers do, and I know I was tempted to at the beginning as well. But at the same time, how much of that is rooted firmly in trying to pass as straight, to hide, not draw attention to oneself? When you spent most of your early life hiding in fear of getting beat up, or even killed, hiding is a pretty sensible maneuver.

Into adulthood, I know it's something that I've been concerned about when giving presentations to my peers. Are the other programmers going to take me seriously if I sound like a queer? Early in my career some of them evinced homophobic attitudes, but thankfully later in my career it hasn't seemed to much matter, which is a huge confidence booster. But these are totally valid questions to ask oneself, especially given research into female speech affectations being a liability in the corporate environment.

And then there's the fact that my voice apparently didn't always sound "gay." Mirroring David's experience, sometime during University my voice became more nasal, higher pitched. More from my throat and nose than from my chest. I knew this because my sister commented on it, wondering aloud if my singing voice would be different when my speaking voice had changed. I apparently never noticed the change, but then again it happened gradually for me, but "suddenly" for my sister.

Was it because I was mimicking the gay peers I generally didn't have growing up? Was I flaunting my sexuality as out and proud now that I didn't have to hide, over-compensating and camping it up? Where did that voice come from?

It's not so much a matter of, "Oh god, why did this happen to me?" as it is an intellectual curiosity at this stage of my life, but there were times when I was younger where I wish I could have code switched to a "straight masculine" voice more easily.


Fascinating Introspection

Something the documentary didn't touch on but I thought was an interesting bit of info is the whole speaking from the throat/nose vs. the chest. Both times I was in Australia, the standard way to talk in Sydney and Melbourne is from the throat it seemed--or at least it was easier to mimic the accent by speaking from the throat--and most voices tended to be higher than they are in North America. The documentary pays lip-service to this by having a couple of interviews with other language speakers, but never sits down to make a serious comparison, so I don't know if it's really extensible outside of this continent.

Overall, it was a fascinating documentary. One which tackles head on historical stereotypes, cultural contexts, and even the dangers that the gay voice can represent. Something a little different, but something pretty interesting in my personal opinion.
#Documentary #Sexuality #Gay

[IndieDev/EonAltar] 3200% Physics Performance Increase

There are certain numbers you pretty much never see in programming. You're often pretty pleased when you can get an algorithm performing 25% - 50% faster. Once or twice in your career, you might nail a mind-boggling number like 3200%. Not a typo.

Green wireframes indicate colliders.

In Eon Altar, we use physics colliders for just about every type of interaction you can think of. Actors and the movement cage to keep them on-screen; turning environment rendering occluders on/off; determining when actors are in melee range of other actors; quest triggers; snapping the movement marker to interactable objects; raycasting the movement marker to the ground; occluding ranged attacks; when to change the camera angle/position; and so on.

My list of systems that had physics colliders, and what they interacted with.

With the sheer number of things we use colliders for, the physics system can get really bogged down really quickly. Whereas the engine can cull geometry that's not visible in an active viewport--for example, when a statue goes off screen, the engine isn't spending time and resources rendering that statue: there's no point--that's not the case for physics objects. If the statue has any physics components, they must be calculated. Things off screen absolutely can and should still run in the physics simulation as they can possibly affect things on screen.

Colliders that don't touch other colliders, or don't move, don't cost much to maintain. However, the more contact points colliders have, the more expensive the calculations get. In Eon Altar, before optimizations, an average level would have upwards of 2000 active colliders, with over 8000 contact points every frame. This bogged the system down to about 10 FPS on a good machine. It dipped to 2 - 5 FPS on crappy machines.

This is a small piece of E1S2, The Portal Obstinate. You can see the actors, plus colliders all over the place.

So the end result was clear, we needed to reduce the number of active colliders at any given moment, and when colliders were active, we needed to reduce the number of contact points. Believe it or not, reducing the contact points was actually the easier of the two tasks.

Unity has a pretty handy feature where you can tell it to only have colliders on specific layers contact colliders on other specific layers. For example, the UI colliders need never interact with say, camera colliders because those two systems never interact with each other. Below you can see the default setting in Unity: everything colliding with everything else.

This is the default, and the default is dumb.

This is clearly not what we wanted. I told my boss, Ed, that I needed 3 days of alone time to break down the system and re-design it. At the end of the third day, if I hadn't received the kiss of True Love from my prince, I'd turn back into a mermaid.

However, making it system-wide that only certain layers interact with other layers was easy, once I figured out what layers had to interact with what other layers (which was seriously the hard part, as it required a lot of thinking/designing/researching code). Add to that code to ensure certain components are on specific layers to make them designer-proof--because you don't want to rely on the designers (or programmers for that matter) remembering "rules", that path leads to bugs and heartbreak--and boom, you've significantly reduced the number of contact points even for colliders that are overlapping, as they may not contact at all if their layers don't interact.

Interaction diagram. Note that some layers interact with themselves, but many don't. One layer may interact with a second layer, but the second layer may not interact with the first, which is a subtle but powerful feature for reducing collision calls.

A much more sparse physics layer setup. This is slightly evolved from the above diagram, so they may not match 1:1.

That alone netted us an 800% - 1600% increase in frame rate, depending on the level.

The second trick was to create "Encounter Zones". Giant colliders that turned a bunch of objects in the hierarchy on or off when the party encountered them. The idea being we don't need a bunch of AI or colliders running if the party is nowhere near them. So everything from enemies to traps to loot to interaction points get grouped up in these Encounter Zones, and when the party gets close enough, voila, everything appears!

This caused some other issues, like having to create a method to slowly load NPCs over time (because initializing an actor is really expensive, and if you initialize 15 actors in a single frame, that frame is going to last on the order of seconds), but for the most part it did the job rather admirably. 

Adding in that gave us another 200% - 400% performance increase depending on the level, so in theory, in the worst levels, we could have been looking at upwards of a 6400% total framerate increase, but in practice I measured a 3200% increase in some of the worst parts of some levels.


Conclusion

Granted, these are things we probably should have implemented off the bat, so it's not quite as impressive as I'm making it out to be, but that's sort of the breaks when you only had 2 - 3 programmers making an indie game and way too much to do to keep other people like design unblocked.

Sadly, these sorts of optimizations took a backseat to feature work until design was all, "WTF the game runs so slow!" and engineering was all, "Whelp, time to put features on hold/cut them and fix this issue instead."

Not that the situation was anyone's fault per se, but the reason we got into situations like that was partly because we had not enough programmers and not enough time to finish infrastructure versus feature work, and partly that nobody on the team at the time had shipped a product from scratch, so we didn't necessarily know we'd hit these situations--though I'll be honest, the physics overhaul had been on my list for months and it was just a matter of waiting until it was unbearable such that I could tell folks to leave me alone while I worked my magic. It also ended up being easier, I think, that most of the systems had been implemented and I could holistically solve the system instead of doing it piecemeal over time.

But at the end of the day, it got fixed up, and it's super solid now. Programmers have to remember that new components with colliders need to have their layers thought about (and we have a wiki with guidelines and instructions), but designers can just use the tools and it all does the right thing, which is pretty awesome.
#IndieDev #EonAltar #GameDevelopment