Post new topic    
Page «  1, 2, 3  »
Liquid Metal Slime
Send private message
 
 PostSat Jul 04, 2020 3:54 am
Send private message Reply with quote
The battle system requires a few things before battlescripting can be added. It needs to be converted entirely into slices, so the UI is customizable as with using the slice collection editor or in-game slice debugger. It needs to accommodate resolutions other than 320x200. Neither of those things is battlescripting, but their absence precludes it.

Beyond that, what do we need? A list of script commands and script triggers that need to be added? Does it need to be more complicated than that?

The most important things I can think of are the triggers:
    Start-of-battle script
    Enemy Death script
    Ally Death script
    Attack: After/Before script
    Hero: After/Before attack script

as well as the commands:
    wait for attack
    suspend/resume heroes/enemies
    start attack(attack id, target)
    various get/set commands for attack data (other than name and caption)

It seems to me like there should be relatively few new commands added, at least at first. It's more important existing commands be functional inside battle. Like Bena's saying, removing the stark difference between the battle engine versus the rest of the engine. Commands for showing text boxes, opening menus, waiting, manipulating slices should all work inside battle if the aim is to be fully customizable.
Ps. I love my wife
Slime Knight
Send private message
 
 PostSat Jul 04, 2020 4:42 am
Send private message Reply with quote
Thanks, Kyle! Good stuff - for anyone who has specific suggestions like Kyle, I will pool it all together and post them
Metal Slime
Send private message
 
 PostSat Jul 04, 2020 6:34 am
Send private message Reply with quote
As an old man who just stops by from time to time remembering the old days...

What is it that makes "out-of-battle" feel reasonably customizable while "in-battle" does not? I think that, in fact, a new user asking questions about "out-of-battle" options would very quickly run into an answer like, "You'll need some plotscripting for this, but it's not hard, let us help you." Meanwhile, a new user asking questions about "in-battle" options would be more likely to run into answers like, "You'll need plotscripting, which in turn means you'll need to script the battle system from scratch, frownfrownfrown."

So yes, I agree with Artimus (and disagree with Charbile) that accessing scripts in battle-mode would be very beneficial for the engine. However, as has been pointed out many times, this is a large undertaking and it's not entirely clear what the end result should look like.

I agree with Kyle that converting the battle-mode to be built out of slices is probably an important start. But it's also important to think about how, in out-of-battle-mode, the Engine itself makes scripting easier. For instance, scripts that move NPCs on maps are "easy" for beginners to write because the NPCs are assigned in custom, not with code. That is to say, HSpeak is built in a manner that takes advantage of the engine's Map Editor. In a similar manner, Battlescripting should be built in a manner that takes advantage of the engine's Enemy Formation Editor. So in my mind, one would want commands like:
"[Get/Set] [Name/ID/SliceID/Palette/Position/Gauge...] of formation slot (slot)"
"Animate formation slot (slot, preset animations defined in engine like death etc)"
"[Get/Set/Increment/Decrement] stat of formation slot (slot, stat)"
Movement commands for formation slots, rather than relying on slices
Check for slot empty or non-empty

Similarly, Battlescripting should take advantage of the engine's Enemy Editor as much as possible. For example, something like:
"Perform attack (formation slot, attack slot)" where attack slot refers to the attack assigned at a specific slot in the Enemy Editor for the enemy in the given formation slot

Basically I'm saying that, if you don't arrange Battlescripting in a manner that specifically tries to take advantage of the editor's organization of battle, then it starts feeling a lot more like you should've told people to just learn to script their own battle system if they want more control.

One other comment: although in principle one might expect certain HSpeak commands to function in battle, one would not expect ALL HSpeak commands to function (like NPC commands for instance). The engine treats in-battle and out-of-battle as separate entities. Perhaps it would be easier to double down on this discrepancy rather than trying to hide it. Let BattleSpeak be a separate language from HSpeak. Let BattleScripts be declared differently from other scripts... maybe even a different file compiled and imported in a different menu. Commands may share some names, but are implemented separately. A PlotDictionary and a BattleDictionary. Everything about the interface emphasizing that the user should think of in-battle and out-of-battle as two completely separate game states with separate scripts and separate commands.
I am Srime
Chemical Slime
Send private message
 
 PostSat Jul 04, 2020 7:25 am
Send private message Reply with quote
There's practically no overlap between plotscripting and battles, so most everything would be from scratch (I think)

here's what I would expect from a customisable battle mode

- attaching effects to triggers, incl. reactions
- being able to specify multiple conditions to check, including actor flags
- actor management/modification. including moving around the screen, and assignable states
- being able to manage the turn list, including pause it

- a way to specify actors e.g, as target(s)
- being able to specify a formulae to apply

- display text. or slices
- display graphics. including animation.

