Battle Engine - Alpha 6 release, downloads in first post

[Jake]

Can the tiles support height data ? Like having a battlefield with stairs, terraces ? My guess is this would add a lot of complexity to an already complex engine, right ?

This is something I've been ignoring for the moment, on the grounds that - as you say - it adds complexity. My original thought was that height could be fudged in a lot of cases by having carefully-positioned nodes (thinking along the lines of the path-based engine demo I put up a while back) which you can enter from one direction but cannot leave in that direction, but while it's workable in the confines of my original plan for that engine, it's not really a good universal solution.

I'm thinking of adding attributes to positions (e.g. grid squares, path nodes) which affect the way fighters interact with them, so 'height' might make an appearance there, but I couldn't promise anything. Certainly I doubt very much this engine will ever support - for example - UFO-style height layers where one fighter could stand directly above another.

Can a character sprite occupy several tiles ? Like a giant or a dragon that would occupy 4 or six tiles and would thus prevent other combattants from being able to walk on them ?

As of right now: no. I've had a couple of ideas since reading the question, though, and I'm thinking that at the very least, a half-way solution (multi-tile occupancy, but still checking for walkable paths and so on as if the fighter were a single tile wide) should be quite possible. Maybe even full support for multi-tile fighters, but I wouldn't want to promise anything.

(This also opens up questions like "how much of a fighter would you have to see to claim LoS to that fighter", or "should a multi-tile attack effect which covers three tiles of a multi-tile fighter perform the attack once, three times, or one time with higher strength?"... there are game-rules considerations as well as technical ones.)

In the case of grenade-like spells or weapons that affect multiple tiles, could the player inflict friendly dammage ? Is that just an option for the game maker to customize ?

Realistically, it's left up to whoever writes the Skill class which powers the attack. It would be possible to write both. Personally, I'd be inclined to damage friendlies with area attacks, so if/when I write an example of such an attack I'll probably do it that way, but it's not a restriction.

Just an idea,

n - doesn't need a target
sl - targets a single fighter, requires Line-of-sight
p - targets a position, doesn't require LoS
s - targets a single fighter, doesn't require LoS
pl - targets a position, requires LoS
f - targets a whole faction

Mm... I'm also reaching the point where I'm thinking it might be useful to double everything up (again!) to allow for including or not including friendlies on the target list (e.g. you might not want to include friendlies for an 'attack' skill, but you may want to be able to target friendlies or enemies for a "change element to fire" skill). I'm wondering whether a TargetData class or something which just gets constructed with various parameters depending on what options you want might be easier, something like:

Code: Select all

    targets = TargetData(fighters=True, los=True, friendlies=False)

...but then, maybe that would be too hard to explain to non-Python-coding users...?

[blakjak]

I'm thinking of adding attributes to positions (e.g. grid squares, path nodes) which affect the way fighters interact with them, so 'height' might make an appearance there, but I couldn't promise anything.

Right, I can barely imagine how hard it would be to program something like that.

Certainly I doubt very much this engine will ever support - for example - UFO-style height layers where one fighter could stand directly above another.

I'm not sure I understand, are you refering to this type of 'standing on top of each other' ?

(This also opens up questions like "how much of a fighter would you have to see to claim LoS to that fighter", or "should a multi-tile attack effect which covers three tiles of a multi-tile fighter perform the attack once, three times, or one time with higher strength?"... there are game-rules considerations as well as technical ones.)

I didn't think about that, off course it would also complicate matters, this multi-tile occupancy possibility would influence a lot of parameters.

Realistically, it's left up to whoever writes the Skill class which powers the attack. It would be possible to write both. Personally, I'd be inclined to damage friendlies with area attacks, so if/when I write an example of such an attack I'll probably do it that way, but it's not a restriction.

I would do it that way too, as a way to also limit the use of grenade-like attacks, or pose a moral choice to the player.

...but then, maybe that would be too hard to explain to non-Python-coding users...?

I'm a non-Python-coding user, and the few times I tried using some, what I had the most hard time with, was lack of documentation, or/and examples understandable by a total newb to coding.

