Battle Engine - Alpha 6 release, downloads in first post

[Jake]

Indeed, in fact the simplest method might even be the best. Red and blue triangles on a plain top-down map. Then during unit execution phase cue static pictures of unit in action and text dialogue showing damage inflicted.

There's a reason I've been citing Advance Wars as well as things like Final Fantasy and Tactics games. :P One project I'd like to get back to is one I started a while ago on the TigSource forum, for one of their competitions, but then had to abandon 'cause work got busy and I didn't have time to learn Flixel and finish the project before the deadline... so I've been bearing that in mind and planning to do it in Ren'Py instead once I've got this engine completed enough.

I was just going through some isometric drawing tutorials and realized you actually have to count pixels (two pixels left/right for every pixel up/down; not really a perfect 30 degrees, just the best-looking one).

If you want to do precise geometric stuff, yeah. But if you just want something that looks OK, you can just sketch out the isometric box to frame your figure within, and sketch using the box for a guide.

[blakjak]

I was just going through some isometric drawing tutorials

Care to share the links ? =P

Can anyone think of, or does anyone know of, a decent f(attack,defence) => damage resolution algorithm that's simple and clean enough to make a good example without having much in the way of arbitrary numbers or special cases (e.g. for 0s)?

Sorry, not competent with numbers here.

[DaFool]

Care to share the links ? =P

Unfortunately I lost the link to the best one (where they had separate sections for building, textures, people, etc.) which was a little too hardcore for me. You might chance upon it in your googling though.

It turns out there's a difference between 'isometric pixel art' and just 'isometric art'. I just want the latter, since I'm not into the retro look.

Though a little old, check this out:
http://digitalurban.blogspot.com/2006/0 ... ng-in.html

Read especially the diehard comments, lol. I'm so lazy, not only am I unwilling to go through the 'pixel-pushing' to create true pixel art, I'm also unwilling to model and texture my units in Blender. I don't want to stretch myself too thin, especially artwise, especially since I want to get something done (i.e. a 25mb or less game that has 10-12 hours worth of gameplay -- story and mechanics are top priority atm). For me it'll be just SketchUp (for objects), Terragen (for terrain), and reuseable sprite faces ala Aoi Nishimata-style. But if you have a budget and want a true 2D or 3D looking game, you'll have to do one or the other.

[blakjak]

Thank you !

I'll be aiming at something reasonable but with a different approach than yours. I want it to look really nice, so that does mean I'll probably be modeling units in 3D. But I'm really planning on just a few characters and for a very short game. I'm thinking modeling in 3d for approximately the scale Jake's fighter sprites are, can be relatively fast considering the size of the characters, there should not be tons of detail. I found a tutorial and script in blender to shoot 3d models in an iso perspective and to create automatically sprite sheets :

http://forums.tigsource.com/index.php?topic=4307.0

[Jake]

I was hoping to be able to release alpha 1 this weekend, thinking I'd mostly be putting together examples in the free time I have this week, but I've been held up a bit by the unexpected extra work necessary to display UI elements on layers other than the one Ren'Py prefers... rather than taking a 'layer' parameter on the ui.* calls, I've had to construct the widget Displayables myself, show them and remember all their tags so I can hide them again after the interaction. None of which is incredibly difficult, but it's time-consuming work I wasn't expecting.

Anyway, it's still possible I could get something ready for then, I really do just have the examples left to do now. Have a gratuitous teaser. ;-)