- AI handler of some kind. a way to control actors, including co-ordinating them
- dummy actors, or ways to act on other-than-actors

It would be nice to be able to design our own interacting systems with its own properties, rules and formulae but that would be prohibitive and you are likely better off learning how to make your own battle system.

Obviously, any high degree of customisation is going to cause a lot of emergent properties. Such as bugs :p probably


I've previously mentioned that maybe attacks should be expanded to perform most battle-script roles, and we just need a manager/organiser/controller.
Attacks are rather like nodes that we use to proc an effect.
If there were some tools to handle them, it'd be the best step towards battle-scripting, imo

FWIW I vehemently disagree with calling them attacks.
It doesn't even make sense!
i miss my wife
Liquid Metal King Slime
Send private message
 
 PostSat Jul 04, 2020 7:39 pm
Send private message Reply with quote
Well I think the discussion has come down to 2 different trains of thought.
The first being that battle scripting would improve the ohr in a very meaningful way for people not wanting to completely reinvent the wheel in order to have a fun new attack.
And the second being that the OHR does not need this sort of thing.

As is normally the case with these sorts of things, both sides have good points.
Not only would battlescripting help developers who don't know enough about scripting to be able to make their own custom battle engine, but it would help devs who do know how to script their own battles and dont want to commit that amount of work to an rpg battle system in an engine that already has a battle system.
The second train of thought I believe is not about not specifically wanting the OHR to have battle scripting or not, but rather that they would rather see the time and effort needed to make battlescripting happen put elsewhere. This stems from the idea that battlescripting would be a large undertaking by a very few amount of people who honestly choose to do what they want to do no matter the requests anyways. The second train of thought is also about who would even use such a system and what would they use it for? It's no secret that the OHR has a limited number of users, I would say even with the silent users who never post there is likely still less then about 50 people using the engine. And we generally know what most people are working on and what they'll likely work on in the future. I would say the people most likely to put it to use are RMZ and Surlaw, and I'm not sure what it would really be used for in those cases.


So, both great points.
Ultimately, I'm not sure it matters.
My post saying we need battlescripting was followed by a bunch of emojis to sort of mock the idea.
I would love battlescripting and may very well make an RPG because of it.
And I get why we don't need it as well, because Myself and others may very well never actually use it for anything worth while and it would take a lot of time to make battlescripting a thing.
Regardless, TMC, James and whoever else are going to add the features they feel like adding to the OHR. If battlescripting is a huge project, then they might not want to break their backs doing it. That's fine with me, they do so much for this community that anything they want to do is fine by me.
Slime Knight
Send private message
 
 PostSat Jul 04, 2020 9:28 pm
Send private message Reply with quote
To be clear, I don't mean to say that we should absolutely get rid of the existing battle system. I think it should be a default that can be turned off.
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 3:34 am
Send private message Reply with quote
Leaving a note here:

A menu option idea for a Battle Editor

heal
amount (default)
percent
full

attack
amount (default)
percent
full


commands:

heal (hero, spell, other hero, amount)
attack (hero, attack, enemy, amount)

hero: specify slot or hero name
spell: which spell from the editor
attack: which attack from the editor
other hero or enemy: specify slot or enemy name
amount: can be an integer, variable, percent, or full
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 7:42 am
Send private message Reply with quote
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)
doattack(selectedattack)
set hero home (enemy x + 50, enemy )
set hero defense (50%)move hero to home

end



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.
Chemical Slime
Send private message
 
 PostSun Jul 05, 2020 7:53 am
Send private message Reply with quote
Even if we just had commands to get battle object data (attack, enemy) then we could script our own battle systems using the databases already there.

The problem with this is that those databases aren't always simple to manage.

Also imagine how many commands you would need lol
i miss my wife
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 8:08 am
Send private message Reply with quote
I very much enjoyed Fyre's perspective on this. I would say my only disagreement is having battle language be its 'own language' in the engine. To me this would turn into yet another unfortunate segregation in the future. That is, unless, there were no longer separate game modes and these commands could be used whenever.

I think if we're going to push for this, we shouldn't lose sight of the need for this to be primarily a part of the editor while also being fully available to scripters.
Metal Slime
Send private message
 
 PostSun Jul 05, 2020 8:08 am
Send private message Reply with quote
Oops I somehow missed TMC's reply before. But yeah, I guess my gut reaction is to disagree. If someone wants to utilize all of Hspeak to customize their battles, that sounds to me like they really don't want to use the engine's battle system much at all. So they're probably better off using instead-of-battle scripts and doing it with code.

