RPG Battle Engine - Alpha 7.5, downloads in first post

[azureXtwilight]

Another quick question:

- About the special skills, like charm, how do I make it such that it only stays in a few turns? (also for the temporary stat-raising skills you told me a few posts ago)
- The events, you mentioned that I should use layers to show the images if I want to put conditional events. How do I do that?

Thank you very much

[Jake]

Xela: You're welcome. ;-)

- About the special skills, like charm, how do I make it such that it only stays in a few turns? (also for the temporary stat-raising skills you told me a few posts ago)

For this, you'll need to use an 'Effect' - you can find some examples of Effects at the end of the engine-extras.rpy file.

An Effect is a class which gets attached to a fighter temporarily because they have some effect affecting them. So for example, the last class in that file is HasteEffect, which modifies their speed to be twice as quick for the duration of the effect... but the effect could simply be "I have been charmed and after so many turns it's going to wear off and set me back to my original faction".

The HasteEffect class doesn't wear off after a number of turns, so here's a quick example of how you would do that - replace the HasteEffect class in that file with this one (I'll keep this changed version in the next release, since it's a better example):

Code: Select all

    class HasteEffect(Effect):
        
        def __init__(self, fighter):
            # Do the default setup for an effect
            super(HasteEffect, self).__init__(fighter)
            
            # set up a starting turn-count for the haste effect to last
            self._turns = 2
            self._name = "Haste"
        
        def FighterStartTurn(self, fighter):
            
            # count down one turn at the beginning of every turn this fighter takes under this effect
            if (fighter == self._fighter and self._turns > 0):
                self._turns = self._turns - 1
            
        def FighterEndTurn(self, fighter):
            
            # If we've run out of turns, remove the effect so haste no longer applies
            if (fighter == self._fighter and self._turns == 0):
                fighter.RemoveEffect("Haste")
                _battle.Announce("Haste wears off for " + fighter.Name)
                self._turns = -1
                        
        def OnRetrieveStat(self, name, value):
            if name == 'Speed':
                return value * 2
            else:
                return value
                
        def OnSetStat(self, name, value):
            if name == 'Speed':
                return int(value / 2)
            else:
                return value

Key changes:

• In the __init__ method we choose a number of (subjective) turns that the effect will last for: I've gone for 2 simply because it's easier to test, but you probably want a higher number in practice!
• Also in the __init__ method we have to give the effect a name - otherwise we won't be able to selectively remove it later!
• In the FighterStartTurn and FighterEndTurn methods we check if we're looking at the right fighter. This is because these methods actually get called every time any fighter starts or ends a turn, in case the Effect needs to do anything at that time... but in this case, we're only interested in a very specific fighter, which is the one this effect is applied to (self._fighter - set in the base class' initialiser).
• In FighterStartTurn we decrease the number of turns remaining until the effect wears off
• In FighterEndTurn we check whether it should have worn off by now, and if it has, remove the effect from this fighter.

If you want to have charm wear off after a number of turns, then you'll need to look at the charm skill to see how it changes the fighter's faction. Create a new effect which simply sets the fighter's faction back to the original when the timer wears off, and create that effect on the target fighter at the same time as the skill is created. (You'll probably need to take a note of their original faction when the Effect is first created, so you have the correct faction to go back to!)

Let me know if you have trouble with that, and I can provide a quick example.

- The events, you mentioned that I should use layers to show the images if I want to put conditional events. How do I do that?

This is a Ren'Py thing - there's a variable called config.layers which contains a list of all the named layers - just like in a Photoshop document, Ren'Py displays things in a layer later in that list over the top of things in a layer earlier in that list.

IIRC everything by default gets shown into 'master', and dialogue text and user-interface stuff gets shown in 'transient'. The battle engine inserts a load of extra layers in between 'master' and 'transient' and shows things on its special battle-engine layers, so as to not interfere with the stuff your game has shown on 'master'... but it does mean that you can't see stuff on the 'master' layer while a battle is in progress. (Dialogue still shows OK because it's in 'transient', which is above the battle engine layers.)
So to display graphics during a battle, it's best to create a new layer above the battle engine layers, or display your graphics into 'overlay' or something. You can create a new layer by altering the list in that config variable, and show graphics on it in Ren'Py script using the 'on' keyword:

Code: Select all

    # Show an image on a user-defined layer.
    show moon on user_layer

If you need to show the graphic in code, then you simply pass a 'layer' parameter to renpy.show:

