Customizable menu system

[Plombo]

I've been thinking about how the currently static menus in OpenBOR could be replaced by a more flexible, customizable system without losing backwards compatibility.

My idea is to define a common API for creating/rendering/controlling menus that is used by all menus in the engine, instead of reimplementing the menu logic in every menu function.  The common menu functions might use a text object to render each menu item (if text objects are feasible for this; I'm not sure).  Each menu item would be attached to a callback that would be called if the item is selected.  This callback could be another menu function (i.e. a submenu), or it could perform an actual action such as changing the music volume, displaying the hall of fame, or starting the game.

This system could be controlled by script by allowing a callback to point to either a script function or a C function.


Update, February 8

The engine would define a set of "default" callbacks for the existing menus and menu items in the engine.  These would constitute the default main menu, which would be the same externally as the current main menu.

These default callbacks would be usable by script-based menus as well, enabling modders to rework or modify the built-in menus, or even create entirely new menus.


This post is just a sandbox for an early form of my ideas.  Feedback is welcome, but nothing here is final yet.  I'm not about to start implementing it, either, because I at least need to finish the script preprocessor stuff before I make any other significant changes to the engine.

[Damon Caskey]

I'm all for it. There are really only two weaknesses left in OpenBOR; net play, and the hard coded nature of elements outside of game play.

 

DC

[bWWd]

ITS good idea,it would improve asthetics a bit and make some mods more unique by using custom menus.

[Bloodbane]

 Ah, this is great idea!

 Aside of modifying menu layout, another thing which crossed my mind is setting game via menu such as setting difficulty, lives and credits (anything I miss?).
 Oh and if there were script run while main menu is displayed, I could reactivate cansave feature in my Contra mod. The only reason I disabled cansave is because I don't want players to bring weapons to different missions via save states.

[talic]

Finally this idea have some opportunity. 

I am happy but with these features:
*Able to change the place of the Menu. (the letters)
*And able to add a extra background for the Option menu.

With these 2 thing the mods will look so awesome.

[DrStrange]

So in implementing this would it require you to separate the menu code from the initialization code and thus allow the menus created in OBOR to be skipped entirely as we discussed here.

[Plombo]

Thanks to everyone who's given feedback so far!

So in implementing this would it require you to separate the menu code from the initialization code and thus allow the menus created in OBOR to be skipped entirely as we discussed here.

Yes, it would allow that.

Ah, this is great idea!

 Aside of modifying menu layout, another thing which crossed my mind is setting game via menu such as setting difficulty, lives and credits (anything I miss?).

That is one of the intended uses, yes.

Oh and if there were script run while main menu is displayed, I could reactivate cansave feature in my Contra mod. The only reason I disabled cansave is because I don't want players to bring weapons to different missions via save states.

This feature wouldn't actually enable that, at least not without using a hackaround.

EDIT: On second thought, it actually could allow a script to be run while the main menu is displayed.

Finally this idea have some opportunity.  

I am happy but with these features:
*Able to change the place of the Menu. (the letters)
*And able to add a extra background for the Option menu.

With these 2 thing the mods will look so awesome.

The first feature will be possible.  The second one won't be when this is finished, but this menu system will make it feasible to implement alternate background loading in the future.

[Orochi_X]

If we end up with some sort of script for when menus are running , we should be able to input our own background images anyway.

And , yeah , I'm all for this. Despite the fact that I've spent a long time on scripted menus. While they work flawlessly (and will probably just stick to them anyway) I didn't really like having the default main menu screens followed by my custom ones.

[DrStrange]

Sorry for digging up an old (very old) thread, this is the best place to continue the discussion. Plombo, any more thoughts on this? Just trying to get the dialogue flowing again as I would really like to see this happen at some point.

[Plombo]

Sorry for digging up an old (very old) thread, this is the best place to continue the discussion. Plombo, any more thoughts on this? Just trying to get the dialogue flowing again as I would really like to see this happen at some point.

Sorry for the late reply. I've been away from OpenBOR development for most of the last year, but I recently started working on it again.  Right now I'm working on adding features to the preprocessor (which I'll make a thread about soon), but scriptable menus have been on my mind as well, and definitely aren't off the table for the future.

[volcanic]

Glad you're back.
This is the very feature I want.
As DC said this is one of the big weaknesses of Bor.
Good luck.

[utunnels]

I just got a thought recently.

Instead of working hard to perfect current menu and select screen system, maybe we can just add an option to skip them and go for levels directly for now. For example, RPGMaker XP can be totally scripted to by pass the menu, in another word, the menu itself is also scripted and can be changed to whatever you want. For OpenBOR, we can keep the mod select screen and logo, after that, there can be an switch(optional) to skip the title screen and menus. You can still access the menu in game, or we can even add a shot cut key if it is really needed, shouldn't be an impact to user experience.

BOR,  initially designed to be a tightly coded beat'em up game, has a quite different model in menu screen than in game. So even if it supports script now, you can't really do as much in menu than in game. I added that alwaysupdate option but found lately it is not just a good way to go. The modder can try hard to patch current menu system and select screen, but what he can do is still very limited.

There are quite a lot of game engines floating around nowadays, many of them even don't provide a game model, let alone menus. That gives game designers the freedom to create their own world without being trap in a limited frame. OpenBOR has an advantage that it provides a quite complete game model, and it also has a working though not too advanced script system, so it would be easier to isolate the menu system than expanding it.

I enabled gravity in select screen a while back, but at the same time I realized it just a waste to have such logic. First of all, the select screen has its own logic, it doesn't have a level, thus some level specific logic must be rewritten here. If we working hard on this, sooner or later there will be as much code in select screen as in game. But since almost all what you can do in select screen can be done in game as well, it would be much easier to write a select level script.

As for the menu system, if you really have the potential and patience to complete it, don't make it title screen only. For example, in a carefully designed level with all cool effects in the background, or even when some demo scene is being played.
 

[volcanic]

I'm very interested in this part.
I'd love to see how it goes.

[darknior]

Very good idea ... put an option to skeep select screen and the moder release his select screen like a stage.
Some moders already do that ... but we must press a button for nothing on the real select screen !

[Damon Caskey]

I'm all about this. Good stuff UT!

DC