discussion of chili menu for games

[Funkencool]

requirement of chili, not all games use chili.

They can continue to not use chili , so?

[Jools]

If that's the case, then I have no problems obviously. But please elaborate then how that is possible.

To be more specific, I don't really have anything against chili, but whether specific games should adopt chili is a topic for another thread. More generally, if it is to be used in the menu for all games, maybe ask the developers of each game what they think. We are reasonable people and it's totally possible to discuss with us, and it's still we who have to maintain or customise this menu to each specific game I assume, so it's natural that we are interested in how it's done.

[smoth]

You would take the gui code, adapt it to NOTChili and then move on with your life.

[Jools]

You would take the gui code, adapt it to NOTChili and then move on with your life.

Regardless of whether it's about chili or strawberries, I think it's a fair point to ask you to listen to everybody's opinion if those decisions will affect us. It's only fair, right?

[smoth]

No. Because you are being unreasonable. No one but you has an issue with chili being used and you do not offer an alternative just that you dislike chili

[gajop]

There's some confusion about the topic at hand.
I think Funken's proposing something like this:
1) Create a game agnostic menu (he's doing that with SKOLM). It's supposed to provide general purpose lobby functionalities (something akin to spring.exe, but more feature rich).
2) Allow encapsulating game-specific Lua GUI by specifying a file that should contain that game's Lua. It can be in Chili or something else, but it would be loaded within SKOLM.

The issue here is that it might look ugly to combine Chili and non-Chili, and that other games might want a different layout. That said the custom Lua code could always disable SKOLM or just launch a startscript that loads their own game so I think it's OK really

[smoth]

I planned on taking skolm and then reshaping it to meet my needs provided I find it friendly than the zk gui code.

[Jools]

There's some confusion about the topic at hand.
I think Funken's proposing something like this:
1) Create a game agnostic menu (he's doing that with SKOLM). It's supposed to provide general purpose lobby functionalities (something akin to spring.exe, but more feature rich).
2) Allow encapsulating game-specific Lua GUI by specifying a file that should contain that game's Lua. It can be in Chili or something else, but it would be loaded within SKOLM.

The issue here is that it might look ugly to combine Chili and non-Chili, and that other games might want a different layout. That said the custom Lua code could always disable SKOLM or just launch a startscript that loads their own game so I think it's OK really

Thank you. This was indeed the questions I was having but was afraid to ask (because it could be interpreted as trolling)

The issue is indeed how such code can be maintained and how good it looks if you combine two different GUI:s.

[8611]

I don't get what's not neutral about that?

Removed my cranky post (no need for it)

Neither from the picture, replies or looking at github I could find answer to:

1) Which parts of the pictured menu are from the 'spring-menu' and what parts are from the 'game-menu'?
I can not tell where the 'spring-menu' ends and the 'Arachnomania' menu begins.

2) Originally it was written:

When main menu is loaded it scans and includes this lua.
-> Said lua code contains that games chili based code for rendering a custom menu.

That means chili would originally have been forced.

Not biggest problem to me, because as I wrote at start:
I could just put a mini-chili-menu into my mod that is nothing but one button:
"[click THIS to start the real menu.]"
...that button does Spring.Reload (my_own_menu_script) and then the mod takes over.

However, it was also unclear what "contains code" really means. It could also have meant that the game just gets to return a config-table with some buttons but does not get to run "active" code. Afterall, it is only loaded by the other menu.

3) One problem remains, back to point 1:
In http://i.imgur.com/g6f0Q5E.png there is a "---Select Map---" menu and red scribbled text "Basic script used" [points to a start button] etc, there was talk of "more options" and so on.
This makes me think that (no matter how clear&simple my 'one button menu' might be) other elements of the 'spring-menu' will always be present, too.

