When joining a new project without tests, here is the value you need to provide through the addition of tests:

1. the application works and doesn't crash
2. the application works and supports a few input cases
3. the application works and supports a variety of input cases
4. the application works and is robust to most input cases

• Write a test that tests the common case usage of your function
• Write tests that cover edge cases of your function
• Write tests to cover all statements, branches, paths

• Verify that the build/tests pass
• Read the issue title and description
• New code
  • Understand the feature and associated requirements that are supposed to be implemented
  • Verify code implements the desired feature and that the requirements are completed
• New/Changed code
  • Check code contains tests
    • Is all the new code covered by those tests?
  • Verify the location of new/moved files
    • Are the files in the right directory?
      • Are they appropriately named?
  • Verify classes, methods, functions, parameters naming
    • Are they significant of their purpose?
    • Are they clear enough?
    • Are they respecting the naming convention?
  • Does the code respect SOLID?
  • Consider that when functions/methods signature change, code may now be backward incompatible.
    • Discuss whether this is necessary
      • Backward incompatible changes should be documented
  • In a weak typed or type hinted language, are parameters and return of functions/methods typed?
  • Are there TODOs that should be completed within this review?
  • Check code for code style issues
• Bug fix
  • Verify that the fix is applied at the right location and will not "fix the symptoms, not the cause"

When reviewing

• Provide specific and actionable feedback
• Clearly mark nitpicks and optional comments
  • Alternatively, use an approach such as RFC2219 where you indicate whether a change is a MUST, SHOULD, or MAY
    • I've used traffic light color emojis to communicate 🔴 MUST, 🟡 SHOULD, 🟢 MAY
    • Another emoji based option is gitmoji
• Assume competence
• Provide rationale or context
• Consider how comments may be interpreted
• Don't criticize the person, criticize the code
• Don't use harsh language

Reference

• https://en.wikipedia.org/wiki/SOLID
• https://medium.com/palantir/code-review-best-practices-19e02780015f
• https://phauer.com/2018/code-review-guidelines/
• https://smartbear.com/learn/code-review/guide-to-code-review-process/
• https://smartbear.com/learn/code-review/best-practices-for-peer-code-review/
• https://nyu-cds.github.io/effective-code-reviews/03-checklist/
• https://google.github.io/eng-practices/
• https://testing.googleblog.com/2019/11/code-health-respectful-reviews-useful.html
• https://engineering.18f.gov/code-review/
• https://conventionalcomments.org/
• https://docs.gitlab.com/ee/development/code_review.html
• https://gitmoji.dev/

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

Client/server
Per region servers
Login/authentication server
Lobby server
Store server

• buy champion/runes
  Transfer player from lobby to game server
• champion selection
• spectators
  Per game server
• Coordinates all 10 players within the game
• controls game events dragon/baron/npc/player gold
• compute damage
• end game lobby
  Game client
• Display animations
• play game state according to server

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.