sherpal/battleforflatland

2D multiplayer coop game

battleforflatland's Issues

Current target should be more easily identifiable

Currently, the only way for.a player to know what its current target is is to look at the name in the target bar. This is far from being sufficient.

The game should at least:

• show, on top of the target unit, its health bar
• highlight it in some way, for example using some pixi filter to add some kind of "selected" effect.

Less player position update and smooth ai movements

Currently, players send they position (and related information such as speed or rotation) to the server 60 times per second. This is way too much and will not scale well with going to ~10-15 players (this would mean 900 actions per second, only for player movements!).

This change should comme with a feature that AIs should have smoother movements, in the sense that they should not have a speed be either 0 or full speed, but should rather accelerate from and decelerate to 0 speed.

Move to Scala 3

See title. Some dependencies are required before making this possible.

I think the stoppers now are ZIO and Circe

More semantic in Asset type

Currently the Asset type (in package assets in the frontend subproject) is simply a wrapper around a String url. It could be good to add more semantic in the type system. This semantic should reflect what the asset is used for.

For example, an asset could be some asset for an ability. We could then define

trait Asset[-For] {
 ...
}

and create an asset for an ability like Asset[Ability]. (I guess this should be contravariant)

This way, we can, at certain places, ask assets for specific things and have more type checking. Also serves as documentation.

Change player radius

Players are currently rather small. 10 units for their radius is way too small.

This should be changed to 20. This change is not that straightforward because some other things depend on that radius, for example damage zones in Boss 102. But the walls in Boss 102 do not, hence changing the radius to 20 makes the game too small.

Implement a proper GCD

The game needs a working implementation of a Global Cooldown (GCD).

The purpose of a GCD is to make melee (mostly) entities do less stuff, which is easier and more intuitive.

Adding origin information to Buffs

Currently, a Buff on an entity does not bear any information on how this buff actually appeared.

This is annoying because it prevents for doing later things depending on the source (for example, who put the debuff/buff in the first place).

I believe this can be fixed by adding to Buff a type parameter Source representing the type of information representing the source. For exemple it could be Entity.Id to tell that the buff was placed by that entity. Then concrete implementations of Buffs should have a value source: Source.
We could also be a bit more restrictive and create an ADT with possible sources, and ask that as a parameter. This, I believe, will fulfil everything that we need and will ease many other implementations.

Such an ADT could look like

sealed trait Source

case class FromEntity(entityId: Entity.Id) extends Source
case object FromGame extends Source
// ...

Players should be able to put markers

The game is all about communication between players. A great way to allow players to communicate is to make it possible for them to put "markers" of sorts in the game.

These markers should have highly distinguishable shapes, and the players should be able to put them:

• on a fixed position in the game
• following a given player
• following a given target.

I believe that 6 possible markers should be enough, for example, a star, a lozenge, a square, a triangle, a skull and a cross.

Players should be able to put them before the fight actually starts, and there should be a shortcut for that.

Actually Send emails when people register

See title. (Send Grid is probably fine.)

Integrating sounds

The sounds should integrate a lot of sounds in order to increase the overall feeling while playing.

Sounds may happen:

• when you cast a spell
• when you try to do something you are not allowed to
• ambiance lines from the boss...

Display error messages ingame

When in game, many "errors" can come from the user action. Typically a user who "spam" an ability key, or tries to hit/heal some entity too far away, or not in sight.

When any of these errors occur in game, there should be, at the top of the screen, a toast-ish red message disappearing after some time. The display of these messages could perhaps depend on the kind of error.

This issue will require a little bit of rewriting in the code. Especially because currently there is no actual feedback onn why a given action can't be performed.