Menus UI
Overview
The UI code for the menus is currently super-grim. What if it could be replaced by web pages?
- Modifying it would become trivial
- Ugly UI code gets replaced by widely adopted HTML5/CSS/JS
- Much easier to deal with pagination (eg. avoiding current issues when you have too many maps or AIs)
- Ability to embed forums, addons-download, etc., in to WZ menu UI
Things like panels, animations, etc., can all be handled by HTML/CSS/JS.
Below is some ponderance about what JS API features would need adding to the window object in order to make this transition possible...
GUI JS API requirements
ini file access
Functions for accessing ini files as described here and here - in particular we'd need ability to read the config file in the user settings folder.
We'd also need a way of setting values in an ini file – eg. to save config on the game menu. This would be restricted to updating config, eg. to save game options, etc.
screenWidth, screenHeight
Screen/window dimensions as applicable. Also useful to have these in normal JS API if poss?
Edit: A browser based interface for the front-end menus would automatically provide this sort of info.
enumMods()
Need this in normal JS API also. A list of mods like those shown at top of main menu screen.
Also, what happens with regards to map mods? Is the list of mods in the chat area on game setup screen different to the list of mods at top of menu screens?
buildInfo
Like version but with the more detailed info shown in the bottom right corner of main menu screens. Would also be useful in normal JS API.
playSound()
Same sort of thing as in JS API but without x,y,z params. Would be used to play sounds when menu options are selected, etc.
Altenratively, a way to access .ogg files in the audio and music dirs through standard HTML5 multimedia controls.
playVideo() and eventVideoDone()
A new function to play a video & the existing JS API eventVideoDone() porting to the menu environment.
Alternatively, a way to access .ogg files in the sequences dir through standard HTML5 multimedia controls.
This will allow play of intro video.
enumLanguages()
For Game Options screen > Languages – will need a list of available languages (incl. system locale).
enumVideoOptions(<setting>)
For Video Options menu, we'll need a list of available options for the following settings:
- GRAPHICS_MODE
- RESOLUTION
- TEXTURE_SIZE
- FSAA
eg. enumVideoOptions(GRAPHICS_MODE) will return an object detailing the available graphics modes (name:value pairs in the object, where name = canonical option caption, value = what should go in the config file).
Stuff for key mappings
Not entirely sure what form this would take - we'd need to load current key mappings in a format JS can understand, and be able to alter that data and save it back in a JS friendly format.
enumSavedGames(<type>)
Return a list of saved games of given type:
- SKIRMISH
- CAMPAIGN
Object would contain as much info as possible about the save game - eg. it's name, whatever reference is required for loadSavedGame() (see later), map, num players, date/time, etc. in order to give UI devs as much flexibility for making awesome UI as possible.
loadSavedGame(<whatever>)
After user chooses which game to load, need some way to actually load it!
enumProfiles(), setProfile(), getProfile()
For set-up of ski / mp games the ability to choose which player profile to use / create new profile / etc.
Profile objects would include name, ranking, etc.
enumMaps()
Get a list of all maps - each map object would contain:
- name
- width, height (if possible)
- num players
- what structures are placed for each player? like an enumStruct()
- any other data that's easy to provide
Filtering of maps by num players, pagination, etc., would all be handled in HTML/CSS/JS. Easy peasy.
getMapPreview()
Some way to get a map preview image (ideally a URL to a png file?)
Not sure how the oil resource / structure overlays would be handled, particularly setting their colour. Maybe an getMapOverlay(player, r, g, b) that returns url to a transparent png file showing buildings for that player in their colour? (player 99 for oil resources)
Alternatively, some sort of data object and we can create the map preview ourselves using canvas object.
enumAIs()
Gets a list of all .ai ini files. The ini features mentioned earlier would then be used to get info out of those files.
enumPalette()
For getting info about colour palette – alternatively, migrate palette.txt to palette.ini and then we can use ini features mentioned earlier to read the colour palette.
chat() and eventChat()
For chat window.
structure limit functions
I imagine similar to what's in normal JS API, perhaps with some tweaks. For use with the structure limits screen – need to read what structures can have limits set, what their min/max limits are, what the current/default setting is.
initGame(...)
Parameters:
- map
- scavengers
- alliancesType
- powerType
- baseType
- techType – 1, 2, 3 (off-topic: also need this in normal JS API and ideally then have tech level applied via rules.js)
- limits – some sort of object/array describing structure limits
- playerData[]
Web servlet to access assets
We'd need some way to access html, css, js and image assets, possibly also audio/video assets too, in the wz filesystem.
joinGame(...), hostGame(...)
Would need guidance on what sort of things are required for mp game hosting stuff.
joinGame() - whatever's needed to list available games via IP or Lobby.
hostGame() - Makes game set-up available for others to join.
Params similar to initGame() but with initial params for password and game name. I guess there will need to be some way of refreshing the info - eg. as players join or if host changes map or other settings, etc.
I assume that once players have joined (see eventPlayerChange below) to start the game some sort of initHostedGame() function would be required?
Maybe initially the MP game setup could just be an mpGameSetup() function that reverts to oldschool C++ UI until we have all the requirements sorted out? I imagine there would need to be a herd of new events and other functions to make it all happen.
_() – localise text
Same as in normal JS API.
quitWarzone()
Immediately exits warzone.
Note: The exit screen would be handled in the HTML/JS/CSS side of things rather than C++ backend.
Tutorial / Fast play
I assume these two modes will end up being replaced by challenges?
And the challenges UI could be handled with ini functions (eg. enumIniFiles("challenges/*.ini") etc). Tutorial and Fast Play would just be names of ini files in the challenges/ folder.
Once challenge data is loaded from ini file, it's just a case of generating the params required for initGame() which should be relatively easy to do using JS.