greenfoot5 / bestagon-defence Goto Github PK

The game needs music.

When you kill a boss, it would be cool if you could pick a reward (or with #93 you pick the reward by picking the wave). This reward should be special, applying to all turrets, or all those of a certain type, or providing a global boost (maybe all enemies are slower, or every 5s one path becomes a swamp tile and slows all enemies that move through it).

It could also potentially be a very significant upgrade to one turret. @bloodwiing had an idea for this.

Currently only an image of the map is displayed. Displaying the features of the map as well as some small stats (keep some stuff hidden) would be good and make it easier for players to pick a map, and make the map variations clearer.

There is a gap between the menu and the play button could provide the info. However, this is a cheap and quick solution (suitable for 1.1 as level info will change with the addition of various enemies in 1.2)

Currently, the level select shows a preview of the levels, it's name, and then info for the leaderboards. It would be better if the following was also added:

• Information about any special traits (i.e. loop not allowing top level modules)
• Information about enemies found in the map
• Information about the bosses
• Generalised information about the map's balance
• Amount of lives and gold to start
• Maybe some tips that can be unlocked once you reach a certain score

Not all of this information needs to be added, but certainly more information is needed. Possibly show it as it is currently, then if an info button is clicked/tapped, you're shown more detailed information on an in-game wiki (#88). It also shouldn't extend the amount of time it takes to get into a level, or resume a level, so having it on an optional extra menu/screen for the extra info could be very useful.

Is your feature request related to a problem? Please describe.
Ghost module has one tier. But it doesn't do that much. I feel it could be improved, as well as have possibilities for upgrading.

Describe the solution you'd like
I'm not sure what could be added
More damage may make it a more attractive module, but I'm not sure it actually adds or improves the module, and it wouldn't be that useful for upgrades.

Additional context
The module currently allows bullets that pass through enemies to deal damage to them as well, but only once.

When opening the shop, the user needs some UI so they can make their choice

Base UI

• A shop button (that's clear it's a shop)
  • Make a change when the user can/can't afford it
• Allow for translations
• Display the purchased items in your inventory
  • Similar items should be grouped together/stacked
  • Stop players "overflowing" the inventory, either by making it scrollable, or giving it a cap

Shop UI

• When you open the shop, there should be three randomised choices the user can pick
• When you open the shop you should get the option to refund your purchase (for no more gold than you paid), an option to gain lives and an option to reroll the three randomised options.
• Time should pause when you open the shop to give players time to pick
  • It should be clear time has paused (some players didn't realise so something to show this better than the background not moving would be good

Shop Cards

• Create the cards displaying the name and information about the choice
• For modules, display what turrets can use it.

Currently, the Node UI displays the important information, but it isn't great. The modules aren't grouped in any way, the buttons look like temporary art (they are) and the stats can be really hard to read (as well as only showing three, where some are completely hidden). It's also unclear sometimes why a turret isn't attacking (i.e. the range is negative, or the attacks speed is negative).

It would be good to rework this a bit showing all the useful information, without blocking off too much about what's going on in the map either. It could also be nice to expose the aggressive retargeting boolean.

At any point in the game, especially with how complex the game can be and the amount of options a player can have, it would be good if players can pause the game, open up a "magnifying glass" and get an explanation on what something does when they hover/click/tap on something.

• Could have a popup that covers the screen when something is clicked/tapped, and pause the game then
• Could have a hover modal and pause the screen as soon as the magnifying glass is used
• Should work at the least on all buttons, enemies, turrets and modules (including those in your inventory)

This would be a significant Quality of Life feature that would mean you don't have to pause the game, find a link to the wiki and locate what you actually want to find info on, instead, it's two clicks and you don't have to leave the game.

Similar to Mini Motorway's photo mode, it would be really nice to allow players to share their scores in a better method, along with their setups when they finish the game.

This would mean the game would need to stop when the game ends, as well as possibly some better layouts. This would mean some UI would need to be reworked, possibly adding some borders, deciding where the score will be displayed, as well as options to display turrets selected and what modules were applied on them would be ideal.

On the programming side, navigation of the UI, but also allowing players to take a screenshot and have it saved to a useful directory.

During the lull between waves, it would be good to show where enemies are coming from, the path their traversing until the end. This isn't that useful currently, but when there are multiple paths, it would be very useful.

The game currently has no sound effects, paired with #107, makes the game dead to the ears. There are currently no sound effects, so everything needs sounds (buttons, enemies, bullets, turrets, etc.)

The choker turret is a mix between the shooter and the smasher. It shoots out a set of bullets in a spread each time it fires. It's not very accurate so could miss it's target completely! It's range also isn't that great either. There are some extra stats that could be modified by modules as well:

• Spread of bullets
• Number of bullets
• (Maybe) accurary, making bullets more likely to be shot in the middle of the spread than the outside

It would be a dynamic turret, so most of the base is written already, it's just the attack that needs creating as well as a design for the turret itself. You may want to consider #85 in the design.

The icons that represent an enemy's ability/ies are basic shapes that don't actually communicate what the ability is. The current abilities that need changes:

• Heal (both radius and self-heal)
• Summon
• Sugar
• Split

The new art should ideally fit the module icons, and possibly #85, they should also be easily recognisable and generally explain what they they do (as best as possible with a small icon)

Initial Idea

Zapper - an AoE turret which prefers enemies clumping up together, but hates single targets
Every time it shoots around itself, the attack chains along enemies and increases in damage. The more enemies, the more it chains and the more it does.
A lot of small bois leading up to a big boy will lead to big damage. A single big boy will basically feel nothing.
On-hit effects could also scale with this, so the more the chain travels, the more potent the slow or stun.
@bloodwiing

It could also fire lightning that simply bounces between enemies, where the max distance between each jump, max length as stats to modify.

Describe the bug

When selecting a turret, modules will be greyed out and you can’t apply them, but they can still be selected if they’re the first turret

Reproduction Steps

1. Have a turret placed
2. Purchase a module that cannot be applied to that turret (it must be the oldest module in your inventory)
3. Select the turret it cannot be placed on, the module is selected but cannot be applied

Expected behaviour

The module shouldn't be selected

Currently the UI scaling doesn't do well on wide, shorter screens. It all squishes together. Equally, on larger, taller screens it doesn't look great. The anchors likely need playing around with, to make sure that it scales up/down correctly.

There are a range of abilities with the players, this splits them up by how many waves they reach. However, what if that could be improved?

The idea follow's Hades' infernal contract idea. Basically by adding difficulty modifiers (increase the number of enemies, bosses gain an extra ability, turrets rotate faster, etc.) you can make the same level replayable many times. This would also mean levels could be shoter, favouring increasing the difficulty from the start, rather than spending an hour to build up a defence to stop a couple waves.

There's also the option of adding modifiers that decrease the difficulty to allow players help with learning the game, or trying out a particularly difficult level.

This system wouldn't work that well without progression, but it could be nice if levels start going on too long to implement.

Currently the leaderboards are quite bland. It would be nice if players could customise their banner on the leaderboards, maybe profile icons, banners and badges. It would be good to give some players a couple to try out for free, and then earn more through special achievements.

Currently, enemies have no way of displaying what ailments affect them, nor how many stacks have been applied. It would be useful if we could display this easily to players, without overloading them with information.

Two possible ideas I've had, but I'm open to further suggestions:

• Particle effects/trail. This was the first attempt, but there were too many particles when this was stacked (poor implementation), so there is leftover code for this.
• Icons underneath the healthbar. This would allow the player to see everything that's been applied and how many stacks at a glance, but how well can the information be communicated if it's tiny?

With the WIP enemy ability system, it was possible to apply negative modules, or debuffs to a turret, however the NodeUI doesn't update to reflect the debuff. I'm not sure how they should be represented in the NodeUI either.

As the system isn't currently in use, this is very low priority, but it's worth noting if it doesn come to use again.

Currently, the only way to deselect is by clicking/tapping again on the turret or an empty node. While functional, it's not very intuitive.

Instead, it would be useful to tap on anything that isn't a turret or button to deselect (the background, an empty node, the path, an enemy).

Allow the ability to change game speed. Probably just a freeze time and play time, as x2 time would mean nobody would play x1 time.

Not sure if I want to add this, as it defeats the point of time between waves.

Planned speeds:

• 0x (paused)
• 0.5x
• 1x

Think of this turret like a smasher, but rather than hitting everything in it's range, it targets a certain location, then fires an explosive projectile dealing significant damage to all enemies caught in the blast.

• For blast radius, it uses the bullet's explosive range.
• Range is used so that the player can only place the target location within the turret's range
• There are no additional stats for the turret (as far as I can tell)
• Since it's more like a mortar, the bullet would probably need a better design (so it looks like it's going up then down rather than across). Maybe worth waiting until #85 has been completed.

The general idea

You can upgrade the home base and add improvements. Possibly also damage and destroy home bases when there are multiple.

The home base being the blue hexagon that enemies try to reach.

Possibly Implementation:

• We could use Scriptable Objects to store the data for this idea.
• We could then attach the main class to GameManager, hooking into GameStats.cs as we want it to be present in every game.

The shop needs to know what turrets the user has, to make sure it shows module for only that selection of turrets. When turrets are pre-placed on the map, there's a very hacky method for adding turrets, which is on the awake event, a turret can run some functions, in this case, it tells the AddSelection script to add this turret.

A better method may be to allow turrets to be assigned to an array of pre-placed turrets in the AddSelection script, or the GameManager, but this is an extra step for map building.

It may be even easier to allow nodes to have a pre-built turret on them (using a turret blueprint) that adds them to the selection upon start. This way there's no extra assignment and it's even easier than setting a prefab into the scene. It would also be useful to show using gizmos what nodes have turrets pre-applied.

Some investigation may be needed to find out what solution is best and if there are others available.

Pretty simple, enemies can jump from 1 location to another across the map by entering the portal.

Currently, leaderboards use exploitavoid.com, but this has several issues (not all on exploitavoid, some on our implementation):

• Secrets are easily found
• No global leaderboard with totals from all levels
• No local score saving
• Two players using the same name doesn't work (and players can't change their name so if they pick someone else's there's no check)
• It's a pain to reset the scoreboards each update
• There's no metadata (no version, no leaderboard customisation, etc.)