(Although probably the most notable thing that I've not shown before is that I now have scenery items working, so the tree stands in front of the grid and blocks movement and LoS...)

[PyTom]

Um... While Ren'Py doesn't take a layer parameter on the ui calls, it does have the ui.layer function.

[DaFool]

Nice! I have already started composing music for my game, which to me is the most important element in setting the mood.

(Although probably the most notable thing that I've not shown before is that I now have scenery items working, so the tree stands in front of the grid and blocks movement and LoS...)

I'm assuming with a top-down view the tree will still block LoS even though it won't block the grid itself? I think some games show LoS with a yellow dotted line... it would be interested to allow for that possibility especially in battlefields with a lot of clutter.

[Jake]

Um... While Ren'Py doesn't take a layer parameter on the ui calls, it does have the ui.layer function.

Yeah, I'd completely failed to notice that. I'd presumed that the ui.* stuff all went onto the Transient layer because that's the only one which gets cleared down after every interaction, and if I changed the layer I'd become responsible for removing everything anyway...

Nevertheless, the ones which gave me more trouble were actually the ones where I was using renpy.display_menu rather than any of the UI functions anyway... and switching to use UI functions means I can also apply a custom style to each of the parts (the Window, the VBox and the Buttons) instead of just the one part which passing a 'style' parameter to the method allows.

(Which is useful since I don't believe Ren'Py allows for CSS-style "style any button which is within a VBox of this style like this" specifications.

I'm assuming with a top-down view the tree will still block LoS even though it won't block the grid itself?

I'm guessing at what you mean, but... the grid itself doesn't have any understanding of whether it's top-down or isometric or whatever; as far as the code is concerned, what looks like an iso grid to you and I is just a tesselation of wider-than-they-are diamonds... each sprite has an anchor property you can use to set (basically) where their feet are, and thus how far from the grid they'll be drawn, so you can set them to be standing higher than the grid to look like it's an isometric setup.

Scenery blocks LoS based on grid squares rather than visual representation, so it works the same way regardless of whether you've set it up as a top-down or an iso grid... and it'll draw the sprite where you tell it to, with a z-order corresponding to its distance down the screen (this was the best generic solution I came up with to having sprite order not look stupid as much as possible), so if you give it a big enough sprite or position it as such, it'll still cover up grid lines in top-down view as well.

I think some games show LoS with a yellow dotted line... it would be interested to allow for that possibility especially in battlefields with a lot of clutter.

Nothing like that is done in the default implementation, 'cause I was going for the simplest option which worked sufficiently well in a lot of cases, but it's plausible someone could write a UI provider, a Battlefield or an Extra which did that.

[blakjak]

Oh wow, Elemental opponents ! Geoff looks like he's gonna have a hard time beating these three. =D

They look good btw, i like the earth elemental the most.
Also, will it be difficult to choose how many tiles you want the battlefield to be ? And how large in pixels the tiles themselves are ?

edit : I don't see the health bars anymore, they didn't make into the tactical framework ?

[Jake]

Oh wow, Elemental opponents ! Geoff looks like he's gonna have a hard time beating these three. =D

He's going to have particular trouble right now, since the only spell I've actually written so far is the fire one... two of those guys are going to be pretty hard to hurt! :3

Also, will it be difficult to choose how many tiles you want the battlefield to be ? And how large in pixels the tiles themselves are ?

'Hard' is relative... it's certainly possible, and I'll make a note of what all the parameters to the GridBattlefield initialiser mean so people who can do the geometry can set their grid up however they like. But as of writing, right now, it's probably not so simple as it should be... you have to specify the size of the grid in squares, the position of the 0,0 square, the width and height of an individual square, and then - hardest to get your head around - the offsets for each move in X and Y to skew your grid how you want.

One purpose of releasing an alpha, of course, is to get feedback on how easy/hard people find using various parts of the framework so I can change them to make them more accessible. I've got some ideas on how I probably ought to provide grid construction, but of course they're just my ideas, and I understand how it works already.

edit : I don't see the health bars anymore, they didn't make into the tactical framework ?

Not yet, but I've left the structure open for them. It's just a case of taking the code from the PoC and slotting it in, really. Same for the fog-of-war, it's not there now (and I probably won't bother coding it up for the alpha 1 release) but I still have all the code and it'll be trivial to adapt, so it will be sooner or later.

[blakjak]

Ok =D

So where should questions be asked ?

[Jake]

Ok =D

So where should questions be asked ?

If you mean support questions on how to use it, then: once I release I'll probably either update the first post in this thread - in which case, ask them in here - or I'll start a new one, in which case, ask them in there!

Of course, I'm happy to talk to people via PM - or if I've given you my contact details, email, SMS, Facebook message, DeviantArt profile post, note blu-tacked to my front door, whatever... I'd recommend stopping short of wrapping a note around a rock and throwing it through the window, though, I have double-glazing and they tend to bounce off and cause unintended injury. ;-)

[blakjak]

ok ok I get it =D

[blakjak]

I see that you're leaning towards CC-NC, does it still leave room for a commercial project with your agreement ?

[Jake]

I see that you're leaning towards CC-NC, does it still leave room for a commercial project with your agreement ?

The simple answer is that I know I'm happy giving away the code for non-commercial projects, but I'm undecided on the subject of commercial projects, so CC-NC is the safe option.

I'm certainly not intractable and I'm certainly not against commercial projects, so if someone really wants to use this engine in a commercial project I'm happy to talk about it. I just don't know what my long-term position is likely to be yet, I haven't thought enough about it.