[Ohrrpgce] SVN: james/12694 New enemy bitset "Controlled by Player"

Thu Jan 27 12:52:15 PST 2022

On Thu., Jan. 27, 2022, 8:40 a.m. Ralph Versteegen, <teeemcee at gmail.com>
wrote:

>
>
> On Fri, 28 Jan 2022 at 01:07, James Paige <Bob at hamsterrepublic.com> wrote:
>
>>
>>
>> On Thu., Jan. 27, 2022, 4:34 a.m. Ralph Versteegen, <teeemcee at gmail.com>
>> wrote:
>>
>>>
>>>
>>> On Thu, 20 Jan 2022 at 14:56, James Paige <Bob at hamsterrepublic.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Wed, Jan 19, 2022 at 6:49 PM Ralph Versteegen <teeemcee at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, 19 Jan 2022 at 13:49, James Paige <Bob at hamsterrepublic.com>
>>>>> 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.
>>>>
>>>
>>> Going down the route of bitsets then I don't really see another option
>>> but adding another bitset to make everyone an enemy.
>>>
>>> Now, I'm not pushing for the team IDs idea, but I just wanted to write
>>> something about complexity. Say you add a third bit, or even a fourth ("Foe
>>> to all"). I think that arguably two integer-valued settings are simpler
>>> than 3 bits, because 3 bits is 8 possible combinations, a lot to think
>>> about. And even an 8-way setting could be simpler to reason about than 3
>>> bits if you don't have to think about any interactions. Complexity of
>>> implementation is usually also secondary.
>>> But in fact after looking at the new version of get_valid_targs I
>>> realised team IDs would actually have been simpler in implementation too.
>>> The bitsets are more complex... in fact I see some mistakes in the code,
>>> which I'll fix: "Dead-ally (hero only)" and "Dead foe (enemy only)" were
>>> meant to be informative only, to warn that those settings didn't make sense
>>> for enemies/heroes, but not to intentionally restrict the targets.
>>>
>>
>> I was actually considering two more bit states-- "Indiscriminate
>> Attacker" to attack both sides, and "Tergiversate Target" to be targeted by
>> both sides
>>
>
> Maybe we need to make more frequent releases so that you can outlet your
> penchant for lexical obscureness elsewise :)
>
>

Haha! I cannot question the perspicacity of this suggestion!

>>
>>>
>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> 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 <teeemcee at gmail.com>
>>>>>> 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, <subversion at hamsterrepublic.com>
>>>>>>> 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
>>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>>
>>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Ohrrpgce mailing list
>>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>>>
>>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Ohrrpgce mailing list
>>>>>> ohrrpgce at lists.motherhamster.org
>>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>>
>>>>> _______________________________________________
>>>>> Ohrrpgce mailing list
>>>>> ohrrpgce at lists.motherhamster.org
>>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>>
>>>> _______________________________________________
>>>> Ohrrpgce mailing list
>>>> ohrrpgce at lists.motherhamster.org
>>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>>
>>> _______________________________________________
>>> Ohrrpgce mailing list
>>> ohrrpgce at lists.motherhamster.org
>>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>>
>> _______________________________________________
>> Ohrrpgce mailing list
>> ohrrpgce at lists.motherhamster.org
>> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>>
> _______________________________________________
> Ohrrpgce mailing list
> ohrrpgce at lists.motherhamster.org
> http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.motherhamster.org/pipermail/ohrrpgce-motherhamster.org/attachments/20220127/fce22871/attachment-0001.html>