Godot
2D-first prototypes, educational games, narrative loops, and lightweight mobile or web delivery.
Use when ownership, speed, and small-team production matter more than a large plugin marketplace.Tech stack
Technology chosen by the game, not by habit.
Chwezi Games uses Godot, Unity, Unreal Engine, TypeScript, Blender, backend services, telemetry, and release automation as a practical stack. The exact route depends on player promise, platform, team ownership, performance budget, release path, and evidence cost.
Unity
Commercial mobile, cross-platform 3D, ads/IAP, analytics SDKs, and client teams already familiar with C#.
Use when the ecosystem lowers release risk enough to justify the tooling.Unreal Engine
High-fidelity 3D, cinematic vertical slices, multiplayer experiments, and publisher-facing visual prototypes.
Use when the production promise actually needs Unreal's visual and pipeline weight.TypeScript Web
Playable browser demos, production dashboards, internal tools, telemetry processors, and marketing sites.
Use for fast distribution, inspection, and web-native instrumentation.Blender
3D asset blocking, modelling, animation, export checks, LODs, and visual-development packs.
Use as the shared asset workshop before engine import.GitHub Actions
Build checks, linting, static validation, deployment previews, and release evidence.
Every client or owned build should have a reproducible mainline.Engines
Engine choice follows the player promise, target platform, team skill, performance budget, and release path.
- Godot
- Unity
- Unreal Engine
- TypeScript/WebGL
Gameplay Architecture
Game rules remain inspectable so saves, AI, quests, progression, and economies can be tested.
- State machines
- Typed events
- Data schemas
- Rule tests
- Debug views
Art and Content Pipeline
Art direction is production-aware: readable on target devices and maintainable by the team that inherits it.
- Blender
- Aseprite-ready 2D flow
- Texture budgets
- LOD checks
- Import validation
Backend and Live Features
Online features start as narrow spikes; authoritative state, abuse risk, and privacy are decided before scaling.
- Node/TypeScript
- PostgreSQL
- Firebase/Supabase when fit
- Leaderboards
- Telemetry
Release and QA
A build is not accepted because it opens; it needs repeatable source, route, device, and quality evidence.
- GitHub Actions
- Build artefacts
- Device smoke tests
- Profiler captures
- Accessibility checks
Website and Growth
Every game needs a public proof surface: what it is, who it is for, how it plays, and what evidence exists.
- Astro
- TypeScript
- Static hosting
- SEO schema
- Campaign landing pages
Engineering rule
Game rules should be inspectable.
Simulation, presentation, authoring data, persistence, and tests stay separate.
Save data is versioned. Content schemas are validated before teams create volume.
AI behaviour exposes perception, scores, state, and action choices in debug views.
Every released build has a reproducible source state and build evidence.