Like, imagine someone wanted to make a 3D Wolfenstein-style corridor maze in place of Map 16 in their game (I think someone's done this already...? I can't remember), but the engine refused to run plotscripts on Map 16. The solution wouldn't be "Allow scripts to run on Map 16," the solution would be "Don't use Map 16, just have the entrance to the maze on Map 15 call a script that codes the entire maze without reference to a Map". Because calling the script from Map 16 doesn't help, because nothing about the Map Editor simplifies the coding for a 3D corridor maze.

Similarly, how much is really gained by allowing plotscripts to be called in Battle Mode? Do these scripts become any easier to write compared to utilizing instead-of-battle scripts? Or are they confusing because the meanings of things like catapillar become unclear? What happens if I have an in-battle attack trigger a script with "walk hero(me,west,1)"? Start a timer? Swap a hero? Teleport to a map?

To me, the simplest possibilities are:
1. Don't allow plotscripts in battle mode. Accomplish customization via a new scripting system built to take advantage of the engine's battle mode.
2. Option for battle mode to be eliminated, replaced by a "battle" that does not leave the map. Then all of Hspeak makes sense in this "battle". But this sounds like adding a whole new version of "battle" just for additional customization... which was already available to coders with instead-of-battle scripts. If someone wants this much customization, how much of their coding is saved by this new version of "battle"? Maybe that's the big question.
I am Srime
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 8:26 am
Send private message Reply with quote
Good questions. The thought is for there to be a system customizable enough by those who don't have skills in programming.

We have to recognize the fact that there are reasons OHR remains niche. There were other reasons in the past, but right now it's about engine capabilities. "Can I do X"

In discord chat just this very day, someone asked if you could have a heal spell that just does a full heal. And tmc had to tell him,

Quote:
umm. I think I've heard that request before. if you want to contribute a script for plotscr.hsd


More words from tmc while we were heatedly discussing this in chat:
Quote:
anyway, of course it's very common I have to tell someone that something can't be done
or that it can be scripted but it's just too much trouble for anyone to write it for them


The purpose of an engine is to be one of two things: clay or legos. OHR is one or the other in all aspects EXCEPT... when it comes to battles.
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 8:54 am
Send private message Reply with quote
ArtimusBena wrote:
I very much enjoyed Fyre's perspective on this. I would say my only disagreement is having battle language be its 'own language' in the engine. To me this would turn into yet another unfortunate segregation in the future. That is, unless, there were no longer separate game modes and these commands could be used whenever.

I think if we're going to push for this, we shouldn't lose sight of the need for this to be primarily a part of the editor while also being fully available to scripters.


I think the idea here is the rest of plotscripting would be updated to match, like having more object oriented stuff. Just that battle scripting would have stuff that only makes sense while in the battle mode (much like our current move npc, commands only make sense in walkabout mode)

The reason I say it's more of a separate or new generation thing is because it's currently it's own sandbox and we don't have any legacy plotscripts to worry about not breaking because they can't run in there anyway. I mean, you can't even show the regular texboxes in there because -their- conditionals/etc don't exist in there, either.

so yeah, to clarify, it'd be more like battlescripting would have leeway to try and do new things, then eventually plotscripting and battlescripting would merge under one unified Hamsterspeak when TMC updates PS to support stuff he's mentioned before, like more object oriented stuff. Until then it'd be like the non-battle mode OHR would be on Hamsterspeak 1.0 and Battle mode would run Hamsterspeak 2.0, then when they merge it becomes Hamsterspeak 3.11 For Workgroups.
Liquid Metal Slime
Send private message
 
 PostSun Jul 05, 2020 9:52 am
Send private message Reply with quote
Quote:
If someone wants to utilize all of Hspeak to customize their battles, that sounds to me like they really don't want to use the engine's battle system much at all.... Similarly, how much is really gained by allowing plotscripts to be called in Battle Mode? Do these scripts become any easier to write compared to utilizing instead-of-battle scripts?

I don't understand why using script commands in battle means not wanting to use the battle system. If I want to show textboxes or manipulate hero sprites with slice commands, does that warrant scripting an entire battle system from scratch? If I want to animate the backdrop with sprite dissolves, if I want to hide the HP bars and make scrolling HP meters like in Earthbound with sprites, if I want to make a particle system that spawns on attack hits? All of those things can be done with existing plotscripting commands and don't impact the mechanics of battle very much. There's a huge amount of meat to the battle system that I don't want to discard. But we have very little control of, specifically, the visuals (and perhaps timing).
Ps. I love my wife
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 10:31 am
Send private message Reply with quote
We have little control of the visuals, but far, far less control of the mechanics. The meat. The actual... game.

A measured plan, with foresight, will put us in a better direction. Such as the attack/heal options I suggested: amount, percent, full. That covers a lot of ground, and by itself outclasses the current battle system. And each function would be three to five lines of code.

Make them wrappers, and now it's downright efficient.
Display posts from previous:
Page «  1, 2, 3  »