Anyone interested in a turn-based RPG combat engine?

[Formedras]

I'm currently making a game set in a fantasy-RPG universe (of my own design - this is NOT a fanwork), and I decided a few days ago that the game was just begging for a combat engine. The style of the game is pretty much "take it slow", so it had to be turn-based. (Plus, I'm not exactly a programmer and trying to implement a real-time or ATB system would be psychological suicide.)

So far, I've used the stats_frame from the demo's demo_ui.rpy and reworked that into a general statframe, and gotten a Python routine that has "Who takes how much damage?" in button form, even being able to select which characters are in the player and enemy slots (currently just called Player 1 and Player 2). I'm still working on it (I just finally got that Py routine working today) and I hope to have something usable within a week. (That is, if I don't experiment TOO much and try to stick to the point.)

I read in an old (by at least a year) post that someone wanting to use an RPG engine should think about using something dedicated for THAT instead. Of course, that's obviously reasonable if you can figure out what you're doing. (Personally, I never figured out HamsterSpeak.) But for me, at least, I figured that even on a non-linear path, I prefer the narrative structure of a VN, but still want some sort of RPG engine. So I decided to make my own. (Plus, I wanted a turn-based system. I don't know of any turn-based engines anyway.)

Is there anyone interested in the engine? (Heck, is there a chance that it would be a good idea for posting on the wiki as a framework, once I finish it up?) I know I don't have it available yet, but if someone asks I'll probably do it. (Hey, I'll probably do it anyway. I have the personal webspace.)

[N0UGHTS]

:raises hand:

Even though I'm as competent at programming as someone who's zonked, I'd be interested in the engine. And playing a game with it, too... Though I guess I'm biased. I grew up with turn-based RPGs afterall. :p And posting the framework on the wiki sounds like a good idea too me.

I say, go for it!

[Midnighticequeen]

I support you in this, it sounds interesting, I'd like to try it when it's done

[Aenakume]

Just FYI, i'm workin on a walkabout engine - which is basically where you have a scene with a character sprite in it, and where you click the character walks to (assuming there's nothing in the way). Events can be triggered (which means labels are jumped to) by entering hot zones or touching other sprites.

This doesn't overlap with what you're planning, i think... but the two engines might work really well together. It would be rather like one of the older Final Fantasy games, where you walk around a scene and bump into enemies (using the walkabout engine) that gets you into combat (using your RPG engine) - or even random battles if that's what you want, i guess.

[jack_norton]

Both ideas sounds very cool go for it!

[monele]

I think a tactical (well, tile-based) RPG engine was in the works for that "do something for RenPy" contest (not really a contest but I'm lacking a better word).

Ahh, there we go :
http://lemmasoft.renai.us/forums/viewto ... ile+engine

[Formedras]

I see that there's at least ENOUGH support to warrant continuing on my work. Just to make sure I'm on the right track, try out what I have so far.

Currently, it isn't complete; it is incapable of handling a full battle. CTB-like Turn-based PVP hotseat combat using different-powered basic attacks is the next step, using the "Refresh Meters (Python Calls)" code as a base.

Note that I made this ZIP using Build Distributions, so you'll probably going to want to just copy over the game directory over to a Millions Combat Test folder in your Ren'Py directory.

Also, I've already said I've used Ren'Py demo code as a base. I also use the Editor button from the demo code. So just consider the project under the same license as Ren'Py itself.

[DaFool]

Sorry, I didn't mean to hijack the RPG combat engine, but this:

Just FYI, i'm workin on a walkabout engine - which is basically where you have a scene with a character sprite in it, and where you click the character walks to (assuming there's nothing in the way). Events can be triggered (which means labels are jumped to) by entering hot zones or touching other sprites.

This doesn't overlap with what you're planning, i think... but the two engines might work really well together. It would be rather like one of the older Final Fantasy games, where you walk around a scene and bump into enemies (using the walkabout engine) that gets you into combat (using your RPG engine) - or even random battles if that's what you want, i guess.

is just totally awesome. I just hope the number of animation frames for the front / side / rear views are expandable so we're not constrained to chibi sprites. Not everyone may like battles in their RPGs, but walkable sprites are mandatory for any sort of town / dungeon exploration.

[herenvardo]

I read in an old (by at least a year) post that someone wanting to use an RPG engine should think about using something dedicated for THAT instead. Of course, that's obviously reasonable if you can figure out what you're doing. (Personally, I never figured out HamsterSpeak.)

Hmm... sounds quite familiar... I think I was told these things some time ago...

So I decided to make my own. (Plus, I wanted a turn-based system. I don't know of any turn-based engines anyway.)

RPGMaker is essentially turn-based, although it messes things a bit and ends up having almost real-time combats... chronoluminaire's battle system in Elven Relations, while having some UI similarities with FF and RPGM, and timing some of the stuff to get a better impression of dynamism, was actually turn-based. I think monele's Ren'Py Generic Battle was also turn-based. Furthermore, the original system I made for the Fall of Jayshn project (check the first link on this post) was also turn-based; as well as the rewrite as a fully-fleshed UI I'm currently doing to it. So, there are some turn-based combat engines out there built upon Ren'py, and some more are WiP. Of course, if the already available ones don't match your needs and the ones under dev don't match your schedules, then be bold and go ahead making your own. I'm just mentioning these ones because you said you didn't know about anyone, yet there are some already there.

Is there anyone interested in the engine? (Heck, is there a chance that it would be a good idea for posting on the wiki as a framework, once I finish it up?) I know I don't have it available yet, but if someone asks I'll probably do it. (Hey, I'll probably do it anyway. I have the personal webspace.)

Sure: there will be interested people. Each post of engines of this kind has attracted at least some attention, and that's for a reason: there is interest on the topic. I can remember some skepticism during the Nano'06 times (when I was starting with the FoJ project), but currently there are some examples of games that include RPGish combat and still are great Ren'ai VNs with lovely characters and stories (the clearest example I can think of is chrono's ER, but I can be quite biased about that one). So, with these precedents, and assuming further works keep up with that level of quality, I'd expect the interest in subengines for hybrid games to keep increasing indefinitely, also bumped by the growth of this community.
Will other people end up using your engine? That'd be a real question, and the answer only depends to you. If you can make your engine extremely easy to use, or extremely easy to customize, then it's likely it will find a home in some projects. If you achieve both things, then you'll have proven to be a genius and I'll raise a monument in your honor

Not everyone may like battles in their RPGs, but walkable sprites are mandatory for any sort of town / dungeon exploration.

I've to disagree on that. As of currently, FoJ includes over half a dozen dungeons, and there is absolutely no "walkable sprites" nor any kind of maps (except for a concept map to help development, but that's quite unrelated ). Honestly, I'm deliberately avoiding mapped dungeons to avoid the chance players would "learn" them, thus ruining the replayability (with a total of 30 character pairings, the game is not aimed to be played just once). I'll consider some sort of mapping if I can come up with some kind of map randomization like Blizzard did on Diablo II. To put another example from Blizzard, I probably could enter the Deadmines in World of Warcraft, reach the final boss, and bring him down blindfolded, and even ensure I'd only engage those enemies which must be downed to advance ("door" bosses): that's what I want to avoid in FoJ's dungeons.
Anyway, even if not mandatory, a walkable sprite engine/framework would be quite useful for many projects.

[DaFool]

Not everyone may like battles in their RPGs, but walkable sprites are mandatory for any sort of town / dungeon exploration.

I've to disagree on that. As of currently, FoJ includes over half a dozen dungeons, and there is absolutely no "walkable sprites" nor any kind of maps (except for a concept map to help development, but that's quite unrelated ). Honestly, I'm deliberately avoiding mapped dungeons to avoid the chance players would "learn" them, thus ruining the replayability (with a total of 30 character pairings, the game is not aimed to be played just once). I'll consider some sort of mapping if I can come up with some kind of map randomization like Blizzard did on Diablo II. To put another example from Blizzard, I probably could enter the Deadmines in World of Warcraft, reach the final boss, and bring him down blindfolded, and even ensure I'd only engage those enemies which must be downed to advance ("door" bosses): that's what I want to avoid in FoJ's dungeons.
Anyway, even if not mandatory, a walkable sprite engine/framework would be quite useful for many projects.

