Tuesday, May 26, 2015

[FFXIV] The Aggravation of Aggro

I (finally) have some time for gaming--there'll be a post about that later, but for those curious as to why I haven't had time, check out this article. My boss Ed Douglas has a pretty meaty quote at the end--and so I jumped back into FFXIV. After running a few lowbie dungeons to get back into the swing of things, I took my big swing at World of Darkenss. And roflstomped it.


FFXIV has a pretty old-school outlook on the concept of aggro. Actions generate aggro. Tanks get a bit of a multiplier on their actions, but otherwise it's mostly related to damage/healing output. Monsters will attack whoever has the most aggro (FFXIV calls this "enmity" or "hate").

So, for example, if you pull three monsters, but as the tank only attack one of them, if the healer performs any healing at all, the other two will peel off and attack them. Or if your DPS go HAM on the core...er, mob that you as the tank aren't, they'll get its attention pretty quickly. Thankfully FFXIV isn't like WoW in that such a mob will eat their face off immediately. A DPS or Healer can generally take 5 or 6 melee hits before they'll be in danger; more if they have defensive cross-class skills or self-heals.

FFXIV's enmity system actually works pretty well when all parties are within a certain gear level of each other. Yeah, depending on what level you are and if you're WAR or PLD, you may or may not have the tools to really tank effectively (30 - 40 in particular is a well-known sore spot for PLD), but besides that, if you're good at tab-targeting and using all the tools at your disposal, aggro isn't that big a deal. Occasionally someone will peel a mob off you, but you can get it back pretty quickly--unless of course you have seven people attacking seven different mobs, at which point *throws hands in the air*.

The Problem

My issue with FFXIV's aggro, however, is tied directly to how FFXIV handles group content. WoW's "Timewalker" dungeons are imitations of how FFXIV has done group content since at least 2.0. When you get into a lowbie dungeon, your gear gets scaled down. Except in FFXIV, your level actually gets scaled down, too, so you might be missing some abilities. But you're always generally running the dungeons with the intended skill set, which is actually super cool.

FFXIV's Scaling in action. A set of mostly level 15 gear vs. Synced down to 15 gear. Primary attributes are relatively close, but some of the secondaries are actually a fair bit higher with the synced-down gear.
So why is this a problem? It unto itself is not. The scaling works pretty well. It's not perfect, mind you, but it's decently close. But a super newbie tank with no cross-class skills and dealing with folks who have materia melded and tonnes of fantastic gear is still going to have a bit of a harder time. The real issue, however, is most post-50 content doesn't sync your item level at all, so you end up with tanks who have 60 ilvl gear dealing with 130 ilvl DPS.

When the DPS can outstrip your maximum aggro generation simply by performing their basic rotation on a target that you're going all out on as a tank? That's not fun, that's frustrating. There's literally nothing I as a tank can do to improve my play to avoid that.

Once you have higher gear levels as a tank? You can ignore aggro almost entirely. My Paladin is at 110 ilvl now. Short of me being asleep at the wheel entirely, or a 130 ilvl DPS blowing every cooldown they have right off the bat, nothing rips aggro off me. It's not even a question. For multi-target pulls, I do still have to tab-target to prevent BLM or healers from ripping things off me, but I only need to hit them a couple times each and they're pretty sticky from there.

There's a very small range of ilvl differentials where aggro is actually fun as a mechanic; where it matters and everyone can't pretty well ignore it.

The Solutions?

The above is funny, because WoW decided eventually that they may as well make aggro binary as a whole. Tank never touched the mob and eats the healer? Tank's fault. Otherwise, good luck peeling anything off a tank in WoW.

I don't think aggro as a concept is necessarily bad. It's how tanks and DPS largely interact in the trinity model, and is what tanks use to control the battlefield in the absence of actually being able to physically stand in the way. Aggro is an easy to understand system as an AI. Enemy behaviour is understandable by players, and therefore they can feel in control of the game.

But FFXIV's ability to sync up and down is imperfect, and in cases where they don't sync at all the system breaks down significantly. At high levels of gear, the system is largely ignorable because aggro modifiers scale so well. The immediate "obvious" solution would be to fix scaling in cases where it's broken, and introduce scaling where it's not. But perhaps there's a different method we can use?

