Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: don't allow gooeys to climb over blocks #72

Open
wants to merge 1 commit into
base: develop
Choose a base branch
from

Conversation

jdrueckert
Copy link
Member

Motivation

IMO part of the fun when playing a tower defense gameplay is to find strategically good places to build towers to most efficiently impact the oncoming waves. This does not work as well if the enemies can basically just walk in a straight line towards their goal, which is the case with the current arena maze being only one block high and the current movement implementation allowing the enemy gooeys to climb over them.

An alternative common tower defense mode is a completely free arena where the enemy waves can by default intentionally walk in a straight line and the player has to create a maze themselves. However, due to the arena design including a maze, I don't think that's the intentional mode here.

What this PR does

It reduces the vertical movement range of the oncoming waves to staying on the same level only. Thus, they cannot climb over the maze blocks and need to find their way through it instead, providing the player with more options to strategically place towers.

@jdrueckert jdrueckert added Type: Bug Issues reporting and PRs fixing problems Category: Gameplay Content Requests, Issues and Changes targeting gameplay mechanics and content Size: S Small effort likely only affecting a single area and requiring little to no research Topic: UI/UX Requests, Issues and Changes related to screens, artwork, sound and overall user experience labels Apr 8, 2022
@jdrueckert jdrueckert requested a review from syntaxi April 8, 2022 19:25
Copy link
Contributor

@skaldarnar skaldarnar left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you just wall off the enemy lines with this change (I guess you could so before anyways)...?

@jdrueckert
Copy link
Member Author

Yes, I think you can. And yes, I think this was possible before as well - although admittedly a bit harder.
Ideally we'd want this kind of "validation enemy" that WC3 tower defenses used to have - basically a dummy enemy that check that there's still a path to be found to get through to the goal... Using our pathfinding, we could also pre-compute this and block/warn the user when they try to start a wave.
Shall I write up a feature request for any or both of these ideas?

@jdrueckert
Copy link
Member Author

@syntaxi commented on Discord:

Ah so they can't climb two blocks high. I seeded the field with the random blocks and the intent was to build a maze ontop of that
So by picking up blocks from some areas and then putting them down in others
Making them unable to go up or down at all is also valid, but I think that the inital maze seeding should be toned way way down then

@jdrueckert
Copy link
Member Author

I responded

Okay if that was the intention, then we can also close the PR, but we would need to make it a bit more clear to the player IMO

However, as stated in the "Motivation" section in the PR description, for me it feels a bit like, we give the player neither the full liberty to create a maze of their own design (blank arena and building blocks in starting inventory or shop or both) nor a preset maze so they can concentrate on the strategic placement of towers instead of having to "farm" blocks first...
IMO the current set up is a middleground that give the player to do either, but at the cost of additional overhead (farming blocks to get a clean slate or a two-block high maze) that distracts from the actual gameplay...

So I think we have the following options to move forward:

  1. close this PR (keep gooey movement behavior as before) and don't change set up
  2. close this PR (keep gooey movement behavior as before) and set up maze two blocks high
  3. close this PR (keep gooey movement behavior as before) and set up arena as blank (without maze) + provide building blocks in starting inventory and/or shop
  4. merge this PR (change gooey movement behavior) and don't change set up
  5. merge this PR (change gooey movement behavior) and set up arena as blank (without maze) + provide building blocks in starting inventory and/or shop

From my point of view, all options but the first would be okay because they take us away from this "middleground" situation.
@syntaxi what do you think?

Irrespective of which option we go with, I think we should explain the intention a bit better, for instance on the game start screen.

@skaldarnar
Copy link
Contributor

My two cents here:

I like the idea of having randomly seed crates as foundation for the maze. However, we should make the player aware that they can place these blocks to guide the gooeys. I'm imagining something along the lines of (maybe parts of it, maybe all, ...)

  • give the player some crates to encourage them to build pathways
  • teach the player better how the gooeys behave (tutorial round of things? some walls already placed 2 blocks high, with the particle path indicating that they cannot climb that?)
  • make sure that players can pick up the crates with a single click, and that they don't need to "mine" them (not sure whether that is already the case)

I'm opposed to start with an empty arena, as it is quite a big area, and the fun part of the game should be placing towers, not these crate blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Gameplay Content Requests, Issues and Changes targeting gameplay mechanics and content Size: S Small effort likely only affecting a single area and requiring little to no research Topic: UI/UX Requests, Issues and Changes related to screens, artwork, sound and overall user experience Type: Bug Issues reporting and PRs fixing problems
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants