Wednesday, February 10, 2016

[IndieDev] Amsterdam Bound! Awards and Conventions

Flying Helmet Games, myself included, have been pretty head's down the past few weeks trying to finish up our big Combat Update for Eon Altar, which should be coming very Soon™. I've personally also been working on a feature that should help bring our game up to more modern standards for RPGs, but that won't be until the patch after next.



But in the meantime, a couple of us will be going to Casual Connect in Amsterdam for the Developer Showcase, where I'll get to man our booth along with our Creative Director. One of the benefits to being a tiny company. I've never been to Amsterdam, either, so I'm really excited to see it. Networking opportunities abound, as well, so I suppose I'll have to get over my social awkwardness for a week.

But on that note I'll be gone for nearly two weeks, so my blog updates are still going to be sporadic at best.


Awards and Nominations


Something To Behold - Most Unique Gameplay
The reason for going to Casual Connect Europe is that Eon Altar has been nominated for the Indie Prize, which judging by the other entries nominated is in fantastic company. I don't know if we'll win, given how many participants there are, but I think we have something unique to offer, and judging from other awards we've received so far, I'm not the only one to think so.

The Big Indie Pitch Trophy

Recently we showed at Montreal's Big Indie Pitch, and came in 3rd place for it. Curse Gaming gave us an award (with a physical trophy!) after PAX Prime 2015 for, "Something to Behold--Most Unique Gameplay." We're one of Pixelkin's Editor Picks for PAX Prime 2015 as well. Holy Grail From Hell put us on their "PCs Finest Games of 2015" list under the Unfinished/Early Access category. Ookpixels thought our story was interesting enough to write a massive article on the origins of Flying Helmet Games.


Pixelkin Editor's Pick Logo we have on our Steam page
Here's hoping the Indie Prize judges also think we have something awesome to offer, but either way it's a fantastic honour and opportunity to go to Amsterdam to participate in the event. We're starting to make (good) waves and I can only hope to continue doing so until our release and beyond.

Onwards and upwards!
#IndieDev, #EonAltar

Monday, February 8, 2016

[IndieDev] I'd Love To Support Your Platform, But I Can't (Yet)

One of the most frustrating things about being a game developer for me, so far, is people unable to play your game. Maybe they don't have good enough specs on their computer, maybe their networking setup doesn't work, or maybe they just don't have devices on the platforms you support.

