• Code changes are stored in git
• Setup continuous integration (e.g., GitHub Actions)
• Use dependency management (e.g., uv)
• Have a testing framework (e.g., pytest)
• Define a code standard, enforced through tools and not documentation (e.g., ruff)
• Prefer typed function/method over dynamic types
• On every commit to git
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
    • Code coverage should be recorded during tests and a report made available
• Prior to pushing
  • Use an LLM tool to review the changes to identify potential issues
• On pushes, the CI should
  • Code quality check
  • Code style check
  • Unit/functional/integration/system tests
• A project repository must have
  • a README.md explaining how to run the project on your own computer
  • a RELEASING.md explaining how to release the code
  • a CHANGELOG.md listing relevant changes made
• Responsibilities are made explicit in terms of roles
• Critical roles, such as project lead, must have a backup/shadow individual
• Setup telemetry, alerts, profiling, logging

A table of probabilities is built
The ratio 1/drop chance is used to compute a total drop chance
A number is generated in the range 0-total drop chance
A table lookup is done to find the associated item
Item properties are randomly rolled
Different table lookup may be built depending on the difficulty setting as well as the current act
The rarity of an enemy pack may either change the random generator distribution or some other mean to modify the probability of higher quality items from dropping
The pseudo random number generator is initialized each game and does not depend on the current time (to avoid issue with reading some timer which may have the same value over many iterations or may be slow to read)
When an enemy is killed, we want to determine how many items will drop

An initial seed is computed and stored in the game save file
Based on this seed, the world is pseudo randomly computed, using a certain chunk/block/tile size (e.g., 32x32, 128x128)
The world map is only generated on-demand, that is, as far as the player can see
When a new chunk is discovered, its blocks are computed and persisted in the save file
If there are no active components in a chunk that is not visible, the game will obviously not render it, it will only simulate it (position, item, velocity, etc)
Certain thing, for instance alien types and alien base size, may only be computed once they are observed. At first, maybe only a location anchor will exist to indicate where they should spawn, but the rest will be generated only when needed.

An initial seed is computed and stored in the game save file
Based on this seed, the world is pseudo randomly computed, using a certain chunk/block/tile size (e.g., 32x32, 128x128)
The world map is only generated on-demand, that is, as far as the player can see
When a new chunk is discovered, its blocks are computed and persisted in the save file
If there are no active components in a chunk that is not visible, the game will obviously not render it, it will only simulate it (position, item, velocity, etc)

Authentication/Login server
Per game server

• compute damage simulation
• in game chat
• decide game victory
• returns end game stats for ui (or done client side?)
  Game client
• display game ui
• play animations
• send commands to game server
  Local backend
• record game
• compute game simulation
• communicate game state to game client