Items in a ticket

• Title
• Important
• Urgent
• Definition of deliverables
• Assignee
• Estimate of effort required
• Deadline

Guidelines

• If a ticket is in a blocked state, then the reason why it is blocked should be made explicit

• 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/

• Code changes are stored in git
• Setup continuous integration
• Have a testing framework
• Use dependency management
• Define a code standard
• Prefer function/method typing over dynamic types
• On every push 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
• A project repository must have a README.md explaining how to run the project on your own computer
• A project repository must have a RELEASING.md explaining how to release the code
• 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

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.

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