One question, what about AI ? Is there any ? How does the engine manage it's fighters ?

[Jake]

Certainly I doubt very much this engine will ever support - for example - UFO-style height layers where one fighter could stand directly above another.

I'm not sure I understand, are you refering to this type of 'standing on top of each other' ?

Nope, I'm referring to the game UFO: Enemy Unknown (Or X-Com: UFO Defense in the US, X-Com: Enemy Unknown in continental Europe), where the grid basically extended as a grid upwards as well, with 1x1x2unit squares. The best example I can find is this video, battle starts around 2:00:

[youtube]<object width="640" height="505"><param name="movie" value="http://www.youtube.com/v/y9-9Y70JNlM&hl ... ram><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/y9-9Y70JNlM&hl ... 2=0x6b8ab6" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="505"></embed></object>[/youtube]

If you had - say - a house with an lower and an upper floor, then you could quite feasibly have someone standing on the upper floor in the same x/y grid coordinates as the person on the lower floor.

(Actually, while I was typing this I had a vague idea of how I might do something like this, but I'm not promising anything!)

I'm a non-Python-coding user, and the few times I tried using some, what I had the most hard time with, was lack of documentation, or/and examples understandable by a total newb to coding.

Mm, and I'm certainly planning to write documentation, at least enough for people to use the framework to run battles. Customising it with your own UI providers and game mechanics and so on will always require a bit more programming, though.

One question, what about AI ? Is there any ? How does the engine manage it's fighters ?

Presently, there's no AI. I plan to implement rudimentary AI for the alpha release (pick randomly from available skills which have available targets, weighting for different skills can be configured so some are chosen more often than others, enemies will tend to move towards players in order to engage them), but I won't do anything that impressive. AI is likely to be pretty game-specific, after all!

(For example, in a game where you can move and attack in the same turn, it's to your benefit to run right up to a player and attack them; in a game where you can either move or attack (e.g. the Abraxas demo I uploaded before) it's to your benefit to stand a space or so away from the player so they can't attack you, and force the player to approach you so you get the first hit in.)

[blakjak]

If you had - say - a house with an lower and an upper floor, then you could quite feasibly have someone standing on the upper floor in the same x/y grid coordinates as the person on the lower floor.

(Actually, while I was typing this I had a vague idea of how I might do something like this, but I'm not promising anything!)

Ah, I see. Well I wasn't expecting this feature, so it would be a bonus, didn't know that game btw, looks like a lot of fun.

Mm, and I'm certainly planning to write documentation, at least enough for people to use the framework to run battles. Customising it with your own UI providers and game mechanics and so on will always require a bit more programming, though.

Like you wrote, I don't see a huge problem to having a class then, if the docs are there, then off course, customizing is never painless

[Jake]

didn't know that game btw, looks like a lot of fun.

UFO is probably one of my most-played PC games ever - definitely my 1993 game of the year! ;-)

[Jake]

One question, what about AI ? Is there any ? How does the engine manage it's fighters ?

Presently, there's no AI. I plan to implement rudimentary AI for the alpha release (pick randomly from available skills which have available targets, weighting for different skills can be configured so some are chosen more often than others, enemies will tend to move towards players in order to engage them), but I won't do anything that impressive. AI is likely to be pretty game-specific, after all!

On the subject - I've done a basic AI which is good enough for bad guys in an FF-style game (which means I only really have UI left and I'll be pretty much done on that front), but I'm not sure of the best approach to take for enemy AI for movement. As I said before, I don't want to do anything too complicated 'cause a lot of it will be game-specific, but does anyone have any ideas regarding movement AI? Particularly I'm wondering about the following kinds of thing at the moment:

- An AI to move towards the nearest enemy (from its point of view - so in a two-faction game, a player fighter)
- An AI to have a fixed ideal-distance to the nearest enemy and move to the point which fits that profile best
- An AI to prefer moving to a better position than performing a skill, or prefer performing a skill to moving

I mean - I can come up with something that makes sense to me, but it would quite possibly not make any sense at all in another context...


This is really the last big thing I've got left to do before I can make an alpha release - at the moment my to-do list for that looks something like:

- Finish off enemy AI (difficult)
- Better UIs for picking targets, positions etc. (time-consuming)
- Flesh out skills (easy)
- Example set-ups for each kind of battle (time-consuming)

[blakjak]

- An AI to target the strongest/healthiest/most powerful or the weakest ennemy.

- An AI to protect a defined party member ( like warriors protecting a warlock by occupying tiles between it and the player controlled party ).

I'll try to come up with some more if I can. =)

[Jake]

In the long run, I'd like to try and write a generic pluggable AI so people can mix and match behaviours, but for the moment I'm just trying to come up with a relatively-sensible default constant behaviour for moving that isn't too hard to code, so I can get the alpha out in a working state and concentrate on extra detail later. (Which isn't to say these aren't useful ideas - keep 'em coming by all means - just that I doubt I'll get that far in the near future.)

I'm leaning towards the framework user supplying a preferred-distance-from-enemy value to each AI fighter, and they'll move to the square which is nearest to the preferred distance to as many enemies as possible. So then your melee fighters can have that set to 0 and they'll charge in, the ranged fighters can have it set to (say) two-thirds their range, and the cowards/objectives can have it set to a large number and they'll constantly flee.

I'm still not sure what to do about prioritising moves compared to actions, though...

- An AI to target the strongest/healthiest/most powerful or the weakest ennemy.

(This has the extra complication that 'strongest' or 'most powerful' are pretty difficult metrics to quantify... it's probably more feasible to check a particular (configurable) stat all the time.)

[chronoluminaire]

Wow. This is looking seriously awesome. I love the modularity and generality you've designed into this.

I definitely agree the game designer might want to be able to specify whether an action can target only friendlies, only enemies, or any unit. Perhaps even a separate flag for itself, for some treatment-style skills that have to be used on a separate ally rather than the caster. Of course, by that point you're getting to where it just makes more sense to let people write a "legitimate target criterion" function and supply that - e.g. only allow Cure to target wounded allies.

3D height-mapping is indeed tricky to find a sensible design for. I loved UFO Enemy Unknown, but I wouldn't say it's the end of the world if you can't write it in this engine.

This engine's looking powerful and versatile enough that I'm thinking that as and when I get to writing my ren'ai tactics game (probably next year), which I had been thinking of doing as an exercise to get my Tile/Unit Engines into a usable state, I might well just use your engine instead.

[DaFool]

This engine's looking powerful and versatile enough that I'm thinking that as and when I get to writing my ren'ai tactics game (probably next year), which I had been thinking of doing as an exercise to get my Tile/Unit Engines into a usable state, I might well just use your engine instead.

Were you planning to overhaul your engine with ATL and other stuff? I was originally planning to sort of 'fake' the gameplay by lots of dialogue decision trees... (i.e. you almost defeat the enemy, reinforcements arrive, the enemy henchman goes on some spiel about obtaining some superpower)... I was hoping that utilizing many context-based mid-battle choices would mask the fact that I hadn't really thought too much about the actual battle system.

I think with rudimentary AI like "preferred distance from enemy" would basically be enough as long as there are enough context-triggered VN story events to explain the current tide of battle and any unexpected surprises, if any. All that's left would be setting different objectives to make each battle feel unique.

If Jake will concentrate more on one style (FF-style ATB) , that will leave someone else to expand upon the tactics-style implementation. If anyone tweaks the mechanics and UI further to make essentially a Disgaea clone (perhaps minus the ability to pick up characters and objects), then that would be exactly what I need.

[Jake]

I definitely agree the game designer might want to be able to specify whether an action can target only friendlies, only enemies, or any unit. Perhaps even a separate flag for itself, for some treatment-style skills that have to be used on a separate ally rather than the caster. Of course, by that point you're getting to where it just makes more sense to let people write a "legitimate target criterion" function and supply that - e.g. only allow Cure to target wounded allies.

You know, that might be a good idea too. What I currently have is a class called TargetData, which has a constructor something like this:

Code: Select all

    def __init__(self, fighters=False, positions=False, Factions=False, los=True ... )

and then a load of static methods for the 'obvious combinations' I thought of before, so you can do stuff like:

Code: Select all

    myTargets = TargetData.TargetFightersNoLos(range=5)

I'm a little concerned that it might be a bit too much like programming for novice users, but hopefully most skills can have their targetting data baked in one way or another anyway. (For example, the grid move skill that I have currently uses the fighter's 'Move' stat to tell it how far it can move, and depletes it as they progress, so it just has a GetTargets() method which returns a new instance of TargetData each time with the relevant range filled in, users wouldn't have to think about it.

This engine's looking powerful and versatile enough that I'm thinking that as and when I get to writing my ren'ai tactics game (probably next year), which I had been thinking of doing as an exercise to get my Tile/Unit Engines into a usable state, I might well just use your engine instead.

As it goes, it was your tile/unit engines which were a bit of an inspiration for going so far with this project in the first place! I also seem to recall some performance trouble you had with the number of displayables you were using at one point, which has helped inform the approach I'm taking for grids...

I was originally planning to sort of 'fake' the gameplay by lots of dialogue decision trees...

I basically started out with the same approach for Abraxas, but soon realised that actually, it would take about as long to do it 'properly', so I might as well.

If Jake will concentrate more on one style (FF-style ATB) , that will leave someone else to expand upon the tactics-style implementation.

To be honest, it's more likely to be the other way around - I'm more interested in the tactics style of battles than the FF style, on the whole. There should still be plenty of space for people to come up with their own style of games, though! The two goals I have with this project are to provide non-programmers with something that they can slot graphics into and make a few simple choices to introduce battles in a couple of varieties into their VN, and also to provide a framework which does all the generic stuff for people who want to write their own system, so they can concentrate on the unique mechanics of their system.

[number473]

I'm still not sure what to do about prioritising moves compared to actions, though...

What about setting an acceptable range from the character to be away from enemies. For example, a fighter would need to move provided there was no adjacent enemy. An archer would move if the enemy was out of range, or when an enemy got too close. So, when the acceptable range is violated, it would move instead of taking an action, and move to the set optimum distance.

[Jake]

What about setting an acceptable range from the character to be away from enemies.

This is something I'd considered - but I'd discarded it for the perhaps-not-ideal reason that it would add another two parameters (or a tuple, which is pretty much guaranteed to confuse non-python-programmers in most contexts) to the initialiser and thus made it seem more confusing to set up an enemy for AI. For the moment I'm trying the following rules:

- If moving is always an option (e.g. movement is 'free', you still get another action and it just uses up replenishing movement points) then move at the beginning of your turn

- while the fighter's turn isn't over
- - Select a skill to use and use it
- - if there's no skill available and moving isn't always an option, then move.
- - if there's no skill available and you can't move any more, then end the turn.

This is going to more-or-less work the same as an acceptable-range-band approach in a lot of cases, because the acceptable range band is likely to be set to a set of ranges in which the fighter can perform their skills (e.g. 2-3 squares for the Advance Wars artillery piece), so if the fighter's skills are available and have valid targets, it's likely that the fighter is already in that acceptable band and wouldn't move under either system.

[DaFool]

Will it be simple to convert battlefield value offsets to fractions of the width/height rather than absolute pixels? (This is to make the game more compatible with scaled screensizes).

[Jake]

Will it be simple to convert battlefield value offsets to fractions of the width/height rather than absolute pixels? (This is to make the game more compatible with scaled screensizes).

On one hand, I'm only ever feeding X and Y positions into xpos and ypos parameters to Transform, so theoretically if you just always specify decimals then decimals will always be passed to Transform and it'll largely be fine... it wouldn't be hard to add some extra checks to the few places where offsets are added to x/ypos.

But on the other hand, I was also under the impression from stuff PyTom's said that if you're talking about OpenGL Ren'Py running on alternative screen sizes, that should be handled by Ren'Py automatically... it's only if you're talking about randomly altering your config. widths and heights that you should ever have to worry about having fed absolute values anywhere anyway, and you'll also start to have trouble with all your art assets if you do stuff like that.