Anyways, if you've been reading this blog's previous posts about Mary's Magical Adventure, you've only been hearing about the main version of the game for computers running operating systems like Windows. However, in the past, I had plans to bring Mary's Magical Adventure to Android. It just sounds great on paper, to be able to take the game on the go and play the very same game you could play on your computer, or to even play with or against computer players using your mobile device!
In this blog post, I'll look back at the times I attempted to bring my game to mobile devices, and what I learned that I may put to use in the future...
World of Kirbycraft (D-Touch)
 |
| Yep, time to return back to those crappy old versions where I had no idea where I was going with the game again... (picture from World of Kirbycraft Development #3) |
Back in 2015, I found out that Beloko Games ported Doom to Android. This was done before, but what made Beloko's port different was that it included GZDoom, the very same version of Doom's engine I used for my in-development game, World of Kirbycraft. Due to how awesome this was, I bought D-Touch and, with a bit of tweaking, managed to get my Doom mods running on my old tablet.
As shown in the screenshot above, it was successful; For the first time, I could see attacks from another player's perspective, and experience deathmatch in my game! The tablet's battery was running low at the time, so this experience was quickly cut short, but everything seemed fine, the usual flaws of touch screen controls aside.
After that video, I started adding CVARs (console variables, or settings) to the game that would, I believe, tweak how running works (xane_dtouch_controls) and reduce effects (xane_dtouch_lag). Even back then, I knew Android could not handle much before it started dropping frames like crazy. After this, however, I don't remember bothering too much to get the game running on mobile, as ensuring it ran and looked good on Windows took priority.
First Real Steps
A couple years passed, and by then, D-Touch's version of GZDoom was way too behind the official engine build used on computers, so there was literally no point to bother making my game compatible with D-Touch. However, in 2018, Beloko Games released a closed beta of Delta Touch, the successor to D-Touch, which came with an up-to-date build of GZDoom! When I saw this, I signed up for the beta, and Beloko Games gave me Delta Touch for free due to my previous purchase of D-Touch on Amazon.
After everything was set up, I ran Mary's Magical Adventure on Android for the first time, and seeing my newly-renamed game running on my phone gave me the inspiration to start bothering with mobile optimization again. Yes, just seeing what I recorded in this video made me excited for a mobile version of MMA:
Mobile Performance Troubles
Yes, it might not look like much, but that was the island Hell City level running on Android, which was "amazing" at the time. Though it looks really close to its computer counterpart, something might bother you, and that's the inconsistent framerate that is first encountered when Mary enters the "park" area with the big fountain. Of course, no one should be surprised that lag is there, given this is Android running essentially a PC game, but...well, would you be surprised if I told you it could've been worse than what that video contained?
Faux-Draw Distance
Basically, look at the beginning of the video and you'll probably see that things in the distance seemingly don't exist until Mary gets near them, like early 3D games did. I implemented this for similar reasons to what those games would've done, for better performance. If I disabled that, the game would try to render nearly the whole map, and the framerate would plummet to sub-one frame per second.
 |
| This is how that level appears with "render culling on (top) and off (bottom). |
So, how did I pull off this weird effect, since I doubt any other GZDoom mod is going to (ab)use it? Well, basically GZDoom supports polyobjects, or moving walls that go from floor to ceiling. These are meant to be used for swinging doors or objects that can "crush" the player, but I discovered that the game doesn't render anything beyond these when I didn't put a texture on one of them.
Now, I couldn't draw a single diamond-shaped polyobject around the player, as that would create a solid object around the player, trapping them. However, by using two chevron-shaped polyobjects, I could place the player between them, then make them follow the player around the map. Back then, polyobjects were always solid, so a single solid object or enemy would stop them permanently until I removed the object, but later on, I modified GZDoom's source code to make "hurt on touch" polyobjects ignore collisions, creating the desired effect.
 |
| If you've ever looked out of bounds and wondered about the weird blue squares with white diamonds inside, now you know what they are. |
Why does this work? Well, you see, Doom's renderer was clearly optimized for the corridor-based, mostly-indoor levels in Doom, which had a lot of walls that went from floor to ceiling. When the renderer encounters a wall like this, everything behind it is not rendered. Polyobjects are also this type of wall, so they stop rendering, which is convenient for my game, which has wide open areas that Doom was never meant to render. Yes, if you stand behind a building on that island level, the game's still rendering everything behind it you can't see because unlike the Source Engine, Doom treats all sector heights equally, so if you can see through even the tiniest gap, the game will happily render everything.
Yes, all of that was just for one optimization; There are more of them, but they seem to be more effective on computers. However, there are other things that will cause Android to slow to a crawl than just rendering a open area without hackish invisible things blocking the renderer's view...
What Makes This Renderer Tick...in a Bad Way?
This is basically not an issue for computers and their high-quality NVidia GPUs and Intel(R) CPUs, but on Android's little ARM processors, the smallest things can cause frame drops. One of these things is slopes. Take a look at this video and notice how the framerate drops every time Mary looks to the left. Why is it dropping? Notice the island and volcano in the background? Yeah, the game's rendering all of those slopes and is lagging as a result.
That may seem understandable, but I've also seen that Android can't handle additive-rendered mid-textures, such as the fake lighting effects seen in City Street Run in the HCPD HQ's bathroom or the windows in Xane Corp.'s light testing room. If the game ever renders a single one of those, the framerate is basically guaranteed to be cut in half.
Overall, pretty much the only levels that work well in Delta Touch on even the high-end Google Pixel 2 are indoor corridor levels that don't use additive-rendered textures and don't have too many slopes. Man, that sounds boring. That sounds like...the original Doom, which Mary's Magical Adventure aims to be nothing like... What to do?
MMA: A New Hope
Well, an idea came to mind yesterday while I was sitting in bed, about to go use the bathroom. What if the mobile version was its own standalone game, separate from the computer game, with its own short storyline and simplified gameplay? Hear me out, this sounds like the best way this could be handled.
Think about it; If I used Mary's Magical Adventure's levels in the mobile version, they would be too open and would probably use too many of the lag-inducing things I mentioned above. This would require me to butcher the levels, adding render-blocking sectors and turning the levels way more linear. That would work better for mobile, but at the same time would probably feel like a bad imitation of a good game instead of an official mobile port.
Therefore, making mobile its own game would allow me to start fresh, with new, more linear levels and simplified gameplay. It would still feel like the computer game, but would be (nearly) made from the ground up to work better on mobile without compromising and possibly ruining anything from the computer version.
The story of the game would take place during Mary's Magical Adventure's two stories, beginning at the end of Xane's story. You would play as Princess Peppermint, the dark-skinned princess of Cumulus Peaks, who is tasked with killing the remaining monsters from the first invasion. However, as she finishes "cleaning up", the Origin Master accidentally releases more monsters, some of which land right near where Peppermint is. One of these monsters catches her off-guard, knocking her off the clouds down to whatever's below at that point in time. Now, Princess Peppermint needs to make it back to Cumulus Peaks to get rid of the new wave of monsters and save the place she rules over!
Yep, no Mary or Xane, just Princess Peppermint. I believe the inventory system would be simplified and any items Peppermint would walk over would be auto-activated, closer to Doom. Also, no upgrades or Jane's Hut, as Peppermint doesn't have the item to warp there. Now, if you've read the previous post, you might be wondering about her magical instrument. Yes, that will be one of her weapons, where pushing buttons would cause her to play different notes from her melodica, which would hurt enemies.
I wanted to add this to the computer version of the game as a mini-story, but with how big and overly-ambitious as my game's become, I think using this story for its own smaller game would work well for mobile! It would be smaller with less content, so perhaps it'd have a chance to actually get finished!
Anyways, with that said, that's the current plans for the mobile version of Mary's Magical Adventure. What do you think? Let me know in the comments below!
