Turning Hot Date into a Mobile Game

When I released Hot Date in May for PC/Mac/Linux I had ZERO expectations. It ended up doing way better than I expected, probably initially because of novelty, but hopefully that wasn't the only reason.

After it came out, I was pretty done with it. Didn't fancy working on it anymore. A few people said I should put it on mobile but I wasn't feeling the idea then, I had other things I wanted to make. Also, honestly, I didn't really know that much about making mobile games at the time. I was still a freshy to games in general. I thought there'd be an avalanche of optimisation and faffing about involved. (there was)

Recently though, I found myself thinking... Welllllll I guess I could port Hot Date to mobile. Take a break. I've spent the year makes games at Preloaded and learned how to actually make games for phones. SO I delved back in. My first impression was AHHHHH WHAT THE HECK. This is probably the case for every coder ever, but looking back at something you wrote 5 months ago is a harrowing experience. Especially when you of 5 months ago didn't know what you were doing.

So the first thing I did was optimise some code. Nothing major, just rewrote some classes and moved things around so it made a bit more sense to me.

Next big thing was figuring out what the inputs would be. I wanted the game to feel really simple and tactile, so I decided to make it portrait. It's easier to interact with, and the game doesn't benefit hugely from being landscape, anyway; all the action is in the middle. So I went from this:

To this:

And it fit quite nicely! Looks like it was a mobile game ~all along~ .

The next thing I looked at was the text. The original version has animated text like this:

Every letter is an animated sprite. I love how it flows, but having all those animating sprites is a bit of an overhead on mobile. I'd also had to write a system for letter kerning (which is still off) and for positioning all the letters centred and on new lines. AND it isn't dynamic to fit any screen size. Fine for desktop, naff for phones.

So I turned to Unity UI and used a Vertical Layout Group as a parent of the text. It stretches to fit the screen size for any device, and then set the padding on the layout group to give spacing at the sides. It looks like this:

And I used good old DOTween (my fav thing on the asset store) to animate the text like this:

It doesn't flow as nicely as it's predecessor, but it works fine on mobile, adapts to fit any screen width and there's no character limit because it will just go onto new lines.

The next thing was the actual inputs. The original did this:

Using the arrow keys to expand/collapse options. All well and good for landscape with a keyboard, but on a phone you've got such limited space. I wanted the mechanic to stay the same with expanding and building up a sentence, so I went for simple buttons that you press, which swap out for the next sections. The sentence then builds up at the bottom. Like this:

To try and keep it feeling tactile and responsive, I made an AbstractButton class that plays a tween animation when pressed, and every pressable object inherits from that. The important thing I realised after seeing the game on an iPhone 4s was to make the text big and the hit boxes HUGE so you can really lazily hit any option, like so:

Also using Unity's UI system I could have any length of text option fit even narrow phones with horizontal layout groups that stretch to fit the screen width:

The main optimisation was with the visuals. With a heavy heart, I got rid of bloom. I miss you bloom. I capped the fps at 30. I combined all the meshes in the scene into one to reduce draw calls. All that stuff helped a lot. There's still an animating character with quite a lot of bones moving around. The li'l dog is fully rigged and set up to walk around, I just came upon this idea which didn't need any of it, so the rig is a bit of an overkill. Could have optimised, but I hate rigging.

I still wanted shadows though and I didn't have the energy or skills to write my own optimised version, so I utilised ~quality settings~ . There's a slider in the pause menu for changing them. The different levels change the shadow resolution (or turn them off), change the anti aliasing, the number of skinned bones, etc.

But the hidden thing I do when the game is launched is check what the average framerate is over a number of frames. Then depending on what threshold it's in, I'll pick a quality setting. Here's the code that does it:

You're welcome to use it if it's helpful, sorry it's just a screenshot!

Aside from all that, a lot of the time I spent sorting out an Apple Developer's License, getting the builds working, using Xcode and all that lame stuff that involves a lot of waiting around. I made a few additions to the dialogue but not much. There's a bunch of other things I did like adding in links to the app store page, updating all the sfx, changing the transition, but this has gone on LONG ENOUGH

That's it! I released the game last night, and now it's nearly Christmas and then I'm going to New Zealand for a month. BYE.