Lemma Soft Forums

This one is the easiest - just open the 'game' folder in the battle engine distribution, and copy the following things to your project's game directory:

- the 'BattleEngine' folder (the scripts for the engine itself)
- the 'gfx' folder (the example graphics)
- the 'audio' folder (the example sounds and music)
- the 'assets.rpy' file (sprites, animations, styles and skills set-up for the examples)

(If you're on a Mac, you'll need to download the Windows or Linux distribution of the game as well to get at the source files, because Macs package everything up inside an .app, and while it's quite possible to get files out it's not trivial to explain.)

Stick these things inside your game folder, and you should have access to the battle engine in your game.



You don't need to jump to a label - rather, you create a python object and call a method on it. This is done in each of the demo files. So you shouldn't need to add any kind of reference; just having the files in a sub-folder of your game folder will allow Ren'Py to load them.




In the demo project, there's three files with code in to start battles: active_demo.rpy, grid_demo.rpy and path_demo.rpy. Check which kind of battle you want to run in your game, and copy the whole python block - from the first 'python:' up to just before the 'jump start' at the end - into your game script, at the point that you want the battle to run. You'll then need to modify the scripts if you want to change the names of the fighters, their stats, or anything like that. (Modify the code you copy/pasted to change fighter names and stats, modify the assets.rpy file to change grpahics or skills/spells.)

I'd recommend starting with active_demo.rpy, because that's the simplest one and thus the easiest to understand. Each of the demo files is thoroughly commented, but I don't repeat comments on things I've already described, and I'm expecting people to read the active one first, then grid, then path.





One final note - for the purposes of testing, feel free to keep using the graphics from the 'gfx' folder and the music from the 'audio' folder while you get to grips with the engine and fit it into your game. However, please don't release a game using these assets. Before you release, you should replace the graphics and the music with your own, because I don't give a license to use my graphics - I'd like to use some of them in a game of my own, in fact - and my brother hasn't given a license for anyone to use his music. (The sound effects are all from FlashKit.com, so long as you display the same credits you should be OK to use those if you want.)

_________________

Ok well that pretty much explained it. Thanks Jake for savin my *** again.

_________________
The true measure of a man is what he does with his power.

That happened to me also! But the traceback was for playing extensively during the game, not in attempting to quit midway. Hopefully 6.11 will clear it up when it introduces more streamlined methods to do things.

I also think disabling rollback and saving prior to battle and calling in a Ren'Py VN interlude would do the job sufficiently.

It would be nice to have examples of projectile-type attacks in future releases that trace line-of-sight path from the launcher to the target (an arrow, for instance). I think I'll wait at least for the beta on 6.11 before doing my own test runs... I still have a lot of sprites to make.

As it goes, all of the single-target magic spells use LoS targetting - you can't fire them at a target if there's a fighter or a bit of blocking scenery in between the source and the target. The first two levels of each element's spell are weak and strong single-target variants (requiring line of sight), and the third level is a target-all-enemies variant (which hits everyone in the target faction, regardless of LoS or range).

