Battle Engine - Alpha 6 release, downloads in first post

[Jake]

(As it goes: this post is going to be a programming/API-design discussion, and while I'd be really interested in any feedback or suggestions, if you're planning on using the engine but not planning to do stuff like code new skills or items, it probably won't affect you.)

One thing that's been on my plan for a long while is adding the ability for a fighter's equipment and/or effects placed upon that fighter to be able to modify the fighter's stats... so if you don a suit of armour, your defence stat could go up, or if someone casts 'Haste' on you then your speed increases. I figure that I have to do this in a dynamic fashion in the engine, and not just require that people calculate the defense of their guy based on what armour he has, because of things like spells and the potential for mid-battle equipment changes or more-complex rules that change over time (e.g. a werewolf's strength going up and down as clouds move away from or in front of the moon, maybe).


So I've done the groundwork, but now I'm hung up on a design question that I've still not come up with a firm answer for - so I figure I'll ask if anyone has any kind of firm preference.

Basically, the problem is that sometimes, you'll want to be dealing with the modified stat and other times you'll want to be dealing with the unmodified stat, and it's hard if not impossible from inside the framework to tell which one is wanted.

For example: You have an MP (magic points) stat (say, of 10), and you're wearing an amulet which doubles your magic points (to 20). So when a spell uses 4 MP, you expect to be left with 16.
On the other hand, if you take off the amulet mid-battle, what should your MP score be? If your MP halves again, we go down to 8. Or maybe all excess points should be lost, and you go down to 10?

Another example: You have a charisma of 10, which affects your ability to convince enemy fighters to join your team mid-battle (Tactics Ogre, at least, did this!), and you have a spell cast on you that doubles your charisma to 20. You receive a scarring wound which knocks 6 off your charisma (leaving aside how realistic this is), so should your new charisma be 14 ((10 * 2)-6) or 8 ((10-6) * 2)? It seems to me that the latter makes more sense, but of course that means it works differently to the previous example.





So, the programming.

My first thought was just to automatically intercept the requests to get the value of a stat and pass it through to the items/equipment to modify it. So the engine needs to check the MP stat, and it picks up the raw stat from the guy (10) and then runs it through the magic-amulet equip to get the final result (20). So then, what do I do when assigning the value back to the stat?
If I set the raw stat ("Stats.MP = Stats.MP - 2") then I calculate 20-2, get 18, then write 18 to the raw stat... but then, next time I retrieve it, it goes through the same item/equip filter and comes out as 18*2=36!
If I set the modified stat, then the Charisma example is broken; the guy's -6Chr scar only effectively loses him 3Chr, because of the x2 amulet.



Now, a fighter already has two collections of stats - regular 'Stats' and 'BaseStats', which is the normal-maximum for that stat. (So a fighter might have Stats.HP = 135 but BaseStats.HP = 200; he can only heal up to 200, no further.) So one option I'm thinking of is to introduce a new 'RawStats', which gives you the unmodified value of any statistic, so I can deliberately choose to modify Stats.MP when I cast a spell, but RawStats.Chr when I get a scar. This means that stat-modifying items will have to provide two functions rather than one; one to modify the raw stat to the calculated stat for normal use (so the magic amulet would return rawMP*2), and another to set the raw stat based on a change in the calculated stat (so the magic amulet would be told to set the MP stat to 18, and pass through "set MP to 9").

