RPG Battle Engine - Alpha 7.5, downloads in first post

[CaseyLoufek]

Certainly there would have been weirdness if you hadn't modified/reimplemented the existing callback at all to work with a hex grid - because hexes aren't continuous in the same axes as the coordinate system, the approach taken in the A7 callback would have - IIRC - covered four of the 12 potential jump candidates and two hexes that should never have been considered! That much is definitely fixed, and I have made a note in my pre-release to-do list to check that move costs aren't being rounded off anywhere. I'm pretty sure I've had it working without rounding - so, say, a fighter can move 4 squares along the flat, for example, but only 3 if there's an upward movement part-way 'cause that upward movement costs 1.25 or something.

Well I did change the callback but I was still wrapping my head around the jump connections. Right now, movement is echoing back values like 1.15 and 2.10 but then those characters get 1 and 2 points subtracted from their movement pool after they move. Using the 4 square move fighter in your example I'll see things like the movement him be shown valid spaces with the right movement costs. Then he moves those 3.4 spaces or whatever, has 3 movement subtracted and if he picks move again now he will be able to go to the final 4th space.

[Jake]

Then he moves those 3.4 spaces or whatever, has 3 movement subtracted and if he picks move again now he will be able to go to the final 4th space.

Ah, yes - you're right. The stat values are rounded off on return to avoid floating-point precision problems (which seem to be the bane of my life on this project!) but they don't need to be rounded so completely as they are. If you change line 31 of engine-fighters.rpy from:

Code: Select all

                    return int(round(value))

to

Code: Select all

                    return round(value*100000)/100000

you'll probably see it start to work as you expected. I'll make the change for the next release.

(The downside is that everywhere that stats are displayed you'll need to round them to an int if appropriate - things like HP remaining and stuff like that - or they'll quite possibly show as "198.0" instead of "198")




An alternative approach, if you want to avoid all that trouble, would just be to - in the engine-skills.rpy file, in MoveSkill's PerformAction method, change the line that reads:

Code: Select all

                    fighter.Stats.Move = fighter.Stats.Move - target[1][0]

to

Code: Select all

                    fighter.Stats.Move = fighter.Stats.Move - math.ceil(target[1][0])

which would ensure that the move costs are always rounded up to the next-highest integer. Which will mean that the hypothetical move-in-two-stages guy ends up being able to move slightly less far than he should be able to in a few circumstances, but definitely never gets to move further than he should, and can still always move his full allowed distance if he does it all in one go.

[MediocreJoker]

Does the engine support the oldschool Dragon Quest style where you simply have images show up on the screen as your opponent + a battle menu?

[Jake]

Does the engine support the oldschool Dragon Quest style where you simply have images show up on the screen as your opponent + a battle menu?

Yes and no.

Presently, you'd need to do a little programming to make it happen, as it would ideally need a new Battlefield type. It's on my to-do list, I just haven't done it yet 'cause it's not a game-mechanics thing - just a graphical presentation thing - and it's not particularly interesting to me.

As usual - if you have a game you want to make and need this feature for it, I'll happily do it sooner rather than later.

[MediocreJoker]

Do it when you have time, I do want to make a game using that battle system, but I'm just starting to get into Ren'py, so I'm not in a big hurry.

[wyverngem]

I was just thinking of something like this for a project idea. Thanks for your hardwork and willingness to share.

[Dite]

Hay, me again. (It slipped my mind, but you did answer my question; I was trying to basically basically apply elemental stuff to weapons. Currently baking that kind of stuff into skills/avoiding weapon tinkering for gui stuff, thanks for explaining.)

I'm having trouble getting stat changes to take after a save and reload; I've basically got an intermission screen that I jump("intermission") to, call the code below to change stats with buttons and stuff--visual feedback tells me it's at least adding correctly-- jump("saveScreen") because it seems like jumping was helping some other save-resistant variables take, then jump("intermission") back.

Code: Select all

[..]
        textbutton "Yes" xalign 0.5 action [addStats(current, targetStat, newStat) ...]

class addStats (Action):
        def __init__(self,fighter,name,value):
            self._fighter = fighter
            self._name = name
            self._value = value
        def __call__(self):
            setattr(self._fighter.Stats, self._name, self._value)
            setattr(self._fighter.BaseStats, self._name, self._value)

The goal is to make permanent changes to the base stats (semantically, not codewise, but IIRC BaseStats is what I want). This came from me dissecting engine-xp's stat changes, because that's very close to what needs to happen here, but I have a feeling I'm missing something based on my aforementioned I Don't Understand Ren'py's Saving-itis. (The changes are being made to a field of an object, and all fighters are objects, ergo nothing I do improperly saves?)

If I'm completely off, is there a class I can call that already exists which'll do this, given a fighter and some stat names?

[Jake]

