westinygame / westiny Goto Github PK

TODO description here

• srv sends ShotEvent (position, velocity vector, time/distance limit)
• Remove NetworkId from bullet

No scope: client "Player shooter system"

Current:
The weapons can shoot only one piece of bullet per shot. (!! Not talking about per trigger ("per click"))
to clarify: A shoutgun's shot parameter would be Shot::Single, because a shotgun shots once per trigger-pull. But it releases multiple pellets which would be represented as bullets in the game yet.

Task:
When the weapon: Weapon shots N bullet entities should be created where N is the number defined in weapon.details.pellet field.

Respawn should happen on a random new position.
Instant respawn is OK for now, some timeout should be considered later.

• Handle it on client

1. Create a network receiver system on client
2. Create a transform update event
3. network receiver system writes the event on this channel
4. an entity updater system updates the entity's transform

(later the system should be extended to be able to create the entities that not exists)

To discuss:
Maybe there should be a separated system that checks the timelimits on entities.

?When time limit reached, the entity should be marked as Eliminated?

Right now server address is loaded from a resource file. During testing it is usually updated, an override option would be nice.

For example: when WESTINY_SERVER_ADDRESS="1.1.1.1:1234" is defined, or a --server-address 1.1.1.1:1234 option is specified, it would use that address instead of one from RON file.

OS: 5.13.11-1-MANJARO
rust version used to build: 1.47.0
Device data: AMD Ryzen 3 2200G with Radeon Vega Graphics | Memory Size: 6 GB + 512 MB (total is 8gb but radeon card uses the rest of memory)
The terminal output keeps printing [INFO][westiny_client::systems::client_connect] Network event: Disconnect(1.2.3.4:5745) but nothing happens.

When a projectile which have Damage component collides with an entity with a health component, this should be drained.

• Server should accept multiple connection from clients
• Server should store client addresses in order to send them messages

Current:
The bullets direction is perfectly accurate to the aiming point.
The weapons have a parameter which tells their accuracy (spread).

Task:
The direction of a shot bullet should have a random spread calculated from the WeaponDetails' spread field.
Note: It's not necessary to be deterministic due to the ShotEvent sends the direction of every bullet to the client

Every client should know that a player dies.
Common:

• Create a PlayerDeath network event (fields: PlayerName, dead_player_position)
• Remove NetworkId from Corpse
  Server:
• In DeathSystem broadcast this event when a player dies
• Remove Corpse from server
  Client:
• Receive PlayerDeath event
• Raise a PlayerNotification about
• Put a corpse with the dead player's last known transform
• Add a Lifespan component to the corpse (e.g. 2 min)

Thus when a player dies, 2 messages will be broadcasted: a PlayerDeath and a NetworkEntitiyDelete.
The receiving order is irrelevant. Remove player entity on NetworEntityDelete, put the corpse and raise notification on PlayerDeath

Currently it seems that sprite visibility has not defined order. Amethyst has support for that, but it requires further investigation.

