switching officially to a plotscripted battle engine...

[shakeyair]

I have been thinking about plotscripting lately while coding a custom battle system for a new project, specifically that it is currently possible to recreate the OHR's default battle system in it, at least visually. And if the rest of the information for enemies were made available to the scripting api, as well as the rest of items and attacks information, and formation sets, etc, the whole battle engine could be plotscripted, and it shouldn't even be especially difficult, though quite time-consuming.

(In my battle engine, stats are all held in slices and children of slices, i worried it would be slow but it actually runs with no delay, even with all the stat checks and child shuffling)

But if this was done, then new OHR games could include the default battle engine set to some sort of 'battle engine plotscript' put probably in 'Special Plotscripts,' already imported, and an instruction to new-comers to include a 'battle.hsi' or such file in new plotscripts so as to not delete it accidentally. For backward compatibility, custom and game could import this script into the proper location automatically. Potentially game breaking features could be added because old files would have their own battle plotscript, and if game and custom simply did not update in automatically, old games would still use whatever the battle engine code was when they were written. Games from before the battle engine was plotscripted would be updated with the earliest script file if a later one would break any compatibility, which would include all the features of the then-current battle engine.

The advantage of this would be easier forking of the battle system, someone, for example, could change it with minimal work to support enemy animation, and if they did it correctly and simply in such a way that didn't break backward compatibility, it could be added in to the official one incredibly easily.

Things that would became new features would then be integrated by developers into the GUI, only having to pass data. so even if a community member added a feature everyone wanted, and it got 'voted in' so to speak, it could quickly become accessible to anyone with no knowledge of plotscripting with just a simple addition by the Devs.

Also, 'battlescripting', if it was set up correctly, would then be fairly trivial, and it would be easy to make an attack trigger a script to start it.

Certainly, the primary advantage of the OHR is the ease of use for newcomers to jump right in and tell an epic story without the worry of making everything work, so at least the default should require no extra scripting. but plotscripts designed to be used in battle could have a 'return to battle' (that put everything back in place in an automated way) the script that can be run after them to not obstruct the flow of things, and even inexperienced plotscripters could implement scenes or new sorts of special attacks fairly easily. and updating global variables based on certain criteria would be trivial.

Perhaps it would be better to wait until plotscripting has actual arrays, and for the new plans for animations to be in.

Certainly, to be made sure it was done correctly, a lot of thought will need to be put into the setup and logistics, but there are a lot more members that know their way around scripting than they do around the source-code, and needed scripts could be delegated throughout the whole community as opposed to the much fewer who know their way around the source code.

Anyway, just looking to start a discussion since i had the idea. things i missed that make this potentially a bad idea? Thoughts?

TL;DR VERSION: I see many advantages with switching to a plotscripted clone of the OHR's battle system. These are outlined above. Are there any drawbacks i am not noticing? Are there any other thoughts?

[Mogri]

If you haven't already, you should play and take a look inside Do You Want to be a Hero? (link in sig). It implements a custom battle engine in a manner not unlike what you're describing. If you are interested (or anyone else is, for that matter), I can make the scripts available.

[crowtongue]

Thread necromancy is a bad practice, I know. But this seems like such a good idea.

It would also be a much better way to learn plotscripting, as you would start with a script that you could make incremental changes to and learn what everything does.

Anyways, seems worth the discussion.

[Bob the Hamster]

This idea absolutely makes my skin crawl. Horrifying. I absolutely don't want to do this.

However, later on, when the plotscripting engine supports real strings, real arrays, maybe even real structured types, then I won't feel so bad about this idea.

We do already have a plan for eventually migrating to supporting scripting in battle systems.

http://rpg.hamsterrepublic.com/ohrrpgce ... escripting

[crowtongue]

So the reason you don't like this idea is because the script would be really messy/hacky as opposed to properly programmed?

Battle scripting sounds nice, I look forward to that.

[TMC]

Yes, reproducing the battle system in HamsterSpeak as it is now is obviously a non-starter.