One possible fix would be to setup our own server, using https://github.com/Dino0040/Leaderboards/tree/v1.0.2 as the base, and then expand, allowing metadata (which can be used for customisation, version and players of the same name), allow deleting of the player's data, better login systems, a global leaderboard and more.

This one would be a big update, and if taken up by someone other than me, you'd have to work closely with me and account for data privacy (allowing players to opt-out at any point of sharing their names on the leaderboards, as well as the privacy policy and terms of service updates)

Smasher used to not deal any damage to enemies whose centres are outside the range. However, modules are still applied, and they are still included in checking if there are any enemies in range.

There were two potential fixes for this:
Option 1

• Don’t deal damage to enemies with centres outside the range
• Don’t activate modules on enemies with centres outside the range
• Don’t include enemies with centres outside the range when checking if there is an enemy in range

Option 2

• Add a buffer zone/minimum damage enemies can receive

I began work on Option 1, but haven't finished it properly. As this is part of the transfer, I'm not sure if the to-do list is properly updated (hence needs more info).

Currently, the laser targets where the enemy currently is, not where it will be in a frame's time, meaning the laser is always lagging behind. Instead it would be useful if the laser could target where the enemy will be next frame, so it can actually hit the centre of the enemy.

Currently, the user is not told when a new highscore is reached. It would be good to show that information. Just a little bit of text to celebrate the user achieveing a new highscore would do the trick.

