Let's talk about battlescripting.

Make games! Discuss those games here.

Moderators: Bob the Hamster, marionline, SDHawk

ArtimusBena
Slime Knight
Posts: 251
Joined: Thu Nov 16, 2017 5:22 am

Post by ArtimusBena »

But yes, I do understand why it would be desired for the current system just to be converted. The only problem is, again, the actual mechanics. Npcs and heroes were converted to slices... which is great... but what about their actual game mechanics changed as a result? If you weren't told they were slices now, would you have noticed.
User avatar
SwordPlay
Chemical Slime
Posts: 966
Joined: Sun Jan 22, 2017 9:32 am
Location: London, England
Contact:

Post by SwordPlay »

Just write the amazing battle system extension we all know you are capable of writing, Bena. Don't be afraid, just let the spirit guide you.
"Imagination. Life is your creation."
User avatar
msw188
Metal Slime
Posts: 787
Joined: Tue Oct 16, 2007 1:43 am
Location: Los Angeles, CA

Post by msw188 »

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?
I think I'm being unclear. To me, examples like this don't constitute wanting all of Hspeak in the battle system. They sound more like wanting specific commands available. All I'm saying is that it makes more sense to me to incorporate these commands via a separate, battle-mode-specific language, rather than trying to allow plotscripts written in Hspeak to run during battles. Imagine having a Plotdictionary when every command needs essentially two entries - what it does in-battle (often nothing) and what it does out-of-battle (also often nothing if we add commands that actually help script battle mechanics). Is that really preferable for users compared to having two dictionaries?
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 also enjoyed reading Fyre's much more radical and progressive proposal. But I think that keeping the language separate is helpful. It comes down, as always, to what the OHR is supposed to be. To me, it was about building RPGs, JRPGs really. The defining features of this genre always included (to me):
(*)Menu-based battle gameplay independent from environmental/movement-based gameplay.

To me, (*) is a core difference between JRPGs and, say, overhead Zelda-style games. People can make Zelda-style on the OHR, but we think it's okay to tell them that this will involve "heavy scripting". If one agrees that (*) is one of the defining features of the genre that the OHR is designed to support, then the arguments for pushing towards unifying the two gamestates is weaker. That doesn't mean that battles shouldn't have scripting - I think most people would agree that they should if possible. But it does mean that scripting in battles shouldn't necessarily be related to scripting outside of battles.

As an example based on an earlier post in the forum, I'll use Chrono Trigger. Battles start without leaving the map SCREEN, but these battles do effectively leave map MODE - battle-mode is a gamestate independent from map-mode. Now imagine having the option for OHR battles to work like Chrono Trigger. Do you really want the command "walk hero" available in battle mode? What does it mean? Should collision with the "background map obstacles" be checked? Collision with the enemies, assuming they were originally NPCs while in map-mode? In Chrono Trigger, the collision questions would be answered "No". Which means, the commands would have different meanings depending on in-battle vs out-of-battle. In that case, why call them the same commands?

The list of such commands is huge! What does suspend player and resume player mean? Calling a menu?
Showing a text box seems fine... but wait what if an enemy uses an attack that shows a text box while the hero's attack menu is open? Or while the player is choosing a target? Should the text box wait for the menu to be done, or the menu/targetting wait for the text box to be done? Is this the same or different from what one would expect if a script called a textbox while a menu was onscreen in map-mode?
I am Srime
User avatar
Spoonweaver
Liquid Metal King Slime
Posts: 6462
Joined: Mon Dec 08, 2008 7:07 am
Contact:

Post by Spoonweaver »

I think the idea of someone scripting out a battle system might be the best realistic option though.

As I see it, battlescripting would be really hard to do for tmc, James, or whom ever. Add on to that the fact that they are doing other things and have more or less said no to this request, so the arguement for or against battlescripting is moot.

So, what can we do without tmc/james?
User avatar
SwordPlay
Chemical Slime
Posts: 966
Joined: Sun Jan 22, 2017 9:32 am
Location: London, England
Contact:

Post by SwordPlay »

Spoonweaver wrote:So, what can we do without tmc/james?
buy me a drink and find out.. what you trynna do ?
"Imagination. Life is your creation."
TMC
Metal King Slime
Posts: 4308
Joined: Sun Apr 10, 2011 9:19 am

Post by TMC »

Spoonweaver wrote:As I see it, battlescripting would be really hard to do for tmc, James, or whom ever. Add on to that the fact that they are doing other things and have more or less said no to this request, so the arguement for or against battlescripting is moot.
I haven't had time to read this huge thread, but skimming it, it looks like people are generally suggesting stuff that was the plan already.

We certainly haven't said no to battlescripting. Step one is to implement script "multitasking", meaning multiple scripts "fibers" running at once, and then we can allow scripts/fibers to run places they currently can't, like menus and battles. This is my next priority after animations (but I now think I made a mistake and it should have been the top priority). Initially the scripts will only be able to modify slices during battles, until we add lots of new commands for battles.

I would really love to allow textboxes during battles.
So, what can we do without tmc/james?
Regarding battles, it's hard for me to think of anything, honestly.
But I think it would be great if someone wrote some standard scripts to use for creating zelda-likes.

If you're willing to write FreeBASIC code, adding new script commands to read attack data would be very helpful. Currently you can only get attack names and captions. Adding script commands is read existing data is easy, requires almost no knowledge of the codebase, and we even have an article explaining how to do it. But do discuss it before starting.
Last edited by TMC on Mon Jul 06, 2020 2:04 am, edited 5 times in total.
Post Reply