Designing Game Onboarding

This is pretty much for me to remind myself while working on MiawFly.

So while developing this game, well actually the gameplay itself is made within 48 hours (even though I thought up the game and designed a few levels on paper probably a few months before).

The bulk of the other time is spent on improving the experience, getting the Google/Apple services and push notifications to work, sql database thingies and others.

So, I'd be detailing all of the other processes later on (for me to read again later), but for now I'll be writing about the onboarding process.

So, once I've settled the push notifications and sql database things and modifying it to make it kinda mobile friendly, I start to play test the game towards new players (The play testing to find out the game is fun or not have been done, and it seems like nearly every programmers around me got hooked to it, so I think it might be fun, I hope).

...It varies between people. Some immediately understood the mechanics, some doesn't but they tried until they understand it, some just tried but missed some mechanics, some simply need me to verbally instruct them what to do.

Now, the problems that I see based on how they played is that:

1) They have no idea how to start playing. They are dumbfounded during the first screen. 

In more detail: At least among the testers that played:

  • Usually they start with 'hmmmm'.
  • Some touched on the right side rather than the left side of the bazooka. This put them off a bit because the bazooka starts pointing the other way. They immediately understood that it's pivot though once they moved around (Unlike in the PC version, the Mobile version you need to target it from behind, sort of like a pivot. This is because I found out that simply making the touch point the same way as PC version blocks the view massively and limits the targeting angle the player have). 
  • Some touched and immediately released, so the Miaw is shot weakly and they didn't understand what happened.
  • Some touched and held and never release the screen. So they missed the point that they could release the bazooka a little bit earlier to control the shooting power. 

2) The restart button is either too small / not prominent so they don't see it. Actually they didn't realize they need to press restart.

More detail:

  • Some people of course immediately understood they need to press the reset button. But usually they'd go "Hmm, I f'ed up. Hmm what should I do, how do I restart? Oh there it is" (These are programmers / used to games).
  • Some completely doesn't see the restart button so they just wonder what is he/she supposed to do after they shot.
  • It feels like the restart button is too small so sometimes they missed pressing on it even though they pressed. They kinda need to press it 2 or 3 times.

3) Some don't even realize the point of the game is to dunk the Miaws into the respective zones.

  • Some initially thought that they gotta shoot at the shadows of the miaw. So they tried targeting the shadow instead. I was hoping that they understood it as "Shoot that yellow Miaw here at the yellow zone" but instead they were targeting at the ghost miaw instead.


(Now this didn't pose a problem in the PC version because I wrote instructions on the screen, and maybe the testers being programmers also worked in my favor. The mobile version I let them use got rid of all texts and rely on visual cues, gestures and arrow to instruct the players but clearly they don't work)

4) And last thing would be in the more advanced levels where it isn't clear that you need to put ALL of the miaws into their respective zones if the zones are there. For example

...It isn't clear that both of the yellow Miaws need to fall into the Yellow zone, rather than only one.

Alright, so those are the biggest problems so I'll need to design it so that all those problems are settled.

And I'd like to take is opportunity to write down what ErebusWolf critiqued about it here: https://www.twitch.tv/videos/206924909?t=10h55m03s

But basically:

  • Difficulty curve too high (Level 1 and 2 was fine he thinks, but Level 3 was too much of a jump because it makes the person had to do a trick shot too early in the game). 
  • Doesn't immediately advance the game when player solves it or reset the game when the user fails / is in a no-win-situation automatically. It relied on the reset button.
  • Doesn't have much sound cues. So like you know when the user hits the correct box, go "Yay!". When the user fails, go "Awww". Maybe when the Miaw is shot, make the Miaws go "meeeoooowwww" or something.

And those are pretty much the biggest problem that needs to be tackled from a game design perspective.

-------------------------------------------------

Alright, so with those in mind, this is pretty much the plan to tackle the problems:

1) They have no idea how to start playing. They are dumbfounded during the first screen.

There are 2 ways to approach this. Either make it fully text on the screen. Say, something like this:

(Pretty much Ludum Dare like, and most time-effective)

Or I make a more complicated one, like this:

