-
-
Notifications
You must be signed in to change notification settings - Fork 27
Think tank
Issues that aren't clear what exactly I want to do about. And possibly new features that I haven't decided if or how to handle, etc. Arguably these could go in the issue tracker, buts mainly self discussion. (Seems easier to just put these on github, instead of various text files on my computers.)
Initially Spearmint was intended to be rebranded for each game, but I changed to wanting to support single engine binary running multiple games. Trying to support both methods for all games causes some logic issues though.
Issues:
If games are released and installed separately, they need to change homepath or else downloaded mods for other games could show up in UI and not be usable because of missing basegame data. The server browser currently has the same issue. Without changing GAMENAME_FOR_MASTER, all games will show up even though games are installed separate.
Allowing games to be separate on master server / server browser is probably a good idea in general, I'm not really fond of Q3 servers showing up in Turtle Arena. 1) Q3 data isn't downloadable, so you have to install it (no point showing it if don't have it?). 2) Turtle Arena is suppose to be 'kid friendly' so having M-rated games in server browser, and joinable, is bad.
I do like the idea of showing all Spearmint games I have installed in one server list (especially since there probably won't be that many servers), but can't list 'only' the installed games because we want mods to show up. Though this would still have the issue of; I have Q3, RTCW, and Turtle Arena installed and leave a kid playing TA and come back and find them in Q3. Bad, bad, bad.
Could let gameconfig.txt set com_gamename, with four recommended 'channels'. Everyone/Mature, Free/Proprietary. Arguably, proprietary games should all be separate though. And games that install separate from 'Spearmint' (have their own client, etc) should be separate. So basically all separate. :-/
I'm not overly fond of letting each game set homepath, but it's probably the only way that Spearmint-installed and Per-game installs could be fully compatible. I'd like them to at least all be in a Spearmint homepath subdirectory (better cross-platform handling and keeps mods from say, reading/writing settings from other software), but people distributing standalone Spearmint-compatible games probably wouldn't like it. Example: Why confuse people by putting it in 'Spearmint/MyApp' instead of MyCompany/MyApp??? :-/
Could let gameconfig.txt set string "MyApp" to use for both gamename for master and homepath, since they should always to paired together.
Oh. Right. The issue with loading homepath from fs_game. Is that it is loaded from fs_game. If game/mod is installed in Spearmint/MyApp/base4really, how do we find it?... Search all directories in main Spearmint homepath?...
The homepath separation discussed above would have the 'benefit' of separating mods for different games and standalone games (in the UI). But then there should really be a launcher because you could download a standalone game...
I'm not overly fond of making an external launcher. I don't want to create and maintain a Qt (or similar) program on multiple platforms. Probably shouldn't use games as the game launcher / selector though. Currently Spearmint requires everyone to have and install Q3 or use command line to run another game. Not ideal at all.
New games will probably want to ship the engine with the game because who wants to ask people to jump through a extra step of installing something (Spearmint) they could include? It would be nice if a person could use Spearmint (in a single location) to run all Spearmint games without hassle (terminal, .bat files, etc).
Creating a launcher that runs as a CGame VM is appealing to me, I like living in my VM sandbox. It will work on every platform supported by Spearmint and doesn't require learning how to create and ship a Qt5 application on Win, OS X, GNU/Linux, Haiku, Android, iOS, etc. I really like the idea, however I'm not sure about integrated update system and other issues (not sure what the other issues are right now).
Ideally the launcher would have a server browser built-in. Easy with CGame-based launcher, already exists and will continue to (can't move out to only launcher). I probably wouldn't add it to external launcher. I don't want to maintain a second copy of all of it.
Having the launcher UI be a custom OpenGL window does not seems idea. Not resizeable (without restarting the CGame VM; I should probably fix this), uses more resources to run?, etc. The UI won't match the OS, but neither does Steam, Google Chrome, WoW/LoL launcher, or other 'cool apps'. Steam Big Picture mode is probably a OpenGL context anyway. So whatever. I think making a launcher using Qt or other external GUI library will just mean that I would make a less featureful launcher that runs on less platforms. So custom UI/OpenGL works for me.
This should use OS update system / app store. Why reinvent the wheel. Now that Windows 8 has an app store, all platforms I'd support have a central install/update system (except older Windows, life's tough).
Going to need to deal with certificate on OS X anyway, gatekeeper complains about unsigned apps.
Could add checking if version is out of date for display in the launcher, incase not installed from an software manager or whatever.
The way I want to handle 'game updating' is by installing a new fs_game directory, which may load pk3s from past versions (if game dirs specified in gameconfig.txt). It allows playing old versions for posterity and connecting to servers that haven't been updated (yet). It should make installing new versions pretty easy too.
I'm interested in gameconfig.txt containing an update URL which will have a list of all game versions, their required engine version, and list of pk3s or something. Though this means the launcher needs to extract info from gameconfig.txt in pk3s in each game dir? Could probably cache the URL when we load the game.
Issues:
- "fs_game quake3" should automaticly use latest version (example: quake3_1.36) if fs_game does not contain version.
- Game config and binds aren't shared or transferred to new versions.