We can never build enough options into the engine to make possible everything that anyone is likely to request; we should not even try. Greater scriptability is a must. The plan in the medium-term is to add battlescripting and to allow replacing different parts of the built in battle system with scripts. For example, scripts to calculate the damage that an attack does, whether an attack misses, preferred targets, enemy AI, and determining enemy and hero counter attacks. As well as scripts being triggered by attacks and things. I think we would likely also expose the internal functions for doing some of these things to battlescripting so that they could be wrapped, or rewrite them as scripts so that you can copy and customise them.

Converting the whole battle system does have those nice advantages like allowing compatibility breaking changes, but it would also be a huge amount of work. I have no idea how many other internal functions the battle system code depends upon which would also have to be converted to scripts or exposed to scripting. Also you would probably find that a lot of it is dense code which is difficult to modify.

Someone can always come up with a scripted implementation of a simplified version of the battle system; it could even grow in time to emulate the whole thing if someone wants it.

[crowtongue]

I hear you... If you create more options for people to use with scripting, eventually it will be easy enough to recreate the battle system with scripting where it won't be a big deal. That sounds like it makes a lot more sense.

Glad to hear that battle scripting isn't too distant in the horizon.

[shakeyair]

Glad to hear that battle scripting isn't too distant in the horizon.

Don't get your hopes up for it to come soon. There's A LOT of stuff the devs need to get to first, before its feasible.

My main thought when initially suggesting this was simply that plot-scripting's functionality has grown by leaps and bounds, whereas the battle engine (while it has made significant strides) has advanced much more slowly.

But I'm sure the battle engine will take off once the groundwork is laid, just like slices did.

However...

Converting the whole battle system does have those nice advantages like allowing compatibility breaking changes

That seems really useful? I know how you guys struggle with back-compat. And while it would be a ton of work, I bet more people would get involved. I'm sure I'm not the only one who would love to help out with the engine, but has absolutely no knowledge of code besides plot-scripting.

[crowtongue]

Glad to hear that battle scripting isn't too distant in the horizon.

Don't get your hopes up for it to come soon. There's A LOT of stuff the devs need to get to first, before its feasible.

The plan in the medium-term

Worth pointing out for sure, but I was responding to TMC's response so no worries there

Someone can always come up with a scripted implementation of a simplified version of the battle system; it could even grow in time to emulate the whole thing if someone wants it.

I've been thinking more about this today, and I think that this could actually be a really good idea. It would be interesting to see it developed in a way where it could be at least semi-modular,and broken down in the form of a tutorial or something like that.

But this takes not only someone who can execute it, but also someone with the time who is willing...

I also realized today while sorting through my emails that before I signed up here I had emailed Mogri to get the DYWTBAH? script he references in this thread, and opening it up gives me an idea of the complexity. Really cool stuff, though.

[marionline]

Reading all this made me think about how a battle engine would look like.
I've never made one, so i'm rather guessing. I tried to imitate what the Engine does now.
It's all theoretical and I don't know if it's possible with the script language to get something like this to run, for example if values can be given from one script to another that easily.

What do you think about this? What has to be improved?
Did I overlooked something important? Made I things more complicated than they have to be?

Battle Engine
Battel Screen + Gaphics Script (handles all the graphics, drawing and removing)

Action-bar Counter script (reads from Enemy Stats and Hero stats, mamages who can attack or do something)

Enemy scripts
-Enemy stats script (sets the stats for battle and organizes stats changes)
-Enemy attak script (chooses an attak and tells the graphics script to draw it on the screen, adresses Hero Stats script for damage)
-Enemy holds item script (checks in the enemy has an item (you can steal, a streal attack would adress this script and the Hero Item script))

Hero script
-Hero stats script (sets the stats for battle and organizes stats changes, tells the Graphics script to change Heros look according to HP)
-Hero Item scrip (reads the amout of items Hero has and manages changes to this)
-Hero Menu script (gets told by Action counter when to show up, tells graphic Script to be drawn)
-Hero menu Item script (lets you choose and item, if its useable as attack it calls Hero Attack script to reform the attack, tells Hero item script to decreas the amount of items etc.)
-Hero Menu Attak script (lets you choose an attack, and tells the Hero Attak script)
-Hero Spells Menu (lets you choose an attack, and tells the Hero Attak script)
-Hero attak script (tells the graphics script to draw the attack on the screen, and tells the Enemy stats script to calculate the damage with the attaks damage value)

