Sun Jul 05, 2020 7:42 am
The battle engine is indeed, getting long in the tooth. It's probably one of the still most 1998-ish aspects of the engine (when it still had no plotscripting). It's still largely a black box - you send players into it, you lose most of the control you had over the game with plotscripting, then the battle engine returns them to you hopefully unscathed.
This is not anyone's fault. Almost nobody wants to touch the thing. It's practically an engine unto itself. I tried to replicate it for a Windows port ages ago and the battle system is what made it fail because it was way too overwhelming to even imitate as a novice programmer. Even with experience I have now, it'd be an undertaking.
It also has some issues, like how even if you do a complicated script that makes your game THE NEXT GENERATION OF OHR TECHNOLOGY, once the player goes into the battle engine it's like showing them flashcards. You can't even do something as basic as change the resolution, it just breaks battles instantly. Once again, this is nobody's fault, because the battle engine is almost a quarter century old.
I think the largest problem with the engine in it's current state is that you can't even do simple variations on the Final Fantasy 2/4/whatever it's imitating anymore theme. Let's say I want a hero to be a berserker. With actual scripting, I could script an attack where the hero dashes forward, hits, and then steps back just in front of the enemy (instead of returning to the default position) to signify they're in the berserk state. I've checked the documentation and sources, and you can't even do something as simple as this, even if you throw mountains of faked enemy spawning and stuff over hours
Whereas with a theroetical scripting, it'd be a simple as:
attack, gointoberserk, begin
move hero to enemy(thishero,target)
set hero home (enemy x + 50, enemy )
set hero defense (50%)move hero to home
Now, making your own battle system is all well and good. People have pulled off AMAZING battle systems using the slices and so on.. but at this point those battle systems are the equivalent of telling a newbie "to first make an apple pie, you must create the universe". Slices walk that thin line between scripting and outright self programming your own engine, turning the OHRRPGCE from an RPG engine into more of a graphics library. Once again, nothing wrong with that, but it can't be the first answer to a newcomer that wants something more than what the battle system offers. (Also, the OHR still has no real basic database creation/retrieval/updating, which can make creating your own battle system, or any system, a pain int he butt unless you want to consume a lot of globals or re-use items/heroes/etc as data holders)
For starters, any new battle system for the OHR needs to be made out of scripts. Everything needs to be a script. This is so it can be easily modified without having to have TMC or James or anyone else willing to program in FreeBASIC modify the battle systems themselves after setting up the foundation. This also makes the battle engine more modular. Even the basic attack needs to be a script.
Secondly, THIS WOULD NOT REPLACE THE CURRENT BATTLE SYSTEM. We would leave the current 'default' battle system in the engine. We could maybe think about converting it so it's made out of scripts itself. But we don't have to and shouldn't throw out what's there. We're not gonna kill off every pre-2020 OHR game to achieve this.
.. I can understand at the same time that some of us here have 20 years of experience with the battle engine. Nothing wrong with that.
Thirdedly, it would probably be a good idea to think of Battle Scripting as it's own language at this point. You could bring over some of the plotscripting concepts, but now would be a good time since we're making a whole new default battle engine, to give it a scripting language or syntax that has the ease of use of Hamsterspeak but sheds some of it's old limitations, like the wonky way strings have to be assembled, etc. We don't have to worry about backwards compatibility here. Also, it may be a good idea to set up script 'chunks' like how Game Maker's drag-n-drop style of scripting works.. designers could assemble 'script chunks' in GAME to make attacks, etc. Yes, it has slices, but maybe this is the change to have some more object oriented commands, sane strings, etc.
Also, to do this is a BIG undertaking. Sounds weird I think the community needs to actually Project Manager a feature like this, to suss out what people -want- the engine to do, make a rough outline, prototype the UI, menus, concepts before sending James and TMC on a wild goose chase.
For example, we already have enemy formations and hero formations. But it'd also help if formation had points of interest you could also drop onto the field, like positions you can move the hero to, or where attacks can sit when cast, or even as a grid-note if you want to make a Tactics style game. Sure, you could add generic node editing to the current system, but then you need TMC or James to glue it to something else.
I'll go over the pros, cons, and caveats in a sort of "risks assessment" style.
Pros of the current battle system
Easy to get a battle up and running
You just assign heroes attacks and enemies attacks and it Just Works.
A lot of the animation styles are handled for you
Perfect if you want to emulate early Final Fantasy titles unless you do a lot of fancy things
You can ignore it entirely if you're good enough to script a replacement from scratch
Cons of the current system
Limited to 4 heroes.
Only does FF2-4 style battles (Without of trippy hacks in-editor to fake first person, etc)
all positioning is based off hero or enemy positions. you can't make formation nodes, you can't have heroes idly move around, enemies can't idly move around, you can't even dynamically make the formation backwards for sneak attacks without having to manually rig a sneak attack version of the formation
it's an absolute PAIN IN THE BUTT to even fake basic functionality like dialogue, voiced or unvoiced
You have to spend lots of time to replace it to even get to basic functionality like stances. At this point you're either experienced or you're not gonna finish your replacement, or it's gonna delay your game by years.
Even getting new animation styles or methods requires manual addition by a good programmer like TMC or James. This makes them a bottle neck but also can lead to burning them out on minutae
Caveats of going to a new, script based system
It may require rethinking of what default OHR battles look like.
It will require making the battle editor more battle style agnostic (it will basically be a diorama editor in a script-based battle engine)
It may require it's own scripting langauge, and way of thinking how scripts execute. It may, for ease of use, need to be an event-based style like Game Maker where it's "when the ready bar finishes, then run the hero select attack script" instead of making players make a manual while loop job queue.
You have to consider a battle engine is both part D&D equations math editor and part animation studio. A lot of battle scripting will need to do a lot of heavy lifting for the user re: animations if we are to keep the 'ohr is easy to learn, easy to master' mantra. Nobody should have to know how to calculate the arc for a jump, it should be a command called 'animate to enemy(style:jump)' or something like that.
This will take a year, minimum, to go from an alpha state to 'retail' ready. Did I mention this is a huge undertaking?
Hooking up all the plumbing to this system may take some rethinking of how CUSTOM works with editing battles. The community needs to all work together on this one and talk honestly about how the UI should work/look/feel. It will be possible to make mock-ups to test. This is where the non-programmers especially can contribute. The UI and pseudocode should be in place before even a mote of dust of real code is written on this.
Success will mean every pre-2020 OHR game will definitely start looking out of date compared to games that are updated to take advantage of the new battle engine. This will be another watershed like plotscripting was.
The new way should be designed without caring about backwards compatibility with the old battle engine for this reason. Worry about mapping legacy OHR battles into the new Battlescripting environment later, until then both the current (legacy in this post) and the new systems can exist side by side. If we can 100% replicate the legacy battle engine in the new one, then come up with a method to autoconvert all old games to it and just make the legacy engine a 'module'/package/whatever in the New Way(tm). If not, then just leave the existing battle engine as an option you turn off or on with a bitset.
Slices have been both a blessing and a curse. We no longer have to make tall NPCs out of 2 kid NPCs in a trenchcoat, but some custom stuff looks to a beginner like 'first draw a circle, then the rest of the fucking owl'. Battlescripting, and just refreshing how battles work, we can keep both the OHR Just Add Water aspects of having a running game while still letting people absolutely free to ignore the boundaries of what they thought before. And new people is what we need to keep the community alive and fresh and
trick encourage even more people into game making as a career.