Battle Engine - Alpha 6 release, downloads in first post

[blakjak]

Cool, because I feel the same way, I have no plan on going commercial at the moment, it's just good to know you're open to discussion in case an opportunity shows up =)

[DaFool]

I've been thinking about commercial for a long time, but the people here who sell renpy games mainly stick to VNs unless they're programmers themselves. What I fear the most is being obliged to bugfix something which I don't know fully the ins and outs of.

You might be able to go for licensed commercial support similar to the card game engine. As for myself Im going for a freeware prototype and market the hell out of it. Then if the IP proves popular enough I can make a sequel on a more standard game engine such as Unity and find plenty of programmers for hire. (of course without discounting the fact that the programmers here who use renpy and python do so more as a labor of love).

[Jake]

I've been thinking about commercial for a long time, but the people here who sell renpy games mainly stick to VNs unless they're programmers themselves. What I fear the most is being obliged to bugfix something which I don't know fully the ins and outs of.

There's basically two reasons for offering a separate license for commercial projects. One is that I'd probably be a little bit miffed if someone started making money directly off the back of my hard work that I gave away for free*, and the other is this - with a licensing deal in place which involves some compensation to me, I'd be obliged to provide some level of support, so people wouldn't be left with half-working battles that they can't fix themselves, or fielding customer questions that don't make any sense to them.

You might be able to go for licensed commercial support similar to the card game engine.

Given that last time I checked the card game engine's license was something along the lines of "use it for free projects as much as you like, contact PyTom if you want to do anything commercial", what I've already said is more or less exactly the same. I don't know of any specific formal license PyTom's using for it.

But then again, if I really wanted to make money off of the engine, I should probably just start developing my own marketable game with it. Or offer bespoke development, so offer to write all of the battle parts - skills, AI, etc - for someone's game for a fee/cut. As it is, the other part of not-being-sure-about-commercial-licensing is that if I started charging people money for commercial use, it would inevitably cut into my free time with support/further development requirements, and I might just prefer to play videogames instead of getting any extra cash. :P

of course without discounting the fact that the programmers here who use renpy and python do so more as a labor of love).

I would say "labour of self-flagellation" on my part, half the time...

Part of my motivation to finish this engine is the simple desire to see more tactics-style videogames, it's true, but a good part of it has been other factors, like occupying my mind during lunch hour at work, or getting a bit of practice in Python in so I can reasonably claim to know some things about the language, etc. ... but there are many things about Python** (and a few things about Ren'Py***) I find incredibly frustrating, and a good part of the reason I've got so far as I have is sheer bloody-mindedness. :P




* Although, this is somewhat mitigated by the knowledge that realistically, game design is more important than engine implementation details in terms of making something people are motivated to buy. At least when the people aren't distracted by shiny graphics.

** Not least that a lot of the people who provide casual Python help online don't seem to program in other languages, so they say things like "all methods in Python are like C# virtual methods" when that's only superficially true.

*** To be fair, probably about half of these are just because I'm not using it for what it's really intended to be used for, and I'm just annoyed by the VN-centric nature of the engine. And another portion just because I'm used to my game-projects work running on an engine I built myself, so I find it frustrating when I get weird bugs and can't instantly take a good guess at which object in which file is responsible.

[DaFool]

Quick question: What's the recommended sprite size for top-down 10 by 10 grid on a 720p screen? 72? It seems like an obvious question; I'm just making sure. Does the field scroll in a viewport?

I have already 75% of my music composed (most of the atmosphere used to design the look/feel of the rest of the game is based upon how the music turns out), all I need to do are sprites (top-down to start simple), a few BGs, and 'show-side-image' headshots. Not only am I waiting for the battle engine and renpy 6.11, I'm also waiting on the specs of Nintendo 3DS (which looks to have at least one wide screen... possibly an HD one at that). Exciting times.

[Jake]

Quick question: What's the recommended sprite size for top-down 10 by 10 grid on a 720p screen? 72? It seems like an obvious question; I'm just making sure.

