Battle Engine - Alpha 6 release, downloads in first post

[Jake]

Any eta on panning?

... the problem is that at some point between 6.10/alpha 3 and now, something weird has happened to move transitions such that about 50% of the time when a fighter moves from one space to another, it doesn't perform the transition and instead just skips straight to the end.

Progress! I've pinned down the particular situation in which this occurs, so my ETA for alpha 4 - containing panning - is "pretty soon now". Now I'm relatively happy that the problem isn't in my code, I'm happy to release it just with a warning that it won't work entirely properly until that bug is fixed.

That said, I think the only notable thing in alpha 4 will be panning - the only other change I've made has been some code to allow multiple bouncing damage numbers at the same time... ;-)

[usul]

Is the hexagonal grid still in the works?

[Jake]

Is the hexagonal grid still in the works?

Still in the works, but I'm getting the panning out of the way first! ;-)

[DaFool]

Can we have something like Alpha3b where panning is demonstrated even if it doesn't work fully due to the Ren'Py bug mentioned?

I just received a gorgeous 20 x 20 test BG and I'm really excited to see if I can load it with 20+ characters and have the most epic Disgaea-style battle ever.

[Jake]

Can we have something like Alpha3b where panning is demonstrated even if it doesn't work fully due to the Ren'Py bug mentioned?

That was what I was going to do, yeah... I was just going to call it '4' regardless.

I'm not going to wait for the bug to get fixed; now I'm happy it really is a Ren'Py thing and not in my code, I'll release the code changes I've made and just include a note explaining the movement bug. (Now I have a clue where to look I'll also have a poke around to see if I can fix it myself, but I wouldn't hold out much hope for that - I got a bit lost last time I looked through that stuff, and since it's all rather time-critical, it's hard to debug through.)

It's just a little annoying, since a completely different bug means that it won't work at all on 6.10, all the fighters get drawn off-screen due to nested positional Transforms each overwriting their parents' positional properties completely, so the warning will have to say something like "this will only work with Ren'Py 6.11 or greater, but at time of writing movement animations won't work properly on versions 6.11 and greater"... ;-)


As to large backgrounds, my only potential worry is that the size of the images means that they won't all fit into the in-memory image cache... and from what I recall of what PyTom told me, Ren'Py's possibly a little too careful to make sure everything that should be on-screen is drawn, so it may end up trying to draw a lot of stuff that's actually off-screen.

Obviously increasing the size of the cache should help with most of that problem... and I have vague plans to add to the BattlefieldSprite implementation to allow it to consist of any number of arbitrarily-offset chunks of graphic, to allow battlefields built of smaller modular pieces, which should hopefully mean people can find a balance between very large graphics and tiles of graphic.
(I've tested a large - 1600x1200 - graphic BG on my laptop and desktop before and it worked absolutely fine with no slowdown, but even though they're a few years old they're still both relatively powerful machines compared to the stuff Ren'Py can theoretically run on. I should try on my ancient tablet PC some day...)

[Jake]

Can we have something like Alpha3b where panning is demonstrated even if it doesn't work fully due to the Ren'Py bug mentioned?

That was what I was going to do, yeah... I was just going to call it '4' regardless.