Gold can be a little confusing with amounts. Why do we need a number anyway? Instead, you'd collect energy bits (collectively bits, but each size has a different name, from small to large, bit, crumb, nibble and byte), until you fill a canister. One canister means one shop opening. Under the hood, the mechanics would remain exactly the same, you gain x energy from each enemy, and when you have enough energy you can open the shop. This instead is just a method to remove the numbers from the UI, and also making it easier for players to see how many times they can open the shop.

To stop having a carpet of blue over the path, nearby bits can merge to make crumbs, or nibbles, or even bytes. They should only move after a certain period of inactivity, or even just when the wave ends.

What if you could mix turrets together to create even more powerful merges? Could be releated to #92 in implementation. For example, smasher x shooter = a turret that shoots a smasher to the target the "deploys" and is active for 10-20s smashing down and dealing damage.

The original idea on Notion was for the 3 basic turrets to be merged to form the other turrets (i.e. smasher & shooter = lobber, shooter & laser = lancer, shooter & shooter = gunner), but I think the current method is better than that as it makes it clearer from the start what you have.

Why play just one map when you can play several at once? I'm not sure how great this idea is, but I had it and I'm sharing it. Basically, you have two maps, far enough apart that they won't affect each other (unless someone stacks range on a tower for that purpose). Both paths could have exactly the same layout, but nodes in different placed, while the enemies are exactly the same. So when a boss appears, it appears on both (but be careful that abilities only apply to those on the current path).

Requires heavy concentration, and utmost planning. It should have a significant spike in difficulty, designed for the best of players.

New players can be left a bit stuck with how to play the game, especially with the game's unqiue rougelike elements, and strange controls due to them not being finished. Currently, only a text based tutorial exists as a temporary measure to allow players to understand the game, but proper work should be done to create an excellent tutorial.

