Thursday, October 1, 2015

[WoW] Revisiting 10 vs 30 Player Raid Difficulty

A while back I wrote a post on why 10-player raids were mathematically more difficult than 30-player raids as they were designed at the time from a DPS perspective. This was written as we were about to move into Blackrock Foundry from Highmaul.

Well, it's nearing the end of Warlords and apparently either the WoW developers read my blog post and agreed with it--which may have been likely, given it got Reddit bombed and makes up like 40% of my total lifetime traffic even today--or came to the same conclusion as I did on their own.

Raid Size Related Hotfixes

Let's take a look at all of the fight nerfs made after each raid was released to account for small group sizes. Note, I am ignoring changes that are basically scaling bug fixes rather than changes in the encounter fabric, but I did consider adding changes where they prevent mechanics from overlapping (ie: bosses putting two effects on the same person). Clearly that would affect a smaller raid disproportionately compared to a large raid, but it still could significantly affect a large raid if they had a string of bad luck, so I opted not to include those.

(6.0.3 Hotfixes)
  • Gruul now uses Petrifying Slam against 5 targets in a 10-player raid, scaling up to 10 targets in a 30-player raid (used to be 8 targets for all raid sizes).
  • Reduced the damage that Gruul’s Inferno Slice deals to 10-player raid groups on Normal and Heroic difficulties, but increased the rate at which damage scales with raid size. Larger raid groups should find the damage relatively unchanged; smaller groups will find that the ability now deals less damage.
(6.2 Hotfixes, More Hotfixes)
  • Adjusted scaling to reduce the amount of health by roughly 10% on Xhul'horac, Omnus, Unstable Voidfiend, and Vanguard Akkelion for a 10-player raid on Normal and Heroic difficulty. Health should remain the same as before for raids with 30 players.
  • Adjusted scaling to reduce the amount of health by roughly 10% on some Hellfire Reinforcements and some Felfire-Imbued Siege Vehicles for a 10-player raid on Heroic difficulty. Health should remain the same as before for raids with 30 players.
    • Hellfire Reinforcements: Contracted Engineer, Gorebound Felcasters, Iron Dragoon, Hulking Berserker
    • Felfire-Imbued Siege Vehicles: Felfire Artillery, Felfire Crusher, Felfire Demolisher, Felfire Flamebelcher
  • Health of adds for [Kilrogg Deadeye] have been reduced by roughly 20% for raid groups with 10 players on Normal and Heroic difficulty. This should help with the difficulty experienced by smaller raid groups losing their DPS when sending players down into the death phase. The health of adds scales back up and should be roughly unchanged from before as raid group size increases.
(6.2.2 Hotfixes)
  • We have made a number of changes aimed at reducing the difficulty of the Archimonde encounter for smaller raid groups on Normal and Heroic difficulty, with a focus on the final phase of the encounter in particular. These changes are offset by increased scaling with respect to raid size, so that the experience for larger raid groups will be mostly unchanged.
    • Infernal Doombringer's health has been reduced by up to 15%.
    • Shadowed Netherwalker's health has been reduced by up to 15%.
    • Living Shadow's health has been reduced by up to 15%.
    • Reduced the damage of Wrought Chaos by up to 20%.
    • Reduced the damage of Shackled Torment by up to 20%.
    • Living Shadows now spawn from each Nether Tear at a reduced rate for smaller raid sizes.
It's interesting to note how many more changes they made to Hellfire Citadel specifically versus Blackrock Foundry, though it's possible they didn't really have the data they needed in BRF to adequately decide that small raid sizes were struggling versus larger. Or the mechanics in BRF just didn't tend to lend themselves to scaling issues.

Most of the fights in BRF didn't involve non-tanks handling adds for the most part, aside from Blackhand or Furnace, and only Oregorger really had an interrupt rotation and it was pretty simple; adding more players wouldn't change the difficulty there.

Iron Maidens Case Study

Iron Maidens suffers the same issue that Kargath suffers except worse: you lose half your raid every boat phase. Because the boat phase always has the same number of players on it, the boat itself shouldn't scale with raid size, meaning that you're losing a disproportionately large part of your raid for the same amount of time if you're a 10-player raid. In fact, if you look at's data, you'll see that Uk'urogg does have 5.45M health on all raid sizes on Normal difficulty, but Admiral Gar'an Normal's health scales up linearly ~5.5M health per player, so you should always send the same number of players to the boat, regardless of your overall raid size.