What if instead of being tied to damage/healing throughput, enmity was statically generated by actions taken? Cure 1 generates 0.5 point of enmity. Cure 2 generates 1. Stone I generates 1. Fast Blade generates 1, comboing into Savage Blade generates 2 more. Flash generates 1.5 for all enemies in range. So on and so forth.

By decoupling enmity generation from numbers and tying it to actions taken, the aggro game then is not tied to your gear at all. Rather, the game as it exists when all parties are close in gear level is maintained regardless of gear disparity.

Does this lead to odd situations like a lowbie tank ripping threat off a much more geared tank? Sure, but you can do that with Provoke anyhow. Well, until you get flattened because you have so much less health. But it also would make tank swapping a lot more predictable, as in both FFXIV and WoW you have issues where immediately after a tank swap, a much better geared tank would just rip aggro again immediately due to more damage output.

So I don't think we needs throw out the baby with the bathwater, but I think an aggro system that didn't scale might be a bit more fun overall imho. At least, it'd flatten out that wacky curve from struggling to ignoring. #FFXIV, #Aggro, #GameDesign

Monday, May 18, 2015

[WoW] One Day I'll Fly Away; Leave Draenor to Yesterday

Flying in Draenor is a pretty hot topic all around. Folks who want it back are vocally vociferous, and folks who're happy where things stand fire back with almost equal fervor.

The reasons the devs dropped flight in Draenor was largely due to design considerations. Bashiok illuminated this a year and a half ago:
Flying trivializes combat. A lot of people like to say we're trying to force world PvP, or that we just really want people to look at the pretty trees we made, but those really aren't the reasons that drive this same decision we've made every expansion. Flying allows you to escape or enter combat at-will. There's a reason why flying isn't allowed in dungeons and raids, or battlegrounds and arenas, and that's because it would trivialize the core mechanic of the game in those areas - combat. For much the same reason it trivializes how content is approached in the outdoor world based on the simple fact that you can lift off and set down wherever you like.