That means the player might get lost/confused by whatever other options there are, when he should just click "that one start button."
(To be clear: I do not mean things like 'Engine Options' or 'Quit', those are okay to have in spring-menu.
I mean "Skirmish" or "---Select Map---" and similiar things that overlap with functionality of a game's menu.)

[8611]

And seperate post, because I really hope you (Funkencool) mean the same thing:

"rename spring.exe into nameofgame.exe" isn't even possible right now, much less necessary. As of right now it would just launch into springs default menu, no matter what.

It is possible right now. Obviously renaming spring.exe is just cosmetic which we both know.
That was in reference to posts like this by you :

If the game dev want's spring to skip all this and go straight into their menu; they would only need to configure spring to do that. Then they could rename spring.exe into nameofgame.exe and it would be like a real game, with it's own executable

A renamed spring.exe [plus config] implies a custom game-installer.
I think that is bad. I think with the SP menu stuff no custom installers will be nessecary anymore.
Do you think so, too?

[8611]

My question for you:
How do you suggest making the running of spring.exe show the 'correct menu' directly?

Imo various ideas:
1) Configurable default startscript setting for spring.exe
This raises questions:
1.1) What will be the default setting? / How to update it? (if defaultstartscript needs a change?)
1.2) Telling players: "Start spring.exe and change option XY=false so spring does not crash anymore?" gets a bit more complicated. (because if spring crashes, they might need the old simple menu to be able to edit settings)

2) Starting spring.exe with a "menu_startscript.txt" as parameter.
already possible without change to engine