Well, that would certainly fit! Depends whether you want any other interface clutter on the screen at the same time, of course...

Does the field scroll in a viewport?

Not presently, I've not looked at scrolling, but I've been trying to not build it out, I'm planning to look at it pretty soon.


(I'm planning to do my Alpha-1 release sometime this evening, so you'll be able to have a look for yourself. :P)

[Jake]

(Copied from updated first post...)

ALPHA 1 RELEASE

I've released Alpha 1, which contains examples of Active Battle, Path-based battles as seen in the original Abraxas proof-of-concept demo, and two types of grid-based battles (isometric and orthogonal). Hopefully the examples are commented sufficiently...

As mentioned in the accompanying notes: this is an alpha release, so it's definitely not feature-complete and there may well be bugs... also, it's quite possible that I'll change some of the interfaces before calling it final, so code written today may break later. I'll try not to break interfaces unnecessarily, but it might happen.

Downloads

Windows [11MB]
Mac OSX [15MB]
Leinnucks [11MB]

screenshot0004.png

I still have a lot more development I want to do before I can call this done, so I'm not incredibly short of new features to implement (see ToDo list at bottom of post), but one thing I'm particularly interested in is ease-of-use, so if anyone has any suggestions as to how it could be made easier to set up a battle, within reason, I'm very interested in hearing them. This is probably the main reason interfaces may change, if I can find a better, easier-to-understand way of putting everything together.

(Lastly - I forgot to mention it in the in-game info, but the music used for the battle sequences was composed by my brother, Isaac Staines, and originally was used in Star Story Saga: Renaissance... I just didn't have any better music lying around. I tried composing some myself, but it was pretty bad and Ike's really good at it... ;-)

[kantocan1]

AWESOME! Nice engine by the way, must of taking you some work to get this realeased. Hey, any chance of making an RPG or RTS game with this? Though i suppose an RTS might be too complicated though. Sounds great all the way and it'll help people too!

[emihaumut]

Yay! A release I'm still downloading it right now (6 min remaining?! Damn my slow internets!) but I can't wait to test it out and then try to implement it into my game somehow, lol. This release may have made my day.

[DaFool]

kantocan1 >> By their default nature, you can't exactly make a real-time strategy game with this. You can however, make a turn-based tactical game similar to tabletop wargames.

Jake >>
Thanks for your hard work.

It's pretty straightforward so I know once I got my sprites done it'll be easy to plug them in and have a working battle in no time. I like how your magic is already in Rock Paper Scissors format (by generally taking out the Wind element) since I have [not-necessarily-magic] skills which are designed that way, so it's pretty much plug n play. While all the other battles are 'easy', the Isometric Grid battle can be challenging because of it.

---

Will there be plans to make your player fighters be selectable not by a menu, but by using the same "pointing gloved hands" used to select enemy targets? I understand that selecting a target is a one-click affair, while menus (especially with skills) are nested sequences, so starting with a menu by default is most logical. However, instead of a centered menu, I'm thinking of a "Command Wheel" like your previous Abraxas demo where each additional menu nest will open up in the center (blocking the sprite, but yeah). I came to that conclusion after a drew a mockup of the battle menu imagemaps (styled like a control panel inside a cockpit) and realized that isolated nests of menus aren't intuitive at all... it's best to have context-sensitive menus which means they must be positioned as close as possible to the target they're commanding.

---

I'm thinking the next step might be implementing facing directions. In addition to quadrupling the sprite requirements, it will add yet another nest of menus in the sequence, e.g:

MOVE -> SET FACING DIRECTION -> ATTACK / SKILL MENU -> (if skill) CHOOSE SKILL

There can also be a damage multiplier type where you get maximum damage when facing the rear of an enemy, and maximum defense for the front. In the meantime I'll look and see if it might be trivial to insert a rotation animation so that (in the top-down view) the player can automatically point in the enemy's direction when launching an attack.