If you assume 2 boat phases, you're looking at about 45s for one boat phase, and 1m15s for the the other at 50th percentile DPS, give or take a few seconds from either, and in that case about an 8 - 9 minute fight. Meaning 25% of the fight, you're missing literally half your raid, and most of them DPS, which means you're not really putting damage on the bosses aside from the tanks, or 1 DPS and a tank. For ease of calculations, let's pretend you always send 4+1 tank, so about 4.75 DPS out of a total of 5+1.5 DPS (2 Tanks).

For 10 players, you're losing  ~73% of your total DPS for 25% of the time, so a net loss of 18.2%.
For 11, ~63.6% of your total DPS for 25% time, so a net loss of 15.9%.
For 12, ~55.9% for 25% time, so net loss of 14.0%
For 13, ~50.0% for 25% time, so a net loss of 12.5%
For 14, ~45.2% for 25% time, so a net loss of 11.3%
and so on.

Clearly an inverse exponential curve in terms of lost DPS. Case closed, right? Not quite. In a twist, it turns out that while the boss health does increase linearly, Blizzard has it increase somewhat  faster than the amount of DPS you're adding, ostensibly to handle the fact that 10-mans have it harder. Also interesting to see just how hard adding a healer hits due to the linear scaling a little faster. Healer bumps are kind of arbitrary, but don't affect the overall curve.

Iron Maidens Normal. It's backwards!
Hans'gar and Franzok Normal. This is what we usually expect boss health per DPS player curves to look like.
It's not really perfect, because the low end still requires exponentially more DPS to make up the loss, and the compensation is linear, but it's clear that Blizzard thought something needed to be done. The question is, though, was it "good enough"? Probably, though as usual unless we have access to oodles of failure rate data for raid size vs. attempts, I couldn't tell you for sure.


I'm pretty sure this is the part where I get to say I totally called it, if I weren't so modest. ;) 

That being said, Blizzard is clearly now designing their encounters with raid size in mind, or at least nudging them after the fact, so hooray for us smaller raids! Perhaps they should consider adding, "How does this encounter play with 10 players?" to their testing/design review checklist so we don't need to wait a month and a half for hotfixes because they're waiting for data rather than performing in-house analysis.

And let me say for the record that Xhul'horac as a 10-player raid is absolutely Xhul'horrific. Half your raid dealing with surge debuffs every 30 seconds, not enough raiders to have folks reliably set for clearing fire via explosions, not enough people to deal with adds while that's all occurring. It's clear to me at least that Xhul'horac, despite the fact they compensated him health-wise, still sucks the big one mechanically for tiny raid sizes. Even having 1 extra person the next week made the fight immensely easier.

There's still the open question on raid cooldowns. 3 healers for 10 players means fewer tools than a 20-player raid (both in the literal and ideally the figurative sense, but that's my bias against large raid sizes showing). Being able to chain, say, Devotion Aura for twice as long is a pretty big bonus given it perfectly scales with raid size. Perhaps that'll be my next project one day, analyzing healing and damage output to see how that changes over raid size and compare that to tools available.

