Battle Engine - Alpha 6 release, downloads in first post

Ideas and games that are not yet publicly in production. This forum also contains the pre-2012 archives of the Works in Progress forum.
Post Reply
Message
Author
Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Battle Engine - Alpha 6 release, downloads in first post

#1 Post by Jake »

ALPHA 7 RELEASE - 20120901 / NEW THREAD

I've now released Alpha 7, and started a new thread for Battle Engine stuff in a more appropriate subforum:

http://lemmasoft.renai.us/forums/viewto ... 51&t=16943

New features include tilemap-based battles, elevation and screens for RPG equipping, party-management and shopping!







[old post follows]

I've now released Alpha 6, which contains all the same stuff from alphas 1-5 - examples of active battles, path-based battles and three types of grid-based battles (isometric, orthogonal and hexes), configurable scenery, easy-to-customize game options, facing-dependent sprites, items, equipment, examples of customising skills and panning, and a 'WargameSchema' which emulates simple card-counter wargames, and adds experience, levelling up, a more useful multi-square scenery, a condition/result event system to build battle events and complex mission parameters, and many display improvements and bugfixes.


As mentioned in the accompanying notes: this is an alpha release, so it's definitely not feature-complete and there may well be bugs... also, it's quite possible that I'll change some of the interfaces before calling it final, so code written today may break later. I'll try not to break interfaces unnecessarily, but it might happen. It's recommended that you use 6.11.2 or later with this, as there are some bugs in earlier releases which make various parts of the battle engine not function properly.

Downloads

Alpha 6 - Zipped game directory[9.9MB]


ImageImageImageImageImageImage

A video of the nifty ActivePanner applied to the old iso grid demo can be found here:
http://www.youtube.com/watch?v=qFEdKxGaLX8

Old Alpha 5 downloads:
Alpha 5 - All[25MB]


Old Alpha 4 downloads:
Alpha 4 - All[25MB]

Old Alpha 3 downloads:
Alpha 3 [15MB]

Old Alpha 2 downloads:
Alpha 2 - All[21MB]

Old Alpha 1 downloads:
Windows [11MB]
Mac OSX [15MB]
Leinnucks [11MB]

Changes:

Alpha 6:
New things:
  • Experience and Levelling-Up (+demo).
  • Condition/Result event system, allowing more-complex mission parameters (+demo).
  • AreaScenery, allowing multi-square scenery with correct drawing (+demo).
  • Items in skill menus can now be re-ordered.
  • Added FighterStatChange event.
  • Added better implementation of GetRange for square-grid and hex-grid
    battlefields.
  • New battle-related preferences have been added.





    Caveats
    If you're moving code from Alpha 5 to Alpha 6, read the caveats section in this release newsletter.
    If you're moving code from Alpha 4 to Alpha 5, I made a small breaking change - and there's a couple of other things to consider:
    • If you make any calls to Fighter.Damage, a new parameter is required - this should be a Fighter instance to show who or what damaged this target. Pass None if not applicable.
    • UIProvider.PickFighter may now return None if 'End Turn' desired.
    • WargameSkill - enforced by the WargameSchema - doesn't really work for AI fighters, so that schema is only good for hotseat play right now. It probably really needs its own AI since the considerations are different.



