DrawImage is kind of slow, and SVG can look weird in Firefox.

1. Identify fastest format to draw (image data? Canvas path ?)

2. Make a tool to convert the image files to that format and import them as a script.

yet another experiment with controls:

• joystick that does directional movements
• jump button
• grab button
• (optional) only display if on a mobile device:
• art for jump button should be a stick figure jumping
• art for grab button should be a hand grabbing a balloon.

Keep the balloons further from each other so that there is less overlap

Use a "network first" service worker instead of "cache first". The performance boost isn't needed right now. Better to have it update automatically.

Can look into other methods later. Currently, a service worker isn't even necessary.

1. As a balloon approaches it's "popping altitude", have the balloon's color change (or provide some other form of visual feedback)

2. Show a "pop" after the balloon object is deleted. Player won't be able to grab the popped balloon, but an image will stay there for a second.

Game viewport

Game viewport = size of <canvas> element.

Currently using a square for the game area.
Ideally, the game should be in portrait mode and take up as much of the screen as possible.

Golden ratio example:
https://github.com/fractalbach/golden-ratio-webpage/blob/master/index.html

Coordinate systems

Requires changing the codebase to separate between the game "world coordinates" and "viewport coordinates".

Would be useful to have to both coordinate systems anyway. That way there isn't a need for a seperate "altitude" variable.

Pause button upper right hand corner of screen when playing the game.

Use Object/Memory Pool
Initialize a bunch at the beginning of program,
Mark as "inactive" instead of deleting.
Reuse the object later.

Why

The touchscreen controls are shit.💩 They are unintuitive, confusing, and sometimes unpredictable. 🤨📲❓ Currently, they can cause players to ragequit within 20-30 seconds.🤬

After experimenting with several different types of controls, there is no clear-cut solution. The only consensus is that "something's not quite right".

How to find better controls

The way forward appears to be constructing a way to compare and contrast different controls schemes.

When given a bad control scheme, it's challenging to identify the "way it should be". It seems to be easier to compare 2 different ones, and say "this feels better than that".👍👎

what's playtest mode?

Able to swap between multiple different control schemes, and compare then on different scales:

• Overall, which feels better?
• Which is easier to learn without thinking about it?
• Which is more fun to use?
• (Finding specific questions to ask is hard.)

For the🎈 Balloon Grab🎈 game, here are some of the control schemes to try. Can try different combinations and mix-and-match different parts together:

• Virtual fixed buttons for jump and/or grab
• Virtual fixed joystick for movement or directional jumping
• Swipe in the direction you want to jump.
• Tap in the direction you want to jump (relative to player)
• Tap left/right sides of the screen to jump in that direction (relative to screen itself, not player)
• Tap on the location you want to jump to.
• Tap anywhere to grab a balloon.
• (More combinations of buttons and tap/swipe anywhere)

First screen, keep it simple.
title, author, Play Game, About Game

(Maybe recent updates)

Otherwise Add extra information in the About Game section.

Save canvas image data using
canvas.toDataURL("image/png").replace("image/png", "image/octet-stream");
Or just keep it as a png

This could effectively save the footage of the game.

Make a seperate tool to assemble the images into a gif or some video format.

Goal

tapping a location on the screen will result in the player "jumping to" that location. The player should always pass that location (if it's reachable).

Currently

Directional Move calculates the unit vector in the x-direction, and uses that to control the extent that a player moves, but it does not actually mean a player will jump to that location.

directionalMove

• takes a unitVectorY as a parameter, but then ignores it.

jump

• is just using a constant value of 20 always
• should be using the unitVectorY that is passed to directionalMove.
• probably should be integrated into directionalMove.

How

• the unit vector in y-direction needs to be used to adjust the "strength" of the jump.
• instead of using a single REQUEST_ACTION , use a REQUEST_JUMP.
• since directionalMove assumes that you are jumping, it should call jump.
• jump() should take parameter jump(unitVectorY=1), so it defaults to a regular full jump in other cases, and when called by directionalMove, it can include the unitVector.

Causes bug where the game does max fixed steps every single frame until the timers are back in sync. Noticable on phone when u close browser and come back after a little while.

• holding Up Arrow can cause you to jump & climb up really quickly, automatically jumping, grabbing, and moving upward.
• it's caused by the fact that there is a REQUEST_ACTION that is being turned on very often by the Up Arrow on keyboards being fired repeatedly
• holding both UP key and either (LEFT or RIGHT) keys will cause you to "slide through" a balloon-grab-box as you are falling.

Presumably, This is a side effect of...

1. REQUEST_ACTION calls both JUMP and GRAB
2. the rapid firing of REQUEST_ACTION
3. After each jump, you fall a few pixels, then you grab, etc..

TODO

This can probably be fixed by...

1. removing the entire concept of REQUEST_ACTION, and
2. replacing it with individual commands for REQUEST_JUMP and REQUEST_GRAB.
3. Improve the controller logic based on the conditions of the game: (ie. do you really want to jump after you have JUST finished grabbing something less than 20 milliseconds ago?)