(This possibly isn't illustrated particularly well in the demos, since there's not much scenery to hide behind... I have a couple of ideas of things I'd like to do as examples, as well, but finishing the fundamental engine parts was a higher priority. ;-)

_________________

I only had time for a quick overview. One thing is I didn't seem to find any code for walking animations ( in particular with the iso grid example ). Is it there but without examples because you do not have animated sprites ? Or is it not there yet ? Same with the "states" the sprites could have, like death, attack etc... Will those only appear in next releases ?

Thanx and good job.

I've not had time to do movement animations yet - I have a fairly good idea of how I'm going to do it, but I figured it wasn't essential so it didn't get into alpha 1. (I expect I'll do those and facings at the same time, they kind of go together.)

There's state stuff in there for deaths and generic 'acting', but I've not done anything with it in the example because... well... I kind of forgot. I need to expand upon it anyway to include sound effects, anyway, so hopefully I'll remember to include examples of this in the next release!

The way one would use it would be to add states or state transitions to a BattleSprite instance, e.g.:



Off the top of my head, valid states right now are "default", "acting", "damage" and "dying". Whenever state is changed, the engine will first look for a valid transition state and show that displayable for however long the duration of that transition is, and then it'll show the displayable for the target state itself, until state is changed again.

If a (fighter)sprite doesn't have a sprite for any particular state, the default state (the Displayable the sprite was constructed with) shows instead.
If a sprite doesn't have a transition stored for any particular pair of states, it'll just switch immediately to the new state without showing a transitional Displayable.

As with all the other BattleSprite Displayable parameters, you can use a Displayable instance or a Ren'Py image reference.

_________________

I had this idea yesterday while I was starting to build my own iso test grid : could it be possible to have tiles on the grid that would "jump" to a label ?

And could going to that label temporarily "pause" the ongoing battle or, put an end to it ?

What I have in mind is for example, the possibility to reach a safe spot, or simply exit the battle grid through a door.

That could be useful if say, my character is being chased by an ennemy so tough, that he could only wish to escape, or go to an armory where weapons are stored and then "jump" back to battle.

edit : or even jump to another "room" where another battle awaits ?

This is certainly all possible - my initial expectation was that the best way to implement stuff like this would be as extras, in the same way as SimpleWinCondition. That would still work, but I'm vaguely considering adding a more-complex event system so people can define conditions (such as "player Fighter is in square X" which lead to labels being called.

Anyway, I'll add these to my feature-requests list. ;-)

_________________

cool =)

That would mean that even a "capture the flag" condition could be coded. Endless possibilities ! =D

Is there a way to make it so dialogue pops up during battle? I'm asking for other people, I'm actually interested but not so much in the engine anymore.

_________________
My handle is Shoe, please use it if you prefer.

International League of Magical Girls
Story: 60%
Script: 15%
Art: 33.33%
Music: 0.002%
Comedy: <9000%

Yes, but how to go about doing it largely depends on what you actually want.

The short version is that you can call renpy.say() more or less anywhere to have a line of dialogue complete with click-to-continue functionality pop up on-screen. In fact, it's how the "Bandit 2 uses Attack" messages are displayed in the examples.

_________________

Let's say I want to build a wall on an iso grid, and I want that wall to behave as Scenery.
Does it mean that for each tile it's going to cover I've got to add a wall section sprite and specify it's position with Add.Scenery ? It seems logical, I think, but I just want to confirm this because it means that all Scenery elements that occupy multiple tiles would have to be designed bearing in mind that there would have to be one sprite per tile, and that they would combine to draw the final element ?

Also,what if I don't want a diamond shaped grid ? Are these the right steps ?

- Build the iso grid in the engine.
- Use Add.Scenery with a totally transparent sprite instanced over the tiles that I don't want the fighters to be able to walk over.

I've also thought of something else that's unrelated :

If there are animations, would it be more efficient for Renpy to load a single filmstrip sprite, and use anim.Filmstrip to animate ? This way a lot of animations could reside on just one image.

Right now a Scenery item can only block one tile, so yes, in Alpha1 you'll have to add one piece of scenery per tile you want to block. I'm still thinking about multiple-tile/position entities, and if I include those, then it'll be possible to add a scenery item which occupies more than one tile.

The hesitation I have in this regard is that I also plan to add the [optional] ability to destroy Scenery, so a Fighter with a bazooka might be able to blow a hole in that wall... and of course, if the wall is a single bit of scenery that stretches for 20 tiles, then shooting just one end with the bazooka would remove the whole 20 tiles. In this case, it would be advantageous to have each tile's worth of scenery be a separate entity, so the bazooka destroys just the three tiles within its blast radius and makes a three-square hole. Of course, I guess the ideal would be to support both...



Again, yes, right now. Although I think offhand you should be able to pass a 'None' into the sprite parameter, if you can't I'll try and remember to fix it so you can for the next release.

This is something I have a fairly firm plan for, on the other hand! I'd like to be able to modify the grid chunk-by-arbitrary-chunk CSG-style (and I have a good idea of how to code this already), so it would be possible to do something like:


Obviously it would be tedious to block out all of the non-grid spaces in that example with individual one-square invulnerable scenery elements, but like this it's relatively easy.




Yeah, it might well be - the BattleSprite will take any existing Ren'Py Displayable or image reference and display it normally, so you can define animations however you like elsewhere in your script. I just used separate files for separate frames 'cause I'm used to doing it like that, and 'cause it's a bit of a hassle to make a filmstrip in Photoshop with a transparent background, 'cause it has a habit of cropping your copy-pasted area to a tight rectangle around the non-transparent pixels. :/

_________________

That'd be friggin' awesome *_*


Something else to look forward too. =D

I'm really liking the suggested future feature list. Thanks blakjak and Jake. I think, though, that map scrollability should be prioritized, then everything else will have more appeal. Imagine a super-huge 24 x 24 maze dungeon complete with destroyable walls, treasure chests that add items to your inventory, entry/exit points that lead to the 2nd floor or a different dungeon altogether, and enemies that seem to come out of nowhere (the fog-of-war being cleared, or simply just coming within line-of-sight). Take out the enemies and you already have a World Map engine good to go! Besides, half the fun in a tactical game is exploring the terrain and suiting it to your advantage.

To further the train of thought, imagine also a special square that when the player reaches it you can save the game!!! It might even be theoretically possible to play the entire game as a series of interlinked battlemaps. It'll be a seamless world like Diablo, only turn-based. The way this would work would be to set Move limits only when there are enemies in the vicinity. If all the enemies are cleared, Move would be set to Infinity. (Resonance of Fate -- surprisingly a current-generation game, made use of nested and interlinked battlemaps: Clear the area, move to the next hex, and so on until you reach the final Boss hex for that dungeon). In these exit type scenarios, when even just one player steps on the exit tile, the whole party gets teleported to starting positions on the next battlemap.