I'm having trouble getting stat changes to take after a save and reload;
...
I have a feeling I'm missing something based on my aforementioned I Don't Understand Ren'py's Saving-itis. (The changes are being made to a field of an object, and all fighters are objects, ergo nothing I do improperly saves?)

Saving and loading of changed stats works fine for me - you can check it in the experience demo, if you save after the first battle ends and before the second starts. So I'm hoping it's the not-understanding-Ren'Py-saves, since they're not very obvious!


The way Ren'Py does saves and loads goes something like the following. When it saves, it saves the value of every single variable which Ren'Py has noticed changing since the beginning of the game. When it loads, it runs all of the init blocks of your game, then sets all of the variables which were previously saved.

Ren'Py only notices a variable value changing when you directly assign a new value to that variable using the '=' operator (more or less). So if you have a variable set to an object, and you change the value of an attribute on that object, Ren'Py won't notice. You're not directly assigning to the variable, and in fact the variable value remains the same - it points to the same instance of the same class, it's just that some of the attributes are different.

Of course, to get an object into a variable in the first place, you have to directly assign the variable, which Ren'Py will notice. The only case where it won't is when the assignment happens before the game actually starts, in an init block. So to get to the point: are your fighters defined in an init block? If they are, move the definitions to just after the 'start' label and it should work fine.