So that's the main reason. But sure there are a lot of other problems it can cause for content design such as zones having to get a lot bigger because flying mounts can travel so quickly (and thus making ground travel in them take much longer), it reduces the impact of elevation within zones, it completely removes the ability for us to pace or present content in any structured way, and in general removes our ability to determine how and when players approach a situation, see a vista or location, or charge into/out-of a combat situation. It just greatly reduces any gameplay we want to create by allowing infinite choice in how content is approached to best suit a player's intention to (usually) avoid that content.
I completely buy into that reasoning for leveling, and heck even max-level solo content (note to the reader: there's a big "but" coming later). When you're playing D&D, your players often go off-roading, and circumvent all your planning. In a tabletop RPG, this is something that should be run with and celebrated. In a video game, however, you don't have that flexibility as a designer, so you try to ensure that players approach your content in a relatively narrow, controlled set of circumstances.

As a player, yeah, that kind of sucks. "The man is limiting my gameplay! I don't like the man's gameplay!" I kid--mostly--but there's a grain of truth in that if you give players a method to circumvent content and go straight for the goodies, they'll take it.

But here's the rub: what unique max-level content is there in Draenor right now that isn't instanced?
  • Apexis dailies
  • Garrison quests
  • Elite hunting/trapping in Nagrand
  • Treasure hunting
Which is to say, not a whole lot of variety.

Most of those, aside from treasure hunting, could be mitigated by introducing no-fly zones, perhaps on the days the dailies are active. "Flying riles the beasties, so no flight except on designated paths!" "Go kill a bunch of Socrethar's army, but watch out, they have anti-air batteries!"

Treasure hunting itself can be fun. I enjoyed it a lot while leveling. But at the same time, those folks who're using addons/maps aren't really doing the content as intended anyhow, and good luck seeing treasures hidden away on the ground while you're up in the air if you're not using those maps. It's also 7 months into the expansion, how many folks are still treasure hunting at this point? Probably more than 0, but I imagine the grand majority of the player base is done with it.

And finally, garrison quests. Blizzard originally claimed that garrisons weren't required content, but by that measure, neither are raids or 5-man dungeons. You're missing out on most of what Draenor has to offer as solo content if you skip your garrison. So why not just gate flight in Draenor at the end of the garrison quests? They can keep the design principles intact for those quests, and give players another carrot to finish that storyline. I mean, we're talking basically 3 months worth of weekly quests to get flight, so it isn't like folks could get it straight out the gate when they hit 100.

But interestingly enough, when I asked Twitter what they wanted to do with flight, it had little to do with Draenor-specific content.

Archaeology was the primary response, which technically has Draenor specific artifacts to uncover, but other things are just soaring through the air, gathering, fishing, pet battling, so on and so forth. Fishing and gathering are mitigated to an extent by the sheer number of resources the garrisons provide. But Archaeology...

This tells me that Archaeology is broken content as is. I agree with Yoco that it was clearly designed with flight in mind. Perhaps it should be redesigned to be less random, and allow you to spend more time at a site to reduce travel. Right now it's basically an excuse for Blizzard to send you cross-continent on a whim. Rather, perhaps it should be a more engaging mini-game unto its own so that it doesn't need to lean on "combat" as the gameplay, as it sounds like a number of people don't care for the two to be mixed.

With 6.2 coming out, and Tanaan being the new content, they could easily put a no-fly zone around it and allow for flight everywhere else, allowing the designers to keep current content as designed, and letting players explore Draenor to (mostly) their heart's content.

While I agree with the designers about flight basically wrecking content, that Pandora's box was opened, and closing it is exceedingly difficult. I mean, how often do you hear people complaining about the lack of flight in Guild Wars 2? Wildstar? Final Fantasy XIV up until the devs announced that they were adding it?
AlternativeChat is giving some sass here, but at the same time, there's a kernel of truth in that statement. If WoW had never had flight, the conversation might not even exist. Turning back the clock on that decision might be a massive mistake.

It'd be interesting to see how many folks have actually left the game due to a lack of flight. The plural of anecdote is not data, and the sample size/methodology is flawed, but I have only 1 person on my Twitter feed that responded who isn't currently playing, and no flying was but one of many pieces of information he used as impetus to quit. So I guess the question for many players is, where's the straw?

WoW is back to the same level of subscribers as it was before the expansion launched, and only Blizzard has the list of reasons people reported for leaving. But unless Flying was a major issue, I don't see them bringing flight back as long as it's performing the way they expected with respect to players and content. But as mentioned above, I don't see a good reason why flight restrictions couldn't be carefully lifted, which still allows for Blizzard to maintain their design considerations. #WoW, #Flight, #GameDesign

Monday, May 11, 2015

[IndieDev/EonAltar] Handset vs. Central UI: We Aren't Phoning It In

Eon Altar is on Greenlight! Please vote YES if you haven't already, everything helps! Thanks! 

For Eon Altar, we have a bit of a unique scenario. Well, not ultra unique, given the Wii U, but when you have 4 players, and they all have their own screens, as well as shared screen, where do we put information where it'll have the biggest impact? Stephen Cleland, our UI developer, has done a fantastic job of putting together some awesome UI, and the team as a whole have been iterating on the design for a while. To be fair, we're still iterating, but let's talk a bit about the problem space, and some of our solutions.

Early UI on our Central Screen
When we first started out, we wanted to unclutter the central screen as much as possible. We had a handset, we could put a bunch of information there and leave the screen big, bold, and beautiful! And it was big, bold, and beautiful, but two major problems cropped up pretty quickly in play testing:
  1. People found it difficult to differentiate enemies from allies, and in some cases, from the environment without any visual cues.
  2. People would get fatigued/annoyed having to "bounce" too often between the handset and the central screen.
With early UI, about the only elements we had were the corner health bars, and your movement marker when you were actively moving it. It worked pretty well, but that was also well before we had textures, lighting effects, and props, and all sorts of other things that--while gorgeous--are technically visual noise when it comes to raw gameplay.

Screen capture from early November, 2014. Little to no UI. The only elements being some debug info, corner health bars, and our cake icons to denote interactables.
Who are you targeting? Who or what are your friends targeting? Who are your enemies? Allies? Hell, where are you on the screen? You could get most of this information by looking at your handset, but that ties into issue number 2, "bouncing". You don't want to have to keep glancing down to your handset every time you need basic information.

Once we realized these were major issues, we had to really double down on what kinds of information the handsets were to convey, and what information the central screen needed to show. To do this, you have to break down how people interact with the game.

Our core interaction loop is relatively simple. The stages can be defined as follows:
  • Thinking
    You're surveying the field visually, looking for what you want to do next. Attack a target? Help a friend? Grab some loot? Check out the shiny?
  • Targeting
    Using your movement marker, you want to select the thing you're interested in.
  • Deciding
    What is the precise action you want to take? Attack them with which power? Debuff them? Move closer?
  • Executing
    Once you've decided your action, execute it.
Any time you have an arrow, you have the potential for a "bounce", where the player will look at the central screen, down to their handset, and back to the central screen. That's a lot of physical movement, and every time the player switches contexts, they have to remember the other context.

Since the handset can provide a plethora of deep information, we decided that any time you want to drill down on a target, the handset is the way to go, which meant giving you enough information on the central screen to perform the other three stages without actually looking at your handset.

Still a work in progress, but we're getting closer!
A few things you can see in this screenshot, so let's break it down.
  • Your movement marker is always visible (when you can act)
    The ring around the feet of your character is what you control with the handset when you want to select something specifically. You can tell what other players are interested in, and when you're not actively looking around, it also shows where your character is on screen.
  • You can tell who you're targeting
    In the screenshot above, Silent Thorn is targeting herself. You can see her targeting flag above her head. We still have some polish left on this mechanic, but seeing in real-time who everyone is targeting has been a huge help to play testers.
  • Interactables are highlighted
    Some things are always sparkly and obvious, such as chests or barrels. Other things you need to search around for a bit. In the screenshot above, because movement markers are close enough to the glowing speech bubble icon on the ground, it became visible. Using your movement marker as a means of exploration without moving your character is a way to see the world.
Some things we're still working on, such as outline highlighting for enemies and other NPCs, a targeting line between you and your target to highlight it even more. We're also considering health bars, since often people will make snap decisions based on enemy health (who is the most injured?). We also use some on-screen UI to indicate "engagement" (when you're locked in melee with a specific enemy), and if you're in combat or out of it.

Also still in progress, but the power wheel in action.
We're getting closer to the ideal--where you really only look down at your handset when you want detailed information, or you want to perform a specific action. Information like, What powers do I have available to me? What's my chance to hit this target? How much damage will this attack do? What kinds of effects will this power cause? 

Really really early iteration of the Power Wheel, still with debug buttons. Late October, 2014.
We've killed all the debug buttons :)
Even as I type this up, we're still iterating on the UI. Play tests have allowed us to get some really good feedback on what works and what isn't helping (and things we're still missing, too!). Mark Hollier has been amping up our UI and transitions between dialogue, combat, and exploration with some sounds, which really helps direct your attention to the place it should be. Small things, like when the power wheel and movement marker show up, and when they disappear help provide context to players as to what they can do at any given moment in the game. #IndieDev, #EonAltar, #GameDesign

Friday, May 8, 2015

NBI TalkBack Challenge: How GamerGate Affected Me

Wow, Izlain, you certainly don't pull any punches for TalkBack challenges for the Newbie Blogger Initiative. Might be a wee too controversial to try and bring new bloggers into the fold, but hey, who knows?

As an almost old-hand at this point (1.5 years and counting!), I figured I'd throw my hat in the ring. But what a ring. You can see the culture of fear that GamerGate has created by the number of folks who put "TalkBack Challenge" in their title but not the term GamerGate, for they seem to be very much like Beetlejuice: call their name enough times and they show up to sow chaos. I won't necessarily link those folks directly, because I respect their fear. 

Frankly, I share it.

I'm no stranger to love...no, wait, that's not right. I'm no stranger to what seems to have been deemed SJW behaviour--also, really, using the term "Social Justice Warrior" as a derisive name? I've been called much, much worse. I've talked about and supported (and broken down) the PAX Diversity Lounge for East and Prime; I've gone to GaymerX; I'm on record taking Blizzard to task in the past about their lack of diversity in games, then celebrated when they had some; I've talked about why I can give FFXV a pass despite being mostly male (because history); and I've also chatted about the importance of speaking up, not letting trolls shout you down.

I've been lucky. I'm a white dude, so that luck probably wasn't earned, but I haven't had the wrath of angry GGers DDoSing my blog, and the only time someone showed up they were pretty respectful in their discourse, despite our disagreement.

But I've seen the effect the "movement" has had on my friends, getting shouted down by a movement that ostensibly values the ability to say their piece on other people's platforms to the point of silencing said friends. I've watched GDC and Gamasutra get flooded by noise and attacked--which is hilariously short-sighted given they claim to enjoy games, but attempting to destroy or demean developer resources is probably not the best way of getting developers on your side. I've watched female colleagues get harassed out of the industry entirely. I've seen friends concerned about their kids who want to be game developers going into an industry where the "fans" are so actively hostile to the folks who make the games they "love".

And I've been afraid to speak up myself. I'm a budding indie developer. Our company doesn't have many voices. To speak up against the loud behemoth that GG acts like means I could be endangering one of the few voices our company has. It's certainly not to the level of some developers, whose very lives are being threatened because of this, but my livelihood could be. Since I can't hide, I've tried to avoid actively engaging. My voice--a developer's voice--has been silenced out of fear.

In my life, I've been verbally assaulted and physically threatened for being a "faggot". I've been physically assaulted for my very existence, and then told by the police that my presence was unwelcome and causing issues, despite doing literally nothing but playing pool and trying to ignore the asshole yelling at us. I've had coworkers in past jobs deride me for who I am, telling me to be more "straight". To a large contingent of people, I shouldn't have the same rights as they do: to marry, to be by my husband's side in the hospital if he's ill, because I'm an "abomination" and "living in sin". I may as well not exist in video games, for all the gay characters that don't exist (though, it's getting better!), but growing up, I had no inkling that there were others out there. Gays didn't exist in the mass media in the mid-90s. Thank god for porn, though. Seriously, that was pretty much my only exposure to other people like me growing up.

I've come through all of that with thicker skin, and a healthy fear of people who hate me.

I've seen online and real life bullies literally insult people to death. People committing suicide because they saw nothing but hate directed their way, and no hope, no other way out. I've seen someone break down because people in LoL told him that they hoped his mom died of cancer, and she really was dying of cancer. When told that's not cool, they doubled down.

This lack of empathy for other people, that death threats and insults are "just how things work," is not acceptable. It's not just how things should work. Thicker skin should be reserved for actual criticism, not for threats or insults.

If you want to actually talk about ethics in gaming journalism? Fine, be my guest, I think that's a totally laudable goal. But GamerGate is not the framework to do that in. It was tainted from the start by bad actors, and continues to be so.

So you want to know how GamerGate affected me?

It terrified me. It reminded me of how I grew up: in fear of other people finding out what I was, and making me feel like a lesser person for it, or getting physically attacked, or even killed. 

It infuriated me. Watching friends and developers I admired drop out of the industry because they were being harassed.

It saddened me. That people could have so little empathy to not see how their actions affected the people they were threatening. That such behaviour was "normal".

It shamed me. That other folks who I share an affinity with--games--would go to such efforts. Gaming as popular culture probably just got set back another 5 years because of this behaviour.

It silenced me. I don't speak for my friends or the company I work for in this matter, but because my voice is one of so few for my company, the two will probably be conflated, for better or worse. So I held my tongue. I don't know necessarily what other folks in my company feel about this issue, I don't represent them. Honestly, I don't know that I want to know. Like the "movement", the conversation would probably be tainted from the start.

So yeah. I don't even know if I should post this. I'm still terrified it'll ruin things for other people associated with me. But I'm going to anyways, because I'm tired of being quiet on the subject directly. #NBI, #TalkBackChallenge, #Personal

Wednesday, May 6, 2015

[IndieDev] My Game Eon Altar on Greenlight! Mobile-Enhanced Co-op RPG

Well, not only my game, there's a few of us working on it, but this is the shortest way to convey I'm on it too.

But! The game that I've been working on is finally on Steam Greenlight! We have a trailer, and we need votes so we can actually sell our game. What is Eon Altar? Well, video is worth a novel, or something, right?

Breaking it down, it's a co-operative RPG for 1 - 4 players, the main game is on your PC/Mac, and you connect to it via your iOS or Android device to control your character, do RPG character-sheet things like upgrading abilities or digging through lore, and get secret quests, party votes, and play out dialogue. You can see more information on our website: http://eonaltar.com/game.html

Team Photo, at our largest.
For background, we're a small team, anywhere from 5 - 30 people depending on the cycle, mostly based out of Vancouver, BC, Canada. I'm remote, in Seattle, WA, US. We've been working on this iteration in earnest for about a year now, though the founders of the company started with a prototype they shopped around PAX East, GenCon, and IDC a few years ago. Many of us graduated in the same class from a small town--Cranbrook, BC--and went our separate ways for a few years only to come back and make a game based on some work we did in high school with a pen and paper RPG, along with some other extremely talented folks we've met along the way.

The main game play occurs on your PC/Mac
But your mobile device let's you control your character, choose abilities, level up, view lore, and more!
We've built the game in Unity (if my other blog posts around Unity didn't give that away!), which allowed us to get up and running really quickly in terms of not having to build a bunch of engine from scratch. We still have a bit of work ahead of us as well, as we're not quite done. But we're super excited to show things off!

If you have questions, or platforms you'd like to see the game on that aren't announced, or anything of the like, I suggest directing them to our Greenlight page. They'll get the most traction where the whole team is seeing it.

Building an RPG the technical and artistic scale that we've aimed for in about a year is kind of insane, when you think about it. We've done a pretty good job I like to think, and it's not over yet! But at the end of the day we are a (relatively) small team, so we can't promise we'll implement everything folks ask for. But we'll take it into consideration.

If you like what you've seen, or think our game is neat, please vote YES on our Greenlight page. It's the only way for us to get our game on the Steam platform, outside of getting a big publisher. We're indie and have managed to keep it that way to maintain our own vision of what our game should be like, and we can't finish this without the support of others.

We hope to see folks playing Eon Altar soon! #IndieDev, #EonAltar, #Greenlight

Tuesday, May 5, 2015

[IndieDev] Unity3D's Networking - An In-Depth Technical Discussion

It's been a couple of weeks since I wrote a blog post. Turns out shipping a game involves some crunch time. Who knew? In all seriousness, it's been stupid busy. Partly because of some insanity that I wasn't originally privy to and/or did not understand the full implications of until recently. Let's talk about the practicalities of networking in Unity, because not many people do, and I'm honestly not sure what kind of game Unity has built their Networking APIs for. Note: This article assumes some familiarity with how Unity works with respect to scenes, components, and prefabs.

Networking in Unity3D

Here's the basics of how Unity does Networking out of the box. You create a Server, and then once your Clients find you, they can connect. Once connected, Unity does all the things under the covers to keep them connected. So far so awesome. To perform networking calls you need to have NetworkView components in both the server and the clients that have the same NetworkViewID and Type. For example: NetworkViewID 12 and Type Scene.

When making a Remote-Procedure Call (RPC) using a GameObject's NetworkView, the NetworkViewID/Type pair basically tell Unity, "Hey, I'm sending a message to the client. Route it to the object with this ViewID/Type." That's all well and dandy, but how do you get there to begin with?

You've basically two options to get yourself bootstrapped: a scene shared between the client and the server, or Network.Instantiate.

NetworkView component in your scene, with a ViewID already allocated.
The easiest--and possibly the most fragile--method is just using the same scene with objects in the scene that already have NetworkView components. Unity will pre-allocate an ID and mark it as type Scene. Once you've connected to the server, your objects will communicate naturally from there. As you can see in the screenshot above, ViewIDs allocated thusly are marked as Type Scene, and you can see an ID already set aside.

This is fragile because once you ship, if you have clients who are out of date with the server, you might not be able to have them communicate correctly. If IDs don't line up, or don't exist, your communications will fail. But it's super easy to set up.

The other solution is to get bootstrapped with a Network.Instantiate. Network.Instantiate creates an object on whoever calls it and all other machines connected to your game. So if you call it from the server, it'll create the object on the server, and all of the clients. If you call it from a client, it'll create the object on that client as well as the server and other clients. Whoever calls Network.Instantiate is the owner of that object. If that object has a NetworkView on it (or any of it's children), Unity will allocate a NetworkViewID marked as Type Allocated such that they can communicate immediately after instantiation.

This is what you've wrought when you use Network.Instantiate, The same object, on all game instances, capable of communication to any or all other instances.
The issue, however, is that by using Network.Instantiate, you've created a Many-to-Many connection, which is effectively peer-to-peer. It's convenient in terms of not having to think too hard about the networking, up until you start running into some gnarly issues around patterns that Unity pushes you to use.

When calling RPCs, you can say, "Send this message to everyone (including myself)," "Send this message to everyone (not including myself)," or "Send this message to the server only." One thing a lot of folks miss, because it's buried at the bottom of the RPC page, is you can direct them to a specific client by passing the NetworkPlayer struct instead of the RPC.Mode. This allows you to communicate specifically with one client directly rather than being stuck talking to everyone, using the same NetworkView.

That being said, though, Peer-to-peer isn't a very common networking pattern for gaming these days. Authoritative servers that sync state and prevent cheating are generally the norm, though I imagine a game like Spaceteam might actually prefer a peer-to-peer model. But for a game like Eon Altar, we need an authoritative server. Since players are each on their own device, and we have a central server which is controlling (and displaying) the state of the game, players shouldn't need to communicate with each other directly.

Why The Distinction Can Be Important

A side note, this whole conversation was precipitated by something that I noticed around how Unity handles objects and prefabs. Turns out that when you have a prefab loaded up, either by linking it in your scene, or using Resources.Load, it loads everything about that prefab and what that prefab links into memory. Which makes sense in hindsight, but judging by the Internet, we're not the only ones to make that mistake.

The issue we hit was the fact that we used Network.Instantiate on our player objects, since the handsets need information like powers, attributes, health, and so on. However, as mentioned above, Network.Instantiate creates the objects on all connected machines, so we have wasted RAM on loading up stuff about the other players on any given player's handset.

In a 4-player game, our liberal use of Network.Instantiate and RPC.All led to a conceptual model that looks a lot like the pentagram spaghetti above.

Note that it's plausible Unity still routes the changes through the server rather than client to client, but conceptually it's still effectively a direct peer-to-peer connection.
To make matters worse, because our "server" is doing the displaying of visual effects, sound effects, and the player model, and those are linked to the player prefab, we're loading up an immense amount of extraneous data. The handsets don't need the sound or visual effects, or the player model at all! This ended up chewing a good 90 - 120 MBs of RAM for no easily discernible reason on our handsets, which when you want to run on a 512 MB RAM iPhone isn't exactly desirable.

Possible Solutions

A solution to the previous issue might've been to create a separate network object for Server<->Player connections, but Unity isn't really built around that. Rather, Unity really likes you to perform your network operations on the objects doing the work. That's not to say it's impossible, but Unity's natural patterns discourage that line of thinking. Fighting your platform isn't generally a good idea if you can avoid it.

Another solution would be to have entirely different objects hooked up with the same NetworkViewID so they can talk to each other. This would require us to abandon using Network.Instantiate, and ensure that we made special code to handle that case.

The solution we're going with is a variation on the previous: abandon Network.Instantiate for the player objects, and basically make our own Network.InstantiateOnSpecificClient code. This allows us to use the same player objects we were before, but reduces the memory required as we're not loading up everyone's player object on every device. It also prevents us from accidentally sending commands to other clients when we really shouldn't be by conceptually enforcing Authoritative server model. Ideally it should also just reduce networking overhead in general because we'd always be sending to specific clients rather than everybody.

Conceptually more sane, and actually mimics an actual Authoritative server model. Also not loading prefabs on every single client is nice.
This of course required us to build our own Network.Instantiate replacement. And it turns out that Unity does a lot of work for you in Network.Instantiate. Without it, you need to make sure you have some object with RPC capability already set up (either via a shared scene, or via Network.Instantiate), then you make a method that:
  • Instantiates your prefab locally
  • Sets your instance's position/rotation
  • Allocates a Network View ID and assign it and a group to your NetworkView
  • Figures out your unique identifier for your prefab (we used the Resource path)
  • Make a RPC call to the client in question which:
    • Loads the prefab from Resources using the unique identifier
    • Instantiates an instance of said prefab locally
    • Sets the instance's position/rotation
    • Assigns the allocated NetworkViewID/Group from the server
Once you have that, you have the ability to Network.InstantiateOnSpecificClient, effectively. In theory they could be the same object, or you could use it to hook up two different objects (something I've done when the server and client need substantially different functionality that it didn't make sense to put it in the same class). 

Note that if you have nested objects with NetworkView components, you'll need to manually allocate those, too. Also note that you'll need to ensure all your RPC communication goes to a specific client (or RPCMode.Server), or Unity will give you errors on the other clients that no NetworkViewID of number blah exists.

You'll likely want to parent that object to something, which requires you to write some RPC code to set the parent. Here's a hint: you can find objects in your scene by NetworkViewID calling NetworkView.Find. If you know the NetworkViewID of the parent and the child, the rest of the exercise should be trivial.


I haven't even touched on buffered RPC calls, or the state synchronization convenience fields on the NetworkView component. But overall, I've found that Unity's convenience methods induce creating bad architecture. When building a network architecture, I highly suggest ensuring that you think about the model you want to follow and ensure the platform you're building on can support that model out of the box. If not, you might have some extra code you need to write. #IndieDev, #EonAltar, #Unity

Monday, April 13, 2015

[WoW] Speculation Station - The Legendary Ring Proc

[Update: This is the old version, not the new one the devs released via Twitter]

So the 6.2 PTR dropped and with it came a plethora of goodies. One of which was the datamined versions of the Legendary Ring. As with all things datamined, take with horse-sized grain of salt. It's fun to speculate, though.

The rings come with extremely interesting procs, ones which at first blush I thought were screwing over small groups. But after more though, I think they're interesting and don't necessarily completely hose smaller groups.

The DPS Rings
The DPS rings (and healer ring) have a fascinating Equip effect:
The Arcane powers of the ring empowers one <Strength|Agility|Intellect|Spirit> Band wearer in your group, transferring to a new wearer every 12 sec. When empowered, you gain 10% increase <Stuff> per <Strength|Agility|Intellect|Spirit> Band in your group.
So, questions already:
  • Does this have 100% uptime? By the text it doesn't seem like a proc, just an effect that bounces forever.
  • Will it cycle through all members once and restart at random? Or does it only not repeat back-to-back bounces (ie: can't bounce to yourself)?
  • If it has 100% uptime, can it bounce to yourself if nobody else is around (ie: you have a constant 12 second buff)?
  • If it isn't 100% uptime, how is the proc determined?
  • It mentions <Strength|Agility|Intellect|Spirit> Band. Does that mean people wearing the non-Legendary versions of this get the effect still, meaning you only need 1 ring of each type in your raid? Or does it really mean Legendary only?
  • Text says "Group". For raids, is it raid-wide, or really only your group?
Another interesting piece of the puzzle is the buff goes up the more rings you have in your group. At first blush this sounds like it's hosing small raids. I mean, 3 Strength Band users, 30% buff. 6 Strength Band users, 60% buff. But since the buff jumps to a new person every 12 seconds and only 1 such buff exists across the group, it's in effect a 10% buff to your total DPS (assuming no repeats).

1 Player = 10% buff for 12 seconds.
2 Players = 20% buff for 12 seconds each, so +20% for 12s, +0% for 12s. 10% overall.
3 Players = 30% buff for 12 seconds each, so +30% for 12s, +0% for 24s. 10% overall.
8 Players = 80% buff for 12 seconds each, so +80% for 12s, +0% for 84s. 10% overall.

The trick, however, is that the bigger your 12 second buff, the more you can game it with cooldowns. But if you're not the first person picked for the buff, do you wait? The longer you wait, the less often you use your cooldowns. If you only have a couple people in the raid, you might as well wait. 12 seconds isn't that long a time. Heroism/Bloodlust will still be up. You might want that last 20 seconds of lust to line up though, so if you don't get it second, it might be better to damn the torpedoes and blow everything. But if you're the first or second player to get an 80% buff? Daaaaamn, your numbers are gonna look good.

The overlap with Heroism/Bloodlust might be sufficient to edge this proc in the favour of larger groups still, as you only have a limited Window, and the 10% overall estimate is dependent on a long period of time. Buffs in general tend to have a multiplicative effect; hence why it's so lucrative to blow them all at once in-line with Heroism, barring burst phase requirements.

However, this is going to screw up parsers so badly that comparisons across the tier is going to be difficult if/once these start proliferating. Which might be an added benefit to Blizzard. If parses are hosed, then people can't really complain, because they just don't know.

Of course, initial PTR and all that jazz. Is this the final form of the ring? Almost definitely not. As Watcher says, avoid reading too much into it. But it's fun to speculate. It'll be interesting to see how this evolves! #WoW, #Theorycraft, #Legendary