But in the meantime, I'm glad to see that efforts are being made around smaller raid sizes. WoW is pretty much the only game out with variable raid sizes with razor balance, so it's new territory with new design problems.
#WorldOfWarcraft, #Theorycrafting, #GameDesign

    Friday, September 25, 2015

    [Eon Altar] Bottled Awesome--Reconnecting Mobile Devices to the Game

    One of the things that makes Eon Altar unique is we use mobile devices--phones and tablets--as controllers to the primary game. Of course, this kind of connectivity means that some state needs to be communicated to the mobile devices as you play. But even more concerning is how to get all that data back to the mobile device when it crashes, or you answer a text and iOS kills the app due to memory pressure, or your battery runs out.

    Flying Helmet Games playing a test build on their phones.
    Interestingly enough, we went for a very long time without a robust reconnect feature, which actually spoke pretty highly of the quality of our controller builds, but now that we have one, I definitely regret leaving it as long as we did.

    The First Solution

    The hardest part about reconnecting, of course, is what I hinted to in the first paragraph: ensuring your state on the controller is correct. The easiest way of doing this, without having to think of any special logic is to copy/paste the state from the main game onto the controller over the network. In programmer terms, serialize the state, and deserialize it on the other end. Given our time/budget constraints, we thought this was a pretty good idea.

    However, once we implemented it, it turned out to be terrible in practice. The performance was abysmal, primarily because of how we organize our data on the main game. When we serialized the state, we also ended up picking up character models, animations, textures, and so on. And not just for your character, but for all player characters. We had reconnect times upwards of 8 minutes per controller when playing with 4 players. That was...not so hot.

    We left the problem for a couple months, though, because we had more pressing needs in keeping the designers unblocked (which is another interesting discussion entirely). We'd lived that long without reconnect, what was a few more months?

    Once we got back around to it, it was also clear from a design perspective that what we were doing wasn't going to hack it. Sending all of that data to the controllers was far too much on 512 MB devices. We were also using the same code to save our game to a file, and that was problematic due to the fact that patching the character or level data after the fact was pretty well impossible, not to mention save files bordering on 1GB+ of data.

    The Final Solution

    So serializing the state naively wasn't going to work, which meant that we were going to have to dig in and actually reason about what data we needed to send across (or save to disk!). Turns out it wasn't too bad at all.

    Thanks to Unity's RPC framework guaranteeing delivery and order, it "simply" became a matter of writing a new network model on top of Unity's to decouple how they instantiated objects over a network, and then reinstantiate the player actor we needed on the controller. Since we knew what we started with baseline, it then became an exercise in determining how that state changed from the baseline. What abilities do you have unlocked? Gear and recipes? Treasure? Renown? Current attributes and status effects? Skills? Lore? Are we in the middle of a dialogue?

    It was slightly more complex than that in the end, because we have a bunch of other synchronized tracking variables that had to be transferred as well, but most of our "state" in the previous paragraph are just prefab objects, so the majority of controller reconnect rehydration is telling the controller, "Hey, go instantiate this actor, and then go grab prefabs A, B, and C for lore, and unlock skills 1, 2, and 6. Also, update these synchronized variables." It's simple, and quite robust.

    Unity Project Setup
    What also helps us here is the fact that our Controller app and our main game executable actually share resources and code. Unity is (mostly) smart enough to only pull in assets based on what scenes we include, so in the picture above, when we build the game executable, Unity pulls in a bunch of data to spit out for the build, and if we build the controller app, same deal, unity pulls in the correct data.

    I say mostly because the Resources folder is special in Unity. We had to do some...shenanigans around Resources folders to get this system to work, and it's not quite perfect. but in terms of reconnect, it's great because when reconnecting, as long as the builds are compatible, I can be guaranteed that the correct data will be there on the controller. And if not, oh well. Think of it as the equivalent of updating tooltips in WoW. The backend server data might change, but the tooltips are local client data, and may get out of date. A patch will fix that right up later.

    There are definite cons to this setup as well, like requiring patching the controllers more often, and the Resources folder shenanigans means sometimes extraneous data gets pulled into the controller build. But it's also super fast from a CPU time and networking perspective. We're not serializing tonnes of data to send over the (local) wire, so the reconnect now takes about 1 - 3 seconds rather than 8 minutes. Actually, the grand majority of the reconnect time is actually just loading the controller UI textures, the same as a normal load rather than anything reconnect specific.

    Bottled Awesome

    The best part about the latest version of reconnect? It's ultra solid. Our lead designer told me it was "bottled awesome". Pretty much any controller app bug we get can be worked around by killing the controller app and reconnecting, which has been an immense boon now that we're in Early Access. 

    We haven't seen many bugs come out of it either, which makes me pretty proud of the quality of the feature as a whole, too. The lack of bugs isn't for a lack of testing, either. We use reconnect all the time. I actually really regret not having a robust reconnect completed much earlier in the project. Mind you, part of why it's so robust is probably because it was done in a single 2-week period after most of the game was already complete. It's "easy" to build something like this and get it right in a single go rather than finish something nascent and update it as you add other systems.

    We probably spent a good 5 - 6 weeks at a minimum between two senior engineers to get this feature correct. When we're talking about only having around 36 engineering months across the whole team, eating up 3% of total engineering project time on a single feature is pretty significant. Granted, it could have been a lot more, but when you look at the list of features as a whole, it's a bit scary how much of our schedule this took. We definitely underestimated as a team when we made the schedule.

    Overall, this is a pretty interesting look at how many things are interconnected: reconnect and save rely on the same code; reconnect relies partly on how our builds are generated; reconnect and other systems such as dialogue, skills, powers, and so on rely on each other. Not to mention how the feature affects the technical requirements, such as build size, performance, and RAM usage. A bug in reconnect can cause display bugs on the controller, or bugs where the controller and the game get out of sync which would likely stall the game.

    I'm glad it's done and it works like a charm, and it was a super interesting feature to work on. We've a few more rough edges to iron out around the reconnect experience, but otherwise, it's been great!
    #EonAltar, #GameDevelopment, #IndieDev

    Thursday, September 17, 2015

    [WoW] The Show Must Go On -- Agile Development vs. Content Pipelines vs. Social Media

    Alternative Chat has an interesting blog post where she talks about the tension between what some devs call "open development", and the fact that Blizzard is basically the Titanic as far as steering the product goes.

    For those not in the know, #RaveholdtOrRiot is a hashtag used by the WoW Rogue community who're upset that the Rogue Class Hall was said to be in the sewers of Dalaran. See, Ravenholdt was the defacto Rogue central in Vanilla, and that was reinforced by the legendary daggers quest at the end of Cataclysm largely taking place in and around Ravenholdt itself. When you have Blizzard stating that Paladins are going to get Light's Hope Chapel in the Plaguelands, and Shaman are going to get a cavern system by the Maelstrom, of course Rogues will want something that's tethered in their history as a class, and not in the basement of the floating Mage city.


    Of course, as Alt points out--and Blizzard has confirmed multiple times--Legion has been in development for well over a year now already. Since before Warlords was even released. And despite Blizzard's insistence for folks to wait for the full reveal, as the tweet above indicates, waiting often means it's too late. By the time it's polished and ready for reveal, there's no going back. In fact, it's honestly probably already too late today.

    I hinted at this a year and a half ago with my post Should Monolithic Expansions Be Obsoleted?. There's just way too much pipeline in a giant expansion in a giant game like WoW to switch directions. A timeline might actually look similar to this:
    • 2012 -- Figure out if Warlords or Legion should come next, begin planning Warlords
    • Sep. 2012 -- Mists Released
    • 2012 - 2013 -- Heavy work on Warlords, Begin Planning Legion
    • Nov. 2013 -- Warlords announced
    • 2014 -- Heavy work on Legion, Presumably planning next expac
    • Nov. 2014 -- Warlords released
    • Jul. 2015 -- Legion announced
    The groundwork for Legion started 3 years ago, probably slightly more. Based on my experiences as a game developer and as a software engineer, plus the data they gave us via the linked interview above, the timeline for Legion might look something like:

    High Level Planning (2012)
    • Basic Concept
    • Basic Story/Continent/Raison d'ĂȘtre, Concept Art
    • ~1% of staff

    Mid-Level Planning (2012 - 2013)
    • Zone flow, dungeon concepts, story flow
    • Feature planning (ie: artifact weapons, class halls, PvP talents)
    • Concept art for zones/dungeon/major story scenes
    • Engineers start prototyping features
    • Ramp to ~25% of staff by next phase

    Low-Level Planning, Level Design, Feature Coding (Late 2013 - 2014)
    • Start fleshing out individual zone design, quest hubs
    • Fleshing out dungeon/raid designs
    • Blocking out the above in rough
    • Start coding features and new tech for server/client
    • Artists start turning concept art into in-game assets
    • Ramp to ~50% of staff by next phase

    Full Production (2014 - 2015)
    • Zones get filled (interview linked above states they had 2 zones in production by 2014 Gamescom) with terrain, art assets, quests, quest hubs
    • Features get design iteration with engineers
    • Dungeons get similar treatment to zones
    • Classes get design attention for new abilities/talents, may need engineering help
    • Artists churning out artworks/music/sound effects for design to use/by design request
    • Probably ~75% of staff

    Beta Release (Late 2015)
    • Most zones, class halls, artifact weapons will likely be mostly done, aside from certain design tweaks.
    • Dungeons and raids may be mostly complete, but missing balance passes, or some encounters, loot, etc.
    • Ramping down to ~25% of staff again.
    • Artists and engineers are likely already working near full time on next expansion by this point, if not a bit before, leaving mostly designers (quest, encounter, class, systems)
    I'm probably off a little bit between phases, and likely pretty off with the staff percentages but eh, I'm more interested in magnitudes than actual percentages. Also keep in mind their production phase was probably side-lined by doubling their staff in the 2013 - 2014 era.

    I don't know precisely how Blizzard pipelines their work, but it most definitely is pipelined. Interestingly, graphics cards and CPUs may provide a good analogy to this. The deeper your pipeline, the more work you can parallelize. But if you have to do a context switch? Dumping the entirely of your multiple parallel pipelines sucks hardcore.

    Agile Development and Content-Heavy Games

    So to get more content out faster, Blizzard has probably built a very deep pipeline. They'd have to, really. There's only so much in a single expansion you can parallelize since you'd have designers waiting on engineers, artists waiting on designers, artists waiting on engineers, engineers waiting on designers, and so on. Having a deep pipeline means less downtime due to waiting on others; you're almost always busy, which is good from a financial and throughput perspective. But having a deep pipeline also means you're very much not agile.

    That being said, consumers generally don't care about the why something is not responsive, even if that something is as huge as World of Warcraft. Consumers see an issue (lack of flying, rogue class hall being in the "wrong" place), and they speak up. If Blizzard can't or won't change in response to that--whether it's for practicality of development reasons, or because they want to stick to their guns--then as Alternative Chat suggests, perhaps they shouldn't be interacting with the community on these issues.

    Maybe discretion is the better part of valour here, and despite the fact that they listened to the community and changed their mind on flight--something they allowed themselves to do because they developed Warlords with the possibility of flight in mind in the first place and probably pulled a bunch of QA and designers from Legion to pull it off--a class hall may have a bunch of art assets, quests, level design, and the like already done likely a year or more in advance is not able to be changed without throwing out a bunch of work and starting from near-scratch. It's like Karabor vs. Stormshield in Warlords all over again, really.

    Using my game, Eon Altar, as an example, having to radically redesign one of our stages is probably outside our current capabilities as a studio. Tweaks to improve quest flow, or encounter design, sure. But re-creating an entire chunk of the level? That'd take our current staff an immense amount of time--time that would be taken from other features/levels/encounters. Time we literally cannot afford. And we have maybe at most 1/30th of the raw content WoW throws into an expansion.

    Agile development can be powerful, especially for programming. But for heavy content games, I'm not sure agile is really possible at the content level, at least not for monolithic expansions the way Blizzard does them. For one, you'd think the film and television industry would've figured something out on that by now, and they haven't really in nearly 100 years, and they're a decent analogue to the content portion of game development. For a small team, with a game that's more features than content, like a match-3 game, or Geometry Wars? Yeah, agile works well to change things up really fast. But WoW? Not so much. Even FFXIV's content pipeline is probably pretty deep. It'd have to be to put out patches like clockwork the way they do.

    Social Media

    Blizzard has a choice to make here: try to make agile work for content and keep responding to content-based feedback as if it matters for the present, rather than as data points for future content; or just...stop responding to that kind of feedback, because right now the halfway point they're hitting feels more frustrating than helpful. People think they have the developers' collective ear, and then folks are told to sit tight, and the devs are clearly frustrated with consumers banging on their window since said consumers don't have the full picture yet (which, to be fair, is Blizzard's fault for giving only a piece of the puzzle).

    Something you learn in music theory very quickly is that silence can say as much as any note. Blizzard may need to learn to exercise that when dealing with feedback that cannot be actionable, rather than being defensive. Even if it hurts to see people upset about your work.
    #WoW, #GameDevelopment

    Monday, September 14, 2015

    Party Progression Problems

    Recently I've been playing some Diablo III, and it was a lot of fun for a bit of time. A friend and I played together a fair bit, and running some rifts/bounties was a good time, especially once we figured we could bump up the difficulty a bit. Playing with friends usually makes the game better.

    I had the unhappy event of having to turn a different friend down who wanted to play with me though. See, my first friend and I were about Paragon level 20, and just peeking over the Torment II boundary. This 2nd friend was Paragon level 580, and trounced Torment VI+ with ease. We literally could not keep up with him. He ran by monsters, and they exploded, and his movement boosts put him well out of our reach. The game devolved into us chasing him around and picking up leavings, which frankly wasn't fun, at all.

    I don't blame the 2nd friend at all, and he understood when I asked him to leave that I want to play the game--I'm not interested in power leveling at all. I like to play it on my own terms, which includes friends who are at a similar point in the power curve.

    An approximation of Diablo III's power curve.
    Diablo III suffers from this issue pretty massively because just how fast power goes up, especially once you're at end-game levels. Honestly, if I had just bit the bullet and let myself be power-leveled, I'm sure I could've gotten close enough to 2nd friend's power level in a few hours, but again, that's not fun. That's a chore.

    Interestingly enough, most MMOs suffer from this issue as well. WoW and FFXIV are a couple of the more active games that exhibit this behaviour, but in a sense even a game like Minecraft has this problem. One of my friends joined my Minecraft server, and he's a helper, but I already had everything I ever needed, so him helping was basically useless. He showed up, and we basically had tamed the wilderness, even providing a train stop for his base.

    Possible Solutions?

    WoW solves it to an extent by basically resetting progression every raid tier, let alone every expansion. You get catch-up mechanics (Timeless Isle, Tanaan Jungle, Isle of Thunder, End of Time Cataclysm heroic 5-mans) to bring you to the power level you need to perform in current content.

    This has the problem that it invalidates older content, and has the player base playing only the most recent content with any sort of ardor.

    Another option some MMOs use--Guild Wars 2 and FFXIV come to mind--is mentoring of sorts. They drop your power level down to the one that's appropriate for lower level content.

    Mentoring works quite well in FFXIV in my experience, though I find losing half my keybinds when I enter a dungeon that's 40 levels below mine really frustrating. Or having to keep Stone I on my keybinds because Stone II might not be available due to the level down system. Guild Wars 2 felt worse in my opinion. Everything you did leveled you down, to the point where it didn't really feel like levels were worth anything. What's the point of having levels at all if you never get to use that power? There are better gating mechanisms than using a number to prevent players from skipping content.

    Or as Diablo III shows, you can just have players start over. Seasons performs this admirably--and as a bonus aside, I really enjoy the new task list they have for Seasons so it's not just you wandering aimlessly. Minecraft and Terraria also have this option, where starting over in a new world is easy, and often fun.

    For a persistent MMO, starting over isn't a great option, because as mentioned above most of the progression in the game is invalidated by the the resets every tier, and the population doesn't exist to support the game at lower tiers of play. And even games that support starting over well, as 2nd Friend showed, you can still easily find a gulf in your powers that is too large to be bridged short of asking the other person to stop playing while you spend hours to catch up.


    Those are three techniques I could think of off-hand to allow parties to play together without ruining the others' experiences because of a gross power disparity. Are there others out there? Or is this a mostly intractable problem with RPG progression mechanics that we'll only mitigate, but never overcome? I don't really believe it's impossible to overcome, and mentoring comes close to a good solution, but with a few kinks--to the point that WoW has started using it with Timewalking dungeons to great effect as well.

    But overall, I wish there was something because it really sucks having to tell your friend, "Sorry, I don't want to play with you."
    #GameDesign, #DiabloIII, #Progression

    Wednesday, September 9, 2015

    [Eon Altar] Post-PAX, Post-Release, and Developer Empathy

    I promise that soon I'll talk about other games (I've been playing some Diablo III and Armello in my spare time), but I did want to touch on how our PAX weekend ended up.

    PAX and Early Access Release

    Four days is a long time to be standing and talking with folks. I haven't done that much hawking my wares at people since I worked retail back in University like a decade ago. While I was extremely excited all weekend, by day 3 I was pretty strung out, as the Aggrochat podcast mentioned. Day 4 I ended up doing an interview on video with some lovely folks, and the only thing I remember from it is that I'm pretty sure I came off as a little manic and under slept. I don't think it's up yet for perusal, though.

    I'm in the upper-left here, demoing our build. This was a relatively quiet period.
    I'll be honest, when my coworkers suggested that we release the game on Early Access Steam just before PAX Prime, I thought they were nuts. We're all at PAX, who's going to be on support if things explode in a bad way? Thankfully, the launch went quite smoothly, excepting a crazy bug I had in my server discovery code. The good news is thanks partly to Fierydemise, I figured it out quite quickly and had a workaround up for folks, and then we patched it on Android immediately. Still waiting for Apple to say 'yes' on the build on iOS though.

    We ended up playing support in the evening when we weren't on the floor, and it worked out pretty well. Being able to say to folks at PAX that "hey, we're on Early Access right now for $5 US," was a pretty decent draw for folks, so I think it was worth it in the end, even if I was more than a bit frazzled from the attention split by the end of the weekend. Add to that the emergency patch for the IP Address issues the Tuesday after PAX.

    Slightly different angle here, getting more of the convention in frame.
    I didn't really get to enjoy much of PAX at all as a con-goer, though. I spent 90% of my time at our booth. I got like 45 minutes to wander the floor and get a quick look at the other indie games (which there were some pretty sweet ones there). I also did a lunch with a bunch of other blogger friends from Twitter, some of who are on the aforementioned Aggrochat podcast. And I ended up taking an evening to myself and hung out with Fierydemise, which was a total blast just talking about various things, from eSports to philosophy to programming.

    Developer Empathy

    If folks follow me on Twitter, or read my blog, you'll know that I'm usually a strong developer advocate. Communication, bugs, game design, etc. I find myself defending devs more often than loud consumers, but now that I'm in the hot seat, I feel I can defend both sides a bit better.

    Eon Altar is basically multi-platform in a way nobody else is. You need to have iOS/Android mobile devices to play the PC game. It's a bit weird, and trying to message that hasn't been easy. We've certainly goofed on the message before.

    So when we started getting forum posts from people angry about our game requirements, I suddenly got why WoW devs often mention that level of passion might be a good thing, somewhat. These are folks who want to play our game, which is great, but are frustrated that they can't because they don't have the prerequisite equipment, which isn't so great. To be fair, one could post a game that requires the Oculus Rift and get the same sort of response, but the mobile/multiple screen thing really does throw folks for a loop. Again, comes back to maybe we're not communicating why we use mobile devices well enough.

    Once I figured out that, it totally changed how I approached people at PAX. I'd very quickly dive in to not only what made our game unique, but why we used multiple screens. I found that turned around the interest factor significantly on the PAX floor, even for folks who don't normally like RPGs or games like D&D.

    Active Development

    We're back to fixing up the game, and incorporating some feedback we got from PAX itself, as well as folks who've written about or played the game already in Open Access. The feedback has been absolutely fantastic. Some things we need to improve, and a few places where we've nailed the experience. The next month promises to be busy, but I can say that manning the booth at PAX, and doing Early Access on Steam? Both immensely worth it already. #EonAltar, #PAXPrime, #EarlyAccess

    Friday, August 28, 2015

    [Eon Altar] We're Live! Early Access and PAX Prime

    Last post I promised I'd let folks know when we were live, and well, we're live! You can check out Eon Altar on Steam Early Access here:

    You can grab the controller apps on iOS and Google Play. Just make sure your mobile devices are on the same network as your PC for Steam, and you should be off to the races!

    Booth Under Construction
    Our booth has been super busy, and we're loving showing off our game! I admit, our game is a bit hard to describe sometimes. But when people have gotten their hands on the game and played through it a bit, you can see their faces light up as the whole thing just clicks. It's been an absolutely amazing experience watching folks play and have fun with it.

     I think this Steam review actually says it really well:
    The shining point here is how much the game feels like a computer aided D&d session. The second screens also pop up with secret quests, individual responses and reactions just for that character. Just like a GM passed you a private note. Player dialogue is not voiced, but pops up ONLY on your screen and you are expected to say it in your best full-on Renn Fair voice. This is totally stupid and totally awesome, especially when the dialogue goes all high fantasy cliche.
    Watching players actually perform voices was fantastic. Totally not required, not everybody was that into it, but watching some folks really get into it was deeply satisfying. So many laughs and smiles.

    Nicole Tanner of Pixelkin stopped by and played our game for a bit, and had this to say about Eon Altar:
    Since I’ve been playing games for more than 30 years, I’m always delighted when I see a game that’s innovative and truly unique...I really can’t overstate how impressed I was with this game. I encourage everyone to check it out.
    I admit, the rush is almost overwhelming. I'm pretty sure I was running solely on adrenaline by the end of the day, but that kind of fantastic feedback is beyond what I personally expected. Not because I don't believe in our game, I's so hard to be objective when you're so close to it. It's too easy to see even the most minute "warts" and be really hard on yourself as a content creator. That's not to say we don't have work to do--we do, and a fair bit of it--but getting the game out there has been quite affirming so far. Absolutely nothing like working on application software. Nobody got this excited about OneDrive and Office. Well, almost nobody.

    We're on the floor for the rest of PAX still, so if you're around, come by and give the game a try. We're happy to answer questions, let folks give it a whirl, and hear feedback--both the good and what needs improvement. Same with our Early Access build. We want to hear what folks really like, and what needs more work, tweaking, or what just isn't working for you. You can find our primary forums here, but we are taking a gander at the Steam discussions, too.

    We need to get some more photos of folks playing from tomorrow. I'll be at the booth tomorrow and Monday (I'm personally taking Sunday to see a bit of the show and visit some friends), but we're so stoked to be there, and be (somewhat) released!
    #EonAltar, #PAXPrime, #EarlyAccess

    Monday, August 24, 2015

    [Eon Altar] PAX Prime and Steam Early Access, Soon™

    The past couple weeks have been absolutely insane as we've been trying to get stuff "done" and aligned for this week. With our handset builds out the door to Apple and Android, and our Steam build in review, all we can do now is generally wait as we prep our showing at PAX Prime.

    We don't have an absolute date at the moment, and until we know we do have a date, we don't want to make liars out of ourselves, but ideally we'll have something up on Steam for PAX Prime. If we do, and you bring your phone with our (free) handset app already loaded on it to play with us, we'll give you an exclusive pin.

    But even if you don't bring your phone loaded with the handset app, you'll be able to play a bit of our game at PAX itself, as we're on the expo hall floor! I'll be working at PAX Prime for the first time ever, and it's gonna be so much fun. And so tiring and long, no doubt. I personally won't be on the floor every day, I think we have like 8 people and we only really want 4 employees in the booth at maximum at any given time.

    We are choosing to go Early Access to begin with. My personal feelings on Early Access are...complex. I can't say I'm a big fan of purchasing games in Early Access (though I've been known to do it on occasion), but that's mostly because I prefer to play complete products myself. I play enough buggy software for my job, thanks :P But, on the other hand, as a tiny studio we could use the additional gameplay/balance/fun feedback, testing, and so on that Early Access can provide us, and it does give folks the opportunity to get in and let us know what works and what doesn't. Who knows, maybe one of my blog readers will have a massive impact on the final product!

    It also allows us to soft launch, so to speak. With having to coordinate Steam, Android, and iOS, our patching/engineering process is likely going to have a few bugs unto itself, let alone the game. Having to be really careful about how we roll out the handsets and the central game, as well as engineering ways to have compatibility across devices that aren't necessarily up to date is going to be a difficult process. I personally have experience doing this sort of updating thanks to my time at Microsoft Office (because compatibility is king for Enterprise software), but still, I imagine we will end up making at least one mistake. Best to get that figured out before we release for real.

    Still, I cannot believe we're already putting our game out to the world. It is exciting and terrifying simultaneously. Will people like it? Will they hate it? Will we get love letters and hate mail? I really hope to see folks who are going to PAX Prime drop by our booth and give the game a shot. And to just say hi! When I figure out what days I'm on I'll pop a schedule here. But looking forward to it!

    #EonAltar, #PAXPrime, #EarlyAccess