(abel: I have found sprite visibility sorting system, but it wasn't obvious when I tried to implement this)

Either in main.rs and server.rs

Current:
The reload happens automatically when the magazine got empty.

Task:
Remove autoreload.
When the Reload input flag is set the player should start the reloading process.

In the released version Readme.md should contain description, usage and config options (username, server address/port, etc.)

Input should be a component attached to the same entity as the player. PlayerMovement system and Shooter system should use this without accessing the input handling resource (currently InputState should be the only updater for Input component on client side)

Make everything else proprtional to it

1. Client sends a ConnectionRequest.
2. Server creates a Player entity with UEID additional component.
3. Server sends the UEID to the client as the ConnectionResponse.
4. Client creates an entity with the components: Player, UEID.

UEID should contain a unique u64 ID

Currently systems directly plays audio which makes hard the client-server separation. For idea, check the more-audio branch and consult the doc section about audio handling.
Currently we need just a minimal solution.

Due to Laminar/UDP nature, it can happen that a ConnectRequest arrives and processed multiple times on server. It should not spawn multiple player entities.

• Display ammo on HUD
• Add AmmoItem which increases active Weapon's ammo in Holster when collides with if magazine is not full & disappears when picked up.

Server should send all the player-related updates in SpawnEvent:

• Position
• Health
• Weapon
• etc.

Of course client must handle it

When player's health reaches 0 it's entity should be deleted.

Consider that later not only player's can have health but any damageable object. From this perspective the work "death" might not be appropriate, so consider using a different name, a synonym of die, death...
https://www.thesaurus.com/browse/death

A pickup that increases player's health with a certain amount when picked up. Then disappears.

You can walk-through these disconnected players which means that the entity has been removed on server but exists on client

They can be simply moved, or added to server as well.

For now the client does not even writes a log entry if the server turns unavailable during PlayState. It just freezes which is not the prettiest fault-handling

Now we call bincode::serialize/deserializer everywhere. Should be moved to a single place, and abstracted away.

With other words: game logic is not interested in the binary format we use on wire.

Then it can be replaced or optimized easily.

The README should explain the implemented but non trivial features.
for now i think just reload and weapon switch

LamincarConfig is hardcoded, load it from a file (can be same file for client and server I think).

Weapons should have different properties

• damage
• distance
• number of particles
• spread

Distinguishing revolver, shotgun and rifle would be a good MVP.

I just ran both commands to build and run either the server and the client. The client ran pretty well, but the client segfaulted just right in the startup. Fallow the output error:

[INFO][amethyst::app] Initializing Amethyst...
[INFO][amethyst::app] Version: 0.15.3
[INFO][amethyst::app] Platform: x86_64-unknown-linux-gnu
[INFO][amethyst::app] Amethyst git commit: UNKNOWN
[INFO][amethyst::app] Rustc version: 1.52.1 Stable
[INFO][amethyst::app] Rustc git commit: 9bc8c42bb2f19e745a63f3445f1ac248fb015e53
[INFO][winit::platform::platform::x11::window] Guessed window DPI factor: 1
[WARN][rendy_factory::factory] Slow safety checks are enabled! Disable them in production by enabling the 'no-slow-safety-checks' feature!
[INFO][rendy_util::wrap] Slow safety checks are enabled! You can disable them in production by enabling the 'no-slow-safety-checks' feature!
[INFO][westiny_client] Starting client
[INFO][westiny_client::states::connection] Server address: 1.2.3.4:5745
thread 'main' panicked at 'attempted to leave type `platform::platform::x11::util::input::PointerState` uninitialized, which is invalid', /rustc/9bc8c42bb2f19e745a63f3445f1ac248fb015e53/library/core/src/mem/mod.rs:660:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
[ERROR][rendy_resource::escape] Terminal must be dropped after all `Escape`s
[ERROR][rendy_resource::escape] Terminal must be dropped after all `Escape`s
[ERROR][rendy_resource::escape] Terminal must be dropped after all `Escape`s
[ERROR][rendy_memory::allocator::dynamic] Memory leak: SizeEntry(262144) is still used
[ERROR][rendy_memory::allocator::dynamic] Memory leak: SizeEntry(4096) is still used
[ERROR][rendy_memory::allocator::dynamic] Memory leak: SizeEntry(2097152) is still used
[ERROR][rendy_memory::allocator::dynamic] Memory leak: SizeEntry(512) is still used
[ERROR][rendy_memory::allocator::dynamic] Memory leak: SizeEntry(327680) is still used
[ERROR][rendy_memory::allocator::dynamic] Memory leak: SizeEntry(32768) is still used
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
[ERROR][rendy_resource::escape] `Escape` was dropped after a `Terminal`?
Segmentation fault (core dumped)

For switching weapons:
1 2 3 4 5 6 7 8 9
For reloading:
R
For running:
Shift?

When the magazine is out of ammo the player should not be able to shoot until reloading finished