---

Would it also be no small task to insert renpy dialogue in the middle of battle similar to the tile/unit engine? I can see a problem with roll-back going back to the battle demo selection menu (I accidentally scrolled the mouse one time) I can foresee a command scenario where for example, one of your soldiers prods you to "Use Uberweapon", and you can either use it and suffer major collatoral damage, or continue to battle as usual. Or where the enemy calls for reinforcements when their numbers or HP are low.

---

Since lots of features are formulated as "AddExtra" plugins which seem to be in python, we can list common mission types so there's a default list of 'plugins':

*SimpleWinCondition()/destroy all enemies: already coded in
*waypoint/capture-the-flag: game ends (or more situations arise) if one side or the other reaches and activates an important hotspot on the map
*protect/escort: game ends (or more situations arise) if an important sprite reaches critical HP level
*time-limit: (as mentioned already), restrict the number of turns to complete objectives.

I'm sure those are listed countless times already, but I honestly cannot think of any others. It seems that even complicated multi-objective RTS scenarios can be broken down into these simple mission types.

---

You mentioned implementing Items and Equipments. Maybe create some form of wrapper so that someone with elite inventory design skills can take care of all the equipment and inventory management (in a separate 'engine'), then just pass them on to the Battle Engine in parametarized fashion?

---

Also, the game crashed twice (it seemed to be Ren'Py itself crashing... I can't find tracebacks on .app distributions). Attached is the log of the first one. I think it seems to be a similar issue to the tile/unit engine where displayables create some form of hog and don't get flushed in time or something, since I had been playing battles one after the other.

Again, thanks for this.

[DaFool]

Will there be plans to make your player fighters be selectable not by a menu, but by using the same "pointing gloved hands" used to select enemy targets? I understand that selecting a target is a one-click affair, while menus (especially with skills) are nested sequences, so starting with a menu by default is most logical. However, instead of a centered menu, I'm thinking of a "Command Wheel" like your previous Abraxas demo where each additional menu nest will open up in the center (blocking the sprite, but yeah). I came to that conclusion after a drew a mockup of the battle menu imagemaps (styled like a control panel inside a cockpit) and realized that isolated nests of menus aren't intuitive at all... it's best to have context-sensitive menus which means they must be positioned as close as possible to the target they're commanding.

I've been rethinking things and perhaps following JRPG menu conventions isn't really the best practice, since they are designed for consoles. Maybe... just maybe, the best practice might be PC-centric RTS menus? (Since its mentioned in the foreward that the interface design is still subject to change and all).

In the attached file, you can see the "dashboard" where you see the sprite of the character's head, and all the commands are already separated to have their own buttons so issuing a move, an attack, an inventory, or a skill are one-click affairs (or two clicks -- command and target/position select). You can even implement hot-keys, thus making nested menus unnecessary. I will also add this is where PC gaming shines... in addition to clearer high res graphics. In particular to the Warcraft example, you probably won't need the central area highlighting which units are selected (unless group attacks are allowed, but tactical games are usually involve ordering one unit at a time). That empty space might prove useful for in-battle dialogue though. And while larger-than-screen real estate maps are not yet allowed, we can do away with the minimap in the meantime, at least until scrolling is implemented.

I noticed that almost every RTS has basically the same intuitive setup, honed over the years. While their turn-based SRPG compatriots consist of a mess of nested menus. While good game design usually involves creating new mechanics and interfaces that are intuitive and easy to learn, it won't hurt to have a default layout which anyone familiar to gaming has already mastered. (Similar to the general VN structure that default Ren'Py main menus follow, but which Screen Language intends to break provided the gamemaker knows what he's doing).

[Jake]

I like how your magic is already in Rock Paper Scissors format (by generally taking out the Wind element) since I have [not-necessarily-magic] skills which are designed that way, so it's pretty much plug n play.

