The acron Game Framework

Beside the engine’s own modules (acron.core, acron.bullet, acron.rmlui, …), the acron package holds a framework of game mechanisms written in Python: the parts nearly every game needs and the engine does not provide on its own – a fixed-step game loop, a character that walks on floors and slides along walls, input actions, a camera boom, menus and HUDs, PBR materials, animation blending, 2D tile maps, saving and testing.

The modules grew out of shipped games, several of them ported from Godot, and they keep three rules:

• Use the engine directly where it already does the job. The scene graph, transforms, model loading and rendering are the engine’s; the framework does not wrap them. Its classes extend the engine’s where they can: PhysicsWorld is a BulletWorld.

• Mechanisms, not policy. Modules take the game’s numbers – collision layers, capsule sizes, tuning constants, key bindings – as arguments, and hold nothing game-specific.

• Familiar vocabulary. Names follow the engines games are ported from where that helps (move_and_slide, is_action_pressed, Signal.emit), without copying their machinery.

Nothing has to be installed: the framework is part of the wheel. Its most used classes are importable from the package itself; the rest from their modules:

from acron import PhysicsWorld, GameLoop, CharacterBody3D, InputMap
from acron.hud import Raster
from acron import simplepbr

The Modules

Page	Modules
The Game Loop	fixed_loop (fixed step, render interpolation), timers, signals, governor (resolution against frame time)
Physics and Characters	world (Bullet conventions), character_body, slide, spring_arm, camera_shake, interop
Input: Actions, Gamepads and Touch	input_map, gamepad, touch; the engine’s TouchGamepad
Menus, HUDs and Text	window, ui (RmlUi plumbing, menus), hud, layout, strings
Audio: Sound Banks, Acoustic Zones and Baked Sound	audio, audiospace, dsp
Animation Blending and Root Motion	anim, keyframes
Materials and PBR	simplepbr, hdri, pbr, materials
Gaussian Splats	sog, splats
Procedural Content	noise, gpu, geom, quads
2D Games	canvas2d, tile_map, sprite2d, area2d, particles2d, camera_2d, parallax, character_body_2d
Porting Games from Godot	gdformat, interop, particles3d, mathutil
Saving Files and Testing Games	persist, testing

Some modules work on arrays and need numpy: gpu, geom, noise, quads, dsp, sog, splats, testing and hud’s Raster. The desktop wheels depend on numpy. The web and Android wheels are built without it, so a game that uses these modules on those platforms has to bring a numpy built for them.

• The Game Loop
  • The fixed-step loop
  • Timers
  • Signals
  • Resolution and frame time
• Physics and Characters
  • The physics world
  • Character bodies
  • Spring arm
  • Camera shake
  • Y-up and Z-up
• Input: Actions, Gamepads and Touch
  • Actions with InputMap
  • Gamepads
  • On-screen thumbsticks with the pointer
  • The touch gamepad
• Menus, HUDs and Text
  • Before the window opens
  • An RmlUi layer
  • The drawn half
  • Lining the halves up
  • Strings and locales
• Audio: Sound Banks, Acoustic Zones and Baked Sound
  • Playing sounds with SoundBank
  • Acoustic zones with AudioSpace
  • Baked sound with acron.dsp
• Animation Blending and Root Motion
  • Weights for a blend
  • Root motion
  • Keyframe tracks
• Materials and PBR
  • The pipeline
  • Lighting from a panorama
  • Godot’s lighting: acron.pbr
  • Materials on texture-less models
• Gaussian Splats
  • Reading scans
  • Drawing them
  • Deforming splats
• Procedural Content
  • Deterministic noise
  • Arrays to textures
  • Building meshes
  • Quad pools
• 2D Games
  • The stage
  • Tile maps
  • The 2D character
  • Overlap sensors
  • Sprites
  • The camera
  • Parallax
  • Particles
• Porting Games from Godot
  • How close ported code stays
  • Y-up and Z-up
  • Reading Godot files
  • 3D particles
• Saving Files and Testing Games
  • Saving files
  • Testing games