How Arepy Fits Together

Arepy separates what a game object is from what happens to it. An entity gives the object an identity, components hold its data, and systems apply behavior. A world brings those pieces together and the engine runs that world frame after frame.

flowchart LR
    Engine["ArepyEngine<br>runs the application"] --> World["World<br>owns game state"]
    World --> Entities["Entities<br>identify game objects"]
    Entities --> Components["Components<br>store data"]
    World --> Resources["Resources<br>store shared state"]
    World --> Systems["Systems<br>run behavior"]
    Systems --> Queries["Queries<br>select matching data"]
    Queries --> Components
    Services["Engine services<br>graphics, input, audio"] --> Systems

Think of the diagram as a map, not a checklist. The quickstart introduces each piece only when the game needs it.

A concrete example

Imagine a bunny moving across the screen:

Piece	In the bunny game
Entity	The bunny's unique identity
Components	Its transform, velocity, and sprite data
System	Code that moves or draws every matching bunny
Query	The request for entities that have the needed components
Resource	Shared state such as the loaded bunny texture
World	The entities, systems, and shared state for this game scene
Engine service	The renderer, input device state, audio device, or clock

The result is gameplay code that can say “move everything with a transform and velocity” without maintaining a separate Python object for every kind of thing in the game.

Read by goal

• Organize game state

  Start with entities, components, and systems, then learn when shared state belongs in resources.

• Understand each frame

  Follow the engine lifecycle from startup through update, drawing, and shutdown.

• Build the playable layer

  Continue with graphics, input, audio, and the built-in bundle.

• Work with lots of entities

  Learn queries and batch queries, then see how recycling and storage affect frame time.

• Add development tools

  Create live inspectors and tuning panels with Dear ImGui, then browse the complete examples.

• Share the game

  Use the game builder when the project is ready to leave your development environment.

Where should new code go?

• Put per-entity state in a component.
• Put behavior that applies to matching entities in a system.
• Put state shared by many systems in a world resource.
• Use an engine service for a platform capability such as drawing, input, audio, or timing.
• Use a query to select data; use BatchQuery when an array-oriented update is a better fit than processing one entity at a time.

These are guidelines, not hoops to jump through. Small games can stay small, and you can introduce more structure only when it makes the code easier to reason about.