(I know some conflicting advice has been floating around on the forum in the past, and I realise that intuitively it seems to make sense to set stuff up in an init block, but the fact of the matter is that you should set all your game-state variables just after the start label; there's absolutely no benefit to setting them in an init block, and setting them just after the start label avoids object-attribute problems.)

The goal is to make permanent changes to the base stats (semantically, not codewise, but IIRC BaseStats is what I want).

For reference:

There are three stats properties on a fighter: BaseStats, RawStats and Stats.

• BaseStats is the 'start point' for each stat - this is particularly used for stats which get reduced and refilled, like movement allowance or health.
• RawStats is the raw, unmodified current value for each stat. This isn't that useful a lot of the time, but it's used by the FighterStats class to calculate Stats.
• Stats is the current value of each stat after all modifications by Equipment etc.. This is generally the value you want to look up to see whether a fighter can do something or how well they perform at a particular task.

Setting a Stats value - at least for all of the equipment in the release - will automatically set RawStats to the adjusted value. So if you have a RawStats.Strength stat of 10, and a magic sword which gives +50% strength, then your Stats.Strength value will be 15. Setting your Stats.Strength value to 30 will automatically set your RawStats.Strength value to 20 (the value which would be necessary to give a total of 30 after the +50% strength).

The upshot of this is that if you want to modify a reduce-and-refill stat like movement or health, because it's being used up, you should probably modify Stats. If the fighter has a pair of double movement boots, then you effectively want to reduce all movement costs to half what they normally would be, so when you take 1 off of Stats.Move, the equipment modifies it and only takes 0.5 off of RawStats.Move.

But if you want to grant your fighter +10 Strength because he's passed the level-up threshold, it's probably actually best to modify BaseStats and RawStats. Otherwise, if the fighter happens to have that +50% sword, he won't actually get the full +10 strength upgrade - he'll get enough of a strength upgrade that after the magic sword it totals a +10. (Which ends up around +6.6, at it goes.)




So in short: thanks for alerting me to the fact that I got it wrong in the engine-xp.rpy file! Experience gains should definitely be applied to RawStats and not Stats, so the fighter gets the full benefit of their gains!

[Dite]

(I know some conflicting advice has been floating around on the forum in the past, and I realise that intuitively it seems to make sense to set stuff up in an init block, but the fact of the matter is that you should set all your game-state variables just after the start label; there's absolutely no benefit to setting them in an init block, and setting them just after the start label avoids object-attribute problems.)

This was exactly what went wrong on my end. I rearranged my stuff so I'm using a label at the start to do stuff I was previously dumping in a real init, and everything is perfect. Or at least it's being intuitive now, and I'm back in control.

Your post was exceedingly helpful at clearing that up, and I really appreciate the breakdown for the various Stats. I had my guesses about how it worked from the damage code, but this'll help me make sure I'm pulling the right numbers for all my stat-effecting junk.

On a "the hell have I done lately?" note, I've got SRW/FE-style counterattacks functional. It's going to be so cool...once I make it prettier, I guess.

[Mole-chan]

Hey, me again. ^^; Trying to implement the new shop screen, but I'm running into some issues.
Namely, there seems to be a part of the engine update that allows there to be a grouped number of equipment, just like was allowed for items in the previous release. But I can't find what part of the engine needs to be updated to allow this.

Because of that, whenever I buy equipment, it comes back as saying I have a quantity of 0 of that equipment. Naturally, this messes up the sell function quite a bit. So if you could just tell me which RPY I need to replace, that would be wonderful.

[Jake]

Hey, me again. ^^; Trying to implement the new shop screen, but I'm running into some issues.
Namely, there seems to be a part of the engine update that allows there to be a grouped number of equipment, just like was allowed for items in the previous release. But I can't find what part of the engine needs to be updated to allow this.

Because of that, whenever I buy equipment, it comes back as saying I have a quantity of 0 of that equipment. Naturally, this messes up the sell function quite a bit. So if you could just tell me which RPY I need to replace, that would be wonderful.

The short answer is that the BattleInventory class is in the engine-items.rpy file.

The long answer is that when I do a release of the engine it contains a number of changes across many different files, some of which require the changes in other files to work properly. I don't keep track of which files' changes depend on which other files' changes, because I expect people to replace the entire engine directory with the new one, and have all of their game modifications outside of that. So I don't know whether the changes in engine-items.rpy - or the BattleInventory class copied and pasted into another file - will work on their own within an earlier release of the engine.

If you've not done that, and you've been modifying engine files directly, then there's a possibility that you won't be able to use particular updates in newer releases. You can try, and if you have any particular problems with it you can ask and I'll try and help, but there may be a point where it's just not worth trying to extricate the changes in one file from the changes in another.

[Mole-chan]

Hey, me again. ^^; Trying to implement the new shop screen, but I'm running into some issues.
Namely, there seems to be a part of the engine update that allows there to be a grouped number of equipment, just like was allowed for items in the previous release. But I can't find what part of the engine needs to be updated to allow this.

Because of that, whenever I buy equipment, it comes back as saying I have a quantity of 0 of that equipment. Naturally, this messes up the sell function quite a bit. So if you could just tell me which RPY I need to replace, that would be wonderful.

The short answer is that the BattleInventory class is in the engine-items.rpy file.

The long answer is that when I do a release of the engine it contains a number of changes across many different files, some of which require the changes in other files to work properly. I don't keep track of which files' changes depend on which other files' changes, because I expect people to replace the entire engine directory with the new one, and have all of their game modifications outside of that. So I don't know whether the changes in engine-items.rpy - or the BattleInventory class copied and pasted into another file - will work on their own within an earlier release of the engine.

If you've not done that, and you've been modifying engine files directly, then there's a possibility that you won't be able to use particular updates in newer releases. You can try, and if you have any particular problems with it you can ask and I'll try and help, but there may be a point where it's just not worth trying to extricate the changes in one file from the changes in another.

I see. engine-items is the first thing I tried, so it must be something else.
I have been making changes to the engine, but all are minor additions, and I should be able to track them down and re-add them. They're generally just little things that shouldn't conflict with the new code if put back in the right place.
Thank you for your help, though. c:

[azureXtwilight]

Thank you! This is the best battle engine I found so far and you did a great job making it! I have a few questions though:
1. I wonder whether the battle engine supports "stats-modifying" skills such as healing others, temporarily raising/lowering attack and defense and such?
2. Can the attack range for the usual attack command varies depending on each person or should I make a new attack skill for a person with far attack range?

Thank you again!

[Jake]

1. I wonder whether the battle engine supports "stats-modifying" skills such as healing others, temporarily raising/lowering attack and defense and such? :)

Yes - you can look in the engine-skills.rpy file for the HasteSkill class for an example of a temporary stat-change. The way that skill works is to add an 'Effect' to the fighter - the HasteEffect class, found in the engine-extras.rpy file.

There's no example of a healing skill in the demo files (I should probably add that!) but it would work the same as the PotionItem or ElixirItem item classes (engine-items.rpy), essentially - just as a skill. It (probably) needs to target friendlies and not enemies, and either use the 'Damage' method on the target Fighter with a negative number (negative damage = healing!) or modify the Health stat directly in the same way as the Elixir does with MP.

2. Can the attack range for the usual attack command varies depending on each person or should I make a new attack skill for a person with far attack range?

You shouldn't have to write an entirely new skill class, but you'll need to create another instance of the AttackSkill class and pass a parameter called 'range' into the initialiser. So where you presently see:

Code: Select all

Library.Skills.SwordAttack = AttackSkill(command=[('Attack', -1)], multiplier=1.2, sfx="audio/sword.wav")

in the assets.rpy file to set up the sword attack skill, you'd need to create another one for your new longer-range attack:

Code: Select all

Library.Skills.LanceAttack = AttackSkill(command=[('Attack', -1)], multiplier=1.4, sfx="audio/lance.wav", range=2)

(Of course, you can call it what you want, change the command name and weight, the damage multiplier and so on as well. Look at the __init__ for AttackSkill in engine-skills.rpy to see the full list of parameters you can pass in.)

Thank you again! :)

You're welcome!

[Eiliya]

Quick Question: I wish to implement the Active type battle you have shown here in a game I am making. How do I actually go about doing that? Do I just copy/paste the script you wrote in the first page in this thread, or do I need to do some more detailed work? Thank you for your time.