Code: Select all

    renpy.show('moon', layer='user_layer')

(EDIT: Fixed a small issue with the HasteEffect class in the fighter-turn-end method - probably worth taking it again if you're using it.)

[Jake]

I'm nearly done with the next-ish release - it'll be more of a 7.5 than an 8 or a beta-1, 'cause it's mostly extending stuff and fixing things. For example, the elevation version of hex maps is included, and there's a load of bug fixes from things people have raised with me over the last couple of months.

One new feature, however:



Rotation is now mostly-working for both square- and hex-grid elevation maps. Note that there's also the option for alternate versions of tiles for different rotations - the path still lines up when rotated because an alternate version with the path running a different direction is used; most of the tiles are exactly the same tile under each rotation.

It comes with some caveats, mostly due to Ren'Py limitations. For example, panning can be done at any time because moving displayables from one place to another can be done by a transform function... but you can only rotate when there's a UI up to do it, because rotating the screen means changing the z-order of displayables, and that's not possible in a transform function (and apparently never will be). Presently, rotation centres the camera on the current fighter, because while all the code is there to rotate around whatever part of the screen the camera's currently looking at, the minor fact that floating point numbers are utterly horrible seems to mean that after a few rotations, the camera starts drifting from the point it should be looking at. PyTom's agreed to put the decimal module into Ren'Py at some point so we can use fixed-point calculations and I'm hoping this will fix the problems, but it's not there yet.

[Jake]

I've released 7.5 - downloads are in the first post, or on my website.

The big new features are - as I mentioned three months ago when I said it would only take a couple of weeks - elevation tilemap support for hex grids, and rotation of both iso and hex grid tilemap battlefields. Sorry it took so long - I encountered a couple of problems that stopped me doing things the way I wanted to, and then spent far too long trying to do them anyway instead of just shrugging, limiting the functionality to just the working part and moving on. The main limitations people will notice are:

- Unlike panning, you can only rotate while the engine is waiting for user input; this is because it's not possible to change the z-order of a displayable in a transform function.
- When rotating, the camera recentres on the current fighter; I had wanted to be able to rotate around whatever point the camera was currently looking at, but there's some problems (probably caused by floating point numbers being rubbish) causing the camera to drift ever further from the origin, meaning that after a few rotations you may not be able to find your way back! So it's locked to the current fighter, to avoid that happening.



Now, unless anyone has any really pressing feature requests or bug reports, I'm finally going to get back to working on writing Ren'Py script extensions for setting up and starting battles - it's been long enough since I started on that!

[azureXtwilight]

Thanks! I manage to make a separate user layer and have it shown also used the haste effect, but I still don't understand how the charm effect should work. I tried to incorporate it like the haste effect but I keep crashing so I returned the values back to how it used to be.

Also, congratulations on the new release! *downloads*

[Jake]

I still don't understand how the charm effect should work. I tried to incorporate it like the haste effect but I keep crashing so I returned the values back to how it used to be.

Sorry, I meant to make the same changes to the charm skill as well, in 7.5 - I even scanned through this thread looking for things I might have missed and missed it!

Anyway, here's a fixed-up version which has the effect wearing off - instance the skill with CharmSkill() to accept the default of 2 turns, or CharmSkill(turns=5) to change it to 5 or whatever.

Code: Select all

    # Next we'll add a skill to entice opposition fighters to join your side.
    class CharmSkill(Skill):
        
        def __init__(self, turns=2):
            
            skillName = "Charm"
            # This time it'll just be a top-level skill item, on the first menu. If that's the case, you
            # don't have to specify a command, and it'll just use the skill name that you pass in.
            
            # A range of 1, so you have to go right up to them to do it, and only targetting live enemy fighters.
            self._targets = TargetData(fighters=True, positions=False, factions=False, los=True, friendly=False, enemy=True, live=True, dead=False, range=1, fightersImpede=True)
            
            # The number of turns the charm effect works for
            self._turns = turns
            
            # Calling through the base __init__ again:
            super(CharmSkill, self).__init__(name=skillName)
    
        def SetUpFighter(self, fighter):
            fighter.RegisterStat("Charisma", 99)
            
        # In this case, we're talking about a built-in always-available skill, so we always return 'True' here.
        def IsAvailable(self, fighter):
            
            return True
                
        def PerformAction(self, fighter, target):
            
            # First, check a percentage against the fighter's Charisma:
            score = renpy.random.random()* 100
            if score <= fighter.Stats.Charisma:
                # get the target fighter
                t = target[0]
                
                # We register a fighter's original faction as a stat, so it happens once and there's no
                # possibility of multiple charms getting confused about which faction to revert them to.
                # (The parameter to OriginalFaction is used as a default only if there's not a stat with
                # that name already registered.)
                t.RegisterStat("OriginalFaction", t.Faction)
                
                # Add the CharmEffect to keep track of the charm and revert back to his original faction when it expires
                t.AddEffect("Charm", CharmEffect(t, self._turns))
                
                # Change his faction to the faction of the skill user
                t._battle.ChangeFaction(t, fighter.Faction)
                
                # At this point you may want to throw up shiny graphics, but for now we'll just announce the success:
                t._battle.Announce(t.Name + " was charmed.")
            else:
                t._battle.Announce(fighter.Name + " failed to charm.")
                
            fighter.EndTurn()
            
    # The CharmEffect effect is applied to the target fighter. You may wish to add a show method - see CurrentFighterPointerEffect
    # for an example of how to do this - to show a visual cue, but it's mostly there to keep track of the number of turns the
    # charm has been in place for and revert the fighter to his original faction once those turns have expired.
    class CharmEffect(Effect):
        
        def __init__(self, fighter, turns=2):
            # Do the default setup for an effect
            super(CharmEffect, self).__init__(fighter)
            
            # set up a starting turn-count for the charm effect to last
            self._turns = turns
            self._name = "Charm"
        
        def FighterStartTurn(self, fighter):
            
            # count down one turn at the beginning of every turn this fighter takes under this effect
            if (fighter == self._fighter and self._turns > 0):
                self._turns = self._turns - 1
            
        def FighterEndTurn(self, fighter):
            
            # If we've run out of turns, remove the effect so charm no longer applies
            if (fighter == self._fighter and self._turns == 0):
                fighter.RemoveEffect("Charm")
                
                # Revert to the original faction again
                # We'll go direct to RawStats because it's a string stat, and we don't want to
                # risk any equipment or effects modifying the value
                fighter._battle.ChangeFaction(fighter, fighter.RawStats.OriginalFaction)
                
                _battle.Announce("Charm wears off for " + fighter.Name)
                self._turns = -1

(You may wish to modify the default Charisma so that it's not almost certain that people get charmed, of course...!)

[CaseyLoufek]

This looks great. I was able to plop my stuff over quite easily. I had practically no problems going over to your hex grid. The only slight issue I had was implementing the new equip screen, since I don't actually have an Attack stat it complained. I just made a new version with the right values for my system and it looks great.

[CaseyLoufek]

So I'm writing a summon skill based on Charm and I'm getting a very weird error.

The summon works perfectly except that I can only see one of them at a time. Their stats track seperate but the last one to move is the only one visible.

Code: Select all

        class MarineDrop(Skill):
            
            def __init__(self, name="MarineDrop", command=None, hotkey='t', weight=0, endTurn=False):
                
                self._targets = TargetData.TargetPositionsLos(range=20)
                self._endTurn = endTurn
    
                if command==None:
                    command=[("Magic", 5), (name,0)]
    
                super(MarineDrop, self).__init__(name=name, command=command, hotkey=hotkey, weight=weight)
                
            def PerformAction(self, fighter, target):
                p = target[0]
                self.summoned = copy.deepcopy(marine2)
                fighter._battle.AddFighter(self.summoned, x=p.X, y=p.Y)
                self.summoned._battle.ChangeFaction(self.summoned, fighter.Faction)
                
                if (self._endTurn):
                    fighter.EndTurn()
                    

I'm trying to use deepcopy to make a unique copy. Generating copies is a weakness of the system so far but I've been able to do this with no issue if I do it before combat begins. Other stats are tracking seperate but when I use this in a skill it seems to think there's one sprite between them all.

[Jake]

The summon works perfectly except that I can only see one of them at a time.

Hah! Congratulations, that's probably the most obscure bug I've ever had reported on this project!



The problem is that each fighter is given a tag (with the 'SetTag(str)' method), which is always used as the tag passed to renpy.show() to display that fighter. (In case you're unaware: when showing, Ren'Py will replace an existing Displayable with the same tag if one exists on the screen.)

When a fighter is added to a faction in the first place, the system constructs a new tag based on the fighter name, the number of fighters in its faction, and so on... meaning that in most normal situations, it should be unique, so when a fighter is shown it will always get shown straight, and not remove anything else from the scene.

The SetTag method is called when the fighter is added to the battle via AddFighter, to ensure that a fighter which is re-used in many battles (e.g. a party member) doesn't accidentally cause a conflict with another fighter which was created just for this battle, and so on; the tag is specific to that battle.

So in the case of your skill here, this was happening:

• Make a new copy of an existing fighter
• Add new copy to whatever the current faction is - probably the last one added to the battle, and thus probably 'Enemies' or something and not the same faction as the caster; at this point the system says "how many fighters are in this faction? Oh, six?" and sets the tag of the new fighter to "Enemies_6" or something similar.
• Changes the faction of the new fighter to "Players" (or whatever) and thus reduces the number of fighters in the 'Enemies' faction to 5 again.
• ...
• Next time you add a new summon, it spawns in the 'Enemies' faction, checks how many fighters - "Oh, six?" and sets the tag of the new new fighter to "Enemies_6"...

So thus, you end up with more than one fighter with the same tag, and when each one gets shown, all the others are removed from the scene because that's a fundamental behaviour of Ren'Py!

(When ChangeFaction gets called, changing the tag is usually unnecessary, as it will have had a unique tag before the change and it'll still be unique after the change, and most of the time new fighters won't be added mid-battle.)


The most direct solution would be to call 'SetTag' on the new fighter before exiting the method:

Code: Select all

            def PerformAction(self, fighter, target):
                p = target[0]
                self.summoned = copy.deepcopy(clyde)
                fighter._battle.AddFighter(self.summoned, x=p.X, y=p.Y)
                self.summoned._battle.ChangeFaction(self.summoned, fighter.Faction)
                self.summoned.SetTag("summoned_" + str(self._count))
                self._count = self._count + 1

This works, but it's pretty hacky. Also, if you have more than one instance of your summon skill, you could still get tag conflicts without some additional messing around... but I present the option to further understanding of the system.

A better answer is to simply set the battle's 'current' faction before adding the fighter, meaning that there's no need to change faction later and the unique tag which is generated for that fighter in AddFighter is valid:

Code: Select all

def PerformAction(self, fighter, target):
                p = target[0]
                self.summoned = copy.deepcopy(clyde)
                fighter._battle.SetFaction(fighter.Faction)
                fighter._battle.AddFighter(self.summoned, x=p.X, y=p.Y)
                fighter._battle.Show()
                
                if (self._endTurn):
                    fighter.EndTurn()

You'll note that I also added a call to Show() on the battle to make sure that the new fighter is shown immediately that it's added. Although realistically, if you want any kind of entrance animation it's probably better to set that one fighter's state to "summoned" or something, then back to "default" immediately afterwards - state changes will cause the fighter to be displayed, and you can then use state transitions to add an entrance animation.





Anyway, while the above fix will work in the majority of cases (you'll still have some potential problems if one of the summoned fighters gets charmed then another summoned, for example) the tag generation needs to be improved, it's a bug that it should ever generate duplicate tags whatever you've done with fighters changing sides or being added mid-fight, so I'll fix that for the next release; thanks for finding it! In case you want to fix it yourself in the meantime, the call in question is on line 406 of engine.rpy, in the AddFighter method. I'm thinking a simple increment on a battle-instance variable which gets added to the tag will be enough.


(You'll possibly also be pleased to hear that to support the new script extensions which are the next release's Big New Feature, I've added a load of 'builder' classes to the next release; so for things like your summon skill, rather than performing a deep copy you could simply pass in a FighterBuilder that you made earlier, and whenever a fighter is summoned, simply call the Build() method on that builder to get a fresh and ready-to-go instance of that fighter. I'm hoping this will be more useful than the "make me a fighter" methods which I've employed myself before (in Tristan, for one) to spawn popcorn enemies and the like.)

[CaseyLoufek]

Thank you that is a big help. I had a Show() in there but removed it while looking for the bug.

I'm looking forward to the Builders, keep up the good work.

[Jake]

Scripting is coming along - I've got all the basics sorted. The following code - with zero lines of Python -

Code: Select all

init:
    image bg woodland = 'gfx/battle-bg.jpg'
    image geoff = 'gfx/geoff.png'
    image bandit = 'gfx/bandit.png'
    image bandit chief = 'gfx/bandit_chief.png'
    
    image fireball:
        "gfx/fire-1.png"
        pause 0.10
        "gfx/fire-2.png"
        pause 0.10
        "gfx/fire-3.png"
        pause 0.10
        "gfx/fire-4.png"

    skill attack = attack:
        command:
            'Attack' 1
        EndTurn True
        sfx "audio/sword.wav"
        
    skill fireball = magic_attack:
        command:
            'Magic' 2
            'Fireball' 1
        damage 30
        cost 5
        range 5
        sprite:
            'fireball'
            anchor 0.5 0.5
        pause 0.4
        sfx 'audio/fire.wav'
    
    skill skip = skip:
        command:
            'Skip' 10

    sprite geoffSprite:
        "geoff"
        anchor 0.5 0.8
        placeMark 0 -100

label start:

    fighter geoff:
        name "Geoff"
        sprite geoffSprite
        stats:
            Attack 10
            Defence 7
            Speed 8
            Magic 10
            MP 20
        skills:
            attack
            fireball
            skip
            
    fighter barry:
        name "Barry"
        sprite:
            "bandit"
            anchor 0.5 0.75
            placeMark 0 -75
        stats:
            Attack 8
            Defence 6
            Speed 13
        skills:
            attack
            skip
            
    battlefield woods = simple:
        bg 'bg woodland'

    battle active:
        battlefield woods
        factions:
            player Team A:
                geoff
            
            player Team B:
                barry
                
                fighter:
                    name "Bertie"
                    sprite:
                        "bandit"
                        anchor 0.5 0.75
                        placeMark 0 -75
                    stats:
                        Attack 8
                        Defence 6
                        Speed 13
                    skills:
                        attack
                        skip

(styling aside)
produces this:




It could all be one script command starting 'battle', with all the fighter, skill and sprite definitions nested! Equally, since each of those script commands creates a regular Python variable with the given name (e.g. 'fireball', 'geoffSprite', 'barry' or 'woods') you can mix and match Python setup and script commands either way around.




So, a question, to anyone who thinks they may make use of this: would you prefer a reasonable template battle to be set up for you and you only need to fill in the particular fighters and skills you want to use, or would you want complete control over everything?

The trade-off, of course, is that with complete control over everything, the script commands get even longer and more heavily-nested than they are already. For example, in the code above there's no mention of extras at all, but the RPGDamage, RPGActionBob, RPGDeath, ActiveDisplay and SimpleWinCondition extras have been added automatically. This means that you don't have to write a load of extra script lines to add all those things and possibly configure them, but on the other hand you also don't have any control over them - if you wanted to display Speed or Level or whatever on the ActiveDisplay that shows at the bottom, you wouldn't be able to.

[azureXtwilight]

Hmm, it looks rather easy, but then again if you want to make a more complicated battle using experiences and such it's not going to fit...

[CaseyLoufek]

Well I'd want complete control of everything... but I also would be working in full Python for that.

Mostly I'd use the script style for defining characters since the way I do it now is just ugly and most other areas require too much fine control.

I'm inclined to think that since the scripts are for simplicity they should be simple. Working with Python logic seems easier then memorizing a ton of parameters.

[Jake]

Hmm, it looks rather easy, but then again if you want to make a more complicated battle using experiences and such it's not going to fit...

The Python methods and classes will always be there, so you'll always have access to all the functionality if you're willing to use Python; I'm just trying to cover a reasonable subset with the script for those people who want to include a handful of battles in their game but don't want to go to all the trouble of customising everything.

Most of the sprite, battlefield and fighter functionality will be exposed to script, that's all fairly straightforward. Skills are limited to a small set of prototypes (the prototype skill classes in engine-skills) and will need Python code to extend past those anyway...

For the battles, I'm also wondering about a halfway solution, where a template subset of extras is chosen, but any configuration settings for those extras - like which stats to display - is made available via the script. On one hand, it seems at face value like that offers the most flexibility... on the other hand, since the user can't change things like the battlemechanic through script, I don't know if people are ever going to want to change things like the displayed stats either!

[chensterrain]

On one hand, it seems at face value like that offers the most flexibility... on the other hand, since the user can't change things like the battlemechanic through script, I don't know if people are ever going to want to change things like the displayed stats either!

I'm one of those people! If it's not too much extra work, I think your halfway solution sounds great - while I'd definitely be willing to try my hand at Python code to customise things the script wouldn't allow, I also don't really know Python particularly well, so any customisation I could do via the script itself would be great. (That basic script looks really awesome and intuitive, though )