Castle Paradox

[ShakeyAir]

Re-posted from slime salad:

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?

[Baconlabs]

I can imagine the only-one-plotscript-can-be-run-at-a-time thing would be problematic to your plan, unless I missed something.

[ShakeyAir]

While plotscript threading would be beneficial, unless i am over-estimating the speed in which i have seen scripts run at, i doubt it would be necessary.

I had set up the start of a ATB-esque battle system when i was playing with scripting before. I scrapped it, because I had set up the way enemies and stats were referred to terribly, and then I have been playing so much of the various MOTHER games lately, that I decided I wanted a much more MOTHER-esque system, so I started with this new one.

But basically the way to keep things smooth is to have a script called 'battle wait' that takes a tick duration as an argument, and calls scripts that update things that need to continue happening during other things. (animation, ATB gauge, etc) Granted, my engine did not get incredibly complex, but it seems like you can call a lot of checks and commands in a 1-wait duration before ticks get any longer.

My Tetris clone, for example, updates slice frames, checks collision, gets player input, updates the score, animates effects, checks for losing conditions, and asks probably over 2000 if questions every game tick, which involves at least 2 loops that cycle through over 750 slices/global variables. the title screen, while it does not check collisions, does the frame-changing of 1500 slices, gets player input, does the top-layer animations, etc. etc. I have tested it on at least a 3 year old laptop that was not very good to begin with, with no slowdown ever happening. I realize some commands are time consuming, (I believe 'replace sprite' is?) but they are few and far between, as to my understanding. And yea, the battle system probably would do more than that, but as long as things aren't run superfluously, I doubt it would ever get slow.

[Bob the Hamster]

The plan we are probably going to eventually end up going with for the battle system is this one

Also I am really reluctant to add commands that give raw access to data. For example, the current commands for reading and writing enemy data are difficult to keep backwards compatible, and make it harder to upgrade the enemy data file format.

However, after the plan for dynamic types is finished it will become much easier to give plotscripts access to lump data in a way that will be easy to keep compatible.