Just to clarify I was thinking of the classic hand-painted pre-rendered 2D backdrops when I made that comment. Semi-randomly generated dungeon encounters while more replayable, have less 'art' presentation.

[herenvardo]

Just to clarify I was thinking of the classic hand-painted pre-rendered 2D backdrops when I made that comment. Semi-randomly generated dungeon encounters while more replayable, have less 'art' presentation.

Of course, if you want classic exploration by walking through a backdrop, then indeed a walkable sprite engine would be a blessing.
I'd also like to clarify myself, and I'll do that with a couple of examples:
On Grey's Heikou, there was a "dungeon" (more exactly, it was a maze) which was, AFAIK, not random. However, there was no map of any kind in the game: the maze's layout was hard-coded in the game menus. I had considered using a similar approach for FoJ, but finally decided against it: it'd be quite easy to get stuck (Heikou dealt explicitly with this possibility, by triggering some "help" if you were having a bad time in the labyrinth); and it would still be possible to "learn" the dungeon, so on the next playthrough you could do something like "left-left-patrol-right-boss" knowing it's the most direct path to the boss... that's raiding rather than exploring; and it's not the approach I'd like FoJ players take.
On Blizzard's Diablo 2 (and maybe on the original Diablo, but I haven't played it so I can't know), maps were randomized once per game: sure, the Cairn Stones are always in the Stony Field; but on each game you might need to explore most of the field before finding them. There was a map, which was uncovered as the area was being explored, and this approach could be reasonably implemented upon a walkable sprite engine (just having to create a custom Displayable that builds the whole picture from randomly-picked tiles), and something like that would be ideal for FoJ. The only reasons I haven't gone straight to such approach is that I haven't been yet able to come up with an appropriate randomization algorithm; and I'm not sure if I could be make that approach work properly side-to-side with my CEAIE*.
With this, I'm trying to show you that "randomized" and "walkable sprite" dungeons are not opposite: Heikou would be neither of that; while a Diablo-like implementation would be both.

