According to guidelines for app store submission it's recommended to switch to using the new sandboxing features on the Mac to specify what an app can and can't do. There's lots of information about this here
I'd like to implement this for the native mac port of the game. I'll need to make some changes to the way the game loads files and the locations they are loaded from and wanted to consult with the rest of the developers on this.
I plan on offering an in-app download facility for users to obtain paksets, to simplify the process as much as possible. I can provide a nice Mac-native panel with a listing, and easy installation by simply clicking a button. I'll always bundle pak64 along with the game inside the app bundle (so people have something to play by default) but any additional paksets would be placed within the data portion of the app's sandbox folder, e.g. under:
Finally users should be able to install paksets the old-fashioned way as well. This won't work if they modify the app bundle themselves (which must be strictly read-only to avoid code signing issues). Thus I'll implement a third location to search for paksets:
(After installing a pakset users will still have to restart the game, however due to the native mac version running Simutrans itself in a thread within the main app this should be easy to do without needing to restart the app itself).
My understanding is that currently Simutrans reads its configuration from three possible places (and the -singleuser command line flag also affects this). These are the user's home directory ~/simutrans/simuconf.tab, the program's directory and per-pakset.
The program directory location will be read-only, the per-pakset ones will also be treated as read-only (along with all the pakset data). The user one will be modifyable by the user as required.
Addons can be installed manually by users into:
This is the current functionality afaics and won't change.
Log files will go in mac-native locations, under /Library/Logs/ (and will be accessible using the Console utility).
Network save games
These currently get downloaded to a temporary save game file in the program directory. This location will be moved into the sandbox:
Autosaves will be stored under:
Users will be able to load saves either in-game (from ~/simutrans/saves/) or by dragging a savegame file onto the app icon/windows (in the Mac-native way). The game will also search the autosave folder to provide a list of autosaved games to load as needed.
One possibility is to change the app so it has an initial launch screen where users can select basic options before loading the game itself, this will roughly equate to a subset of the command line options (and maybe other things specific to the app). I'm undecided on whether this will be needed however. For the iOS version certainly a lot more of the interface will need to be provided in a system-native way.
Save/Load dialogs (Mac native)
Another possibility, to provide system-native dialogs for these functions (e.g. outside of the game).
These will need to be stored somewhere obvious to the user, maybe ~/simutrans/screenshots/
My idea on implementing this is to move some of the functionality which is currently in simmain.cc into the platform-specific simsys_XX.cc files. E.g. having a function to determine locations on a platform-specific basis, or hooks to permit opening platform-specific dialogs. Of course the simsys_XX files aren't actually OS-specific, but rather backend specific (e.g. the SDL one is used on multiple platforms) so this may not be the best way to go about it.
Moving this kind of functionality into a separate file per-platform makes it much more maintainable, since maintainers of ports can simply modify their own files rather than having to maintain patches against simmain etc. That's what I like about the simsys_XX interface so far.
So should I implement this using a #define (keeping just simmain.cc), or by using functions defined in simsys_q.mm (and then giving the other simsys_XX.cc files similar methods)?
I'm thinking methods along the lines of:
Which can be overridden as needed.
Does anyone have any suggestions around this kind of refactoring? Or any files which Simutrans needs to write to which I've missed?
I've decided for now to go with the approach of creating a simsys_osx.mm file, which can contain OSX-specific stuff (including sandboxing) and replace simsys.cc for this project. simsys_q.mm will contain the things specific to Quartz. Eventually there may be a simsys_ios.mm of course, and the Quartz stuff will be common to the two.