Another approach would be to check the difference between the new and old values when setting a stat, work out a proportional change (so 20 -> 18 MP is a -10% change) and apply that proportional change to the base stat (so the base 10MP becomes 9MP).
This would mean that items/spells only have to write one function - how they modify the stat - but you lose the flexibility of being able to feed back to the raw stat differently for different skills (so the Chr and MP examples would have to work the same way, and a guy who happens to be luckily wearing a charisma-doubling amulet when he gets scarred effectively only takes half the penalty he would have if he weren't wearing the amulet, even after he takes it off).

Anyone got any particular opinions on this front? Any other ideas how this could be managed? Any examples of how they'd want to see stat-modifying equips/effects working that wouldn't be covered by one or both of these options?

[DaFool]

I got kinda lost in the last paragraphs maths there, but I tend to go by what I've encountered before:

Temporary stat-boosting and stat-decreasing effects usually affect only INT, MAG, DEF, ATK, etc. so you only need to add a factor to the damage resolution table. I have never encountered a +HP or +MP equip that can be changed/removed during battle except during action RPGs where I sometimes nonchalantly tinker with my inventory even while being attacked.

But that doesn't apply here. The only time I see HP and MP change during battle is when, in some games, a character levels up during the battle (usually after performing a finishing blow). In those instances, the stats only go up, and they are permanent, and sometimes even refilled.

I think it's pretty safe to assume that items will be able to change resistive stats (INT, RES, DEF, etc.) temporarily, but raw HP/MP numbers are affected by equipment which technically you shouldn't be able to change mid-battle. I only recall games such as Persona or Grandia where you have an equipped magical being or magic egg which you can swap to a different element, but once again they only affect resistive stats.

[jack_norton]

Now, a fighter already has two collections of stats - regular 'Stats' and 'BaseStats', which is the normal-maximum for that stat. (So a fighter might have Stats.HP = 135 but BaseStats.HP = 200; he can only heal up to 200, no further.) So one option I'm thinking of is to introduce a new 'RawStats', which gives you the unmodified value of any statistic, so I can deliberately choose to modify Stats.MP when I cast a spell, but RawStats.Chr when I get a scar. This means that stat-modifying items will have to provide two functions rather than one; one to modify the raw stat to the calculated stat for normal use (so the magic amulet would return rawMP*2), and another to set the raw stat based on a change in the calculated stat (so the magic amulet would be told to set the MP stat to 18, and pass through "set MP to 9").

That's what I'm using in Planet Stronghold and what I did with Magic Stones. I did some research too when I encountered that problem, and I think that this is the best solution, all the others might lead to successive bugs or more difficult game balancing So my vote goes to that implementation.

[Jake]

Temporary stat-boosting and stat-decreasing effects usually affect only INT, MAG, DEF, ATK, etc. so you only need to add a factor to the damage resolution table. I have never encountered a +HP or +MP equip that can be changed/removed during battle
[...]

As it goes, while this would be a pretty good simplifying assumption in any specific battle system, the fact that it's a generic system at the engine level makes them not too implementable, unfortunately. There's only one stat which is mandated by the engine - 'Health' - and everything else is entirely customisable. Any other stats get given to a fighter either when that fighter is set up (by the game programmer) or when they're assigned skills which require a stat they don't have (in which case they get the default defined in that skill for that stat).

And while I tend to agree that it's unlikely that a character should be allowed to activate/deactivate a piece of equipment mid-battle which affects things like HP or MP, I can't rule it out, 'cause I don't want to place arbitrary restrictions like that on other people's games.

(In fact, even without that it's possible to need to change stats like that mid-battle; perhaps in one game mechanic, a fighter who receives a critical hit has a certain chance of taking a crippling injury which affects his defence, toughness, dexterity or whatever... he could also have come under the effect of a spell which boosts one of those stats for a certain amount of time.)

[Jake]

I've been working on items and equipment lately... I have basic item and equipment functionality finished, and a few test items like a health-restorative potion and an amulet which doubles your attack strength while equipped. Presently items work just like single-use skills, so they can target as flexibly as skills and do more or less anything when activated, and equipment works like items with added stat-modifying functionality for when it's equipped.


So now I'm thinking about how to implement restrictions on fighter equipment. Most games give you some restrictions (e.g. only allowing you to carry one weapon, one armour and four accessories at a time) but the types and details of those restrictions are pretty varied!

It seems to me that a lot of these details are going to be game-specific and shouldn't be dealt with in the engine, so if your game world demands that the name of every item of equipment a character has must begin with a different letter then it's up to you to implement it, the engine can't be expected to deal with weird cases like that out of the box. In keeping with the rest of the engine I'll try and leave the classes as open to extension as reasonably possible, so you'll just have to write the one method in one place to make that check, but you'll still have to do some coding.

On the other hand, though, there have to be a relatively small set of common behaviours that could cover 80% of people's requirements. So, my present plan for the next release is to have finished implementing the following, all of which will be optional:
- Limit to items in inventory based on weight of items.
- Limit to equipment based on attributes equipment is tagged with - so you can easily set it up such that a character can only have one "armour" item and one "weapon" item in use at a time, but up to four "accessory" items.
- Limit to equipment based on how many hands it requires - so a Fighter could have one or two "1-hand" items or one "2-hand" item... unless they had more than 2 hands.

Can anyone think of any common cases which these systems couldn't cater for? Or for that matter, any other feature requests to do with items or equipment that you think I should consider?

[jack_norton]

I think you covered the most common cases. For magic it would be different but as you said impossible to make it generic, so should be hand-coded game by game.

[usul]

Is it possible to turn the Game engine into a two-player confrontation? I tried changing the playerFaction variable to True but nothing changed during the gameplay. Is it because the game is limited to one playerFaction?

Code: Select all

battle.AddFaction('Enemies', playerFaction=True)

[Jake]

Is it possible to turn the Game engine into a two-player confrontation? I tried changing the playerFaction variable to True but nothing changed during the gameplay. Is it because the game is limited to one playerFaction?

Absolutely it's possible, there's no hard limit to the number of player factions or the number of factions period.

The distinction isn't just the playerFaction parameter - that's just to give the BattleMechanic the opportunity to present you choices about the faction if appropriate - for example, if you set playerFaction to True for the grid demo which uses the turn-based mechanic, then you'll get to choose the order in which the enemy fighters make their moves. If you change it on the active demo, on the other hand, it won't change anything at all - since turn order is determined by the fighter's speed, there's no faction-level decisions to make anyway so the parameter is basically ignored for active battles.

The other half of the problem is the type of Fighter that you're constructing; if you use a PlayerFighter then you get presented with the choice of what to do with that fighter when it's their turn; if you use EnemyFighter/MovingEnemyFighter then the choices will be made automatically. (Those two should really be named "SimpleAIFighter" and "SimpleMovingAIFighter" or something, I'll think about changing them for the next release to try and avoid confusion.)

There's two things to note here:
- Firstly, constructing the fighter and registering skills is slightly different for AI fighters, so it's not quite so straightforward as swapping 'MovingEnemyFighter' for 'PlayerFighter'.
- Secondly, you can also use this method to add AI-controlled fighters to the player's side. Maybe in your game you want to give the player control over his main character and everyone else on his side is an AI? Just only have one PlayerFighter in that faction.


If you want a demo of how to do player-vs-player battles, check out the facing demo in facing-demo.rpy; both sides are player-controlled in there, by use of playerFaction=True and PlayerFighter on both sides.

[usul]

I'm adapting the battle engine for a game I'm working on set in space. I've basically replaced the fighters with spaceships and the sword and knife skills with photon torpedos (temporary attack for testing). It all works fine (I'm using the active demo) but I'm not sure on how to go about the following:

-Adding attack/shooting animations, whether the be static lights on the ships firing or sprites following a trajectory (which I doubt has been programmed at this state).

-Adding Shields up/down, I'd like to be able to have the shields go up or down and have a life variable of their own.

I'm sure I'll think of more along the way, but that's it for now.

[Jake]

I'm adapting the battle engine for a game I'm working on set in space.

For what it's worth - it's intended to be generic and extensible enough to do this, so hopefully you won't have to actually change anything in the engine*.rpy files to get what you want. Let me know if this isn't the case!

-Adding attack/shooting animations, whether the be static lights on the ships firing or sprites following a trajectory (which I doubt has been programmed at this state).

Basically, you'll add new animations by adding new states to the fighter's sprite. Check out the facing demo for an example of adding new states (you can add states with whatever name you like) and then, in your Skill's PerformAction method, call ChangeFighterState on the Battle instance like this:

Code: Select all

fighter._battle.ChangeFighterState(fighter, "firing")

You may want to call renpy.pause() for whatever the length of your animation is, as well, so it has time to show before moving on. (I did write support for state-to-state transitions that take a particular length of time to run, but I've just realised I didn't actually demonstrate it in any of the demos...


As to sprites following a trajectory... it's not something I've done yet, because it's not really plausible to get it the way I'd want it with Ren'Py in the state it's in currently. Namely, if you just use a regular move transition to move a sprite from one place to another you can't vary the z-order that the sprite is shown at, so you can't have it pass between fighters before getting to its target.
Of course, if you're happy to have your torpedoes drawn over the top of everything else, then you could just draw them on a layer above your fighters at the start position, then draw them at the end position with a renpy.transition(move).

-Adding Shields up/down, I'd like to be able to have the shields go up or down and have a life variable of their own.

Check out Effects - near the bottom of the engine-extras.rpy file there's an Effect called 'CurrentFighterPointerEffect' which draws a thing over a fighter until the effect is removed... and if you look a bit up from there there's a CurrentFighterPointerExtra which demonstrates how you can add or remove an effect. You can do the same thing in a Skill, of course.

In alpha 2 there's no support for effects changing anything about the fighter without having to go in and fiddle stats when it's added/removed, but if you wait a few days, the next release (I've almost finished it, I just need to clean up a couple of things and write demo code for it all) will have Effects and Equipment which can modify a fighter's stats on the fly, so your shields Effect could multiply the ship's defence by ten, for example, if that's the kind of thing you want.

[usul]

I've followed your instructions and gotten it to work. I'll wait a few days for the new version to come out before implementing the shields, but in the meantime I'm going to try and figure out as much of the code as possible.

The comments you provide in your script are very useful. But still I find myself getting confused when trying to figure out the nuts and bolts (I'm trying to learn how it works and not just build a game on top of the engine). Thanks for the work you're putting into this project, it's very much appreciated!

Please try to put in demos of all the features though. I know it's a lot of work, but for non-programmers, if there's no demo, we won't even know it exists.

[Jake]

The comments you provide in your script are very useful. But still I find myself getting confused when trying to figure out the nuts and bolts (I'm trying to learn how it works and not just build a game on top of the engine). Thanks for the work you're putting into this project, it's very much appreciated!

You're welcome! I do intend to document everything in the end, nuts and bolts and all, but I'm trying to get the important bits working first. Feel free to ask if there's anything you're curious about, though, and I'll answer as best I can!

Please try to put in demos of all the features though. I know it's a lot of work, but for non-programmers, if there's no demo, we won't even know it exists.

Yeah, I know! I thought I had written a demo for the sprite state transitions, but apparently not...

[usul]

Will it be possible to add fighters once a battle has been initiated? I'm thinking for example of a magician who might summon an elemental to join the fight or a creature that might spawn another.

I'd also like to see scenery that can be modified (trees cut down, fences broken, etc.) but I think you already have that on your todo list.

Something else that might have been overlooked is converting enemies to your side. You could have a fighter, a magician or a priest with a convert skill that changes an enemy's allegiance and puts it under your control (or vice-versa)

[Jake]

Will it be possible to add fighters once a battle has been initiated? I'm thinking for example of a magician who might summon an elemental to join the fight or a creature that might spawn another.

Certainly, yes - I've actually got an example of this ready for the next alpha, although I should probably do a graphic for it as well...
(It's certainly possible in the current a2 release - you'd need to create a new skill, set the '_currentFaction' member of the Battle instance (fighter._battle in a skill PerformAction method) and then just use the same code you'd use to add a new Fighter pre-battle. But in the next release there's a utility method that makes it a little more straightforward.)

I'd also like to see scenery that can be modified (trees cut down, fences broken, etc.) but I think you already have that on your todo list.

Indeed. I'm just prioritising more core-gameplay stuff at the moment - alpha 3 will be mostly about items and equipment - and after that I'll get back to little details like this. ;-)

Something else that might have been overlooked is converting enemies to your side.

I loved Tactics Ogre, so this is something I'd never overlook! ;-)
Again, it's something that'll be easier (and hopefully demonstrated) in the next release, there's another utility method for this kind of thing... if you wanted to write a skill to do it now, you'd have to change the Fighter's Faction property, and then also remove them from the battle's FactionList for their old faction and add them to the FactionList for their new faction.

[usul]

If it's not too much to ask, could you comment on the Fighter class, more specifically the leadup to the Show function, especially the position variable. I'm trying to reproduce this in a simplified version in order to understand, but I don't get how you feed the info into the functions.