The acron Game Framework¶
This section describes the acron framework, a set of Python modules
that ships in the acron wheel. It has no C++ counterpart; a C++ game
uses the engine’s classes directly. The few engine classes it mentions,
such as TouchGamepad, are shown in both languages.
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:
PhysicsWorldis aBulletWorld.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 |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.