Bear in mind that if you want to change the way damage is resolved, you should be able to create a new DamageResolver (I believe the ElementalDamageResolver which is used by the examples is right at the bottom of BattleEngine/engine-schema.rpy, off the top of my head) and a new BattleSchema (of which there's an example in the assets.rpy file of the demo) to include that DamagerResolver in the battle.

(My intent is that it should be relatively easy for a programmer to extend the engine in this manner, by replacing/extending individual components of the engine that each do more or less one thing. One thing I'm planning to do is to implement a 'CustomSchema' that takes all the damage-resolver, game-mechanic bits as initialiser parameters so you don't have to actually instance a new class to replace one part of the battle.)

While all the other battles are 'easy', the Isometric Grid battle can be challenging because of it.

Mm, I didn't make much effort to balance most of the battles, so they're easy for the player to complete - the kind of thing you might see as random encounters in an RPG. The iso-grid demo is intentionally a lot more difficult to highlight the elemental rock-paper-scissors damage system. ;-)

Will there be plans to make your player fighters be selectable not by a menu, but by using the same "pointing gloved hands" used to select enemy targets?

I probably should have done this for the default UIProvider before releasing Alpha1, but yes. I do actually plan to create more-appropriate UIs for each of the main Battlefield types, so there'll be an ActiveUI which looks like an FF game, which won't be too different from the demo, and a GridUI which selects movement/target by highlighting the whole grid square instead of pointing at the fighter, and that kind of thing.

I'm thinking the next step might be implementing facing directions. In addition to quadrupling the sprite requirements, it will add yet another nest of menus in the sequence, e.g:

It's certainly fairly high on my to-do list, which is a little longer and more-detailed than the overview in the first post. I know more or less how I plan to do it.

Would it also be no small task to insert renpy dialogue in the middle of battle similar to the tile/unit engine? I can see a problem with roll-back going back to the battle demo selection menu (I accidentally scrolled the mouse one time)

I seem to recall that rollback is pretty easy to completely disable, so I should probably do that at the beginning of battles. I'm unsure about Ren'Py interludes, though. On one hand, they're dead easy to get in, we just need to call renpy.call_in_new_context (IIRC the name of the method) with the name of the Ren'Py-script label to jump to, and it'll execute the scene therein, just like it was normal Ren'Py code, and get back into the battle when that code returns.

The problem is that I don't know offhand how that will interact with saves. I think that if you save inside the Ren'Py interlude, then when you load, it'll take you back to the beginning of the battle, just like if you save in a battle... but I'm not sure. The reason it does this with a battle is because it's in Python code; I believe Ren'Py calls a save-checkpoint method upon each interaction and when you save, it just preserves the most-recent checkpoint (probably using the same system as rollback), so my worry is that in Ren'Py script called within a battle, it may checkpoint inside the Ren'Py script, save that, but without the call stack 'cause normally it doesn't matter, and when it returns the user will just be dumped back at the main menu. Which would mean that we'd have to disable saves as well within battles to avoid users saving their progress inside a battle Ren'Py interlude and losing their progress through the game.

Of course, I'll experiment and investigate and see what's best, it's something I do intend to include one way or another.


(The other potential problem is that all the battle layers are shown above the 'master' layer where your sprites and BGs normally go, but that can be fixed by just hiding all the battle stuff before calling the interlude, and showing it again afterwards.)

You mentioned implementing Items and Equipments. Maybe create some form of wrapper so that someone with elite inventory design skills can take care of all the equipment and inventory management (in a separate 'engine'), then just pass them on to the Battle Engine in parametarized fashion?

Well, put it this way: items in the engine need to have some degree of battle-awareness, so that - for example - a healing potion knows how to heal 200HP when it's used. My intention is to make the item/equipment support in the same fairly-modular way that the rest of the engine is built, and thus hopefully it'll be as friendly to program against as possible; at the very least, I expect that if you maintain your guys' sets of Things separately you should be able to empty the [Battle] Fighter's inventory before the battle starts, synch up with your other inventory, and then all you need to do is make sure your Items in the other system implement the same interface as the battle system expects (so the potion can heal, and so on).

