Lemma Soft Forums

:O I hardly did anything. I just unzipped the entire thing, went into the folder, and tried to launch.

The battle system reminds me of Disgaea, although it gives off a different vibe, i guess it depends on how the character sprites look. The characters in the demo's on youtube remind me of something you would see on the history channel, so you can replace the sprites? if so that would be amazing, its a shame it wasn't a platform based rpg, like final fantasy, although it looks good and is the only free RPG battle engine around.

_________________
http://berry-melon.deviantart.com/

Hah! Yeah, I guess they're not so fantastic as a lot of JRPG characters. Of course you can replace the sprites - in the case of the non-animated ones, they're just a single graphic that's loaded in when the fighter is set up; in the case of the animated ones it's a little more work setting up the animations, but it's all completely customisable.

If you download the "zipped game directory" demo project linked to in the first post, you can look at the demo scripts, hopefully it should be fairly straightforward to replace the sprites. Look at the scripts in the same order the different battle types are shown in the demo menu, then you'll have each thing introduced a bit at a time.



I'm not sure what you mean by 'platform based rpg'? The engine does support the early-mid FF-style 'ATB' kind of battle, but I've not played any FF past 10, so I don't know what I'm missing in later games. ;-)

_________________

Great work on this so far, I like it when a visual novel has minor battle elements that allow you to take a break from the reading.

A question, is there going to be an option for battles to be from first person? Sort of like in the Love Hina dating sim floating around on Newgrounds (I'm fairly sure most people here have played it). It has a primitive but neat battle system.

Oh. My. Morg. All. The. Gourds. I cannot believe this...this gorgeous masterpiece. THERE ARE NO WORDS, SIR.

This whole thing is fantastic, and holy moly thanks for sharing the codes. I mean, I had thought it would be nice to include some battling in my own but didn't think this would be a viable option to explore. Learning it all and knowing where to place what is indeed going to be a challenge but having this makes everything yards easier. Thank you, so much. TT^TT

Me again, sorry. 8'D Small issue this time that shouldn't be too difficult.

I'm trying to access items in the equipment menu outside of battle, but even after referencing some code in the engine, I'm not sure I'm calling the items correctly to use them.

My code is thus:

When I use an item, Ren'py crashes and produces this error.

14 is the beginning of the python code, 160 is the "PerformAction" line, and line 12 of item assets refers to the potion item being used.

I'm not sure what the issue is. ._.;; It'll probably be something obvious, but it's stumping me for now.

PerformAction here expects two parameters - the first parameter is the fighter who is performing the action, and the second is the target. The problem is that the target isn't just the target fighter - it's a tuple of the target fighter and then the range to that fighter. So - for example - if you had a magic wand item which zapped enemies but the effect wore off over distance, it would need that range passed in to work out how much damage a particular target took.

Unfortunately, rewriting the line to this:

(which assumes a range of zero, which seems sensible if a fighter is using an item on themselves)
still has problems. Namely, the system assumes that the item will be used in battle, and as a result the fighter sprite gets displayed and the little green "+50 Health" popup displays if you have that extra enabled, and so on.


It's on my to-do list to allow skills, items and spells to be used outside of battles (where appropriate). Most likely this will take the form of a second method on the item, skill or whatever which does the out-of-battle version of the PerformAction method, but that's at least a month off for now, I'm afraid.

_________________

Ah, I see. That makes sense. ^^ I'll just wait for that, or remove the feature, then, if it's not possible at the moment. Thank you for clearing that up.

(Also, since somebody asked above: there will be an option to have battles from a first person at some point in the future, but it's not a high priority on my to-do list.)

_________________

I am so sorry to be bothering again so soon. Again, just a small issue that's kind of eluding me right now.

Messing with sprite states, and I can't quite get the 'damage' one to display properly. I created a sprite state,


and applied the DamageState extra to the battle. However, it remains in the default state, even after damage is taken.

Hopefully it's not something too stupid or me being on the wrong track with what it does. ^^;; I looked quite a bit at the demos and engine to try and figure it out, but I'm afraid I'm rather stumped.

Thanks in advance, and sorry for the trouble.

The problem you're facing is that immediately after the damage state is set, the code sets the state back to 'default'. It's intended to be a short animation which plays as the character takes damage, not a permanent state (for that, you're actually best off replacing the fighter's sprite with a new one, which obviously could be a bit of a hassle... I'll add it to my To-Do list to add some sort of sprite-changing mechanism, but it's going to be fairly low-priority, I'm afraid.

Anyway, when a sprite state change occurs, the engine obviously starts out with the start-state displayed, it looks for a transition from start-state to target-state and if it finds one, plays it, waits for it to finish (duration defined when the transition is added) and then displays the target state. The DamageState extra simply causes the fighter's sprite to transition to 'damage' and back to 'default' whenever it takes damage, so the engine will do something like:

<damage occurs>

• State changes to 'damage'
• Look for a transition from "default" (or whatever state the fighter is presently in) to "damage"
  
  • If it finds one, it replaces the fighter's sprite with the Displayable set for that transition
  • Then waits the duration defined for that transition
• Next, the "damage" sprite is displayed
• Immediately after, the state changes to "default"
• Look for a transition from "damage" to "default"
  
  • If it finds one, it replaces the fighter's sprite with the Displayable set for that transition
  • Then waits the duration defined for that transition
• The "default" sprite is displayed.

So if you want to include a short animation which plays as the character takes damage (e.g. the so-called 'pain frames' that a lot of 2D games have) you'll actually need to add a state transition, which is a short animation which plays when moving from one state to another. It's intended originally for things like animations rotating the character from one facing to another, if that helps conceptually?



This will play an animation called "myFighter damage" for 0.5 seconds whenever the state transitions from "damage" to "default". (You may think it's weird that it's damage->default and not the other way around, but it's safest like that - we don't know what state the fighter is in before they take damage, but we know that they definitely go to default after taking damage, and it'll happen so fast that the player won't notice the difference anyway.)




You're welcome - and it's no trouble!

_________________

Ah! That's actually exactly what I was going for, thanks! I didn't even know that little feature existed. ^^ Thanks for your help, as well the explanation.

You're welcome! For reference, the state transitions I have noted in the code comments as "useful" are as follows:

• default -> acting
• acting -> default
• default -> damage
• damage -> default
• default -> dying
• default -> moving
• moving -> moving (different facings!)
• moving -> default
• default -> melee
• melee -> default
• default -> magic
• magic -> default

I realise it doesn't make much difference in your game, but for the sake of completeness in case anyone making a grid-based game is reading: these can also by specified to start on or end on particular facings, the full form for the AddStateTransition function is as follows:

Where fromFacing and toFacing are optional named parameters you can use to define the same state-to-state animation multiple times for different facings, or define a facing-to-facing transition for the same state (moving being the obvious one here.

It's also worth pointing out that the engine and associated code isn't entirely consistent with some of these, thanks to the largely organic way it's grown - I think the 'acting' state is barely supported, for example, in favour of separate states for moving, melee, magic (and so on, as necessary).

_________________

Here's what I've been working on lately:



(You may want to watch it on YouTube, the forum software shrinks it quite a bit...)

_________________