KivEnt gives Kivy an entity component system, and keeps the data on the C side

An entity component system for a framework that does not have one

KivEnt is described as a framework for building performant, dynamic real-time scenes in Kivy for Python2 and Python3, and the README notes that at the moment it is 2d oriented.

The architectural choice is the interesting part. An entity component architecture is used to control game object state and the logic of processing the game objects. Your game objects are made up of collections of independent components that strictly hold data, and each component corresponds to a GameSystem that performs all data processing on those components, in the update loop each frame, and as a result of user interaction or other programmatically generated events.

That is a specific and deliberate departure from what a Kivy application usually looks like. In plain Kivy, a widget is a graph of Python objects and the game logic lives in those objects. In KivEnt, the data is in components and the logic is in systems that sweep over those components every frame.

The other structural decision, and the one that has the most engineering consequence, is that all memory for the built-in components is allocated statically. The README links to a memory handlers page for anyone who wants to learn more about how that works.

Static allocation for component data is a performance decision with a real cost. You get contiguous memory for your component arrays, which is exactly what you want when a system is iterating over thousands of entities every frame, and you give up the ability to create and destroy entities on demand in the way Python would allow.

The Python API and the C level API are the same design

KivEnt is built with a modular architecture and designed to have both a Python API and a C level Cython API, which allows more performant access to your game data.

The README explains why that matters in a way that is really about workflow. It makes the framework suitable for quickly prototyping a mechanic completely in Python, and then relatively trivial to deeply cythonize that GameSystem if you find it to be performance sensitive. And it notes that this process has already been done for the built-in components, meaning they are ready for you to build new, performant game systems on top of them.

So the built-in components ship with the expensive parts already compiled. If you use the built-in systems you get the C level path for free, and the place you are likely to be writing code is in new GameSystems, where you can prototype in Python first and compile only the ones that turn out to matter.

That is a genuinely useful property for a game framework, because the performance questions in a real-time scene are rarely evenly distributed. Usually one system, the physics or the particle update or the collision check, dominates the frame budget, and the rest is negligible. Being able to leave the cheap parts in Python and compile one system is the difference between a rewrite and an afternoon.

The primary language of the repository is listed as Cython, which is the direct consequence of that design.

Five modules, and only one of them has no extra dependencies

The dependencies section is short and it is the clearest guide to what each module actually is.

The core module, kivent_core, is dependent only on Kivy. That is the whole point of the core, since it holds the entity and component machinery and the systems that operate on them.

kivent_cymunk adds cymunk, the Python wrapper around Chipmunk2d, for physics. The README names the dependency directly in the introduction, noting that the kivent_cymunk module is based on Chipmunk2d and its cymunk wrapper. kivent_particles adds particle behaviour and needs only Kivy and the core. kivent_maps adds python-tmx for loading Tiled map files. And kivent_projectiles is the most dependent, pulling in cymunk, kivent_cymunk and kivent_particles, so projectile behaviour with physics and particle effects is a single module that carries three dependencies.

The repository layout matches. There is a modules/ directory at the top level with the module directories inside it, plus examples/, tools/, scripts/, website/ and a requirements.txt.

The dependency list at the top of the README also has a note worth reading. It says that if you want to learn more about memory management you should read the linked page, which tells you the built-in components use static allocation. If you are evaluating whether KivEnt can hold the number of entities your game needs, that page is where the answer lives.

Building it is setup.py in each module directory

The installation instructions say to install all dependencies first, then to build the module you want. The commands are indented code blocks in the README rather than fenced ones, but the content is the same.

    cd .../KivEnt/modules/core
    python setup.py build_ext install

And the same for the physics module if you want it.

    cd .../KivEnt/modules/cymunk
    python setup.py build_ext install

If you want to install into a system Python on something like Ubuntu you may need to run the same command under sudo.

    sudo python setup.py build_ext install

There is also an in place build, which is what you want while you are working on the source, with PYTHONPATH pointing at the module directory so the import finds the freshly built extension.

    cd .../KivEnt/modules/core
    python setup.py build_ext --inplace
    export PYTHONPATH=/path/to/KivEnt/modules/core:$PYTHONPATH 

So this is a source build, module by module, and there is no pip install of the framework itself. The requirements.txt file lists Cython 0.29.10 or newer, Kivy 1.11.1 or newer, and a git dependency on cymunk pulled straight from GitHub.

