Eiliya wrote:
I figured I would begin by replacing all the images in the assets file with the ones I would use for my own game (I am allowed to do that, I hope..?) and encountered my own lack of knowledge in the size-limits for the images. By researching the files used in your demos, I realized that most images used (for characters, monsters and effects, that is) are somewhere around 200x200 pixels. Is there any specific reason for this, or can I use whichever size I see fit? In case it matters, I am only after the Active battle function for this test of mine.
With regard to permissions - presuming you are making a non-commercial game, you're welcome to use any or all of the code in the downloadable release; the only parts I request people not to make use of are the images, and even there you're welcome to ask, I'm not necessarily going to be inflexible. It'd be nice if not everyone using the engine had exactly the same effect graphics and everything, but the only bit I'm really absolutely sure I don't want people using are the isometric tilesets used in the elevation demos, 'cause I have plans for a game using those myself! Of course, you're free to use all the graphics supplied as placeholders until your own art is ready.
You can use images of any size you want, just bear in mind that:
- larger images will obviously take up more screen size, so plan your sizes accordingly
- you'll probably want to play with the 'anchor' and 'placeMark' parameters to BattleSprite if you change the sprites much from the examples.
The 'anchor' parameter when you create a BattleSprite tells the engine which part of the sprite should be positioned at the point on the screen that the fighter is 'standing'. Essentially, you should change these values to be the point on the sprite where the fighter's feet are.
The 'placeMark' property - which is actually only set on the enemy sprite in the active demo, because there's no reason to be selecting friendlies - tells the engine an offset to point to with the little pointy-finger when selecting it. You'll need this if you want to include anything that targets friendly fighters, like heal spells, potion items, and so on. Otherwise it'll just point to their feet, because it defaults to the anchor position. Because Ren'Py coordinates start in the top left, a placemark of (0, -75) means '75 pixels up from the anchor point'.
Eiliya wrote:
I would like to use some kind of animation or other effect to indicate which character is doing what (like a sword-slash or something) but I have no art for that yet. So now we come to my second question: Which .rpy files will I have to study and eventually modify in order to get what I am looking for, and how difficult will it be for a complete programming beginner like myself?
Do you know how to define animations in Ren'Py using ATL? That's the easiest option - you can find documentation for ATL
in the Ren'Py documentation.
Once you've done that, you'll need to assign your animations to 'state transitions' on the fighter. The battle engine sets a fighter's 'state' property depending on what they're doing - if they're doing nothing special, they'll have the 'default' state, if they're in the middle of a melee attack they'll have the 'melee' state, if they're taking damage they'll have the 'damage' state, and so on. You can define different sprites for different states, by writing Python code like this:
Code: Select all
geoffSprite = BattleSprite('geoff default', anchor=(0.5, 0.8)) # This creates a sprite using the image called 'geoff default' as the default state image.
geoffSprite.AddStateSprite('damage', 'geoff damage') # This adds the image called 'geoff damage' to be used when in the 'damage' state.
Now, the tricky part is that the fighter is only actually in that state for as long as it takes the engine to work out the effect - so it's in the 'melee' state for as long as it takes to calculate damage, and it's in the 'damage' state for as long as it takes to reduce the fighter's HP by the appropriate amount... which generally means "a fraction of a second", which isn't very useful!
If you want an animation to play - say, the character swinging a sword, or reeling back taking damage - you'll want it to stay there long enough to see the whole animation. So instead of just setting the state sprite, you're better off creating a 'state transition' sprite. This is a special sprite that gets shown for a defined period of time whenever the fighter changes state from one state to another. So for our melee-attack animation, we'll need to create a state transition from 'default' to 'melee', and place the animation in there, telling the engine how long the animation needs to be shown for:
Code: Select all
# The following line of code shows the image called 'geoff sword attack' for 0.75 seconds whenever the sprite changes from the 'default' state to the 'melee' state
geoffSprite.AddStateTransition('default', 'melee', 'geoff sword attack', 0.75)
Like this, we ensure that every time the fighter makes a melee attack, we see our sword-attack animation for the whole 0.75 seconds it runs for, then we let the engine move on to actually calculating the damage and applying it to the enemy and all that.
These images - 'geoff default', 'geoff damage' or 'geoff sword attack' in the examples - are simply Ren'Py image names. So you can set them up as straight static images if you like, or you can create an ATL animation however you like for geoff swinging a sword, call it 'geoff sword attack', and the engine will play that animation instead of just showing a static image.
You can find some examples of state animations in directional_sprites.rpy starting around line 250 - be aware, though, that these are for the grid battlefields so there are multiple versions of each sprite for facing in different directions. If you're just using the active battle mode, then you can just leave off all the 'facing', 'fromFacing' and 'toFacing' parameters entirely, don't worry about them.