It could be done in two ways:
2.1) The installer ( https://springrts.com/wiki/Download ) does already create a shortcut to spring.exe
Adding a script.txt as parameter would be small change.

2.2) The installer ( https://springrts.com/wiki/Download ) also includes Springlobby.
Springlobby could add a button "Singleplayer Menu" that executes spring.exe --startmenuscrip.txt


If spring.exe suddendly contains a wonderful new menu players would not notice it:
Imo cooperation with lobby and installer makes sense anyway because the lobby is where the players are. And the installer is how players install spring.
(yes, in future, maybe, multiplayer lobby will too be ingame, future,..)
It would be nice to have other lobby clients cooperate too, but the one officially included in spring installer is a "must-have", imo.
https://github.com/springlobby/springlobby/issues/368

Currently 2.2 sounds best to me because:
+If SL people want to cooperate, this might be doable relatively quick.
(yesyesiknow, judging how much work someone's else project is..but it is just one button?)
+Should be it nessecary to change the startscript, it could be done by springlobby update.
Updating engine is much slower process.

[Funkencool]

I can not reply to all your questions, there is simply too many. You are getting way ahead of yourself or at least me. But I will at least try to explain a few things.

2) Starting spring.exe with a "menu_startscript.txt" as parameter.
already possible without change to engine

It could be done in two ways:
2.1) The installer ( https://springrts.com/wiki/Download ) does already create a shortcut to spring.exe
Adding a script.txt as parameter would be small change.

2.2) The installer ( https://springrts.com/wiki/Download ) also includes Springlobby.
Springlobby could add a button "Singleplayer Menu" that executes spring.exe --startmenuscrip.txt

I'm completely aware of this. Neither of those is "double clicking spring.exe". I'm refering to essentially turning the spring engine invisible; So the user doesn't see 'spring.exe' but 'gametheywanttoplay.exe'. Nearly every 'engine' I've used came with a to compile a binary of your game to distribute. This would be a good imitation of that.

And like mentioned by others, I don't think shortcuts are the best solution. (I thought even you said this?). It would just be nice if people weren't required to make shortcuts to get the effect they want. What if a user decides to run spring.exe directly? It would probably be quite confusing. This is all especially true for portable installs.

Simply put A shortcut should not be required to replace the current menu

Game menus and a new hypothetical engine menu would both benefit from this.

Now as far as your questions about what is 'spring menu' in my picture. I'll do me best to explain simply.


A - hypothetical default backend/UI included with spring, so the user has some way of switching between different things (options, menus, lobbies, chat, whatever they want, etc..)

B - hypothetical included menu I made that uses A's simple API/backend and chili. The user could add his own or change the included ones if he doesn't like what the community decides should be default.

Code: Select all

  AddMenu{name = 'Games', width = 80, content = VFS.Include(MENU_DIR .. 'Games.lua')}
  AddMenu{name = 'Match Maker', width = 110, content = VFS.Include(MENU_DIR .. 'Skirmish.lua')}
  AddMenu{name = 'Quit', right = 1, OnClick = {function() Spring.SendCommands('QuitForce') end}}
  AddMenu{name = 'Debug', right = 1, content = VFS.Include(MENU_DIR .. 'Debug.lua')}
  AddMenu{name = 'Options', right = 1, content = VFS.Include(MENU_DIR .. 'Options.lua')}

  ShowMenu('Games')

That's what gives the above. right now everything is in the game dir (startscreen.sdd). But it could just as easily be pulled from other games or a different source all together.

[Funkencool]

Also, I think some confusion comes from the fact that my posts cover a broad range of stuff that could be useful for both game menus and a new engine menu. It makes sense that a default engine menu could be used as a template for games to build a more personal menu for their game. I don't think these ideas are mutually exclusive.

[8611]

Now as far as your questions about what is 'spring menu' in my picture. I'll do me best to explain simply.
http://i.imgur.com/U7s1Lyh.png

A - hypothetical default backend/UI included with spring, so the user has some way of switching between different things (options, menus, lobbies, chat, whatever they want, etc..)

B - hypothetical included menu I made that uses A's simple API/backend and chili. The user could add his own or change the included ones if he doesn't like what the community decides should be default.

Ok.
Uhm, have we talked past each other?
I asked about: How would a game-menu integrate into the spring-menu?

I see no game-menu on http://i.imgur.com/U7s1Lyh.png :
To my understanding A+B both together ARE the spring-menu. (A is options, Quit, B is where player picks a game.)

Yesyes, "hypothetical" menu but if that (B) is an example of a game's menu then is either really bad example or it raises more questions than it answers. (B) is clearly a Select-Game thing..

---

If you want 'gametheywanttoplay.exe' that means there would also be 'another_game.exe' and 'yet_another_game.exe'
Spring has no way to distribute such .exe files.
I do not see why it should be nessecary anyway.
On one side you say "It would just be nice if people weren't required to make shortcuts to get the effect they want."
But you also say things that seem contradicting:

Nearly every 'engine' I've used came with a to compile a binary of your game to distribute.

What reason does a spring-game have to come with binary .exe file? Imo none.
Why would it be desireable? Imo it is not.
Spring has download system, has lobby system, now gets another useful system.

Simply put A shortcut should not be required to replace the current menu

Maybe misunderstanding:

In the past one way to open the "correct" menu or game were shortcuts, created by per-game-installers.
Variante of that are "launche.exe" that then run spring.exe --script.txt but that is kind of the same thing.
The idea of those shortcuts/launchers I find very bad and a dead-end:

(random selection of screenshots I could still find)

ONE button in springlobby (or ONE shortcut created by spring installer etc) I find okay.
There is no configuring for players because the menu.sdz asks them what game they want to play etcblabla.


"double clicking spring.exe" is imo okay, too.
But first needs an replacement for the "Edit Settings" that covers ALL options and is NOT in-game.
(because one can not use an in-game menu to fix game-crashing settings)

Also button in lobby is imo convient to players.
Player is already in lobby, chatting and playing MP. To doubleclick on spring.exe player has to dig through system. Having a button in lobby just makes sense. At least until 'everything and everybody is in spring.exe' or whatever might happen in far future.

What if a user decides to run spring.exe directly? It would probably be quite confusing. This is all especially true for portable installs.

The engine menu can be changed too (by engine devs) and another "Launch the Play-Area" button could be added.

[Funkencool]

To my understanding A+B both together ARE the spring-menu. (A is options, Quit, B is where player picks a game.)

Yesyes, "hypothetical" menu but if that (B) is an example of a game's menu then is either really bad example or it raises more questions than it answers. (B) is clearly a Select-Game thing..

Your understanding is wrong. B is merely an example of whats possible, not a representation. A is not options, quit, etc.. they are the same as 'Games'. Think of them as extensions loaded by A.

In my code example

Code: Select all

-- these are all 'modules' (B) loaded by a broader lua system that handles them (A).
-- I specifically made these ones so that I can test my system with something. 
AddMenu{name = 'Games', width = 80, content = VFS.Include(MENU_DIR .. 'Games.lua')}
AddMenu{name = 'Match Maker', width = 110, content = VFS.Include(MENU_DIR .. 'Skirmish.lua')}
AddMenu{name = 'Quit', right = 1, OnClick = {function() Spring.SendCommands('QuitForce') end}}
AddMenu{name = 'Debug', right = 1, content = VFS.Include(MENU_DIR .. 'Debug.lua')}
AddMenu{name = 'Options', right = 1, content = VFS.Include(MENU_DIR .. 'Options.lua')}

-- you can automatically show select 'module' on startup
-- 'Games' is an example of how a user could quickly launch spring, then use this system to get into other game and/or menu systems (like a launcher)
ShowMenu('Games')

If you want 'gametheywanttoplay.exe' that means there would also be 'another_game.exe' and 'yet_another_game.exe'
Spring has no way to distribute such .exe files.

You don't get it. In this scenario Spring wouldn't distribute .exe files. Each game would be it's own Spring folder with it's own spring binary, installed to it's own directory. It could completely ignore the entire spring ecosystem. It could include it's own map, settings, missions, etc.

People don't fire up Unreal Engine to get to the Unreal Engine based game they want to play. They install and run that game. Why do you want this to not be an option for game devs that share this opinion?

Not everyone want's spring to be a singular entity. Lobbies as they are would still exist if people want that experience. Game devs should have the option to choose. They should not have to rely on pre-existing systems(like springlobby) or otherwise face inconvenience.

What reason does a spring-game have to come with binary .exe file? Imo none.
Why would it be desireable? Imo it is not.
Spring has download system, has lobby system, now gets another useful system.

Your opinion should not prevent others from doing things how they see fit. Just because you prefer the latter method does not mean everyone does. Both can coexist.

[Funkencool]

Perhaps I should just split my code up into it's seperate parts already.

It's hard to explain things to you when what we want from spring is subjectively different.

You seem to want things to be mostly as they are, set up like a 'hub' for a spring player to play different spring games.

I want games to be able to stand on there own without the need for all that.

The idea of those shortcuts/launchers I find very bad and a dead-end:

Me too. So I'm trying to do something different. Something that doesn't require launchers, shortcuts, or lobbies.

I'm also trying to reach a middle ground that would allow both ways to use the same system.

The engine menu can be changed too (by engine devs) and another "Launch the Play-Area" button could be added.

Why? We could skip that step entirely, it's redundant. A new better looking and more functional menu could be made, that does the same things as the current engine menu. Technically I can already do everything the current engine menu can. That is select a game, map, and script.

Unfortunately I have to use a shortcut to get into my personal menu. This causes numerous small issues I would just rather not deal with.

[8611]

We are discussing a "SPRING menu" and you talk about things that "completely ignore the entire spring ecosystem"...

You don't get it. In this scenario Spring wouldn't distribute .exe files.

I perfectly get that.
You want the option to make seperate game-installer and distribute them.

As if history has not teached us anything.

These new features could improve and grow the Spring Eco system but people are too egocentric and shortsighted and greedy to cooperate on that.
Instead of makig "Spring" better everybody seems focused on getting as far away as possible to greener pastures.

[gajop]

These new features could improve and grow the Spring Eco system but people are too egocentric and shortsighted and greedy to cooperate on that.
Instead of makig "Spring" better everybody seems focused on getting as far away as possible to greener pastures.

Well, while the rest of us are actually contributing to the Spring project you just seem to be whining...
Before you criticize everyone (and we know you've done a lot of that), maybe you should consider contributing yourself .

[Silentwings]

These new features could improve and grow the Spring Eco system but people are too egocentric and shortsighted and greedy to cooperate

Seems completely wrong to me. The person who is actually producing the content in discussion here is someone who started out creating a piece of work for a particular game and is now trying to find ways to make that work more accessible to Spring projects at large.

You may dislike the implementation or some of its potential use cases, but that is not a reason to cast general insults around.

[smoth]

Or you could wait until he is done then expand it. That's the funny thing about open source