genba-games / morsemadness Goto Github PK

I think most of the logic is already there, we just need to invoke it.

We should add at least a text that says that you win.

Now when you win or loose the game sends you back to the main menu without any input or anything, we should at least freeze it until you press something.

9/10 times you can't get past the first 15 seconds or so of the game because lava gets to you before opening the firsts doors or advancing enough horizontally.

The new keyJustPressed helper method does not have support for keyboard keys just yet.

I'm including this in #16.

Some ideas that came during discussion that the pattern length does not necessarily imply difficulty so we should classify them by the time that it takes to input the code with the number of errors.

Different objects are called various names throughout the code. I'm opening this issue to converge on some names and update the codebase accordingly.

The three main objects we need to name are:

1. Signals sent by the operator.
2. Signal Arrows.
3. Groups of signal arrows.

Some terms I found sprinkled everywhere:

• Signal → Usually used for Signals sent by the operator.
• Transmission → Used for both arrows and signals sent by the operator.
• Pattern → Usually used for Signal Groups.
• Morse → Usually used for Signal Arrows.

When activating doors with the operator signal queue full, the condition check to generate the transmission morse codes only if there's enough room in the operator queue is checked after activating the door. This leads to the door activating and not creating the morse codes. Since the last morse code in the transmission should open the door and is never created, the door can never be opened.

Replace npm install with npm ci.
https://medium.com/@tomastrajan/how-to-speed-up-continuous-integration-build-with-new-npm-ci-and-package-lock-json-7647f91751a

When dying, the character disappears after playing the whole animation.

For some reason you cant play without gamepads.

its out of place since we shrinked the game

For some reason the maze generator dies when you shrink the canvas. I'm looking into it and it dies when the maze generator is setting the corner down right to the wall.
Another thing i realized is that it does not happen if you set the y offset to 0.
The first question that comes to my mind is why do we deal with offsets instead of absolutes?
I'm still looking into it using this issue as a log!

For some reason both players share the action key. Enter and Space

Such as dungeon, city?, cave or similars!

I already implemented a crude eye catcher menu, i think we should do it in that state or add an extra settings state!

Itch.io has a cli software that we can use to update our game, since GKE is free now im pretty sure we can run a jenkins instance there that builds on master push events.

When the game swaps the gamepads it stuns you for some time, it'll be nice to show that somehow

Design and implement items.

The code for the Item class, dweller, item collision (through gActors), and generation of items in the maze are already in place.

The new keyJustPressed helper method does not have support for controller axes just yet.

I'm including this in #16.

When you try to move with the arrows it scrolls!

This is up to discussion to figure out what will be scored and how it will be.
For the maze part we need a timer and for the operator part we need a score system that counts hits and misses and maybe time the shots.

When playing as the operator, keys are only polled 250ms after the last key was pressed.

The gamepad rework removes this limitation with the keyJustPressed helper function. This poll delay should be removed in favor of this new method.

Right now when you press any button the game starts, it should end the intro animation and let you choose if you want to play the original game or training mode.

Try launching the project with phaser 3.

Keymaps now hold both keyboard and controller button/key configurations in the same array. This makes it so that overlapping codes can trigger unexpected actions. Splitting this into groups would allow to check each set of buttons/keys with its own, input-specific function.

I'm adding this to #16.