Let me go back for a moment to the original quote:

walkable sprites are mandatory for any sort of town / dungeon exploration.

I have highlighted the part that forced me to disagree. I guess my disagreement is with the wording, rather than with the (now clarified) idea There are some sorts of town / dungeon exploration that don't use walkable sprites at all (like Heikou, relying on menus to explore a dungeon; or a game you surely know which uses plain imagemaps to explore a town).

[Aenakume]

My motivation for the walkabout engine was two-fold - personally, i want to see if i can make a limited form one of those old-school Maniac Mansion or Day of the Tentacle type SCUMM engine games in Ren'Py... and secondly... the dating sim engine seems to ask for (at best) an image map to choose the day's events (at worst, just a menu), but i thought instead of just clicking on the locations, walking to them creates more interesting possibilities, with chances of random encounters with one of the datees or things like if you stop to talk to one datee while another one is walkin nearby their jealousy rises, etc. etc.

i don't know how well the walkabout engine will work for a dungeon exploration game, but it might be pretty sweet. You could make a huge map and put the whole scene in a viewport so only a bit is visible at a time. It should be pretty easy to randomize the scene on each playthrough, too.

[monele]

I'm reminded of a game, top-view, similar to most old school RPGs, that was purely a dating sim... but you had to walk around, go to places at the right time, meet people in the streets of the little town and such. Never played it but I remember reading about it and thinking "hey, this is cool!". Also, I think the Idol game posted a while ago works that way too, right?
So ya... this could also be fun... but there is a question as to which engine is better fit.

[Midnighticequeen]

I personally think both engines sound interesting, and I can't wait to try them out.

[jack_norton]

Personally I can't wait to try both too. And I really don't think "you need to use a specific program". The best situation for any game developer are libraries/add-on like those 2 that can be added on top of a very good solution which is Renpy (not talking about the possibility to expand/modify it yourself using python).
I've tried LOT of those so called game engines, and if I'm doing 3 games with Renpy at the moment, believe me, it's because it's simply good