Current Feature List
- 'Active' battle mechanic
- simple turn-based battle mechanic
- card-counter wargame battle mechanic
- FF-style simple face-to-face battlefields
- Abraxas-demo-style fixed-path battlefields
- Tactics-style Grid-based battlefields
- Hex-grid battlefields
- Basic enemy AI
- State-and-facing-aware sprites (so you can have death animations or attack animations or walk in particular directions, etc.)
- Plug-in skills (so far I've done obvious stuff like 'attack', 'defend', 'skip turn', 'move' and limited magic)
- Scenery (single and multi-square)
- Attribute system (e.g. an enemy can have the 'fire' attribute, which makes them weaker to attacks using the 'water' attribute)
- Highly customisable (pick-and-mix to a degree for non-programmers; very open to customisation and extension for programmers)
- Items, Inventory and usage
- Equipment and equip limits
- Panning
- Hex grids
- Experience and levelling
- Condition/result event/mission parameter system

Planned Future Features (not going to make it into alpha release)
- Variable-movement-cost positions, so it can be harder to move through marsh than on a road, for example
- Custom UIs for each type of battle
- More skills and extras
- Documentation (!)
Last edited by Jake on Sat Sep 01, 2012 8:58 pm, edited 16 times in total.
Server error: user 'Jake' not found

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Battle Engine

#2 Post by Jake »

EDIT: This example is pretty old, and some things have changed. It should be just as easy today as it was when I wrote this post, but some details are different (and the screenshots should be prettier ;-) - please refer to the latest demo download for example code rather than trying to copy this.

Here's an example of a fairly default FF-style battle. This is literally copy/pasted from my test scripts, so it's the way the framework's working right now; there are some small changes I want to make still, to make it a little easier, but this is the basic model. This is all python code, by the way.

To create each of your fighters, you'll need to write code like this:

Code: Select all

        # First, create the skills you're going to use:
        attack = AttackSkill()
        skip = SkipSkill()
        # Here we create several versions of the 'fire' spell with different names, strengths, MP costs and targetting options
        fire1 = FireballSkill("Fireball", 2, 5, 1)
        fire2 = FireballSkill("Comet", 5, 10, 1)
        fire3 = FireballSkill("Inferno", 2, 10, 5)

        # Next, create each person and assign their skills:
        bobSprite = BattleSprite(im.Image("battle/bob.png"))
        bob = PlayerFighter("Bob", Speed=7, Attack=10, sprite=bobSprite)
        bob.RegisterSkill(attack)
        bob.RegisterSkill(skip)

        geoffSprite = BattleSprite(im.Image("battle/geoff.png"))
        geoff = PlayerFighter("Geoff", Speed=14, Defence=5, sprite=geoffSprite)
        geoff.RegisterSkill(attack)
        geoff.RegisterSkill(fire1)
        geoff.RegisterSkill(fire2)
        geoff.RegisterSkill(fire3)
        geoff.RegisterSkill(skip)
Only a couple of stats are defined for each fighter - the skills you add to a fighter can register their own stats and set a reasonable default for them. I've given them both the 'attack' skill, which registers an 'Attack' stat with a default value, but in Bob's case I'm overriding that and setting his Attack to 10. If I didn't bother to set any stats when I created the fighter, it would still work fine and do all the things it could normally do because its skills would give it any necessary stats.

These fighter classes aren't tied to any specific battle, so you can create them at the start of your game and use the same instances throughout if you want health levels and so on persist from one battle to the next.

To start an actual fight, we'll need to create a 'Battle' instance, which defines the rules by which the battle takes place:

Code: Select all

        battle = Battle(ActiveSchema())
For this battle we're using 'ActiveSchema', which informs the battle framework about all the rules and mechanics of an 'Active' battle; this is basically something like you see in earlier FF games. Each fighter has an 'initiative' guage which fills up slowly as time progresses, and once it's full they get to take an action. Once they act, their guage is emptied and it has to fill up again before they can do anything again.

Next, we create a battlefield for the fight to take place on:

Code: Select all

        battlefieldSprite = BattlefieldSprite(im.image('battle/forest_battlefield.jpg'))
        battlefield = SimpleBattlefield(battlefieldSprite)
A 'SimpleBattlefield' is the classic FF-style two-parties-line-up-against-each-other layout. There's no worry about positioning and everyone can attack everyone, so it's the simplest option there is.

Next, we need to add our fighters to the battlefield:

Code: Select all

        battle.AddFaction("Player")
        battle.AddFighter(bob)
        battle.AddFighter(geoff)
        
        battle.AddFaction("Enemy")
        battle.AddFighter(steve)
        battle.AddFighter(jim)
Lastly, we'll add a few extra bits which modify the way the battle behaves or looks:

Code: Select all

        # RPGDamage means a little number bounces out of a fighter when he gets damaged
        battle.AddExtra(RPGDamage())
        # RPGDeath means a fighter fades out from the battlefield when they die
        battle.AddExtra(RPGDeath())
        # SimpleWinCondition means that the battle is won by the first faction to wipe out their opponents
        battle.AddExtra(SimpleWinCondition())
        # RPGActionBob means that when a fighter does something, they bob once up and down.
        battle.AddExtra(RPGActionBob())
        # ActiveDisplay shows a stats line for the specified faction - the dictionary says which stats to show on the stats line, and what to label them.
        battle.AddExtra(ActiveDisplay("Player", {"HP": "Health", "Move": "Move", "MP": "MP"}))
        # CurrentFighterPointer makes a little pointer appear over the fighter whose turn it is. 75 pixels above them, here.
        battle.AddExtra(CurrentFighterPointer(im.Image("battle/pointer.png"), (0, -75)))
Lastly, we kick off the battle so it starts now:

Code: Select all

        battle.Start()
        
        winner = battle.Won
Here's what that battle will look like:
Example FF-style battle
Example FF-style battle
Once the battle is over, the 'winner' variable gets set to the name of the faction that won, this can then be used to tell the player who won or show a 'game over' screen or whatever.

Now, I know that's a lot of lines of code, but honestly I think all those things need to be specified, and a lot of them (e.g. setting up your fighters) only need to be specified once, so it's not too bad.

The neat bit is that you don't have to do much more than that to have a battle with a different set of mechanics - for example, if you want to switch to a tactics-style game on a grid, you just need to change these lines:

Code: Select all

        battle = Battle(ActiveSchema())

        battlefieldSprite = BattlefieldSprite(im.image('battle/forest_battlefield.jpg'))
        battlefield = SimpleBattlefield(battlefieldSprite)
into these lines:

Code: Select all

        battle = Battle(SimpleTurnSchema())

        battlefieldSprite = BattlefieldSprite(im.image('battle/forest_battlefield_grid.jpg'))
        battlefield = GridBattlefield(battlefieldSprite, (400, 350), (4, 4), (100, -50), offsets=(-100,-50), diagonals=True)
The 'SimpleTurnSchema' tells the battle how to operate the game allowing each player to chose the order in which to use his fighters, and give him one turn with each one before it's the other faction's turn.
The GridBattlefield lays out the grid on which the battle takes place. The extra parameters are: the position on the screen of the first square of the grid (400 pixels from the left, 350 from the top); the grid size of the battlefield (4 by 4 squares); the 'size' of an individual square (100 pixels wide and -50 pixels tall - that is, higher gridlines are drawn further up the screen rather than down the screen); the 'offsets' for each square (in this case set up to an isometric-style grid (e.g. most tactics RPGs, Disgaea etc.) rather than an axis-aligned grid (e.g. Advance Wars), and opting to allow travel along diagonals. (If anyone has a better way to specify that, particularly the offset, I'd love to hear it.)

When you add fighters to such a battlefield, you also need to specify their position:

Code: Select all

        battle.AddFighter(bob, position=(0, 3))
That'll get you something more like this:
Grid battle
Grid battle
Choosing where to move
Choosing where to move
Last edited by Jake on Tue Nov 02, 2010 9:30 pm, edited 3 times in total.
Server error: user 'Jake' not found

IceD
Veteran
Posts: 433
Joined: Sun Feb 01, 2009 6:15 pm
Contact:

Re: Battle Engine

#3 Post by IceD »

Holy friggin... This looks great! Too bad I'm at work, but I'll definately give it a look when I'll get back home :)

Chansel
Veteran
Posts: 249
Joined: Sat May 01, 2010 6:11 pm
Projects: School's Out! -- A GxB or GxG VN/Dating Sim
Location: The Netherlands, Noord-Brabant
Contact:

Re: Battle Engine

#4 Post by Chansel »

My god, this looks amazing :O I'm sure you're going to make a lot of people very happy with this!
Image ~ A GxB or GxG Visual Novel/Dating Sim

User avatar
azureXtwilight
Megane Procrastinator
Posts: 4118
Joined: Fri Mar 28, 2008 4:54 am
Completed: Fantasia series (ROT and ROTA), Doppleganger: Dawn of The Inverted Soul, a2 (a due), Time Labyrinth
Projects: At Regime's End
Organization: Memento-Mori VNs, Team Sleepyhead
Location: Yogyakarta, Indonesia.
Contact:

Re: Battle Engine

#5 Post by azureXtwilight »

This is awesome! You're the best, Jake! I'm sure many people will use this!
Image

Tsundere Lightning
Miko-Class Veteran
Posts: 910
Joined: Sun Jul 06, 2008 4:30 pm
Projects: And plenty of them!
Location: Creche Alpha, Treasure Island
Contact:

Re: Battle Engine

#6 Post by Tsundere Lightning »

Holy crap. I think we have a Super Renpy Wars engine, at least.

What's the deal with using this? Is it CC Attribution Share-Alike?
She's sun and rain: She's fire and ice. A little crazy, but it's nice.
Bliss Stage: Love is your weapon! A sci-fi visual novel about child soldiers coming of age. Kickstarter prerelease here. WIP thread here. Original tabletop game by Ben Lehman here. Tumblr here.

blakjak
Veteran
Posts: 224
Joined: Fri Dec 21, 2007 2:36 pm
Location: France
Contact:

Re: Battle Engine

#7 Post by blakjak »

Looking great !

About features or game mechanics for the :
- Tactics-style Grid-based battlefields
I have ideas but they are also questions because I'm not quite sure of what it is possible to do with your engine yet.

Could there be a tile highlight system that shows on which tile you can move a character to ?

Are you going to be able to have different states for a sprite walking to an upper tile, side and bottom one ?

Will you have a system that enables the player to choose the direction the sprite faces after moving to a new tile, like if it has it's back to an enemy it will be more vulnerable ?

Can the sprites move over several tiles at a time ?

About Zdepth, let's say I want the tree to be on top of the player sprite if it moves next to it, in your isometric grid example, I guess I would need a separate sprite for the tree, but what if I have the player sprite going in front of the tree, does the engine handle this type of Zdepth sorting ?

Could you have some tiles that would have specific attributes that would influence the characters ? Like a mud tile that would slow movement ?

edit : Do weapons and magic have range ? Can they score a hit across several tiles ?

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Battle Engine

#8 Post by Jake »

Tsundere Lightning wrote:Is it CC Attribution Share-Alike?
Absolutely not, because I dislike GPL-style licenses that force others to adopt your preference of license for their whole project.

It's likely to be either CC-NC or CC-BY.
blakjak wrote: Could there be a tile highlight system that shows on which tile you can move a character to ?
Yes, at least with a small amount of work. I'll try and include an example which does this, since it's a pretty good idea.

The 'easy' version would be that if you see the "choosing somewhere to move to" screenshot, this uses buttons which are placed with an xpos and ypos of the screen positions of the valid grid positions to move to. So it would be quite possible to just re-style those buttons to have a background of a highlighted tile.

The not-so-easy version is that the framework is fairly loosely coupled, so you could just replace the default UIProvider with one specifically written for grid-based games (and this is the thing I'll try to include an example of) which would allow you to just completely re-work how position selection was done whichever way you wanted.
blakjak wrote: Are you going to be able to have different states for a sprite walking to an upper tile, side and bottom one ?
It's certainly on my to-do list, yes. Again, it'd be possible for someone writing against the framework to provide their own, more-game-specific implementation, but I plan to eventually include one which resolves any movement to eight-way movement, so 'normal' grids will have perfectly-aligned character movements.
blakjak wrote: Will you have a system that enables the player to choose the direction the sprite faces after moving to a new tile, like if it has it's back to an enemy it will be more vulnerable ?
This is something I was considering just the other day - it's certainly possible within the confines of the framework, but I'm not sure of the best way to do it yet.
blakjak wrote: Can the sprites move over several tiles at a time ?
Yes. If you check the example pictures, in one you'll note that the moving character has "1/3 MP"; immediately before taking that screenshot I'd selected him and moved him from the bottom-most tile to the one he presently occupies in one move.
blakjak wrote: About Zdepth, let's say I want the tree to be on top of the player sprite if it moves next to it, in your isometric grid example, I guess I would need a separate sprite for the tree, but what if I have the player sprite going in front of the tree, does the engine handle this type of Zdepth sorting ?
This is a two-part thing... I'm planning on doing the majority of Z-depth stuff like that simply by using layered backgrounds... so you'd have one BG image which was the default battlefield without the tree, and one with only the tree and other foreground elements on the same 'layer', and any given grid position would be either in front of or behind the tree. So when the battlefield gets drawn, the background layer gets drawn, then fighters in grid positions behind the tree, then the tree layer, then fighters in front of the tree layer. At least, that's the plan - it's something I've not implemented yet.

On the other hand, while I should have this static positioning/Z fixed by the time I release the alpha, there's a limitation in Ren'Py that means you presently can't transition a sprite from one Z value to another Z value in - say - a Move transition using ATL Transitions, which means that (for example) when a guy moves from behind the tree to in front of the tree in one go, we'll have to either draw him in front of the tree and other fighters he passes for the whole movement, popping up to his new Z at the beginning of movement... or have him keep his old Z, staying behind the tree and other fighters he passes until he finishes his movement. PyTom suggested he'd be amenable to making the required change at some point, but it's too much work for him to get it done quickly.
blakjak wrote: Could you have some tiles that would have specific attributes that would influence the characters ? Like a mud tile that would slow movement ?
It's certainly theoretically possible - I'll add it to my list.
blakjak wrote: edit : Do weapons and magic have range ? Can they score a hit across several tiles ?
Skills of all kinds (weapons and magic included) can be targetted to fighters, positions or whole factions, and have a targetting range - once the target position/fighter has been chosen it's up to the skill code to determine what happens next, so yes - it's perfectly possible to have a skill which will affect a three-tile radius, for example.

It would be much trickier to have the select-a-target-spot show the affected radius on hover, on the other hand. I wouldn't like to say impossible, but trickier.
Server error: user 'Jake' not found

User avatar
azureXtwilight
Megane Procrastinator
Posts: 4118
Joined: Fri Mar 28, 2008 4:54 am
Completed: Fantasia series (ROT and ROTA), Doppleganger: Dawn of The Inverted Soul, a2 (a due), Time Labyrinth
Projects: At Regime's End
Organization: Memento-Mori VNs, Team Sleepyhead
Location: Yogyakarta, Indonesia.
Contact:

Re: Battle Engine

#9 Post by azureXtwilight »

Jake wrote:Here's an example of a fairly default FF-style battle. This is literally copy/pasted from my test scripts, so it's the way the framework's working right now; there are some small changes I want to make still, to make it a little easier, but this is the basic model. This is all python code, by the way.

To create each of your fighters, you'll need to write code like this:

Code: Select all

        # First, create the skills you're going to use:
        attack = AttackSkill()
        skip = SkipSkill()
        # Here we create several versions of the 'fire' spell with different names, strengths, ranges and targetting options
        fire1 = FireballSkill("Fireball", 2, 5, 1)
        fire2 = FireballSkill("Comet", 5, 10, 1)
        fire3 = FireballSkill("Inferno", 2, 10, 5)

        # Next, create each person and assign their skills:
        bobSprite = BattleSprite(im.Image("battle/bob.png"))
        bob = PlayerFighter("Bob", Speed=7, Attack=10, sprite=bobSprite)
        bob.RegisterSkill(attack)
        bob.RegisterSkill(skip)

        geoffSprite = BattleSprite(im.Image("battle/bob.png"))
        geoff = PlayerFighter("Geoff", Speed=14, Defence=5, sprite=geoffSprite)
        geoff.RegisterSkill(attack)
        geoff.RegisterSkill(fire1)
        geoff.RegisterSkill(fire2)
        geoff.RegisterSkill(fire3)
        geoff.RegisterSkill(skip)
Only a couple of stats are defined for each fighter - the skills you add to a fighter can register their own stats and set a reasonable default for them. I've given them both the 'attack' skill, which registers an 'Attack' stat with a default value, but in Bob's case I'm overriding that and setting his Attack to 10. If I didn't bother to set any stats when I created the fighter, it would still work fine and do all the things it could normally do because its skills would give it any necessary stats.
Just wondering, what does the numbers 2,5,1 mean? And how do I define the MPs of each character?
Image

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Battle Engine

#10 Post by Jake »

azureXtwilight wrote: Just wondering, what does the numbers 2,5,1 mean?
It's the stats for each individual fire-based spell. So 'Fireball' has 2, 5 and 1 meaning it has a strength of 2, a cost of 5 MP (sorry, the comment above it is wrong; I'll correct it) and targets 1 person. 'Inferno' has 2, 10, 5 because it has a strength of 2, cost of 10MP and targets everyone on the opposing side.

The targeting options aren't so obvious, but aside from using words instead of number I'm not sure what to do about it. Basically the values are currrently as follows:

0 - doesn't need a target
1 - targets a single fighter, requires line-of-sight
2 - targets a position, doesn't require LoS
3 - targets a single fighter, doesn't require LoS
4 - targets a position, requires LoS
5 - targets a whole faction

(This list may change before alpha release, although obviously once I've made a release I'll keep it as backwards-compatible as possible. If anyone can think of any extra options I might not have thought of, that would be nice, too. Specifically targeting, though - as I said earlier, if you want to target an area, you can just target a position and have the effect over an area around that position, for example.)
azureXtwilight wrote: And how do I define the MPs of each character?
In the screenshots, you'll see that Geoff has an MP total of 10 - that's the default that the spells skills impart. If you wanted to give a character a different number of MP, you'd just pass it in as a parameter when you create the character, along with all the other stats, something like:

Code: Select all

        geoff = PlayerFighter("Geoff", Speed=14, Defence=5, MP=25, sprite=geoffSprite)
You can add as many stats as you like in the parameter list, anything that the framework doesn't recognise as an option it knows about (e.g. 'sprite') it will assume is a stat.
Server error: user 'Jake' not found

User avatar
azureXtwilight
Megane Procrastinator
Posts: 4118
Joined: Fri Mar 28, 2008 4:54 am
Completed: Fantasia series (ROT and ROTA), Doppleganger: Dawn of The Inverted Soul, a2 (a due), Time Labyrinth
Projects: At Regime's End
Organization: Memento-Mori VNs, Team Sleepyhead
Location: Yogyakarta, Indonesia.
Contact:

Re: Battle Engine

#11 Post by azureXtwilight »

Does the line of sight only matters at the strategy-like battles?
And what if we want to start a new battle with different characters later in the game? Do we have to reassign the members?
Image

Jake
Support Hero
Posts: 3826
Joined: Sat Jun 17, 2006 7:28 pm
Contact:

Re: Battle Engine

#12 Post by Jake »

azureXtwilight wrote:Does the line of sight only matters at the strategy-like battles?
Yeah - some types of battle, like the FF-style one in the first example, don't use Line-of-Sight at all; specifically, the system presumes that everyone always has line of sight to everyone else.
azureXtwilight wrote:And what if we want to start a new battle with different characters later in the game? Do we have to reassign the members?
You can keep the Fighter definitions, but you should ideally start a new Battle instance (the second chunk of example code onwards) for each battle - so yes, you'd need to set up the factions and assign fighters once for each battle in your game.
Server error: user 'Jake' not found

Kyosuko
Newbie
Posts: 16
Joined: Mon Apr 12, 2010 1:14 am
Projects: Red Thread(GXB)
Location: at my room in front of my laptop
Contact:

Re: Battle Engine

#13 Post by Kyosuko »

I would have like to use this...but probably when i become more pro on programming.

Nice engine btw. XD

User avatar
DaFool
Lemma-Class Veteran
Posts: 4171
Joined: Tue Aug 01, 2006 12:39 pm
Contact:

Re: Battle Engine

#14 Post by DaFool »

I am still looking forward to your release; however I have super-simplified the mechanics to my particular intended application that it can be done by just imagemaps governed by a super state-machine (just like my previous games... games which don't crash by the way :) It might still take a while for me to get over the 'designed to fit within 10 megabytes from the ground-up' mindset, even though I now have fast broadband like everyone else. When you have the alpha done it's going to be serious time between it, the Tile/Unit engine, and my flowcharts.

blakjak
Veteran
Posts: 224
Joined: Fri Dec 21, 2007 2:36 pm
Location: France
Contact:

Re: Battle Engine

#15 Post by blakjak »

The not-so-easy version is that the framework is fairly loosely coupled, so you could just replace the default UIProvider with one specifically written for grid-based games (and this is the thing I'll try to include an example of) which would allow you to just completely re-work how position selection was done whichever way you wanted
This is very sweet.
It's certainly on my to-do list, yes. Again, it'd be possible for someone writing against the framework to provide their own, more-game-specific implementation, but I plan to eventually include one which resolves any movement to eight-way movement, so 'normal' grids will have perfectly-aligned character movements.
Ha great !
blakjak wrote: Will you have a system that enables the player to choose the direction the sprite faces after moving to a new tile, like if it has it's back to an enemy it will be more vulnerable ?
This is something I was considering just the other day - it's certainly possible within the confines of the framework, but I'm not sure of the best way to do it yet.
Happy to know you're at least considering it.
Yes. If you check the example pictures, in one you'll note that the moving character has "1/3 MP"; immediately before taking that screenshot I'd selected him and moved him from the bottom-most tile to the one he presently occupies in one move.
Ha great again !
This is a two-part thing... I'm planning on doing the majority of Z-depth stuff like that simply by using layered backgrounds... so you'd have one BG image which was the default battlefield without the tree, and one with only the tree and other foreground elements on the same 'layer', and any given grid position would be either in front of or behind the tree. So when the battlefield gets drawn, the background layer gets drawn, then fighters in grid positions behind the tree, then the tree layer, then fighters in front of the tree layer. At least, that's the plan - it's something I've not implemented yet.

On the other hand, while I should have this static positioning/Z fixed by the time I release the alpha, there's a limitation in Ren'Py that means you presently can't transition a sprite from one Z value to another Z value in - say - a Move transition using ATL Transitions, which means that (for example) when a guy moves from behind the tree to in front of the tree in one go, we'll have to either draw him in front of the tree and other fighters he passes for the whole movement, popping up to his new Z at the beginning of movement... or have him keep his old Z, staying behind the tree and other fighters he passes until he finishes his movement. PyTom suggested he'd be amenable to making the required change at some point, but it's too much work for him to get it done quickly.
Well yeah, Z order transitions is something that is very tricky, which ever game engine is used. Especially in isometric view. I've read the Z-depth issues you are going through. Having the sprites pop-up at the start or end of their movement is not great, but hell, at least they can be moved along their Z axis, more than I could ever achieve by myself.
blakjak wrote: Could you have some tiles that would have specific attributes that would influence the characters ? Like a mud tile that would slow movement ?
It's certainly theoretically possible - I'll add it to my list.
Cool.

Skills of all kinds (weapons and magic included) can be targetted to fighters, positions or whole factions, and have a targetting range - once the target position/fighter has been chosen it's up to the skill code to determine what happens next, so yes - it's perfectly possible to have a skill which will affect a three-tile radius, for example.

It would be much trickier to have the select-a-target-spot show the affected radius on hover, on the other hand. I wouldn't like to say impossible, but trickier.

The possibility to show affected radius sure would be a nice plus, but as long as grenades or bows can be used on the map, I'm happy.

I've got a few more questions :

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 ?

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 ?

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 ?
The targeting options aren't so obvious, but aside from using words instead of number I'm not sure what to do about it. Basically the values are currrently as follows:

0 - doesn't need a target
1 - targets a single fighter, requires line-of-sight
2 - targets a position, doesn't require LoS
3 - targets a single fighter, doesn't require LoS
4 - targets a position, requires LoS
5 - targets a whole faction
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[/quote]

Good luck !

Post Reply

Who is online

Users browsing this forum: No registered users