Hello there.

One thing that we knew we wanted to have in-game eventually was friendly AI combatants. I put off their implementation for a while, as I wanted to tackle other important systems before I got around to doing what I saw as a new class of behaviour. This weekend, while working with Scott, I realized that I’d been thinking of it entirely wrong: friendly NPC combatants are indistinguishable from enemy AIs save for one thing- their targets. A few tweaks to the existing enemy AI and friendlies were in.

NPC targeting behaviour is fairly simple: if an NPC currently has no target or their existing target dies, it will first check for any nearby enemies. What constitutes a nearby enemy, as it happens, is easy to determine based on the way collision detection works. The game world is partitioned into rectangular bins, and entities are placed in bins based on their current position. Any collision detection for an entity needs only be done on their current bin and its closest surrounding neighbours, reducing the number of collision checks for any given collision pass. This partitioning lends itself well to finding nearby objects, as anything in the same or nearby bins as an entity is guaranteed to be close by without needing to do any explicit checks on distance. A NPC searching for a target simply checks its surrounding bins for any live enemy, and chooses one if found for its new target. If this fails, the NPC will then be assigned an enemy from the global enemy collection. If this also fails, it means that there are currently no live enemies on the field, and the NPC will then target the player (without attacking) and move towards it. If following the player, an NPC will periodically check for valid enemies to which they can direct their aggression. Enemies will choose NPC or player targets similarly, but I have yet to decide on specific target preferences, as ideally the majority of enemy attacks will be directed at the player rather than at NPCs.

As it stands now, the targeting works in a first-come first-serve manner. If targets exist close by, target acquisition will simulate a reasonable level of prioritization based on ‘danger’ levels. Once targeting reaches the global stage, cases where a choice of a far target instead of a close target is made can happen, which isn’t really the type of choice a person would usually make. I decided against doing more proximity checks to avoid this in the interest of keeping things efficient: in this type of game enemies are short-lived enough that this tactical ‘mistake’ shouldn’t be too visible. Were this a strategy game, things would be different. I think I will add a tendency to switch to current aggressors, however, to make enemy and NPC AI a little more reactive (if an NPC or enemy is targeted or damaged, they will prefer to switch to targeting an attacker).

Also in the list of recent developments: an audio engine that takes into account position and distance (thanks OpenAL!) and a keyframe style cutscene engine. If anyone wants a more detailed explanation of anything I’ve done on the code side of things, let me know and I’ll make a post about it.

-David

p.s. Every level from now on will be an escort mission where failure to protect every single NPC results in instant failure, and as a bonus NPCs will have no regard for their own safety. You guys love that, right?

Getting Out of the Prototype Phase

Last night was a good night for Dave and I. We spent a little time working together, implementing some new animations, particle effects (woo!) and laying some really important groundwork for making this game more like what we initially envisioned. We got a couple more good playtests thanks to the very friendly folks at Bento Miso, so thanks for giving us the chance to get another playtest in. We’ve been telling people how this is an Arena Shooter RPG, so it’s about time we brought in that second element.

David has been busy overhauling the backend so that we can have a proper guardian leveling system, and although little has changed in the way of what you see on the screen, it’s been a very important first step to getting a proper demo release out to the public. On my end, I’ve been conceptualizing story elements, and trying to get as many characters into the game as possible. 

As we’ve been developing Elegy we’ve been plagued with this nagging concern: How do we bring our current iteration of the game from prototype into the realm of finished product? We’ve received generally positive responses about our game mechanic, but people are still very curious as to how the RPG elements will fit in, and more importantly, how the finished product will play once they get their hands on it. Over the next week or so, Dave and I intend to get a concrete answer to that question. 

We’re ready to move this forward from a playable tech demo to a fleshed out Alpha. Over the next 3 months, David and I intend to move from a mass prototyping phase into creating a public demo. We’re happy with what we’ve managed to get into the game, and now it’s time to pretty it all up, and allow for some serious testers to try it out. 

I’m currently working on fleshing out the leveling system for the game. I’ll share some of our thoughts and ideas to give you a better idea of what we’re aiming for, and how we’re tackling problems that can arise.

Elegy features light RPG elements (so, no, you can’t choose Void-speak as a language proficiency and then chat up all the monsters), with both player characters and enemies gaining new skills and statistics as they improve. Scott and I decided early on that we didn’t want to encourage large amounts of grind, but when you can pick and choose guardians to bring with you into levels, you can end up with guardians that are significantly weaker than your mains (everyone’s played Pokemon, right? We all know how this is). The first way to counter the need for grind was to make stats follow a curve with diminishing returns. For example, the difference in effectiveness between a rating of 10 and 20 in a stat is much larger than the difference between 90 and 100. The actual math behind this is fairly simple- meet the sigmoid functions.  I’m still playing around with exact details, such as the width of the curve and whether or not I might add a second, linear term to the equation to counteract that flat asymptote.