• Create a tutorial base
  • Allow the tutorial to be started from the settings menu
  • Have the tutorial start with the first time the game is loaded
• The tutorial should explain the following:
  • Three basic turret types (shooter, smasher, laser)
  • How to place a turret and control it's settings
  • Point out in the shop selection about turret icons
  • Explain what modules are
  • The general UI
  • How to apply a module to a turret (and point out the changes)
• Add a wiki/reference that contains all the turrets & modules and what they do, accessible at any point.

Some other notes:

• The tutorial shouldn't be too long, as then it doesn't need to be skippable.
• The tutorial should use the prototype level, and once completed, allow players to continue the game and earn their first highscore.
• The game shouldn't force a player to make a certain choice in the shop, and should still randomise the shop

A good video that explains what makes a good tutorial: https://www.youtube.com/watch?v=wG4Yy-1G-wc

Our Turrets are really basic: each a triangle that's a bit hard to tell the orientation of. They are also simple sprites that rotate.

The idea is to slowly upgrade our graphics over time, giving them more detail and life. Which will affect, but is not limited to:

• Turrets
• Worlds
• Enemies
• Bosses

This specific issue only focuses on Turrets for now. Later ones will be created for the rest of designs. Turrets have taken priority because they are the only visual you always see on the screen.

The design needs to follow some rules for consistency, but it's also a bit lenient for any creative additions or modifications:

• If possible, use Hexagonal Prisms in the model. Alternatively you can also use Hexagonal Pyramids, even when they are cut by plane.
• Keep the designs low-poly. The game is still meant to run on Mobile, by reducing our polygon count we can keep it easy to render even in the most visually complex scenes with bosses.
• Limit your use of textures. There is a specific Shader/Material developed for colouring and shading the model. Textures can add detail that may not even be visible or make the model feel too-detailed for the rest of the world. There can be exceptions, but this really depends on how they are applied.
• Don't use too many colours. By keeping the colour palette simple, it can help distinguish turrets even faster by their palette, not just shape or firing mode.

It would be nice if not only could the build effect be better/nicer, but also per turret. This is purely just a cosmetic change, but it would be nice to have.

(Credits to @bloodwiing)
More keyboard shortcuts

• Q - sell
• E - apply
• R - change targetting
• TAB - inventory toggle
• 1-9 - inventory slots

Maybe

• SPC or C - shop
• SPC - 0.5 speed

Currently, there's no way to know what modules the user can apply to a turret once it's been selected. Nor is there any way to know what modules are on a turret once purchased before it's placed.

Module Inventory

• Display that a module cannot be used on the current turret
• Display which turret(s) the module can be used on
• Don't allow a module to be selected if it can't be applied
  • Has a bug with current implementation, see issue #80

Turret Inventory

• Display what modules are on a turret

Currently, many effects use basic shapes in an explosion shape. This is ok, but it's basic. An improvement on the VFX of both bullet impacts as well as enemy deaths. This is separate from their coin explosion effect, as that would be changed with #102. I'm not sure if different death effects are needed per enemy, maybe just bosses should get them.

There's a lot of freedom with this task as I don't have much guidence. A turret shoot effect may also be needed, but that can be discussed in #85.

Currently, there are many enemy prefabs, but when more and more enemies are added, it's easy to mess up prefabs and takes ages to work it out, as well as updating multiple enemies is tedious. Instead, it would be useful to break the stats down into groups, and place them in SOs that can be placed into the scriptable object when it spawns in, reducing bloat and keeping the project files cleaner.

Currently the wave spawner's waves are preset, increasing only health and amount of enemies are the waves increase, where they can only hold a single path.

Instead, the following additions to the wave spawner would be good:

• Better Editor controls
• Options for different paths (and how to split the enemies up, is it randomised, does each "set" of enemies take a certain path?)
• Allow enemy waves to be picked (either by reward #94 or the boss you face)
• Make enemy "sets" to be picked (i.e. a set of waves with a boss at the end) so it can be changed, rather than looping over and over)
• Have better method for increasing difficulty of waves

Some quality of life improvements:

• Allow the paths to be displayed prior to the turret
• Allow the player to see what enemies are coming next
• Show how many enemies are left when the timer is 0

How this is all implemented is unknown, especially the editor, it's really important the editor bit is implemented well to allow the easy creation of wave sets. Any additional features of the wave spawner would be good if you want to mention them, or how the choices would work. I don't want players always picking the hardest option because it gives the best reward, or getting really strong at a couple wave set types and always picking that. Hades is part of the inspiration here, it tells you the reward and if the wave is hard or not (sometimes even hiding the reward), and then you have to decide if you can beat or not. That way you always have to put up the best defence, but maybe a hint at which boss (or boss type) so that you can better prepare your defences would be good.

