FFXIV vs. WoW: Content Delivery Comparison

I'm nearly finished the story content in FFXIV, and wow, it's been a long--but extremely entertaining--haul through it. FFXIV has a lot of content. I recently finished the Hildebrand quest line, finished the Shiva line (to the commenter previously who said I'd enjoy the music, good call that!). I still only have a single job at 50, Paladin, so I've been tanking it up through the group content.

Compared to WoW, where I'm literally only logging in once per week for 3 hours for our Blackrock Foundry raid (10/10 N, 4/10 H now, yay!). But I do admit I still really enjoy WoW's raiding content.

One of the things I've heard mentioned numerous times is that Square Enix is putting out content at a much faster clip than Blizzard is. Blizzard has also made mention numerous times they'd like to speed up the delivery of content. There's also a question of quality of content, but in a themepark MMO quantity is still pretty important. So I decided to sit down and make a comparison between the two games.


Types of Content

Both games are very similar from a content type perspective. As mentioned before, they both are heavily curated themepark MMOs, and therefore have a lot of the same features:

• FFXIV's "Light Party" (4-player) dungeons, vs. WoW's (5-player) dungeons
• FFXIV's LFR-style 24-player raids, vs. WoW's LFR 25-player raids
• FFXIV's 8-Player difficult raids, vs. WoW's Mythic 20-player raids
• Both have group-based PvP
• Both have mini-games (WoW's pet battles vs. FFXIV's Triple Triad)
• Both have story quests (Albeit FFXIV's are much more cut-scene and dialogue heavy versus WoW's sit back approach of just tossing a wall of text)
• Both have rare monsters to find and kill out in the wild, including raid-level bosses
• Both have treasure hunting of a sort

Some of the features of the games are unique, however, when compared to the other. Note that yes, other MMOs have a lot of these features; however, that's not what I'm interested in currently setting the stage for this discussion.

• WoW's Normal/Heroic versions of the same raids are unique to WoW excepting one set of FFXIV's Coil of Bahamut, which has a "Savage" version; Also, FFXIV's version of LFR are entirely different raids compared to other raid content
• FFXIV's Guildhests (4-player trinity training scenarios) and Trials (8-player bosses similar to WoW's Malygos where it's literally just the boss) are mostly unique to FFXIV
• FFXIV's FATE system with dynamically appearing content in the world is unique to FFXIV, excepting a brief time during WoW's 5.3 Escalation patch
• WoW's Garrisons are very mobile game-based, vs. FFXIV's player/guild housing which is primarily for looks, but has some functionality like chocobo training/ingredient farming

Clearly that's not all the features, but that encompasses a lot of the (current) primary game content, ignoring gathering/crafting because that is another discussion entirely. These are the things we're going to focus on in terms of determining what content each team is delivering.

I will be comparing FFXIV 2.0 through 2.55, and comparing it to Mists of Pandaria as well as Warlords of Draenor side-by-side. One thing which muddies this is that FFXIV prefers smaller, more frequent content patches, whereas WoW seems to prefer mega-patches. So let's take a look.


Patch Frequency

Below are two timelines, readjusted to the year 1900 because I couldn't find a generic timeline thingy (Flash objects, sorry!), which demonstrate FFXIV's major patch schedule versus WoW's MoP.

Two things are immediately obvious: FFXIV is like freaking clockwork at about 3 - 3.5 months per major patch, preferring smaller patches. WoW attempted this in MoP, and honestly I think it worked rather well. Except that as discussed previously they probably should have spaced out their patches a bit more. They were generally within about 2 months of each other: probably a bit too short, which led to the second observation: WoW's massive gap between content and next expansion. FFXIV clearly didn't suffer this issue.

So from a cadence perspective, ignoring the actual quantity and quality of content, FFXIV's team is amazing at keeping a tight schedule.


Patch Content

So what did each patch bring to the table? One thing to keep in mind is that WoW's expansion releases tend to have a fair bit more to them than FFXIV's 2.0 in terms of end-game, so FFXIV spent a lot of time catching up. But it's still not quite apples to apples, because FFXIV's 2.0 was basically a new MMO launch. I'm not quite sure how much work they had lined up before kicking off 2.0, but as an end-user, I don't really care. All an end-user cares about is, "Themepark MMO, where's my content?"

So it might be a bit strange to ignore the initial releases of both Mists and A Realm Reborn, but I see no other easy way to measure content delivery over time. Heavensward and the 3.0 patch schedule is going to be very interesting to see if the FFXIV team can keep things up.

NOTE: CONTAINS SPOILERS
You can find the details of patches here: http://talarian.blogspot.com/p/wow-vs-ffxiv-patch-note-comparisons.html

If we extremely arbitrarily assign a value of 1 to each boss, and perhaps a value of 0.25 for each difficulty added for a given boss, we can get a pretty good estimate on at least sheer quantity of bosses. But again, not an apples to apples comparison. As I mentioned previously, Blizzard's dungeons tend to be prettier and tell a story via environment extremely well. FFXIV's spaces tend to be utilitarian.

But I much prefer FFXIV's Hard Mode dungeons to WoW's Heroic dungeons. WoW's are just the same thing, but tuned a little higher. FFXIV's are entirely new bosses and mechanics; your starting point is altered and they'll often send you to different areas, so it's not really the same.

Also, whereas WoW uses zone-wide tunes, FFXIV has unique music for each trial, which as discussed before takes cues from the battle itself.

Basically, it's fascinating to see where each company puts its resources in terms of content creation.

Anyways, here's the high-level rollup of MoP versus A Realm Reborn patch cycle:

Mists of Pandaria

• 7 World Bosses
• (7 "Boss Points")
• 12 Bosses w/ 3 Difficulties + 14 Bosses w/ 4 Difficulties + 1 Boss
• (27 + 0.25 * 2 Extra Difficulties * 12 + 0.25 * 3 Extra Difficulties * 14 = 43.5 "Boss Points")
• 9 Scenarios + 6 Heroic Scenarios (Repeats w/ Bonus Objectives)
• 2 Raid Zones
• 2 World Zones, 1 World Sub-Zone, 1 Altered World Zone
• 3 Reputation Grinds, 3 Currency Grinds
• 1 World PvP, 1 Arena, 1 Battleground
• New Feature: Flexible Raids
• New Feature: Proving Grounds
• New Feature: Brawler's Guild (Something like 40 solo fights with unique mechanics)
• New Feature: Pet Battle Stones

A Realm Reborn

• 20 Raid Bosses + 4 Savage (* 0.25) + 12 Trials + 8 Diff. Difficulties
• 36 "Boss Points"
• 15 Dungeons
• 5 Entirely New
• 10 Altered Hard Mode versions
• 5 Raid Zones (Might also be said 2, split up in piecemeal across patches)
• 12 "Boss Rooms" in Trials, each significantly different
• 1 World Zone, 0 World Sub-Zones, 1 Altered World Zone
• 5 Reputation Grinds, 1 Currency Grind
• 1 Arena, 2 Battlegrounds
• New Class/Job: Rogue/Ninja
• Significant Side Quests: Hildebrand, Delivery Moogle
• New Feature: Treasure Hunting
• New Feature: Guild Housing
• New Feature: Aesthetician
• New Feature: Gardening
• New Feature: Challenge Log (Weekly Quests)
• New Feature: Glamours (Transmogrification)
• New Feature: Retainer Ventures (Similar to Follower Garrison Missions)
• New Feature: Sightseeing Log (Similar to GW2's Vistas)
• New Feature: Chocobo Training/Recolouring
• New Feature: Private Rooms in Guild Housing
• New Feature: Hunts (Rare Spawns)
• New Feature: Ceremony of Eternal Bonding (Marriage Ceremony)
• New Feature: Chocobo Racing/Breeding
• New Feature: Triple Triad
• New Feature: Assorted Mini-Games in Gold Saucer

Overall, if you like raid combat, WoW is your winner. WoW has more unique bosses (by 2) and way more difficulties, but FFXIV isn't that far behind. WoW's raid bosses tend to support much larger raids than FFXIV's. The grand majority of FFXIV's are 8-players, excepting the 12 LFR-style Crystal Tower raids which are 24-player. Note I say LFR-style, but the difficulty of those raids are probably closer to WoW's Normal difficulty than LFR.

That being said, my personal preference for bosses is still WoW. Don't get me wrong, I enjoy FFXIV's immensely, but WoW's been in the business for much longer, and they've really got that good raid fight down to an art. WoW just seems to have a much larger repertoire of encounter mechanics to pull from right now. Whether that's a technical issue or a design issue, I'm not sure, but I'd be willing to bet FFXIV will catch up pretty quickly given their pace so far. But FFXIV's music is way better. Also, new music for every trial is pretty sweet.

WoW's world zones, Isle of Thunder and Timeless Isle, were amazing bits of content with an immense number of things to do. Where FFXIV uses FATEs to shore up the whole faffing about from a combat perspective, WoW's zones are fantastic. The interesting thing here is that this is probably informed by their different play models: WoW has alts, whereas FFXIV you just switch classes and start leveling that up, necessitating re-doing earlier content such as low-level dungeons and FATEs. This means that FFXIV gets way more mileage from lower-level content than WoW does, and therefore likely doesn't need to invest as much in max-level world zone content. But I really enjoyed WoW's new zones.

That being said, if you like smaller group content like dungeons, FFXIV is the way to go. Their dungeons are a lot of fun, and there's a lot of them. Mind you, as I've said multiple times, WoW's are prettier, but FFXIV's get the job done decently. Especially later dungeons. Their early dungeons are ugly and dull. Ones built later seem to exhibit a lot more craftsmanship from the designers, which is nice. FFXIV may eventually close that gap.

If you like story, FFXIV is where you want to be. They do major story updates with each patch, which ends up being a couple hours of questing with actual storyline. And not just big bad takes over the world, but with politics, economics, mystery, humour, and so on. FFXIV also has significant side-quests (Hildebrand, Moogle Delivery) which are hilarious, and literally hours more of awesome content. Whereas WoW focuses on grindable and repeatable content, FFXIV seems largely content to hand out very JRPG run-once content. WoW's story in Mists was quite well done--Landfall and Isle of Thunder in particular were quite engaging. It's tapered off since, however, and Warlords' post-100 story is nearly non-existent.

That being said, FFXIV has introduced an astounding number of content features throughout patching. Now, to be fair, it's way easier to add new features to a newer code base. Also, FFXIV has the "benefit" of playing catch up. A lot of their new features exist in other games, and they're just getting them implemented. But holy cow, the amount of content from entirely new features that we'd normally only see with an expansion in WoW is just nuts. Also, the Gold Saucer in general was amazing amounts of extraneous content. And they added an entirely new class during, to boot.


Conclusion

Overall, I think FFXIV has the edge when compared to Mists, and has a massive lead compared to Warlords. 6.2 promises an immense amount of content, though so it should be interesting to see how it holds up. WoW's generally been gameplay first, and after playing FFXIV, I wonder if that single-minded focus is doing it more harm than good at the end of the day.

WoW seems to like dropping mega-patches. 5.4 and 6.2 are ginormous, whereas FFXIV much prefers to space things out. If Blizzard were to do The Binding Coil of Bahamut, we'd have probably seen all 12 bosses at month 6 after release, whereas FFXIV was dropping 1/3rd of the raid every 6 months (every other patch), interspersed with a different raid in the 3 month intervals in-between. Honestly, I'm not sure which I'd prefer in the end with respect to raiding.

With WoW's precipitous subscriber drop, I think we're in an era where folks will be subscribed until they're satisfied, and drop the subscription until the next content that interests them appears. FFXIV may have the advantage here, because folks can't binge on everything and complete it in 2 weeks. It's being fed at 3 - 3.5 month intervals like clockwork. On the other hand, if they complete that in 1 week and then leave for 2 months? I guess they'll still get more subscriber money overall.

Oh, and FFXIV is managing to actually put out an entire new expansion 3 months after their final patch of the current version (and said expansion looks just as meaty as any WoW expansion in terms of content, if not meatier). WoW takes a year or so each time. From that alone, I give huge props to the FFXIV team. If this pace proves to be sustainable, they may just dethrone WoW as the Themepark MMO to beat. #FFXIV, #WoW, #Patches

[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.


Aggro

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

[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.

.@Talarianjs The thing that jumps to mind as answer to that question is Archaeology - that seems it was designed with flying in mind.

— Yoco (@yoco68) May 15, 2015

@Talarianjs Archaeology, Fishing, Sometimes just flying thru the air enjoying the view while waiting on a queue. Increased gathering.

— Manech (@MichaelJPetty) May 15, 2015

@Talarianjs Archaeology. I just want to zone out and dig without having to fight a bunch of stuff along the way.

— Ryan Alexander (@RGAlxndr) May 15, 2015

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?

@Talarianjs People want it because Blizzard took it away :P

— The Year of the Alt (@AlternativeChat) May 15, 2015

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

[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

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".

@DanRyyu @doctordake As an indie dev it's terrifying. I don't have the "luxury" of silence if I want our game to succeed. People suck :(

— Talarian (@Talarianjs) May 7, 2015

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

[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

[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.

Conclusion

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