On Wed, Jan 19, 2022 at 6:49 PM Ralph Versteegen <[email protected]> wrote:
> > > On Wed, 19 Jan 2022 at 13:49, James Paige <[email protected]> wrote: > >> So I do have a few other changes related to this one planned. >> * An option to make heroes controlled by (random) AI >> * A concept of "traitor" which will affect targeting classes when an >> attacker is targeting >> * A concept of "turncoat" which will affect targetting classes when an >> target is being targeted >> * Attacks that can turn these effects on and off or set-to-default >> >> So an enemy with all 3 of Controllable, Traitor, and Turncoat would >> function as a hero for that one battle. >> >> To simulate a classic "Confuse" status, you would have an attack that >> turns Controllable off, and traitor on, but don't touch turncoat. Then to >> end that status, use an attack that sets Controllable and Turncoat back to >> default. >> > > I was hoping this meant you were going down this direction :) > > I'm not sure whether "Traitor" is proposed to swap foes and allies of a > target, or just makes everyone count as a foe. Those are two different ways > that you might want a Confused status to work, and it seems that these bits > would only allow one or the other. > > What I was thinking was to give each combatant a team (default 1 for > heroes, 2 for enemies) and an "acting" team. A target is considered an ally > by an attacker if their team is the same as the attacker's acting team, > else they're a foe. Also team 0 could mean "independent", with no allies. > You probably wouldn't use more than a third team, for "Nature", say when a > clan of hyenas opportunistically attack while you're fighting someone > else). > > So Confuse to make someone attack anyone indiscriminately would change > their acting team to 0 (so two confused targets still hit each other), and > to swap sides you'd change their acting team (although now I realise that > means the attack would need to be specific to use by heroes or enemies, > unless there was an attack bit like "swap target's acting team" that just > set it to the attacker's). > > Maybe I've overcomplicated it again, while still not adding all that much > utility/flexibility (really should work on allowing script hooks for things > like this) vs just adding a third Independent bit. > Yeah, I think teams will overcomplicate it for now-- and yes, having scripting hooks so people can customize this behavior will be the best way to get advanced fancy effects I do kinda like the idea of being able to make a confused enemy target all, rather than only the opposite side, but I'll have to think if there is a nice simple way to do that. > > >> >> Or a classic Berzerk could be implemented with Controllable=Off and could >> end with controllable set to default (this would work for heroes, but >> wouldn't do anything meaningful on an enemy) >> >> This should allow a lot of possibilities, and is all pretty easy to >> implement. >> >> And yes, someone could totally fake 5 or 6 heroes in the party with this, >> by using an instead-of-battle script, and adding hero enemies to the >> formation with a script before the battle starts. Definitely not ideal, but >> fine if people want to try it. >> >> Actually increasing the size of the active party > 4 and increasing the >> number of enemies in a formation > 8 is something I definite;ly want to do, >> but it will require lots and lots of cleanup, which is outside of the scope >> of what I am trying to do right now. In particular, there are tons of >> places where the ID range within the bslot() array defines what a >> BattleSprite Instance does, so the first step of that cleanup will probably >> be to convert all access to bslot() to a set of accessor functions for >> heroes, enemies, attack sprites, and weapon sprites. Then those different >> ranges can be split apart into different arrays, which can be dynamically >> sized when you load a battle formation with 15 enemies in it, or something >> like that. But that is for later. I want to keep the scope of what I am >> working on broken down into bite-sized baby-steps to mix a metaphor :D >> > > I don't think we would want to split bslot() into separate arrays for > heroes and enemies: being able to index across all of them with a bslot() > index is very useful and widely used (eg. targeting) so it would be a lot > of work to remove that. Why not just add is_hero and is_enemy attributes. > There's a lot of lines of code to change, but each would then be an easy > change. Could also start using polymorphism. > Yes, you are right. is_hero and is_enemy attributes are much better than what I was thinking of with the accessor functions for bslot. Glad you said it :) > On the other hand, I do want to remove attacks and weapons from bslot() > and was considering doing it soonish. Almost all of the BattleSprite data > is irrelevant for them, and nearly all of the advantages of having them in > bslot are (or will be) gone now that battles are converted to slices. > Ah, right! Those only get used in animations, so the slice is all that really matters :) > > >> Fortunately I think the current features I am adding will not make any of >> that later work harder, and might even lead to a little helpful cleanup. >> >> --- >> James >> >> >> >> >> >> On Tue, Jan 18, 2022 at 8:22 AM Ralph Versteegen <[email protected]> >> wrote: >> >>> Wow! That's not a feature I was expecting to see for a long time. A nice >>> surprise! >>> >>> I suppose this is particularly useful for giving the player extra >>> actions they can perform in battle. People are going to inevitable think to >>> use it to get around the 4 hero limit, but it seems really problematic for >>> that. Or is time to add team numbers to battles, so you can define which >>> combatants are "foe" or "ally"? >>> >>> On Mon, 17 Jan 2022 at 14:01, <[email protected]> wrote: >>> >>>> james >>>> 2022-01-16 17:01:32 -0800 (Sun, 16 Jan 2022) >>>> 39 >>>> New enemy bitset "Controlled by Player" >>>> --- >>>> U wip/bmodsubs.bas >>>> U wip/enemyedit.bas >>>> U wip/loading.rbas >>>> U wip/udts.bi >>>> U wip/whatsnew.txt >>>> >>>> _______________________________________________ >>>> Ohrrpgce mailing list >>>> [email protected] >>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>>> >>> _______________________________________________ >>> Ohrrpgce mailing list >>> [email protected] >>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >>> >> _______________________________________________ >> Ohrrpgce mailing list >> [email protected] >> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >> > _______________________________________________ > Ohrrpgce mailing list > [email protected] > http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org >
_______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
