mengelcode / finalfate Goto Github PK

After a small chat with another developer, I think I should interrupt the current game session when an input device is used, but is removed during in game. I will add blockers for this issue if appropriate.

When choosing to work on an issue on an own fork (with the goal of a Pull Request), please assure the following:

1. Don't work on issues labeled "Elementary".
2. Only pick issues without assignee.
3. Contact me via a comment on the issue beforehand.

The usage of function variables has been quite overdone at some point. So, before continuing, the object types an own Enemy class could be created for should become the subject to refactoring.

Since merging #33,
automated docker building stopped to work, seemingly.

Idea:
Have a bomb-like object which will do damage to the space ship.
The damage will be determined by the distance between space ship and bomb.

I think a portion of the implementation can be shared between #42 and this issue.

To be used for #30.

Even if most things in the game are self-explanatory, it is good if there was a guide, dedicated to end-users. I know that mostly devs are active on GitHub, but I think a user manual, in the most ideal case, available in the native languages of the players, should come with a good game.

Related to #4.

Example: It is not documented at all that the game can be paused, saved and resumed.
(Pause on keyboard = button p, Pause on gamepad = Button 9, a.k.a. "Start button")

The task can be divided into following sections:

• Create hatch for "secret fun".
• Create arms for attack.
• Create the two behaviours for the "fun".
• Adapt HUD (#16)

The task is a subset of #6.

Right now, there are basically limited ways I hint potentially new players to this repository.
These include, but are not totally limited to multiple Discord channels, most of them being public, some of them being more private.

TASK: Post about the game more often at the communication channels right now available.
BONUS TASK: Make YouTube videos possibly "public" instead of "not listed".

A potentially new player reported they would like to try the game on their XBox 360 and/ or XBox One.

TASK:
-Do research if the game could possibly run on one of those consoles.
-Prepare a webserver who can deliver the game to the consoles' web browsers,
-Contact the requester if the previous tasks were successful.

RESULTS (subject to updates)
The Edge included on an XBox One console is seemingly capable of HTML 5. In order to remove the mouse out of the picture, use:

navigator.gamepadInputEmulation = "gamepad";

This property does not exist elsewhere and adding it on another platform will most likely simply have no effect at all.

When you press either space or your self-chosen fire button at the title screen, you will most likely also shoot bullets, even if you did not intend to directly fire at something.

"Potentially unwanted" chosen because I think this is a super-minor bug. Correct me please if you think it is more severe.

The level is about Blinky enemy types.
So, some nice cube disco should be added at some point.

The backgrounds of Level 1 (blue entity filling the entire screen) and Level 2 (none at all - the default black of the canvas) could use some live.

It would be nice if one could play the game live without getting it on their computer in the first place.

TASK:

• Decide if the docker container or an already running Apache at my home is used.
• Setup one of the domains I have in order to show to my luckily static IP address.
• Add this as a way to play in the repo description and in the readme file.

Camping here will rewards players with points - - unacceptable.

maybe add a save feature too

Because the new Docker configuration files are now licensed under a Creative Commons license, the license file is no longer correct.
To prevent too much from going wrong, I think I should freeze all running tasks until I worked this out.

Related:
#20 and #33

In normal and easy difficulty, the game is too easy because everything except bosses can be one shot.
Include a bit of randomness.

"Keep in my that this feature is experimental and only applicable for Firefox browsers right now."
This is what the last sentence of the "The project" section reads. "Keep in my" was intended to be "Keep in mind".

Level 1 and Level 2 are playable. So the next logical step is to begin creation of the next stage.

A player reported that they find it rather unintuitive that the smallest object can hit them as it just fits into he gap between the two bullets shot.

TODO:
Make the shots spawn closer to the cockpit.
Change the look of the space ship.
Change the physics model if required.

When the game starts execution, the sizes of HTML canvas and 2D context are adapted to the window size. The sizes are not adapted when the browser window size changes after initialization.

Dear Mengel,

I dockerized your project with automated mutliarch (arm64v8 & amd64, arm32v7 aka armhf) images.

There is a catch: automated dockerhubbuilding doesn't support experimental features, so that the "ungrouped" images are not flagged with the correct architecture. The complet manifest is tagged correct so that this can be ignored safley for endusers.

I am working on a lightweight solution for that flaw but haven't got one so far. DIND (Docker in Docker) is my best working try but to heavy for just pushing the image - if you ask me. In case you don't care about buildtimes I can help to get it running.

Steps to accept:

1. Create or login to your hub.docker.com Account
2. Create the repository "finalfate"
3. Setup an automated build with github
4. Merge a pullrequest from my fork
   • Optional: Moove the build-args from the buildhooks build (and delete them in post_checkout since src_arch isn't in use anyway to your Dockerhub
   • Replace maintainer with an email (can be found in the same file)
5. Wait for the build to finish
6. Test the image e.g.
   docker run -dit --name test -p 8080:80 mengel38/finalfate:latest-amd64
   and open 127.0.0.1:8080 in your browser
7. Update your Readme
8. Enjoy

further ideas:

• Dockerfiles could be combined into one with a some
  sed
  commands and tweaks in the build hook (DOCKERFILE_PATH is the var send from dockerhub and the
  docker build
  command already uses DOCKERFILE which is already customised right before)
• Enabling automated tests could help with bugfinding.
• There is a great Browsertesting gitlab-ci.yml template from where you can start

The idea: For a short time, you can see a very large enemy. It can spawn Blinky enemy objects at random locations on the screen. Most likely, it will not spawn Blinky Tracer objects.

To be used for #30.

In #6 a level is implemented. I want to add an extra life icon. Changes will be committed together with the level progress.

Difficulties "Easy" and "Normal" are theoretically also too easy.
TASK:

• Create an invisible enemy object which sole task is to generate some walls.
• Create instances of it for Levels 2 and 3 (and later for others).

An interested player wished that the bullet color can be configured by the player.

A user stated that, in Mozilla Firefox, under certain conditions, a gamepad is no longer usable for steering of the space ship.
Reproducibility: Unknown
Stated condition: Lose all lifes, lose the last time while being in the right corner of the playfield.

The possibility is given that the user accidentally disconnected the gamepad for a short moment of time.

During the second boss fight, there is an area you cannot leave. Borders should be visible.

The creation of the current boss gives reason to enhance the HUD with a field "Status", which displays general info: Without spoilering the boss fight, following status texts might apply:

• Normal --> Standard state.
• Low HP --> HP beyond 40.
• Critical HP --> HP beyond 20.

Additionally, the HUD should be able to have a red background.

In #18, I misleadingly announced the usage of the BSD license by accident. It sadly took me a while to notice the mistake.
So, now I am going to be correct and more concrete in the announcement:
All commits after December 31 2019, 23:59:59 CET will be subject to the MIT license.

The collision detection for the power-ups is apparently still not perfect.
TASK: Fix this.

Related to #2

In #12, a saving feature was requested. Altough the game is supposed to be as old school as possible, some adapations to modern society could be necessary. The game must be saved and resumed later if the player wishes so.

This feature might completely change the nature of the game, so both "Enhancement" and "Elementary" will be added as label.

The shots are correctly registered so far. Where the current game "physics" still have its weakness is in the collision matrix of the space ship. An enemy needs to be there quite for some time in order to get a collision detected.

The aim is it to fully support both Firefox and Chromium-based Browsers. The current experimental gamepad support does not work with Chromium as intended.

Multiple persons asked me if I could implement a power-up which upgrades your cannons in a way that they shoot multiple distributed bullets. So, I guess this is now also in the project scope.

Levels 1-3 exist. 2 and 3 have some random-generated elements. Level 4 is supposed to focus on unexpected evilness, which can be learned to some degree.

Further versions of the game will be licensed under another license. The current state can be considered as "Public Domain" (free for everybody, without any conditions). Altough I cannot (I am not even willing to do so) revoke this, I will apply the BSD license in one of the next coming commits. The only true restriction for you will be that you are required to give credit then when re-using and distributing the software. Old commits and progress states are not affected in any way.

When using the pause function of the game, the spawning of the enemies is influenced.

Known cause: The "aniCount" variable still counts up, altough the normal game cycle is stopped.

How to (most likely) repair: Stop the frame counter when switching to pause. To animate something in the pause menu, an alternate counter needs to be used.
#19 should be resolved beforehand.

The idea: Flying objects looking like the enemy object type "Meteor", with a small twist:

• If you do not shoot them, your screen fill be filled with some fog. You will not be able to see new objects.

I want to use them for #30. This issue will become a very early blocker.

While working on #12, refactoring and possibly other factors did severe harm to the mechanisms which poll and apply the states of a possibly connected gamepad. This results on game crashes and/ or general unusability of the device. A new branch has been openend.

TASK

Manually merge the master branch and the new branch. Any work has to be stopped until this is resolved.

Because the scope exploded too much, I guess I need to decide if I will cut what I wanted to be level 5 of the game, a rather mecha- and metal-themed world.

A player reported they would like to be respawned in front of the level boss if they reached the end of level 2 or a follow-up level. The decision to implement this was taken.

Basically any sort of documentation is missing from the repository.

Because of #31, I decided the add a third bullet in the middle.

#2 has been solved. However, the price for correcting the algorithm is a serious loss of performance, notable in Firefox and Chromium.

TASK

• Re-write the structure of in-game enemies in a way which makes as little changes in the level generators necessary as possible.
• Check if the former task and the removal of now hopefully unneeded "shadow entries" in the collision matrices help performance to become acceptable again. All level 3 tasks will be blocked.

I think this name is not suitable for this game. I originally have chosen it because the corresponding enemy type has no capabilities except simply falling down /flying into a single direction.

TASK:
Refactor "StupidEnemy" to "SimpleEnemy" in the code.

During a showcase, it was asked if a volume control could be implemented. So I guess this should be added.

A player asked if a difficulty switch could be implemented.
I will continue development as I am doing anyways, but this will be the "Hard" difficulty later in its original.
Levels are supposed to be:

• Easy
• Normal
• Hard

As an owner of a Nintendo Switch console, I would like to use nice little "Joy-Cons" (basically small gamepads which can form together "one" gamepad).

If you try it right now, the following problems will occur:

• A "Joy-Con" can register to an ordinary computer via Bluetooth. But the problem is that one "Joy-Con" will always be a single whole gamepad from a technical point of view.
• The peripheral uses other axis ( axis 5 and 6 instead of 1 and 2) in order to register stick movement. So it will be impossible now to steer the space ship.
• I simply dream of playing my own game similar to how I can play what runs on specified console.
• A reliable way of differencing those devices from all other gamepads will be required.

Disclaimer: In no way I am affiliated with Nintendo, the owner of mentioned trademarks.

A user reported that they cannot differentiate between the red of the non-stop fire powerup and the brown of the enemy objects on their television.