One pitfall facing the use of a stats system with diminishing returns is a homogenizing of characters. Once you get into the upper levels of useful stat increases, everything is going to handle pretty much the same. There are a few strategies to counter this. Firstly, everything has base stats: at level 1, every entity has their own starting statistics that influence their roles and abilities. Secondly, all the guardians have distinct attack styles, so even with the same statistics no two guardians will perform the exact same function on the battlefield. Thirdly, the conditions I mentioned a post or two ago also help to differentiate roles. Finally, (at least for strategies we’ve considered using so far, there are no doubt myriad ways to tackle the issue) just don’t let everything getto those stat values. The easiest way to do this is a hard level cap. The use of a sigmoid function already imposes a soft effective cap, but still allows the aforementioned homogenization.

Now for some words about the stats themselves: HP, Armour, Attack, and Accuracy. It is to my eternal shame that I’ve not chosen an alternative name for HP that begins with an ‘A’. HP is simple: when something gets hurt, they bleed numbers. When all the numbers are knocked out of them, they die. Armour works to counteract this strange arithmetic phenomenon: The more armour you have, the less damage you take. Attack affects the maximum damage something can deal. All attacks have a base damage, and a higher Attack score raises this base damage. Accuracy affects minimum damage and critical hit chance. When an attack connects, the damage dealt before Armour negation is calculated in a range between the minimum damage and maximum damage. The higher the Accuracy score, the closer the minimum damage is to the maximum damage. For an attack deemed a critical hit, the maximum damage of the attack is added to the previously calculated damage.

Returning to leveling, on level up an entity’s stats will increase. This will not be by purely preset values, but will involve a random increase per each stat. On top of this, we’ve toyed around with the idea of allowing the player to choose one stat to increase further per level up, as in the wonderful Mario and Luigi games, allowing for a finer tailoring of guardians.

None of this, of course, is set in stone, and could change at any time as we balance things. Nonetheless, this should give you an idea of where we’re going and how we plan to get there.

-David

Today I finished putting together two new things: the first is a new attack style for a new, hush-hush guardian Scott has put together, and the second is a system for conditions. Attacks can now apply conditions to enemies, making them weaker, slower, more susceptible to damage, or take damage over time through something like poison, amongst other effects. Enemies can also apply these conditions to the player, so avoiding enemy attacks will be even more important. If you favour pure DPS, pick Guardians that are geared to that. If you like finding combinations of Guardians whose attacks apply conditions that complement each other, build your team with that in mind.

- David

So after the initial prototype for the Captain system was done, I looked at a couple of minor issues to improve. One of those issues involved dodging: the new enemies were no longer dodging out of the way of bullets, but instead throwing themselves in front of them. This happens as bullet dodging uses the movement target as a center point and then calculates dodge trajectory on a tangent relative to that center. With the target no longer the player but the boss, the math used to calculate the tangent ends up flipped. So, a quick one line change and the enemies were back in business, keeping out of the way of my attacks.

Turns out, meat shields that do their darndest to not be meat shields aren’t very effective. The cowards were simply leaving their slow, less agile Captain- whom they were presumably sworn to protect- wide open. This wasn’t much fun to fight, and was in fact the opposite of what I wanted with the Captain system. End result: suicidal minions are back in.

- David

Why hello there, it has been a while. The past bits of development have been focused on menus (the bane of my existence), hence the lack of excited, enthusiastic posts on my part, but today we have something cool to talk about!

We’ve just finished prototyping an early game boss enemy tentatively called The Pinwheel. He’s a big, bad dude and wants to kill you. He lumbers around the playing field, shooting out bullets in all directions with reckless abandon. To supplement his lack of finesse in aiming, he’s brought along a complement of minions to help him out. These little guys are running on the new ‘Captain’ system I wrote today, and will follow their leader to the death.

The Captain system allows groups of enemies to be assigned to another enemy as minions, and they will cluster around their leader and protect it with their tiny, fragile bodies. When their leader is killed, they will scatter and focus their attentions on you, the player, albeit with significantly less tactical forethought than they used to protect their captain.

Here’s a screenshot of the boss and Captain system in action. The boss sprite is nowhere near a finished product, but expect another beautiful final product from Mr. Gamble.

-Dave

Thursday Throwdown: The Next Step

Today was a day of nailing down the features we’d like to have in the game, and what we should work on next. As we said at Fan Expo, I would say we are at least a year away from release, and there is still a lot to do before we can confirm that. To say the least, we have a pretty good plan of what needs to get done, when it should be done, and what we hope to accomplish by our next milestone. 

From this point forward we hope to roll out more robust details as features make their way into the game, as we’ve been keeping a lot of you in the dark. Check back next week for more info, and from here on out, Thursday will be the day for new informations! Hopefully we’ll finally have some juicy new details to share by then. 

For now, behold our pixellated TO-DO list! 

-Scott