The pip install line only appears for the cymunk wrapper itself, in the Windows portable package section, where the README tells you to install it from a master archive.

    pip install https://github.com/tito/cymunk/archive/master.zip

The Windows portable package path, and the examples that prove the install

The Windows instructions assume the Kivy portable package, and they are organised around running the examples as a check.

You open the kivy-2.7.bat console, or kivy-3.4.bat if you are on the Python 3 portable package, and install cymunk from its master archive. Then you either download and extract or git clone the KivEnt source.

    git clone https://github.com/Kovak/KivEnt.git

Then, in the portable package console, with KivEnt in the root folder, the sequence is build the core module, run an example to check the install, then build the cymunk module and run a second example to check that one.

    cd KivEnt/modules/core
    python setup.py build_ext install
    #check core install
    cd ../../examples/2_basic_app
    python main.py
    cd ../../modules/cymunk
    python setup.py build_ext install
    #check that cymunk install
    cd ../../examples/6_controlling_the_viewing_area
    python main.py

That is a good pattern to copy in general. The examples are numbered and each one exercises a specific capability, and two of them are used as smoke tests for the two modules you are most likely to need.

The example list in the repository shows the coverage. There is an empty Kivy app and an empty KivEnt app as the two starting points, a basic app, creating a gamesystem, adding physics objects, interacting with physics, controlling the viewing area, star fade, simple animation, twinkling stars, particles demo, SVG demo, drawing shapes, tilemap, tmx loader, camera rotate, SVG physics objects and joints.

The ordering is a curriculum. The first four are the core ideas, and the later ones are the modules.

The README still describes a Python 2 era toolchain

This is the most important thing to know before you plan around KivEnt, and the README does not hide it, it just states it in a short section.

The Tested On section says it was tested with the master branch of Kivy, with Python 2.7 and Python 3.4. The tested platforms are Android, Ubuntu, Windows and OSX, with iOS coming soon.

The support channels are also from that era. The mailing list is a Google Group, and the IRC channel is on irc.freenode.net on ports 6667 and 6697 for SSL, in the #kivy and #kivy-dev channels. freenode is long gone as a network, and the README's own support model leans on a Google Group for user support and the same for developer discussion.

None of this means the code does not work. The repository is not archived and the last push was on 2026-10-12, so somebody is still committing to it, and the requirements file asks for Cython 0.29.10 or newer and Kivy 1.11.1 or newer, which are far more recent than the versions the README says were tested.

What it means is that the stated testing matrix and the actual dependency floors have drifted apart, and the project is not being tested against a documented modern matrix. For a framework you intend to build a game on, that is worth weighing, especially given the last recorded tests were against Python 3.4.

Where KivEnt is the wrong choice

Three cases, and the first is the one the README states plainly.

It is 2D oriented. There is no 3D support in this framework, and the examples reflect that, tilemaps and sprites and 2D physics rather than anything spatial. If your project is 3D, this is not a candidate.

The second is if your team does not already write Kivy. KivEnt is an add-on to Kivy, and the learning curve is KivEnt's plus Kivy's, not KivEnt's alone. The README sends you to the introduction on the GitHub wiki as the starting point, which suggests there is a fair amount to read before you write a line, and the contribution and support channels assume you are already familiar with the wider Kivy project.

The third is the static memory allocation, and it needs care. It buys you the performance that justifies the framework, and it costs you the ability to allocate component memory on demand. If your game has a highly variable number of entities, or you want to spawn and destroy large groups at runtime, the static model is a constraint you have to design around rather than a detail you can ignore.

There is also a licensing wrinkle to check per module, which the README calls out itself. KivEnt aims to be a full MIT licensed project, and at the moment every module is MIT, but this could change in the future, and to be sure of the licensing for a module you should refer to the LICENSE file inside that module. For a framework you intend to vendor into a commercial game, that file is the one to read, not the README.

Editorial conclusion

Adopt KivEnt if you are building a real-time 2D scene in Kivy and want the entity component pattern with the data access kept in Cython rather than in Python objects. Do not adopt it for a 3D project, or for a team that does not already write Kivy. Before you start, check the Cython and Kivy versions in requirements.txt against your environment, since the file names Python 2.7 and 3.4 and the build goes through setup.py, and confirm the licence file inside the specific module you plan to use, because the README says the licensing is per module and could change.

Frequently asked questions

Official sources

1. Issues
2. kivy/kivent on GitHub
3. Project website
4. README