Eon Altar has a bit of a double whammy on the platform part, because we're limited for both the main game, as well as the controller applications. Right now we're Windows or bust via Steam for the main game (though we're working on OSX when we have spare moments), and for the controller apps, we're on iOS 8.1+ or Android 4.1+ on 512MB+ devices.


Platforms and Market Share

We expected some folks to ask for their platforms, but I'm a tad surprised as to what seems to be the most popular requests. For OSX we had a large number of users at PAX ask us about it--I personally fielded about 5 - 10 OSX requests a day--and I think we've had maybe 3 people total ask about Linux (which given Steam's statistics show a 1% user base for Linux users, not really surprising).

Steam Hardware Survey, January 2016
But on the mobile device side, we're had a surprising number of users asking for Windows Phone (or to a lesser extent, Windows Tablets). More users asking than OSX and Linux combined easily. Given Windows Phone only has a 1.7% market share vs. iOS at 13.1% and Android at 84.7%, I'm shocked by how many people outside of Microsoft's bubble owns these devices. Although if you look at country-specific data, you can see Windows Phone market share is largely driven by a few European countries, where Windows Phone share actually rivals or even beats out iOS in some cases.


Zug Zug

However, market share is a bit of a moot point for us on the controller app side. We're a Unity 4.x shop, and Unity 4.x doesn't support networking on Windows Store apps. While Unity 5.x's networking stack does support Windows Store apps, converting Eon Altar to use the new networking stack is non-trivial work, which is programmer speak for it will take a really long time. Probably on the order of weeks, if not months, to get correct, let alone all the other things that will break when we upconvert the project.

As the only programmer on the job currently, that would mean cutting features, like checkpoint saves. If I had to choose between checkpoint saves and another platform--oh wait, I do have to choose, that's my job!--I'd pick checkpoint saves, as that affects all of our current and future users in a supremely positive, non-trivial way. Also, we've had more requests for checkpoint saves than for Windows Phone.

There's also a question of, well, couldn't you just port the controller app to a ye olde Win32 (or OSX, or Linux) application? Push a button and go? The short answer is no, not really. The longer answer is it still involves work to ensure that resolutions work out, how do we ship the controller, is hardware support there, how does it play with a mouse instead of a touchscreen if the device has no touch screen--as well as a lot more testing. Which still means cutting features to get out the door.


Never Say Never

That's not to say we'll never support these other platforms. There are clear paths to doing so in all cases, it's just a matter of time is money, both of which are in extremely finite supply currently. Supporting more platforms so more people can play our game is definitely on my wish list, but right now we need to focus on getting the game out on the platforms we currently support, and if the game takes off sufficiently, we can revisit the platform discussion.
#IndieDev, #EonAltar, #Programming

Wednesday, January 13, 2016

[FFRK] Ultimate Rubicante: A Puzzle Cloaked in Fire

I'm still playing FFRK, and it's been a lot of fun, despite some of the wonky balance issues that pretty much necessitate the use of S/L tricks to reset the fight. As the game moves forward, you have power creep as you are wont to have in a mobile game, but the developers have started putting in extremely difficult fights that are FFRK at its best: a puzzle game with an execution phase.

There have been 3 of these "Ultimate" fights so far: Exdeath (FFV), Yunalesca (FFX), and Rubicante (FFIV).

Exdeath was a bit of a wake-up call for a lot of players. The ability to spam AoE magics, AoE physical attacks, and Dispel the entire party as a counter attack meant that while the standard Retaliate/Reflect strats were pretty well required, you also really needed a lot of mitigation. Stacking Shellga, Full Break, and Magic Breakdown reduced damage to tolerable levels (though it still required a lot of AoE healing). The fun part was that while he got twice the actions per round once he hit 50% health, because most of them turned into single-target mega-spells, suddenly you could just Carbuncle to reflect-all. The latter half of the fight was easier than the beginning of the fight.

Yunalesca was crazy easy, especially compared to her FFX counterpart which was probably one of the harder fights in the game. Retaliate was the name of the game here, and you'd pretty well rip through her in no time. Because of her Stage 3 Osmose spam pretty well reducing you to no ability uses left, Retaliate allowed your party to dish out impressive damage still.

Rubicante Ultimate, though, oh man, this required some impressive thinking to try and fight the mitigation required onto your team, deal with his gimmick, and still dish out enough damage to win, but quickly enough to keep taken damage low and kill him before your mitigation ran out. This fight really stressed having access to specific abilities that could only come from pulling certain gear.

The FFRK community on Reddit has determined there are 3 types of Soul Breaks (SBs)--super special attacks characters can learn from equipping gear, and can only be cast when your soul break bar has enough energy gained from taking damage/using actions--that are pretty much essential. Named the Holy Trinity of SBs, they are Wall, Medica, and Hastega (or Boostega).


The FFRK Holy Trinity

Wall is only on two characters currently: Tyro, and Y'shtola. And both of them require a very specific relic to learn said wall. But the effect is to raise the Defense and Resistance of all allies by 200% (!!!) for 25 seconds. This stacks on top of Shell/Protect, which both raise Resistance and Defense by 100%, so combined you're looking at a damage reduction of nearly 88% (since they stack multiplicatively), which makes this incredibly powerful.

Medica is basically any AoE heal (as they are only available via Soul Break). There are currently 19 Medicas in the game, of varying effectiveness. I have Y'shtola's and Vanille's, which are two of the most powerful ones available. On top of that, many Medicas have secondary effects. Vanille's also casts Protect as well as healing. Y'shtola's has an Esuna effect, both quite useful. I also have a "Shared" Soul Break from the armor "Mystery Veil" that cannot be learned, but a character can access while they have the item equipped, which has helped in a pinch as well.

Hastega/Boostega is generally a two-buff AoE Soul Break, generally one of which is Haste. You cannot get AoE Haste outside of these Soul Breaks, which is why it's so powerful. Currently there are only 3 Hastega Soul Breaks: one for Red XIII (Lunatic High, Protect/Haste); one for Sazh (Boon, Shell/Haste); and Eiko (Emerald Light, Medica/Haste). All three are incredibly useful, especially when you need to bring both Shellga and Protectga to a fight, saving you an ability slot.


Mitigation While Missing The Trinity

I'm a Day 1 player of FFRK, which means I have an impressive amount of gear and abilities. A really impressive amount. Yeah, I've spent probably about $100 on the game, but I've also played for 9 months, which works out to less than what I'm paying for WoW, so I'm okay with this. But even still, I'm missing Wall and Hastega from the Trinity. As mentioned, I have three Medicas (Y'shtola, Vanille, Mystery Veil), though only two of them are really fantastic.

Unmitigated on a character with ~250 Resistance, Rubicante dishes out ~5400 damage single target to a character. Most of my characters have 4000 health of so. Rubicante resists Breaks, so Magic Breakdown will "only" reduce that by about 41%, bringing each shot down to ~3,175 damage.

Shellga increases Resistance by 100%, so stacking those two brings him down to ~1,774 damage a shot, which is still not enough. He'd roast me well before I could heal my party. Even with two Medicas that heal the entire party for ~1,800, I can't spam them every round, so we need to reduce damage further.

So either I had to find a way to fit Full Break on my team, or I suck it up and use my "Wandering Record Warrior", AKA friend power, for 2 uses of Wall. This would mean that with Shellga, Wall, and Magic Breakdown, said attack would only do ~991 damage, well within healable range.

For funsies, Celes' default Soul Break, Magic Shield also boosts the party's Resistance by 50%, and is stackable, bringing us to a total of ~705 damage with all my possible mitigation up for the largest single target attack he can bring to bear. His AoE attack would only hit the party for ~423 damage.

So we can survive, and I'm pretty much obligated to bring Celes, Y'shtola, and Vanille, and a Wall for a friend, leaving me with 2 other characters to bring, but no Hastega.


Dealing With Mechanics and Dishing Damage

The next step was to fit someone on my team who could use Thief 4 abilties. Rubicante is weak to ice/water damage, but every 3 turns he'll put up his cloak, which makes him absorb those elements instead, and counter pretty much everything. Basically, when he cloaks, you're going to get wrecked.

However, you can force him to remove the cloak early by "stealing" from him, similar to the mechanic in the original FFIV game. In this case, your options are Steal Defense or Steal Power. Steal Power is the only that ups your own damage, and given most of my attacks are going to be magic since Rubicante counters physical attacks often, Steal Defense makes not much sense.

So now my party was:
Celes (Magic Caster)
Vanille (Magic Caster/Healer/Buffer/Whatever)
Y'shtola (Healer)
Magic Caster
Thief

No Thief can use Full Break and Steal Power, so rather, I decided to use Spellblade for Watera Strike. That meant using Balthier, as he is the only current Thief 4 with Spellblade 3.

Which left us with a Magic Caster to bring. Since I had a fantastic weapon for Rydia, and she would get the Realm bonus, Rydia it was. For Celes I had a FFIV synergy 5* Ice Rod thanks to the earlier FFIV event loot that increased ice damage dealt, so she got all my ice spells, and Rydia got all my Water spells.

I still needed to fit Magic Breakdown, Shellga, a heal, and to deal with the fact I didn't have Hastega, I needed Haste. Y'shtola can use Magic Breakdown, so that meant Vanille was going to be my buffer with Shellga and Haste. I finally had a party:


You'll notice that pretty well every character is wearing a Mage robe of sorts, for Resistance. Most characters had 300 Resistance or more rather than the 250 I was using baseline for my calculations, which meant taking a further 39% less damage or so. Add to that Vanille and Y'shtola wearing Fire Resistance accessories, and my mitigation was through the roof.

You'll also notice that my two offensive casters weren't using Devotion or Impetuous Youth for their Record Materia. Those would reduce their Resistance, and frankly, survival was more important than DPS in this case, especially since I could capitalize on elemental weaknesses.


The Battle

Combat with Rubicante himself still required a few S/L's. Interestingly, his first attack is always Blaze, which does 25% of the party's HP in damage, unmitigatable. This allows you a round to set up defenses, and solves to an extent the problems I had with other fights being RNG heavy and taking a blast to the face off the bat.

However, timing issues and figuring when to use abilities are really what caused me to have to reload a few times. Who to Haste first, in what order for maximum survivability. The timing of Steal Power got me a few times, too. Rubicante is fast. Even with Haste, if I hadn't started an action by the time his second attack got off, I usually waited until I could Steal power for his third to uncloak him. Also, Water spells have a faster cast time for some reason than other spells, so that timing threw me a couple times too.

Sentinel's Grimoire, my Wall, I had to hold off from using for the first 25% of the battle or so. I couldn't kill him fast enough to keep the buff for the entire battle, and he does less damage in the first 50% of his health than he does in the last 50% (Triple Firaga can go sit on a tack, thank you).

But eventually:


Woohoo! Nailed him! It was a hard fight, and when you think mobile games you don't necessarily think of the strategy required to beat an enemy of this difficulty. These Ultimate fights are really where FFRK shines in my eyes: when both the meta setup and the actual fight execution itself are a puzzle.

Despite having to go through 262,029 health to kill him, I had just enough ability uses to make it through. I had just run out of Steal Power, I was down to 1 heal left, no Soul Break power left in the tank for my two Medica users, both casters had maybe 3 or 4 casts left, and Balthier has 1 use of Watera Strike remaining when Rubicante went down. Talk about balanced on a knife's edge!

All in all, I've really been enjoying these fights. Well done, DeNA!
#FFRK, #Theorycraft

Monday, January 11, 2016

[IndieDev] Balancing Access vs. Experience; Where Should a Game Dev Draw the Line?

I think I've finally hit upon a subjective enough issue that I'm really not sure what the right solution is. The problem in a nutshell:
Player wants to play Eon Altar, a game where their phone connects to their PC. However, they're at University, or they otherwise don't control the router/network they're connected to, and the PC/phone can't see each other, and therefore they cannot currently play.
The game heavily relies on the network being really fast (low latency), and going through the Internet could possibly make the experience extremely poor. So we--the developers--when designing the game, decided that it should only work over local area network (LAN), which clearly prevents our player from playing.
So here's the catch: do we create a solution where they can directly type in an IP Address on their phone to connect to the PC, at the risk that we have way less control over the experience, and the latency might make the game unplayable (and result in an unhappy player, and thus bad reviews/word-of-mouth); or do we just leave it be and tell the user, "Sorry, no dice?" (and result in an unhappy player, and thus bad reviews/word-of-mouth).

We know how the experience will degrade: we saw this at PAX Prime, with 60,000+ techno-savvy geeks all on our mobile/wifi devices. Despite having our own routers, the radio interference made the game frustrating. Your movement marker wouldn't react cleanly or smoothly and dialogue responses would sometimes hang briefly. Pressing and holding for free-running was frustrating because it would take 200ms - 500ms for your character to start running, and stopping also took that long, so you'd overshoot, constantly. It all made the game feel really unresponsive--because, well, in the context of a extremely high latency network, it really was unresponsive.

There are in-between options here. We could bury the Connect Directly to IP Address under a help menu as a last resort kind of thing, with big warning signs on it saying the game wasn't really designed for over-Internet play, but is that really helpful? Are we still going to get slagged, even with a warning message?

There's also a maintenance cost and a support cost. If the Direct to IP doesn't work for whatever reason, we (and by 'we' I mean 'I' as I'm the technical guy) will have another thing to possibly have to troubleshoot remotely via forum/email, but on the other hand, it is a workaround tool we could have built into the game. However, it means that I likely won't be able to fix some other unknown subset of bugs/features because I'll be spending my time implementing this feature.

But having players who can't play the game is frustrating on our end, too. We want people to play Eon Altar, and anything that gets in the way of that--short of not having a capable mobile device, sorry, but that's required as part of the vision of our product--should be fixed with prejudice if possible.

So, do we, or don't we? #IndieDev, #EonAltar

Thursday, January 7, 2016

[IndieDev] The Omniscient Programmer

We've been in Early Access for Eon Altar for a good 4.5 months now, and as we get closer to releasing, it hasn't been an easy transition ramping down. I've been the Lead Programmer since April 2015, and recently I've been the only professional programmer on the team. Even when we had a team of 3 programmers, it necessitated a very generalist approach as we just haven't had the number of staff to allow for deep specialization. It's helped that some of our non-programmers know some programming (our lead designer and our animator specifically), but they've not been entirely self-sufficient in that arena--and nor would I expect them to be any more than I'd be expected to be self-sufficient building an animation.

However, today, as the primary technical person, I am expected to know, well, everything technical.

It's a crazy challenge, but an awesome one as well, especially on a game as relatively complex as Eon Altar is. Compare that to my time at Microsoft where I could afford to go really deep on a single problem at a time, like designing and implementing a replacement for an old, inefficient proprietary database; or syncing two file sync engines to the same cloud endpoint. Granted, those are both incredibly complex and nuanced areas, but I had months, even years, to really get everything correct. Eon Altar, our timeline, feature set, and low staff numbers didn't allow for that amount of depth or complexity.

With almost no one aside from the Internet to fall back on at this point excepting a few very specific cases, I need to understand the entire codebase, and be able to make changes within it with confidence.


Being a Programmer

At the lowest layer, this coincides with the sort of things most professional programmers should know at some level: coding and debugging, memory management, algorithmic complexity, language features (C++ vs. C# vs. Javascript, for example), performance profiling, optimization (space and/or time), multi-threading, networking, testing. If one were to compare programming to another job, like a civil engineer, this would basically be "how to build a basic building with infrastructure that won't fall down under the stresses of the natural world".

Nothing too special, though having extra knowledge of how code looks and performs when it's compiled; how different hardware such as graphics cards, processors, RAM, and hard disks changes performance characteristics; how the operating system you're working in handles memory and disk writes; how your garbage collector works if you have one; and so on can help make your code even better--and part of why coding for consoles which largely have set hardware capabilities is actually pretty appealing.


Being a Unity3D Game Programmer

To be a game programmer specifically, and being the only programmer, it means I must understand how every aspect of games works, including rendering, sound, physics, time, animation, AI, pathfinding, cameras, and runtime asset management, just to name a few major systems. We can't have one programmer working on rendering and animation and a different programmer working on AI and pathfinding.

That's where a system like Unity3D or Unreal Engine both come into play, because all of those things are written for you. But you're still building on top of the tools provided, which means you still need to understand how they work, and fairly intimately in many cases--especially when someone decides that the built-in pathfinding tech just isn't good enough.

Some basic camera math using characters on-screen and the camera frustum to calculate the distance the camera needs to be to include all characters on the screen.
An example here would be Unity3D gives us basic camera tech. We don't need to write the code that tells Unity3D how to render a screen based on a camera and a bunch of polygons and textures that the camera can see. But I do need to understand how that works to be able to debug rendering issues, or build a camera controller system, or use cameras to create projectors.

Using our civil engineer example from before, this might be analogous to, "How to build a skyscraper specifically, and all the extra aspects that go into it," like ensuring it doesn't collapse under its own weight, can handle winds at high altitudes, and keeping upper floors cool because heat rises.


Being an Eon Altar Programmer

Then for Eon Altar specific features, I need to understand the level design tools we've created or imported from the asset store and how they interact with everything else, like state machine scripts which control many in-game sequences; character data; dialogue; level loading; UI; Controller-Central Game networking; layered music system; saving and loading games; logging and collecting crash data; analytics; game versioning; combat/action systems; tutorials; lore; camera cage to keep players on screen; combat and power AI; platform-specific features; and I'm probably missing a few other systems.

And then a lot of those systems interact with each other. Save games requires knowledge of player and level state, as does reconnecting controller devices. Game versioning is important to do robustly so we can prevent bad builds or old builds of the game and controllers from connecting to each other. Combat and power AI hooks into character data and the combat/action systems. Camera cage and camera controller both know about player movement and can guide/control it at occasions. Level design tools can inform pretty much everything on the list.

Interestingly enough, being the programmer makes some of that easier to an extent. Despite not writing the original version of some of those features--I didn't write the dialogue system or UI, or the underpinning of the combat/actions, or the sound systems, and while I've had a strong hand in many other systems, I wasn't always the lone programmer on them--because I have intimate knowledge now due to iterations and bug-fixing, writing other features such as save games and reconnect actually went pretty smoothly as I already have all the details I need to know. In a bigger team, I'd have to rely on others understanding what I want to do and getting their feedback on how to integrate with their features.

I'm stretching the civil engineer analogy pretty hard at this point, but this might be analogous to, "How to design extra specialized infrastructure systems within the skyscraper." Maybe I should've picked a different job to use as an example...


Being the Technical Person

Of course, it doesn't end with that. I am the technology gatekeeper, which means I'm also in charge of creating, developing, and maintaining the technological infrastructure surrounding the game, including automating build systems for all platforms; unit testing; patch scheduling; deploying to Steam, iOS, and Google Play; debugging Windows, OSX, iOS, and Android; keeping abreast of changes to the Unity3D platform and keeping it up to date; code repository management, including creating release branches, development branches, and bailing out coworkers who get in trouble with it; differentiating asset management for the exe based on platform (as both our Controller and Central game use the same codebase/project); and of course, technical support for our customers.

Technical support so far involves a lot of debugging customer networks from afar. Are all their devices actually on the same network? Can their iPhone or Droid even see their PC in any app, not just ours? Is something like a firewall eating UDP packets? Why are Zenfone 2s specifically freezing?

We've had a few other bugs that our logging has helped us nail, along with good descriptions from the folks in the forums as well. Add to that automated crash/unhandled exception logging for iOS, Android, and PC (and I had to write something cloud-side for the PC from scratch, which was an interesting exercise), and a lot of what I do today is trying to suss out wtf went wrong at any given moment.

For our civil engineer, this might be equivalent to organizing delivery of materials and workers, scheduling when parts of the building would go up, orchestrating repairs, and answering the phone when someone's toilet got clogged.


Bigger Teams Than Ours

If you were to look at a bigger team, like at EA, the build engineering and deployment would generally be another department entirely, and you'd have specialists on your team for handling platform specifics, or at least mobile vs. desktop. Tech support would still be done by those who owned the breaking features.

You'd probably have different programmers for game logic versus designer tools versus your engine programmers, who'd be handling rendering/sound/asset management/networking, and often would specialize in one or two of those sub-areas. And the more programmers you can afford, the more complex those features could be. A lot of our features are pretty simple, because we literally did not have the manpower to ship anything more complex.

While programmers make up a small portion of most teams (content creators generally being the lion's share), you're still looking at anywhere from 6 - 18 programmers for a major game like an RPG, and usually for many years. Mass Effect, a triple-A RPG, had about 45 in-house programmers over the course of it's development according to the credits. Probably not all at the same time, mind, and Mass Effect is certainly far more complex than Eon Altar (especially since we didn't have to create the engine from scratch), but that gives an idea of team size. Tales of Zestiria seemed to have 10 in-house programmers, and 10 from a contracted studio based on their credit scene. Heck, Super Mario RPG had 5 programmers.

Which all is to say we definitely would never have been able to make Eon Altar without an engine like Unity3D, but even with an engine like Frostbite, Dragon Age: Inquisition still has well over 60 programmers listed in their credits.


Holy Moly So Much Stuff

So how does one keep all this stuff in their head? Well, to be fair, you kinda don't. I hinted at it earlier, but the Internet is a great resource to allow you to make it once you've faked it to a degree. You really do need your fundamentals down pat and largely internalized, but once you start getting into systems such as physics, you kinda just need to understand vaguely how it likes to store information, and how it works on a frame-to-frame basis, and you can usually either puzzle the rest out when you need it, or look up the specifics. Game specific features, thankfully, are documented and/or in code.

A lot of tech support is going, "Oh, crap, why is it broken? Okay, let's try a few general tests to see if it's a problem I understand. Nope? To the Internet!" Build engineering? I knew I had to link a bunch of stuff together, and knew that I could do it in a bash script, so it became a question of, "Let's go learn bash scripting for OSX to tie all this together!" One day I'd like to learn more about Jenkins if I'm going to be doing more automation, as that seems to be the industry goto for that sort of thing based on further research.


My university degree provided me a mathematics background as well as some classes in graphics, physics, and cameras on top of a lot of the "being a programmer" stuff, but Unity3D itself I learned on the job. I've learned a fair bit about software lifecycle management from my time at Microsoft, as well as a lot of other engineering skills that you just don't learn in school. Everything else I've picked up effectively by osmosis, or research when required. And so much research, all the time!

What makes programming so wonderful and terrifying is that every day you're pretty much learning something new: about the tech you're using; about some pattern or technique you've "discovered" or read about; about some security flaw that you now have to patch in your own code; about how to perform some task that you didn't even realize you needed to perform the day before; about some new tech you need to integrate into your product.

The danger in generalizing, of course, is not being able to dive deep enough when a large organization requires more specialized expertise. It also means that it's quite possible for you to know just enough to get yourself into trouble, but not out of it. But so far that hasn't happened to me, knock on wood and all that.

Eon Altar has been a wonderful project to work on, and I've learned so much doing it, both from my fellow programmers when we still had them, and a lot just by going through the motions of building features and debugging issues. We're not done yet, but it's definitely been worthwhile.
#IndieDev, #EonAltar, #Programming

Sunday, January 3, 2016

[Minecraft] Automate All the Things!

It's been a while since I last posted; nearly a month. December was busy, between a trip to Toronto to see family, running tech support for Eon Altar, doing some apartment hunting, and some money hunting, it left me with little drive for much else.

However, January is here and I figured, let's toss something up on the Interwebs!

And what better than a video tour of my Minecraft base? A few folks on Twitter were curious to see, so I made a video of the different contraptions I built--generally using other people's tutorials, but I'm starting to get better at redstone free-hand so hopefully I'll start building things of my own soon!

Farms/contraptions you'll see in the video include: a semi-automatic cocoa bean farm, automatic cactus farm, item sorting system, automatic golem (iron/poppies) farm, automatic sugarcane farm, automatic pumpkin and melon farms, semi-automatic wheat/potato/carrot farm, semi-automatic cow cooker, automatic smelters, and a villager generation/trading hut.

I still have a few more farms to set up long-term: an automatic slime farm, a mob spawner sky-farm for sweet sweet overworld mob drops, and a gold/XP farm in the Nether. If I was really saucy, I could set up an automatic witch hut, but my Villagers provide me with plenty of redstone and glowstone, so there's not much point. But once the other farms are done, I'll be well on my way to having as many materials as I could ever want and I can build, build, build!

Without further ado, the video!



#Minecraft, #Redstone, #Video

Thursday, December 10, 2015

Game Design and Player Behaviour

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

To anybody who studies communications and/or marketing, this fact should come as no surprise. But the more interesting aspect of the discussion was what Celestalon--a technical game designer on WoW--posed to the community at large:
Many of the responses that came out of that boiled down to, "You can't, it's the community's problem." Which is a frustratingly unhelpful answer, and possibly flat out incorrect.

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


Real-Life Examples

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

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

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

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

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


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


Simultaneous Insufficient Info and Info Overload

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

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

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

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


What to do?

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

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

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

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