[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

[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

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

Behind every great programmer is a self-conscious person making it all up as they go, desperately hoping not to be found out.

— Justin Searls (@searls) January 7, 2016

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

[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