I've been rethinking things and perhaps following JRPG menu conventions isn't really the best practice, since they are designed for consoles. Maybe... just maybe, the best practice might be PC-centric RTS menus?

It's certainly plausible. Hopefully this kind of thing can be relatively-easily implemented as a UIProvider class! (The UIProvider basically gets called by the engine with requests like "pick a target fighter for this guy; here's the source (the fighter who needs the target) and here's the list of valid targets and their respective ranges". The UIProvider is then responsible for doing whatever is necessary to pick the target (presenting a load of buttons, in the default implementation; maybe another implementation could try reading the player's mind, read input from a file, or randomly pick everything) and returning the target that was picked.

[Jake]

Also, the game crashed twice (it seemed to be Ren'Py itself crashing... I can't find tracebacks on .app distributions).

I saw this a couple of times on the Mac, when I went to quit... more or less as I mouse-overed the 'Yes' button on the 'Are you sure?' screen. It didn't seem related to what I'd done, how long I'd used the game for, how many battles had been fought or what had happened in them. Was this the same point that it crashed for you, or was it somewhere else?

I'm sure you noticed, but if you download the Windows version all the files are unarchived, so you can just drop it into a new project on your Mac and run it outside of the .app... but I didn't get a traceback for the crashes I saw anyway. I'd be interested to know if you do, and if you do to see it!

The plus side is that I never saw this behaviour at all on my Windows box, it seems limited to OSX (although I don't know about Leinnucks). I spent about equal time on each machine while developing the engine, and both machines are more or less identical in hardware spec (one of them has the mobile version of the other one's graphics card, even), so I'm presuming for the moment that it's a bug in either Ren'Py, Python or one of the libraries used on OSX... and I'm wondering whether it'll magically go away with 6.11, so I've not put any thought into it yet.

But as it goes:

I think it seems to be a similar issue to the tile/unit engine where displayables create some form of hog and don't get flushed in time or something, since I had been playing battles one after the other.

I'm not so sure. Firstly because the crashes I saw on OSX weren't dependent on how long I'd been playing, and secondly because the crashlog file you gave (while I'm no expert at reading such things) looks to me from a quick scan like it's crashing in thread-synchronisation code.

And unlike the tile/unit engine, which I gather used a displayable for each grid square, the battle engine is pretty Displayable-light; there's probably more Displayables on-screen in the snowblossom demonstration in the Ren'Py demo than for this (one for each fighter, one for the BG, one for each bit of draw-over-the-top-of-fighters scenery, one for each spell that gets cast, one for the bouncing damage and then assorted UI widgets which have been used far more numerously in some other games, such as Jack Norton's stat-building management sims).

[shahab96]

Can you tell me exactly how I can integrate this into my game (I dont really have much experience in Python just a week or so of the basics) so that I can start a battle at any point in the game?

[Jake]

Can you tell me exactly how I can integrate this into my game (I dont really have much experience in Python just a week or so of the basics) so that I can start a battle at any point in the game?

Have a look at the demo files - active_demo.rpy is a good place to start. The code is commented, telling you exactly what you need to do to set up a battle, and why. If you want to add more spells or change the sprites, go and look at assets.rpy.

The glib answer is "copy and paste the contents of active_demo.rpy into your script in each place you want a battle"... without more specific questions, there's not much I can really say. :/

[shahab96]

[quote=Jake]without more specific questions, there's not much I can really say.[/quote]

ok...i'll be more specific this time.
1) I need to know which files I need to copy paste and where to do them.
2) When I want to start a battle in my game how will I give renpy the reference so that it know where to load your engine from? Should i make it a label or do you have one premade that i can jump to?
3) If i need to import your engine into my game what code should I use?
for example in java you would use import (package.*)
in c++ you would use #include <whatever>

Well those are the three questions i needed you to answer.
Sorry for not pointing them out before.