Nowadays I do not write useful commit messages anymore.
The main reason is that most repositories I work in professionally use squash merges, meaning that all commits done in a branch are squashed into a single commit when merging the branch into the main branch.
The commit message of the squash commit is usually the title of the pull request, meaning that the individual commit messages are not very useful anymore.
The commit message ends up containing the PR description, which gives the what and why of the changes, which is generally enough.
With the rise of LLMs I have never found myself looking at the commit history and the commit messages to understand why things changed.
If something isn't working, I simply get the LLM to help me fix the problem.
- One liner describing what changed (not period terminated)
- A few lines describing in more details why things changed
- GPG signed commit
- Separate subject from body with a blank line
- Limit the subject line to 50 characters
- Capitalize the subject line
- Do not end the subject line with a period
- Use the imperative mood in the subject line
- Wrap the body at 72 characters
- Use the body to explain what and why vs. how
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.
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
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
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)