Currently, the critical module doubles any damage based on the chance. It would instead be better if rather than doubling damage, it could be set by tier, for example 150% damage for T1, 200% for T2, 300% for T3.

This should be the simple addition of an extra parameter to CriticalModule.cs and then adding stats for each tier as required.

Currently, when attempting to place a turret, you get no information on how it will do in that space. A preview of the range minimum would be best (rather than forcing the player to learn and guess).

Currently, the laser's laser is quite bland, not doing much/showing how powerful it is. It would be good if it had a "pulse" effect to show it's still shotting rather than being a bland rectangle on the screen. A texture could help as well.

Currently, the best way to balance the game is by player feedback and me playing myself. This is fine with smaller amounts of players, but as the game goes onto the play store, it would be useful to be able to see what many players are choosing, aggregate the data and analyse it in useful ways.

As we're using Unity, it's possible to hook this into the Unity analytics, allowing me to easily see the data and analyse it.

For data privacy, it's important that players can opt-out at any time, and have their data deleted. The data wouldn't use their username, but would have a uuid so I can split the data for users, based on their score and do more effective analysis. It would also have to be properly explained in the privacy policy.

As with v1.1.-alpha.11, modules of the same tier will be merged to create the next tier (where allowed), meaning there's still module progression and the UI isn't so cluttered.

The general idea

Instead of merging modules of the same level, only the highest is kept, and any other modules of that type make “progress” towards the next level of the module on the turret.

Other ideas/variations

• Means fewer modules and shown, and lessens the burden on the UI.
• It can take a while to upgrade, but is it worth the investment?
• Give passive upgrades (so % is granted towards the next level every kill/round/second/activation/whatever trigger

Potential Issues

• How can this be displayed well in the UI?

This turret has significant range to begin with, lying in wait, it tracks it's target, taking it's time to lock on and have a sure hit... THEN BAM! It takes a massive chunk of health off it's prey, as it turns and looks for the next target...

The Hunter is special as it always targets the enemy with the most max health, and if there are multiple, the one with the most current health. It also uses aggressive retargeting so once it's shot it makes sure that it's always targeting the largest prey.

To attack once the hunter has found a target, it takes time to lock on, requiring more time depending on how much current health the target has (either just the current health taking into account health scaling, or just a % of max health). Possibly even dealing damage based on how tanky the target is, but cannot accept damage modules as upgrades.

When playing, the device can go to sleep if the user isn't active within a certain window, despite it being a game (and typically ignoring sleep timers). More infor is needed as it needs further investigation to see what devices this happens on, and if it can be fixed.

Basically bigger turrets that can behave in completely new ways. Perhaps a sun turret that burns all enemies that enter it's range, or a moon turret that shoots boomerang crescents that chill targets. These turrets take up 7 tiles to make a mega-hexagon.

These turrets should probably start as a pre-placed turret. It could also be a wave reward , a special shop choice, upgraded only by special modules, or something that takes resources to construct and multiple shop openings (i.e. you need 6 bases and a core to make a mega turret, the core decides it's type, and that's only obtainable after all bases have been placed in a ring)

These are very special turrets, and should be rare (only on one or two maps have them, most likely only temporary maps, and you should maybe place 1-2 during a game, the best players maybe reaching 3) as well as hard to construct. Otherwise they're not special enough. Their attacks should also be very special. Another way to make them special might be only granting parts in boss rewards - #94.

Currently, the module selection randomly selects an option based on the weigting of the modules stacked together then checks if the module is a valid pick (i.e. isn't a duplicate) and doesn't make sure all chances are positive.

Instead, it would be useful to add together the weightings of all positive & non-zero modules for that wave as well as any duplicates.

It should also have defaults, to make sure that in the event there are no chances (total weighted chance is 0) some options should be given, possibly Damage I, Range I and Fire Rate I

So, we've decided to move from Notion's To Do List (that wasn't consistently updated) to Github's issues. This means we can still have all the important information, using labels, projects and milestones, but also allowing us to mention the issues we're fixing in a pull request, as well as trying to generally use Github more.

It also makes it easier for people to get involved, as more people have a Github account than don't and also means any potential new contributor can see what needs doing easier rather than finding the link in the README.md

If you've got any queires, questions or suggestions about this change, feel free to reply to this issue. I will close it at least a week after all the to do items have been transferred and I feel Github has been properly setup for everything.