Progress update: a Solid Foundation

It's been a week since last post. I kinda wanted to put up a first concept build by now...

On the last post, I posted a draft for a small 2-player encounter. The purpose of it was to start laying down the foundation for the boss mechanic system. I find it easier to design technical systems that way:

1. Come up with something(or a bunch of..) that the technical system needs to support(spells, mechanics, etc)
2. Map out in my head what the supporting system needs to be like
3. Start building it and implementing given spells/mechanics using that system
4. As I build, keep asking myself: "If I wanna make a broader/different thing, does my system support it?"

Usually I end up with flexible systems that do fit my whims, and often I thank my past self for making a system broad enough to support something new that I totally didn't foresee when initially designing. I hope, this time it is no different, however, networking surely made things more difficult.

In my previous project, I went hard on YAML files when making the ability system. The flexibility that gave me was incredible. (SillySwords game, in case you wonder.) This time, I decided to use ScriptableObjects, and use them as lego building blocks for encounters. As of right now, in broadest strokes, I have a following system for boss encounters, from bottom to top, each level being a ScriptableObject:

1)  At the base level, there are "projectiles", which are in-game objects spawned by the boss. They are danger zone indicators, they are actual harmful projectiles, they can be pretty much anything. They control which prefab is used, its size, how it moves, how it interacts with other projectiles. As an interaction example, I have a mechanic implemented, where the player baits an ice projectile onto a fiery floor, neutralizing it.

I am considering moving size-related data from projectiles from this SO to the one below, but I am not sure if there is a practical reason to.

2) At the next level is the "MechanicSegment". Probably not the clearest of names, but its purpose is to manage a number of same-type projectiles. Imagine, for example, that the boss places a danger zone under each player - "MechanicSegment" is responsible for handling the logistics. It is not an entire mechanic, because, after placing those danger zones, the mechanic can have more stuff going on - but those will be different projectiles, managed by another MechanicSegment. Each MechanicSegment manages only one projectile type. When a segment is activated, it spawns its own prefab, which spawns and handles projectiles. 

Yeah, this is quite a bit. This dictates what getting "hit" by a projectile entails - "Damage", as you can see in Hit Effects, would deal damage to the player. If it's something you need to get hit by - that field would hold "Defuse" instead. TargetType and TargetSubtype used to work differently, but they were quickly redesigned. "TargetType" defines which sort of a target to request - a player, a random point, an "Anchor"(invisible object placed on the arena, specifically to be used as a mechanic anchor point). "TargetSubtype" defines how to transform the acquired target. In the example above, it takes a target memorized from a previous mechanic and recorded under tag "fireline0_1", which happens to be an Anchor. Then, it takes the entire horizontal row of that Anchor(I should probably explain how Anchors work in another post), which is a list of Anchors, going left to right. Then, since I want this specific part to go from right to left, it reverses the list. Having acquired this target list, it spawns the ExpandingRight projectile on each target, with a 0.5 second delay. Lemme make a clip of that real quick...  The TargetCount variable is a bit misleading: it dictates how many projectiles to request/expect in the inital target request, but following transfromations can yield a different amount of targets. Anyway, here's a gif:

Visuals, naturally, are placeholders. I have not added anyting related to boss' model animations here, and I will need to. But, as you can see, there's no boss to fight in this gif. That'll come soon.. :D

MechanicSegments do more than just operate projectiles, though. In this example, a MechanicSegment dictates the lock-in of the projectile - when the tether swaps to the warning zone, and the orb "chooses" a lane in the grid. My options were to either create a projectile that behaves like that, or expand the system to give the ability for MechanicSegments to use Events. The latter sounded like a great idea which would provide plenty of flexibility in the future.. So it was done.

3) The last level is "Mechanic". It is fairly simple - it stores multiple MechanicSegments, and fires them, with individual/blanket delays, if specified. It also has some functionality to randomize mechanic segments in it, if necessary.

I am not sure if keeping delays here is a good decision - two lists is clunky, but I am not sure how else I would wanna do it now. And adjusting them all in once place while polishing up the mechanic does feel convenient.

Now, Mechanics like this are loaded into the CombatManager, which fires them one after the other - waiting for the Mechanic's duration before switching to the next one.. And, so far, this works well for my purposes. 

While building this, my main mindset was "if there's something I wanna do but my current system doesn't allow for it - I must modify the system". There's always a quicker and easier way - make a custom projectile/script, a one-time solution. But while I'm focused on building this "mechanic-creating" system, I avoid using any custom one-time solutions - the more flexible the system is, the easier my life will be in the future.

I used this to create about half the encounter I planned - which fully covered all "unique" mechanics I had in mind for it. At this state, the entire planned encounter can be built and tested within an hour or two, minus the assets/visuals.

Now, before making a build and testing it all with a friend or two, I wanted to add the actuall boss body(easy), as well as add one combat character class with 4 spells, and make sure it all works with networking(less easy). Fresh of SillySwords, I had a flexible Spell/Effect system in mind. Totally overengineered for this game's purposes, but, well, I've said the word "flexible" a few times too many already. Anyway, a basic spell system is already in place, with an action bar, tooltip, resource generation/spending, cooldowns, buffs, yadda yadda. Currently I'm working on an elegant way to communicate said buffs/debuffs across network, to make sure every player has proper icons/tooltips. The boss itself will be called an "Advanced Target Dummy", it will be stationary, so - not much to implement here, the health bar is already in place.

Now, just to figure out those buff networking, put together the rest of the mechanics, and I'll be testing the fight. I'll drop the build on the game's page - will probably add a few screenshots to make the page look like something.