Space Game

Personal Information

  • Full Name: Jörg Müller
  • Email: nexyon at gmail dot com
  • IRC Nickname: neXyon


The target of this project is to create a space game with PySoy adding the necessary features to the engine. The first half of the project is to add general functionality to the soy.scenes.Space class to enable rendering and physics simulation of such outer space scenes and create a simple game with it, where you can fly around and shoot asteroids. The second part of the project extends this game and the functionality by improving a specific area of the game which is either graphics or AI.

Work Description

  • Preparation work: More research on the necessary data structures and algorithms for the basic rendering and processing of the basic Space scene. Deciding with the Mentor on which specialization will be implemented as the second part of the project.
  • By Midterm: The first half of the project is complete when you can fly around shooting in a huge asteroid field between planets.
  • By Finals: One of the three proposed specializations are working, see the details on which those three are.


Basic Rendering and Physics

The datastructure behind the Scene is an Octree. The rendering is basically done using the Painter's algorithm. This algorithm draws a scene by ordering the objects to render by depth and drawing them from back to front, painting over the objects that are further in the back. This is obviously done in layers for the space scene, where each layer can normally be rendered using the Z-buffer. Additionally we can investigate using the Reverse Painter's algorithm which draws front to back without drawing over already drawn pixels and again this would be done in layers using the Z-buffer in between. Physics processing between objects (especially collisions) is done for objects between each cell as well as neighboring cells. Each cell in the octree has a 3D integer vector as ID and each object stores it's position with a Cell ID and a 3D float vector as position inside this cell.

Each object has a specific distance as property and when the player is further away than this distance the objects will be taken out of the octree and either placed in a list of inactive objects or completely removed. Every time the player transitions from one cell to another this inactive objects list will be checked and objects that are close enough again will be added to the octree again and the developer will also be notified of this change with a callback to be able to load more objects. The specific distance this system is based on will be automatically calculated considering the bounding sphere of the object or alternatively it can be set by the developer.

Rendering details: As background for the scene there will be a skysphere to render a starfield and other "unreachable" far away objects such as nebulae and galaxies. Planets and stars are spherical objects. As long as they are quite far away, they can be rendered using a simple OpenGL quad, as the normals can easily be calculated inside the shader. The important thing for all those spheres (skysphere, planets, and stars) is to have very high quality and high resolution texture.

To sum up the algorithm:

Each frame (so executed multiple times per second):

  • Update (physics, collisions, logic) active objects in the octree.
  • Active objects that get too far from the player get removed or moved to an inactive object list.
  • Render the frame using the octree and the painter's algorithm.

The smallest cell of an octree around the player is where the most of the action is going on, imagine lots of small fighter crafts in a dog fight. If the player is near a border of these small cells, then obviously up to 8 cells have the action going on. Now every time the player crosses a boundary from one to the other cells, the inactive list is checked for objects to reactivate. Now if the player transitions the boundary very often in a short amount of time, like when he's flying a small circle, the inactive list shouldn't be checked every time, which could be prevented by having a timeout or some distance hysteresis to keep it from constantly checking.

Breaking this down in milestones which can be implemented in order:

  • Octree data structure with objects transitioning between cells.
  • Physics updates only between objects in a cell (including objects that overlap cell boundaries).
  • Distance checks for elements and the inactivity list and it's handling on cell transition of the player.
  • Painter's algorithm for rendering the scene with a clean Z-buffer and correct projection matrix (far/near plane).

The API for this system is actually quite simple and only a view calls have to be made by the user, most of them are optional.

  • A new Scene type Space will be added with a constructor [Space(sky_sphere, minimum_cell_size, cell_count)] and a method to set the transition callback and change the sky sphere.
  • The transition callback will get information about the cell coordinates (from, to) and which objects get deleted because of this.
  • A new body type Planet will be added inheriting from a normal Sphere, but with special internal treatment for rendering.
  • The objects of the Space scene have additional properties: distance (for inactivity checking), keep (whether the object should be deleted or not when it gets out of reach), active (whether the object is active or in the inactivity list) and cell_position (3 dimensional integer position)

The Basic Game

In the Basic Game the player controls a space ship flying in a stellar system with planets and an asteroid field in which he can shoot asteroids with laser gun, nothing too fancy, but a nice demo to demonstrate the functionality of the system.


I thought about three specializations, based on my studies for my master's degree. Two are in the field of computer graphics and one is artificial intelligence.


The target of this specialization is to get a rather simple rendering of the stellar objects to a very beautiful one. The main focus of this will be a particle system that can be used to render explosions, engine thrust, dust clouds, laser shots, small particles of dust flying by, and many more effects. Other possibilities include atmosphere rendering for planets, warp fields and animations, force fields, etc.


Procedural generation is the topic of this specialization. The plan is to build procedurally generated planets. The backbone of this is a level of detail system that manages how much geometry has to be generated of the planet to look nice. There is even more that can be generated procedurally, like the stars of a whole galaxy to render a skysphere making it easier for the developers to create the high resolution textures for it.


This AI specialization focuses on building an artificial intelligence that controls enemy space ships. This AI needs a decision algorithm to let it decide whether it should attack or flee and which detailed actions should be executed. Even more important is the control of the movement, to be able to dodge shots and get the ship in a good position for attacking (behind the victim). On top of that there can be a collective AI that generates strategies for multiple enemy ships working together.