Apologies for the delay; I've been a bit ill and a bit busy, but I've now cleaned up all the bits I wanted to clean up, and written the extra code I wanted to write. The panning is now smooth, using the same formula as ease, and there's an 'ActionPanner' Extra which automatically pans to Stuff That's Happening for you (making the enemies' turn a lot more cinematic) and a new PointOfInterest event so that skills and so on can signal that Something Interesting Is Happening Here if they want to (so, for example, the magic attacks pan to centre on the target before the animation starts rather than at the moment that the damage is taken).

All I have left to do is to re-do the buttons for the pan controls so that they're properly styled instead of being hard-coded to the top-right corner, so I should be able to make another release this evening.

[blakjak]

Wow, this is fantastic. That feature is so specific to the T-RPG genre. Game engines that can help you build this type of game with so many built in features are almost non existant, the only one I can think of is the japanese-only Sim rpg maker by Hit points, and even this one has many limitations like resolution for example.

Sorry to hear you were ill

[Jake]

I've released Alpha 4, which contains all the same stuff from alphas 1-3 - examples of active battles, path-based battles and two types of grid-based battles (isometric and orthogonal), configurable scenery, easy-to-customize game options, facing-dependent sprites, items, equipment and some examples of customising skills. Alpha 4 also introduces panning, allowing battlefields larger than a single screen, and a few utility bits related to that.

The panning demo has some pretty hasty graphics 'cause I only remembered this evening that I didn't have any battlefield graphics lying around larger than one screen - I'll probably re-do them for a later release so they're at least as shiny as the other demos, but for now it's very basic five-minutes-in-Photoshop stuff.

A video of the new ActivePanner applied to the old iso grid demo, which YouTube has helpfully cropped so you can't see the whole screen, can be found here:
http://www.youtube.com/watch?v=qFEdKxGaLX8

Downloads

Alpha 4 - All[26MB]

[DaFool]

Excellent. Thank you once again. I'm starting to get more final art so I can make some tests that will go towards the final builds. I'm going to take it nice and slow and customize and tweak one battle at a time. I might have more feedback for you this weekend.

Besides blakjak, usul and I, who else here is making an SRPG (Utawarerumono / Disgaea / FF Tactics clone)? Art is expensive (time or money-wise)! I'm using 3D for almost everything, and with everything prerendered the game could take gigabytes of space. I can't wait until next year, when all the big games that push the boundaries of Ren'Py are supposed to be completed.

the only one I can think of is the japanese-only Sim rpg maker by Hit points, and even this one has many limitations like resolution for example.

By any chance have you come across easy tools to generate isometric walk-cycles similar to the plenty on offer for RPG Maker type games? Then again, it's one thing to have low-resolution generic chibi pixelart in 4 frames and another matter entirely to have HD sprites like in Disgaea 4 where the minimum seems to be 8-16 frames.

[jack_norton]

Just curious but what takes gigabytes of space? if you have an iso-tilemap and sprites in 3d unless you use 1680x1050 resolution (which would be crazy lol) don't understand what is taking so much space ?

[DaFool]

Just curious but what takes gigabytes of space? if you have an iso-tilemap and sprites in 3d unless you use 1680x1050 resolution (which would be crazy lol) don't understand what is taking so much space ?

Each set of prerendered pngs per character is around 40 megs - that includes all animations in 8 directions. I have about 2 dozen units, including generic types. (Add backgrounds, music, voices... you get the idea). I also don't have an iso-tilemap, instead using fully-crafted backgrounds that happen to fit onto a grid.

That's the element that took me back by surprise - the sheer amount of different units that is required for a tactical game. For an action RPG you just need one character + a few monsters; for a regular JRPG you need a party list of 4-6 characters; but for an SRPG you should be able to call forth at least 8-10 on the battlefield (with plenty more in reserve).

The mechanics of tactical RPGs haven't changed much since Advance Wars and X-COM -- so the way you make your game interesting is to provide expansive maps with lots of obstacles and a bigger variety of unit types with complementary abilities.

[Jake]

Besides blakjak, usul and I, who else here is making an SRPG (Utawarerumono / Disgaea / FF Tactics clone)?

Well, it should come as no surprise that I've got a game or two waiting in the wings for the engine to be ready for them and for me to have enough free time to devote to them!

I'm seriously considering upgrading Abraxas to a full grid-based game instead of the path-based thing I had before, for starters; I didn't consider it before because it started out as a NaNo project, and as such I wanted to not spend too long on the battle system for it, but since I missed that deadline, I could see myself spending longer on it. I've also got a story-driven SRPG/Advance-Wars-clone idea that I wanted to do for a TigSource competition ages ago (I could probably still use the same free sprites and tiles, in fact) but got busy with work and ran out of time for... I might even leave re-do that from scratch as a NaNo project next year. ;-)

Each set of prerendered pngs per character is around 40 megs - that includes all animations in 8 directions.

Out of interest, what sort of resolution are you working at, and how many animations do you have?

The Clyde graphics for the demo take up just a bit over 200kb for four 6-frame walk directions and standing directions. Taking twice the number of directions and frames, that would be 800kb, then just at a guess, based on other games' sprites, maybe multiply the frame count by 4 to take into account all the other animations (attacks, hurt, etc.)... that still leaves me at around 3.2MB, an order of magnitude less space!

The mechanics of tactical RPGs haven't changed much since Advance Wars and X-COM -- so the way you make your game interesting is to provide expansive maps with lots of obstacles and a bigger variety of unit types with complementary abilities.

The basic mechanics haven't, but then the basic mechanics of the FPS haven't changed much since Wolfenstein 3D back in 1992 (most of the improvement has been technological). Various titles - including several of Nippon Ichi's - have put new rules into the mix that result in quite a different game, all the same. Go play Phantom Brave and then come back and tell me it's the same game that UFO: Enemy Unknown was! It's admittedly not so much of an evolution as Gears of War to Wolf3D, but it's still development of the idea which distinguishes that game quite distinctly from others of its type.

[DaFool]

Abraxas, oh yeah (duh!)... the whole reason why this Battle Engine was created in the first place!

My sprites are 512x512 and have about 5-8 animations each, rendered 8 directions in 8 or 16 frames, . 512 is very large (I may end up with 256x256 standard tactical view; 128 is still too small for the amount of detail I want to convey), so they may need to be downscaled, but that's what I'm going to use whenever there are close-ups. The 3D models that are the source of these prerenders are easily the most expensive part of the project, so I do hope to reuse them someday in some sequel -- using a 3D engine maybe. (With all the redrawing in HD and retexturing that's going on in game companies these days, I figured I'd future-proof the art assets already).

I haven't played Phantom Brave, but read up on some of its unique rule sets. I do have one or two new rule sets up my sleeve, but at this point I'm not really trying to innovate.

[Jake]

My sprites are 512x512 and have about 5-8 animations each, rendered 8 directions in 8 or 16 frames, . 512 is very large (I may end up with 256x256 standard tactical view; 128 is still too small for the amount of detail I want to convey), so they may need to be downscaled, but that's what I'm going to use whenever there are close-ups.

Do you really need to ship the full 512x512 sprites for every single animation in every direction, though? Are you likely to need all of them for closeups? I mean, that's a lot of data, and even at - say - HDTV res you're going to be able to fit a handful of them on-screen at once at that size...!

(And remember, while it's more efficient from an OpenGL-memory-usage point of view, there's no requirement to use power-of-two graphic sizes for source material, so you don't only have a choice between 512, 256 and 128... a 3:1 resampling down to 170 pixels wide would still resample fairly well, reduce your data usage by a factor of nine and hold more detail than 128-wide.)


Still, I'll look forward to seeing all this stuff in action!

[jack_norton]

Well I would definitely reccommend to resize down those sprites at 512x512 each frame, you're cutting out lots of computer/videocards since needs ton of VRAM to display that thing on screen (if was a full 3d game would be quite different). Planet Stronghold has maximum 4 enemies on screen (even if are bigger, like 1024x1024 scaled down) but have no animations, and still when some menu go up/down I notice a slowdown even with RenpyGL (you can also hear the music scattering a bit).
Anyway when you'll have a demo I'm curious to see how will run, especially on some Macs!