digitalextinction / game Goto Github PK

Map validation is currently custom-implemented. Validation would be needed on multiple places so it is better to device some more standard way how to do it.

Consider using some already existing crate, for example https://crates.io/crates/validator

This is a continuation of #7.

• Modify map TAR file so it contains an entry with the heightmap (NPZ entry?).
• Split the terrain to a grid of meshes:
  • This allows better camera frustum culling (only relevant parts will be rendered).
  • Also, various intersection algorithms will be faster due to AABB pre-filtering.
• Modify line rendering (originally implemented in #489) so they are rendered correctly on uneven terrain.

This requires modification of object placement and movement in the map so everything is positioned correctly on the surface.

Benchmark the solution: if slow, RTIN or other mesh simplification techniques might be required.

• There should be a section for generic questions.
• ?

So players can play more than just the one bundled map.

Once #2 is implemented, it will be necessary to implement static object placement so the objects are correctly placed on the surface.

The terrain should be artistically pleasing & reasonably realistic.

Benchmark the solution on large maps.

• Insert all solid objects to a spatial index
• Update positions of the objects in the index on GlobalTransform change.
  • Make sure this happens after Transform -> GlobalTransform propagation to avoid one frame lag.
• Remove all solid objects from the index after despawning.
• Use the index + Parry for object selection (and remove current ray intersection implementation).

Use ToastEvent instead.

• Draw circles on terrain below selected units
  • Solved in #209
• Draw squares on terrain below selected buildings

Based on input criteria and a random seed, generate a map.

Select all object inside a selection frustum (rectangle on screen). This is an improvement on top of basic object selection defined in #10.

Movable objects of the player should move out of the way when possible (and then move back). Otherwise, some destinations could be blocked or alternative and much worse paths might be used.

To make life of developers easier. When published on the web, it is easier to reference to it.

• Include private items in the docs (cargo doc --no-deps --all-features --workspace)
• Make it accessible from the web, e.g. docs.de-game.org

Design:

• Internet games are started via a (central but configurable) lobby server (#255). The server serves as a rendezvous.
• LAN games start the same server locally and announce it over mDNS.
• In came networking is based on a (custom?) peer-to-peer protocol.
  • This limits the load on the central server,
  • and decreases latency (especially on LAN and other close network endpoints).
• The over the Internet pear-to-peer connection is be established with Hole Punching technique.
• The (message oriented) communication is be based on UDP:
  • all messages are idempotent (thus packet duplication is not an issue) and order independent (thus reordering is not an issue),
  • most messages won't require 0% packet loss,
  • a to-be-decided technique is used to guarantee delivery of some messages.

Explore:

• message-io
• GGRS
• Laminar
• Renet

Do not display it by default, use configuration to enable it.

This is especially important for non-combat units.

First idea: compute influential map (some combination of HP and damage of friendly end enemy objects) and minimize it when path finding.

• Map is loaded from a TAR file
• Only map size is part of the map file. It is a TXT entry with a number.
• Game is initialized only after the resource is loaded & the terrain added.
  • This is preparation for future more complex initializing.
• Simple green plane is used for terrain.

Caps Lock - CTRL swap is not respected in the game.

Currently, minimum axis-aligned bounding box of the entity shape and all descendant entity shapes represented with Parry's Cuboid is used.

Use better shapes of higher fidelity instead. These can be stored alongside object models. The shapes should be simple for fast geometrical operations.

Place the information to CONTRIBUTING.md and link it from README.md.

This will spare a lot of resources.

https://stackoverflow.com/questions/62325286/run-github-actions-when-pull-requests-have-a-specific-label

This cannot be done before #84, otherwise, CI could be skipped completely by not applying the label.

Groups of object should reasonably move together:

• clustering
  • objects are clustered when send to a target so close objects make flocks
• flocking
  • objects are attracted to their relative position from flock centroid
  • object are influence by average flock velocity
• repulsion
  • objects are repulsed from other nearby object

Benchmark the solution.

• energy generation
• energy distribution
• energy storage
• energy consumption
• consumption prioritization

To make life of developers easier. When published on the web, it is easier to reference to it.

• Include private items in the docs (cargo doc --document-private-items)
• Make it accessible from the web, e.g. docs.de-game.org

Setup & update shadow projection so it is not too coarse but covers all/most of camera view.

Also see related: cascaded shadow map

After #11 is implemented adapt it to proper object movement.

There are several requirements:

• Do not go across terrain obstacles.
• Avoid all solid object, static and movable.

Research available algorithms. Plain A* won't work.

The initial implementation will be minimal:

• necessary network configuration -- to enable multiplayer
• some start game button
• waiting screen when other players join & assets are being loaded

• General goals
• Gameplay goals
• Technical goals

• MVP Milestone: https://github.com/DigitalExtinction/Game/milestone/1
• #37
• #71
• #72
• #73
• create Matrix or Discord room / space
  • https://discord.gg/vHMFuCWGSX
• #88
• #86
• #120
• #38
• Add Roadmap section to README.md - link this to milestones
• publish version 0.0.1 of the crates to crates.io so no bot can steal the name

Before doing so, make sure that:

• outsiders cannot set labels for PRs
• outsiders cannot approve PRs

?

This is related to #85.

The following conditions must be met for a PR to be merged:

• The PR is approved by a repository administrator
• All conversations on the PR are resolved
• The PR is not marked as Draft
• Rust workflow was executed successfully

URL: https://de-game.org/

Contents:

• basic info about the game (license, status, goals, link to GitHub repository, ...)
• embedded video with gameplay so people can see how it looks like

• Select single object by clicking on it
• Select multiple object when holding CTRL while clicking.

Log to a file. To output could be used for example for bug reports.

• When a single factory building is selected, a menu with available units is shown. When the user clicks on a unit, it is added to a manufacturing queue.
• For each factory, there is a queue of units to be manufactured. The queue is gradually processed.

Once #43 is done, this can be tested on a generated game.

The upper limit of entities for each player will be 1023 (buildings & unites combined).
The upper limit of players will be X.

• There is a JSON file in the map TAR file which contains information about each object.
• Each object has two coordinates: horizontal position in meters along x and y axis.

This depends on #10.

• Send selected (movable) objects to a location when right-clicking on the map.
• Implement naive version: objects go on straight line ignoring any potential obstacles.

• All entities has max HP and current HP.
• Entities with attacking capability have something like LaserGun { damage: f32, rate: f32, last_fire: Option<Time> }
• When an entity reached HP of 0, it is destroyed.
• There is a new EntityDestroyed event handled by all relevant plugins (to remove dangling Entity IDs).

• Make all or most camera parameters configurable (e.g. movement speed, minimum and maximum zoom, etc.).
• Load & store the configuration to an appropriate path (e.g. XDG_CONFIG).
• Document the configuration format.
• Make sure that issues in the configuration are properly reported (logging and error and fall-backing to default?)

UI for the configuration is not part of the issue. Manual edits to the configuration file are good enough.

This relates to #69.

This is blocked by #243.

Update directional light projection with camera movement -> otherwise shadows would be too coarse on large maps. (cascaded shadow map in Bevy v0.10 is used instead).

This is related to bevyengine/bevy#3629, cascaded shadow would work even better.

Cascaded directional lights are supported from Bevy v0.10 (migrated to as part of #324).

• Move all user input code to de_controller crate
• Systems from this crate run first & emit various events
• These events are processed by various other plugins (e.g. camera)

This will improve code quality. Currently user input code is at several different places.

• Horizontal movement
• Zooming
• Rotation & tilting