Game Development Engineering

An engine chosen on purpose, builds anyone can make, frame and memory budgets you check every week, playtests that change the game, and a launch and patch plan that survives first contact with players.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Then open the Marketplace in the app, search for Game Development Engineering, and click Install. It goes into your own files, and works offline from then on.

What it installs.

1

Pillar

1

Area

50

Projects

198

Starter tasks

⚙️ Software Engineering

Game Development Engineering

Building video games, from engine choice and gameplay programming to asset pipelines, performance on target platforms and publishing.

  1. Game engine decision for the next project
  2. Design pillars and a scope you can finish
  3. Target platform and minimum spec matrix
  4. Version control that copes with large binary assets
  5. Asset naming and folder conventions
  6. Greybox vertical slice in six weeks
  7. One-command builds for every target platform
  8. Crash reporting and log capture in every build
  9. Input mapping and controller support baseline
  10. Weekly playable build for the team and testers
  11. Frame time and memory budgets checked weekly
  12. Bug triage and crash bucket review
  13. Playtest feedback loop that changes the build
  14. Asset import pipeline health checks
  15. Engine and plugin upgrade cadence
  16. Save compatibility regression tests
  17. Milestone review at the end of each production phase
  18. Monthly devlog and build notes for players
  19. Platform requirements checklist kept current
  20. Game loop, frame timing and fixed timestep fundamentals
  21. Vector maths and transforms for gameplay code
  22. Entity component systems and data-oriented design
  23. Physics, collision and character controllers
  24. Shader programming for gameplay effects
  25. Game AI with state machines and behaviour trees
  26. Game feel with input buffering, coyote time and hit stop
  27. Animation state machines and root motion
  28. Profiling CPU and GPU frames on target hardware
  29. Data-driven tuning tables for designers
  30. Removing allocation spikes with pooling
  31. Load time and asset streaming improvements
  32. Versioned save system with migrations
  33. Multiplayer networking model decision
  34. Choosing audio, physics or UI middleware
  35. Localisation-ready text and font pipeline
  36. Accessibility options players actually use
  37. Game jam entry in a weekend
  38. Store page and wishlist campaign before launch
  39. Public demo for a games festival
  40. Console certification submission readiness
  41. Launch day build and first patch plan
  42. Early access first update and public roadmap
  43. First small game shipped solo in six months
  44. Gameplay scripting for artists and designers
  45. Moving from web or app engineering into games
  46. Porting a finished PC game to a handheld or console
  47. Rollback netcode for a competitive game
  48. Job system for multi-core gameplay work
  49. Seeded procedural generation with repeatable results
  50. Draw call, LOD and occlusion budgets for large scenes

Where it starts.

Each project arrives with its purpose, milestones and first tasks written out. Here is how the first three read.

Game engine decision for the next project

Choosing between Unity, Unreal, Godot, a framework such as MonoGame or a custom engine fixes your language, your licence costs, which platforms you can reach and how much of the next two years goes on tooling rather than the game. A written decision tested against a small prototype of your hardest feature stops the choice being made by habit or by whichever forum thread you read last.

First tasks

  • List the three hardest technical needs of the game you want to make
  • Read the current licence and revenue share terms for each candidate engine
  • Build a two-day spike of the hardest feature in the top two engines
  • Write the engine decision with the conditions that would reopen it

Design pillars and a scope you can finish

Most unfinished games die of scope rather than bad code: one more mechanic, one more biome, one more boss. Three short design pillars and a written list of what the game will not contain give every later feature request a quick test, and make cutting features a decision rather than a defeat.

First tasks

  • Write three design pillars in one sentence each
  • Sort every planned feature into must ship, should ship and cut
  • Set a launch content count for levels, enemies and items
  • Review the scope document with the team and date it

Target platform and minimum spec matrix

Your development machine flatters the game: what runs well there can be unplayable on a five-year-old laptop, a handheld PC or a last-generation console. Deciding the target platforms and a minimum spec now, and buying or borrowing one device at that spec, means every performance and memory budget later has something real to be measured against.

First tasks

  • Choose launch platforms and write one reason for each
  • Check a public hardware survey to set a realistic PC minimum spec
  • Buy, borrow or borrow time on one device at minimum spec
  • Agree frame rate and resolution targets per platform

Make it yours.

Install Game Development Engineering, then tell Aurum the date you're aiming for. It checks whether the plan fits the weeks you actually have.

Free · Mac (Apple silicon) and Windows · v1.0.0 · Other platforms

Blueprints are general information to help you organise your own work. They are not medical, financial, legal or other professional advice. See the Terms.