What about things like the config file, screenshots, message logs saved with /savemsgs, world files saved from Options > Save World, etc. Are those also stored inside this virtual sandboxed file system? If so, how does a user access those files? Would we need to implement some UWP APIs in our game to make it possible to save files outside the sandbox?
And a quote from the article you linked:
The idea is that developers can use Project Centennial to bring those classic apps to the new Windows App Model, but Win32 apps will still only be able to run on desktop or notebook-style computers with x86 processors until all the code is converted to Universal Windows App code.
So it sounds like they expect this method to be used to gradually update your application to UWP. Perhaps they'd even eventually force apps that were converted using this method to be migrated to UWP or risk being removed from the app store.
One part of the app store that has both advantages and disadvantages is the automatic updates. The advantage, of course, is that it could ensure users always have the latest version of the game, which is better from a developer perspective. But from a user perspective, they want to be able to choose the version they run. This would also be complicated by the fact that we'll eventually release another major (incompatible) version of the game. Normally during that time people may have both the previous and current major releases installed as game servers will only gradually be updated. For instance, the league might still use the previous major release until plugins/servers get updated to the new major release, or someone's favorite map is still only running on the previous major. So, from a BZFlag player perspective, automatic updates would also potentially cause problems and frustration.
There also seems to be a
number of limitations to UWP games, some of which would affect us if we converted to a UWP game. It sounds like the game couldn't be modified, which would mean users couldn't replace the textures or
sounds, or add additional fonts or translations.
The Windows App Store also hasn't had the best track record. Might be because they're a bit newer to the party and haven't worked out all the issues that the other app stores possibly had at the start as well. As recent as February of this year, they still had problems with
fake apps, for instance.
As for your comment about the Xbox,
it doesn't sound like the Xbox One supports OpenGL, so at minimum we'd have to switch to using OpenGL ES 2.0 with
Google's ANGLE, which would mean redoing all of our rendering code to use a more modern version of OpenGL that uses shaders. This would be a significant amount of coding to get that since we'd essentially be rewriting all of our graphics code. The other way would be to move all the rendering code to a library and then support multiple rendering APIs. Then we could use DirectX 12 directly, for instance. But again, that'd be a lot of work to put into the existing codebase. And maybe DirectX 12 is a requirement for games that are fully UWP.
All in all, I'm unfortunately not seeing enough advantages that would make up for all the effort involved to code it and maintain it. I appreciate the attempt to find a solution to the declining user base. I just honestly don't feel this is the route we should go. BZFlag in it's heyday was possibly more popular because there wasn't a lot of free online multiplayer 3D games. That has changed and there are thousands of those now. To get back into the game (pun intended) we need to rethink the game as a whole and get the game up to current expectations, not just push it into the app stores and cross our fingers.
