Post new topic    
Page «  1, 2, 3
Slime Knight
Send private message
 
 PostSun Jul 05, 2020 10:40 am
Send private message Reply with quote
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.
Chemical Slime
Send private message
 
 PostSun Jul 05, 2020 10:48 am
Send private message Reply with quote
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.
i miss my wife
Metal Slime
Send private message
 
 PostSun Jul 05, 2020 7:04 pm
Send private message Reply with quote
Quote:
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?

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 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
Liquid Metal King Slime
Send private message
 
 PostSun Jul 05, 2020 10:23 pm
Send private message Reply with quote
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?
Chemical Slime
Send private message
 
 PostSun Jul 05, 2020 10:25 pm
Send private message Reply with quote
Spoonweaver wrote:
So, what can we do without tmc/james?


buy me a drink and find out.. what you trynna do ?
i miss my wife
Metal King Slime
Send private message
 
 PostMon Jul 06, 2020 1:55 am
Send private message Reply with quote
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.

Quote:
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.
Display posts from previous:
Page «  1, 2, 3