But this takes not only someone who can execute it, but also someone with the time who is willing...

What about making a projekt out of it where several people can work on? I'd like to help, but i'm not a good scripter.
It could be chaos in worst case, but in the best case we would have a nice battle engine. (It dosen't have to be official, if that's not wanted.)

[TMC]

Yes, I do hope to add "immediate mode" scripts in the next version (scripts like attack damage, which are called like a function and must return a result immediately without waiting), while more general battle scripting (including commands to manipulate stuff in-battle) is much more work. (But that was also the hope for Beelzebufo, and it didn't happen.)

A custom battle system with lots of features built in would be nice. It would probably be more useful to users than a port of the existing battle system to HamsterSpeak, which I think looks pretty unlikely.

If you want to contribute to the engine but aren't a programmer, you can! See Contributing. The HOWTO is badly in need of updating. I think most of the material has not been changed since the 90's. Even if you don't want to write anything, you could go through the HOWTO and update the 10+ year old screenshots. (I recommend talking to BMR, who said he was working on a rewrite of the HOWTO. Maybe he needs prodding, maybe he has partially finished material, or maybe he needs to admit he won't be finishing it.)

In addition, the plotscripting dictionary could do with lots of improvements. I only just put it through a spell checker for the first time recently. I want to add "topic" sections to it explaining things like hero ID vs. party slot vs. rank vs. active party slot. Or you can submit improvements to F1 help pages (which I figure also need hyperlinked pages for better organisation).

[marionline]

Wow, so many ways to help!
Sounds good! I'll try to help.

How about making the dictionary part of the wiki?
We could add tags to each little entry, so it can be found more easily. The Page could be either in some kind of alphabetical list or sorted by topics.
That way there could be also added more plot script examles to the dictionary.
And, by the way the dictionary really needs to be more readable. ^^"

I want to add "topic" sections to it explaining things like hero ID vs. party slot vs. rank vs. active party slot.

This sounds helpfull.

[Pepsi Ranger]

For Callipygous, I would really like to see the zones feature completed (we're still waiting on zone script triggers on hero and NPC entrance and exit, I believe, and maybe one or two other features). It would also be nice to see some strides made toward improving shops and finally, after all these years, get us in the direction of plotscripting shop features.

And, of course, script-multitasking, but I will always hope for that next.

...wait, this has nothing to do with the original topic, does it? For a moment I thought I was responding to the Beelzebufo release candidate thread thanks to all the talk about updating the plotscript dictionary. But since we're talking about things to do next, I figured I'd just give my two cents here.

[TMC]

Whoa, this isn't a feature request thread.

The Plotscripting Dictionary used to have a copy on the wiki, one page per command, but they were labouriously deleted because they had become out of date. We didn't have any decent way to copy changes made on the wiki back to the main copy.

If you want to make improvements to the dictionary, I've added a page explaining how to do so (but maybe it needs more details).

Also, I'm pleased to see Jack has started updating HOWTO screenshots!

[Mystic]

So uh... Silhouette actually does this pretty well, if I may say so. It also supports rudimentary animations, although none were used in my release.

The main reason I scripted my own battle system was so I could:

• Have more complicated attack AI scripts (You can't really tell that this happens in my release, but you can get some hints by the way the only boss works) but in some of my designs there are Chrono Trigger esque combo attacks, including ones done by the enemies, as well as a much more complicated set of attack preferences (there are enemies who use how much damage allies have been taking to choose to buff their armor or to attack that turn)
• Have much more complex status effects, along with multiple stacking status effects (you can see this in game, with status icons)
• Allow for 6 person parties and the possibility of switching party members in the middle of battle (and also having location-matters attacks, Etrian Odyssey style)

I could probably spend some time severely cleaning up the code and getting rid of the Silhouette-specific stuff, then releasing it out. (Though I am nervous at making my code visible: I learned a lot while making it and a lot of the stuff is probably embarrassingly bad!) The next step would be emulating the different attack effects supported by the main engine, since my current attack animations just display the 1-2-3 on top of the enemy.