Stuff Under the Header


Changing Methods

Slaix and I had a conversation that involved randomized and deterministic elements in games. I won't go into exactly what we were talking about, but later on when thinking about it, it did remind me of the shift I've had in designing DT3, especially compared to DT1. That being, everything being designed lately has not had any random elements to them. Every action an enemy has is completely deterministic based on it and the player's current state.

Flame Instigator
Thinking back to the Flame Instigator fight in DT1. All his actions were somewhat randomized, but depending on what was happening, certain actions had a much better chance of occuring than others. At the time, I felt that was okay. Had I made that today, there would have been more to his decision making and no random elements would be around.

Looking at Death, he has 3 scythe swings that can be chosen, in a combo of 3. These are chosen at random, which will be changed before the final version is released. I'll instead, set up a table that he cycles through. (Though I will have something set up that will skip or reset the table to keep it from being a set sequence every cycle.) I'm somewhat okay with that random element, given what it is, but in an encounter like Death, I'd like everything to be consistent.

Another random element to Death are where the single spawning scythes appear. They always appear at the top of the screen, with a variance of 16 pixels along the y. For x, they'll appear anywhere randomly within a 32 pixel margin border of the map sides. This will change to always be consistent for the final version. Something like spawning it directly above him, then the next spawn above the player, then the next being the median between the two along x, always near the top of the screen.

The larger scythe summon (where he'd kneel) has always been set in a sequence. The first is on the left, then right, then the top, and it repeats that cycle.

Gate G Boss
I won't be spoiling who/what it is, however the fight has similar elements of the above 2 encounters. I'll be keeping with my current standards of it being 100% deterministic.


Kurtis Haren said...

The problem with completely refraining from any amount of random behavior, or at least what comes to my mind, is that it seems that the player would be able to more easily lock the boss into a pattern and make it easier to beat.

It's not the best example, but I'm reminded of the different Mega Man bosses whose patterns reset when they're struck at the proper moment with their weakness.

Do you have an idea on a way to prevent that, like having something along the lines of "This didn't work the last time I was in this situation, let me try a different attack instead this time"

ZephyrBurst said...

The behavior can come from something like, if the player x is a multiple of 4, do this, or a multiple of 3, do that, or both, do something else. That's kind of a last resort, I just mean that I won't be using:
if variable=1 {stuff}
else if variable=2 {other stuff}
That kind of random is going out the door.

The most recent boss I coded has a set of behaviors that are chosen based primarily on distance to player, if the player is currently using an offensive ability (or guarding), or how far along in the enemy's attack string he was. For example, he had up to 4 actions in a single string of actions before having any down time. Those all have a slight variance on what its looking for to determine what attack or action are used.

Anonymous said...

I don't know if it is a good idea to change Death's behaviour. His random attacks made it a reflection test. The palyer was forced to react accordingly to his attacks. It's a fair fight since Death shows what his next attack will be. So the player does have a few moments to react accordingly. Taking away that would be sad.