zeskysee / we-missed-party Goto Github PK

As more and more NPCs get added to the conga line, they start to veer off screen. Worse, they take longer and longer to go to the back of the line, so the more NPCs the player has, the more they have to wait for the new NPC to go to the back of the line, making it difficult to get lots of followers.

NPCs should readjust their position the more numerous they become. They should try to fit into the screen and be close to each other as much as possible.

This is a quality-of-life issue. When the player triggers the ending, it is very easy for them to accidentally press the "Interact" button and skip through. This may cause frustration. It is currently not known how to exactly tackle this issue, I'll leave it up to the person who decides to implement this enhancement.

Some possibilities are:

• When the player presses Interact, show a prompt to "Press Interact again to return to title screen" so they have to press it again to confirm.
• Use another key, show a prompt "Press to return to title screen"

Another thing that this issue should tackle is that pressing "W" on the keyboard will also return to title screen. This is because the "jump" action is included in the ending.gd input check. The reason being that controller uses a separate button for jump and it feels natural to press to proceed. This should be differentiated from the keyboard controls.

Currently NPCs spawn endlessly at fixed spots. The level is also not very interesting, no landmarks in particular. Perhaps we may need to add some extra gameplay elements as we discussed in our larger scope that we couldn't fit into the jam period.

White color font NPC count is not very visible

Currently, while there is a skip button, this is not communicated to the player during the cutscene. The following changes should be made:

• Add "Press to Skip" prompt during the cutscene, similar to how "Press Spacebar to Interact" is.
• In addition to pressing a key to skip, the player should also be able to press the skip prompt with the mouse to skip.
• Allow instant skip from title screen and ending screen to gameplay (no prompt needed for this one).
• Add a new more accessible alternative key other than "~" to skip, maybe "R" (reload) or something.

Steps to Reproduce

1. Start the game and resize the window to a more square-ish or vertical aspect ratio.
2. Skip the cutscene or something to start the transition wipe.

Expected Result

The 4 transition wipe squares that appear should be discernable from each other, move smoothly and steadily.

Actual Result

The squares come out very abruptly, and in some cases, undiscernible, like a glitchy square.

Notes

This problem is caused by the 2D expand mode set for the game to automatically resize the sprites/viewport to fit the screen. When the aspect ratio of the game window is resized to be different, the transition ColorRect still has the same 16:9 aspect ratio as before, and does not expand to fit to the window well. For the jam, I rushed this by simply making the ColorRect really big by multiplying the window size, and because it's so big, the AnimationPlayer has to scale it very quickly to fill the screen, thus looking very abrupt.

This problem can perhaps be resolved by having a separate viewport on top of the existing one, but make it use stretch mode instead of 2D expand mode (unsure if possible or not). Another way is to find out the aspect ratio on window resize, then set the ColorRect size to match that aspect ratio, but this can be tricky because the 2D expand mode interferes with this width/height calculation.

Another possibility is to change the way the ColorRect fills the screen. Right now, because the ColorRects are anchored either left or right, the AnimationPlayer simply sets the scale from 0 to 1 to make the wipe happen, courtesy of @RailKill's idiocy. Instead, it could actually move the ColorRect position. Maybe this way, the ColorRect's anchor and margins can be made to always fit to screen (Full Rect) without the need to resize, and the AnimationPlayer never touches the rect_size or scale.

What's better than inviting followers to a party? Have friends help you invite!

It's not necessary but I think this game is simple enough that implementing multiplayer can be a great learning experience.

This game is very accessible and can already be played with the mouse, you can skip cutscene, proceed with dialogue and interact with NPC/trigger ending with just left-clicks all the way. The only thing missing is that you can't walk with the mouse.

When the player is in the neighborhood, left-clicking near the left side of the screen should make the player walk left, and left-clicking near the right side of the screen should move right. The advantage of only using left-clicks means that it should also work with touchscreen without any problems. Alternatively, we can use right-clicks for movement. Additionally, perhaps mouse scroll wheel should change the volume.

Currently in party_house.tscn, the interactions are all tied to the level, i.e. we cannot instantiate the level without the dialogue all being there. Ideally, interactions should be separately loaded from the level scene.

Also, @RailKill's stupid idea of embedding speech in magic_monster.tscn needs to be moved out. These speech do not belong to the magic monster, they belong to the intro interaction, and they should all be separate from one another. Level scene is a separate scene, magic monster is separate, and intro interaction is a separate scene too.

My current implementation of deleting the interactions on party_house.tscn's _ready() and rearranging the Nodes in the scene to prepare for the ending is dumb; this poses serious maintainability issues because nobody can actually see what's going on and has to imagine what would happen if the code ran to picture how the scene would look like. Supposedly, this should just be its own separate scene! Why so stingy with creating new scenes??

Mostly just unused variables/parameters and unused return values. Try not to use ignore-warning comments. For unused variables/params, either remove them or put underscore in front of the name. For unused return values, it depends; for error codes, we can print them out, for things like move_and_slide(), the velocity should be recorded (assigned to variable) - if there is no need to record its velocity, then there's a big question whether or not it even needs to be a KinematicBody.

Some actors such as player and npc have Area2D as the root node, and a KinematicBody representing their bodies as a child node. Because all child nodes follow the transform of their parent node, it seems unintuitive even if the Area2D is static that the KinematicBody's positioning is based on the area's. It should either be the other way round if the area needs to follow the body, or have no parent-child relationship (separate from one another).

Add skip instruction at intro & ending scene at the top left side of intro & ending scene

I think currently, this project is still too small for this. However, it's a good practice / learning opportunity for anyone who hasn't done this before for Godot projects. For CI (continuous integration), see https://github.com/abarichello/godot-ci and set up a GitHub Action. It's quite easy and convenient, every time we push to master or something, it will automatically build and export the project, so reviewers don't even need to checkout the branch if just wanna test the game. You can even refer to my existing setup: https://github.com/RailKill/the-fat-hand/blob/main/.github/workflows/godot-ci.yml

For automated tests, we'll need an addon. There are two main ones, GUT and WAT. Suggest to go for GUT (I use WAT but wanna try something different).

There are some things I'd like to have automated testing on:

1. Able to skip to gameplay at opening, intro and ending, prevents regression of #17.
2. Able to walk endlessly.
3. Able to interact with NPCs and get them to follow.
4. Can trigger ending.

This game is a simple game, but it can turn into a complete game if there is some sense of progression. For example, games like Crossy Road is really simple too, but it's the progression that makes it quite replayable. Through different endings, perhaps we can grant the player rewards.

Possible progression points are:

• Unlock more different types of NPCs to interact with.
• Unlock better stats/abilities like speed.
• Cosmetics? Different party house and props?

Maybe we have a final end game achievement of 100 followers. And in the journey of doing so, have some quests like get 2 dogs in the party or something. Completing these smaller quests will give the player more power to get to 100 followers easily. Once this is done, this project can be considered complete and we don't have to come back to it anymore, yay.