After the User hold and move around, after 5 seconds then it plays the successful sound and then move to another level with the rocket launcher loaded instead.

...And you know what, while writing I just came up with the idea where the first level will be surrounded with blocks and the bottom will have the yellow zone while all of the place will be filled with slopes that will slide all the Miaws there.

Over there all the tutorials will be done in order -> Dragging, Shooting, Shooting with Controlled power and Target the Yellow Zone. Miaw.

Unity: Camera screen resolution

https://answers.unity.com/questions/574951/make-unity-camera-appear-all-screen-width.html

The orthographicSize property defines the viewing volume of an orthographic Camera. In order to edit this size, set the Camera to be orthographic first through script or in the Inspector. The orthographicSize is half the size of the vertical viewing volume. The horizontal size of the viewing volume depends on the aspect ratio.

https://docs.unity3d.com/ScriptReference/Camera-orthographicSize.html

Using Camera > Projection > Ortographic, Unity will only take the Vertical units as the one being rendered onscreen, THEN render the horizontal lines that fit.

For example:

If you've set the Camera Size to 10, the playing area in Unity Editor will be 20x20 units, which is denoted by the lines (remember, the size is counted starting from the center, so 10 to the left, 10 to the right, 10 upwards, 10 downwards, so 20x20).

Then, let's say you try to publish on a screen that is 300x400  resolution. Then, Unity will fit 20 units vertically at first so that it fits the screen. So each unit will have 400/20 = 20 pixels.

However, the screen only has 300 pixels horizontally. So the screen can only fit 300/20 = 15 Unity units. So only 7.5 Unity units from the origin will be rendered horizontally. So the whole thing being rendered in Unity units is 20x15. 

Make sense?

How about the UI?

https://stackoverflow.com/questions/32347009/unity-canvas-does-not-fill-screen

1. On your canvas, set the Canvas Scaler component's Ui Scale Mode to Scale with Screen Size. Then you can define a Reference Resolution of 1080p, i.e. 1920 x 1080.

2. To see the canvas fit into the camera's size in the scene, change the Canvas component's Render Mode to Screen Space - Camera, and drag the camera from the hierarchy to it.

3. Me: Set the UI Scale Mode to Scale with Screen Size

4. Me: Lastly, set the Screen Match Mode to "Match Width or Height". Then, set the "Match" value to "Height" (You can also set it to 0.5 if your game is both horizontal/vertical). So now the canvas will act like a Camera as well, will first adjust to the correct height first, then fill in the rest.

https://docs.unity3d.com/Manual/HOWTO-UIMultiResolution.html

youtube: https://www.youtube.com/watch?v=svyDgYz5idg

 

 

Modern Mobile Game Design

I'll be looking for resources about Modern Mobile Game Design and list them below. Basically this post will be a placeholder until I actually have a grip hold of the most important ones, or enough to design a good mobile game.

  • Very short tutorial length
  • Get rid of main menu if possible. The player should immediately play the game after launching it. 
    • First time open, immediately play. Then from game over screen can return to main menu (or the game over screen is main menu itself, depend on game).
    • On second open onwards, open the main menu (some games save state when exit and start there?)  .
  • Game mechanic that is not immediately understandable after 2 second of playing? Back to the drawing board.
  • See Voodoo or Ketchapps game (Dunk Shot, Rider, Dunk Hoop)

 

Git cannot clone remote repository

https://developercommunity.visualstudio.com/content/problem/19752/git-cant-clone-remote-repository.html

This one:

https://developercommunity.visualstudio.com/solutions/66693/view.html

 

I am getting this same error in 15.2 (26430.12). I tried the above best solution and it did not resolve my error. I could repeatedly reproduce this issue if I went to:

  1. "Manage Connections"
  2. "Connect to a Project"
  3. Selected any repository
  4. selected "Connect"
  5. Try to clone from the Team Explorer window

Almost all of the repo is cloned and at the very end I get the CloneCommand.ExecuteClone error.

However if got to

  1. "Manage Connections"
  2. "Connect to a Project"
  3. Selected any repository
  4. selected "Clone"

then the repo will successfully clone. Again, I tried the best solution above and it did not work.