I've always disliked when people use "personal stuff" as an excuse for not getting their work done. This problem ran rampant during my college days, and it was especially frustrating then because I knew that that kind of behavior in the real world would result in getting fired, but nothing could really be done about it in the context of a team project. But here's what's really interesting: I've been seeing the same thing happen more and more lately to some Patreon game developers I follow. Their updates get released days or weeks late, and are near unplayable due to bugs so bad it's baffling how they got past testing...and it's always because of vague "personal stuff". In that case, of course, the solution is to stop supporting said developers when such a pattern emerges, but I think in most cases they've already become successful enough that they can afford to become lazy and lose a few morally-superior patrons without much feeling it. Where am I going with all this? I'm just trying to apologize for why I haven't done a post in a while; it is indeed due to "personal stuff", such as going out of town to interview for jobs on-site. Remember, even as I'm making games for my own pleasure, I'm first and foremost job hunting. It's why I never set release dates unless I've already met all of my tasks for them, which is in turn why I could never set up a Patreon for myself. But I'd rather continue like this, on my own time table, than damage my reputation over missed deadlines. It's about knowing my limits, and being responsible enough to schedule my time so that if something does come up, all the essential work is already done.
Okay, enough of that. In between everything, I've been working on the How to Play screens. I wasn't sure of the best way to handle them, for a few reasons. First, it baffles me how few people will actually click through a How to Play menu or play a tutorial, preferring instead to just jump right into playing and then complain about not knowing how things work. Intuitive gameplay and all that, granted, but personally I like to be armed with as much knowledge as possible when starting something new. Now, some games will force you through tutorial sections at the beginning, but this wasn't really an option for UO. I thought about a "firstTime" flag that would spawn some special sections at the beginning, freezing time as you approached your first obstacles and enemies, but on top of all the extra code to pull that off, I'd need to consider the different levels being played, and a way to re-enable the flag, probably through the Options Menu, which would necessitate a redesign of that as well. All just so people could complain about an unskippable tutorial? No thanks.
So instead I'm back to a dedicated menu, but that wasn't without problems either. I knew that the hardest mechanic to explain was the phone tilting; all my research into gyroscopes taught me that there's no good way to describe tilting "forward" vs. "backward" vs. "towards" vs. "away", or god forbid trying to actually name one of the x-, y-, or z-axes. What I really wanted was a graphic showing the phone actually tilting around the relevant axis, so there would be no confusion possible. One million hours of artwork later, and we've got this:
I use a very simple script in-game to cycle through the images for gif behavior. Displayed next to it is a picture of the submarine, which also moves up and down in time to the phone's tilt. I added a brief blurb below the gifs, and created similar pages for the other mechanics like shooting and moving faster and slower.
I wasn't sure how to talk about the various obstacles, since A) I wanted to leave their specific behaviors intentionally vague so that players could discover them on their own, and B) there are only a few different variations of these behaviors, but the obstacles themselves may look completely different in each different level. Should I do a new obstacles page for each level that I add? I decided not to, and in fact to pretty much just restate what I said above: learn the few different behaviors, and then be able to categorize anything new you encounter into one of them.
There's one last thing to mention, and that's my secret plan to launch at least one demo build of this game to the internet before it goes live on the app store. I've already got the back-end code to make this possible, because I added keyboard controls early-on so I wouldn't have to keep deploying builds to my phone to test anything. But a How to Play screen would be pretty useless if all the controls it mentioned were for a completely different platform... I needed a few more art pieces to replace the phone up above, but for the most part, switching the How to Play pages used the same way I switched the controls themselves wasn't a big deal.
That web build shouldn't be too far away at this point, but to bring things full-circle in this post, I'm not going to make any promises I'm not 100% sure I can keep. I've still got a few sound effects to pin down, and I need to create dozens if not hundreds more variations of the obstacle gates, followed by testing...but know it's coming!