Speaking of mobile Doomsday, having played around with Qt 5.3 on iOS and Android, I now have a bit more concrete picture of what Doomsday will look like as a mobile build.
Supporting mobile platforms is something I think is very much necessary for the future. I see desktop computing becoming more of a niche thing, as most people’s needs will be met by various forms of phones and tablets. Still, DOOM was born in the age of desktop PC gaming and Doomsday will naturally respect this; not only will we continue to develop the project on desktop (or laptop) computers, that is the environment the game was originally designed for.
When it comes to Doomsday, I have somewhat mixed feelings about working on a mobile version. The differences to desktop are numerous and have a drastic impact on the gameplay experience. Particularly on iOS there are restrictions on things like file transfer (for accessing WADs), usage of dynamic libraries (plugins), and of course the overall GL throughput is much lower than on the desktop. Also, player controls are very different, so devising a good input scheme is crucial. External gamepad controllers could be a viable option, however having one cannot be a requirement.
Android is more free in terms of what is allowed, however the devices people are using are so varied that technical difficulties are bound to surface. In practice, we’ll have to target specific Android devices and just hope for the best.
Various mobile specific notes:
- We need a completely separate mobile
.profile — reusingclient.prowith some build settings will not cut it. Anyway,client.prois headed towards only containing GUI desktop specific stuff, with the common engine code moving to libdoomsday. - There needs to be a native wrapper for the mobile OS written in Qt with a sprinking of iOS and Android specific code. The libappfw UI framework will run under this wrapper app. The wrapper will be handling touch events, sensor input, and that sort of mobile specific things, passing them to the portable parts of Doomsday in a suitable format.
- Each supporting library needs a “static library” build option. We need to build all the supporting libraries statically and link them into the app (required on iOS, certainly doesn’t hurt on Android).
- It must be possible to statically build all the game plugins and link them all at the same time. The plugin code can then simply switch around some entry point function pointers to switch the game plugin.
- A good first step would be to get the GLSandbox test app running on iOS and Android; it is already fully GL2 compatible, so any OpenGL ES specific issues in libgui can be addressed with this test app.