[DaBrain]

In terms for usability for modders/developers I see the the interface as the most outdated part of the engine.
It's not impossible to have nice menus, but it sure takes a lot of  work.


A long time ago I suggested an imrpovement to taylor. (Actually it was for more. We wanted to use it for comic cutscenes back then.)
I suggested supporting Flash. That was a long time before I ever heard of Scaleform or GameSWF.

Due to some issues (I recall licensing issues) it was never realized.
I'm not going to suggest the same thing again.


An even more powerful and flexible solution would be to embed a HTML rendering engine.
http://www.gamedev.net/community/forums/topic.asp?topic_id=527416


Imagine the possibilities! You could finally put together option menues in any way you want. You could use JavaScript to interact with users. Menus and screens could be easily extended and many many people have enough knowledge of HTML to create great menus.
You could even have online news about the project in the menu, or check the current version of your mod/game and tell them about updates.

This would also be the first step to get rid of our menu inconsistency. Some options are in the game, some are in the launcher. It's confusing for new players.


 
I guess it's a lot of work, but I thought I should at least suggest it.

If you have any concerns about this, or maybe even completely different ideas, I'd love to hear them.

[The E]

An HTML renderer.

I would be lying if I said that the idea doesn't have some merits.
I'm just not looking forward to implementing it.

[Galemp]

*thinks about the potential for exploits*

[The E]

To be more precise, I think in this case we're better off defining our own markup for interface stuff instead of importing something like this. At the very least, it'll make debugging things easier.

[jr2]

* jr2 has an idea... lolcode? 

[DaBrain]

*thinks about the potential for exploits*

Hmm what kind of exploits are we taling about?

I think there are way more 'interesting' systems that can be exploited right now.

To be more precise, I think in this case we're better off defining our own markup for interface stuff instead of importing something like this. At the very least, it'll make debugging things easier.

Well that takes away one of the big avantages. There are many people who know how to create websites and there are tons of tools out there, but it if it can't be debugged properly it's hard to mainain...

[Nuke]

we could use lua. we would need internal command interface and gui functions, lua would just be used to say what goes where and what graphics to use. many game engines use there scripting systems for this kinda thing. alternatively is use a tableish format.

[portej05]

*thinks about the potential for exploits*

The engine has _had_ demonstrated security flaws. I doubt that introducing an HTML renderer would introduce all that many more.

[The E]

Okay, whatever we decide, it's always going to end up in someone, or several someones, diving deep into missionui\ and menuui\ to redo most of what's in there.

Also known as a ****load of work. I don't exactly see people lining up for that.

[Echelon9]

*thinks about the potential for exploits*

They likely already exist in the parsing code for game data / tbls. I know I had one in get_mission_info() via Lua which worked reliably before the large safe strings work by portej05.

[DaBrain]

*Bump*

I can't get the idea out of my head...


Maybe this could allow us to create completly new/different games.
If the main game logic runs in the browser, maybe via javascript or php, and the actual action part is still handled diretly by FSO, we could create really deep games with way less effort.

Like a browser RTS, but you can jump into the action.

I'm not that familiar with FRED. Can we use values from a database to fill SEXPs and determine how big squadrons are?


I have a completely non-linear game in mind, or maybe something like a "Privateer light".

[Nuke]

i for one really dont see html as being very multires friendly, or suited to the kind of content we want, not without embedded scripting anyway. if that embedded scripting happens to be java, then thats yet another scripting language to implement. id rather see lua bindings to wmcgui and use the existing interface hooks. id have the engine do the heavy lifting, and only use scripting to load and unload graphics, and to configure the interface for each screen, also the on frame hook is available if you want anything fancy (you would probably also call a renderInterface() function here as well).

only other thing that would be needed is the command interface, so game configurations can be made. this could be done through wmcgui or with a console interface, whichever makes more sense. i personally would love to have a console interface. much like the debug console but with a command line, and rendered ingame. besides a place to spew internal messages, it would also let you set, read, and get information about in game settings. it would also have a scripting interface, so you could change and display the current settings in the gui.

it has already been demonstrated that game content can be run from the interface, which could be overlayed with interface graphics. and scripting already has access to the sexp system. most of the systems needed to get what youre after are already available and only really costs some dev time.