Xylo

By

Liva Stubbe Teglbjærg, Rasmus R. Nagel & August Knut Gustaf Almgren

Take control of Xylo as he finds himself in a hidden lab - somewhere unknown. Fight the moving platforms and collect the flags one at a time for points and happiness! Also there will be scary monsters.

There has been made two versions of this game. One for the prototyping course made in the game engine: Pygame - and another one for a programming course made in processing. Both games are based on the same concept and each has its own qualities. Both of them can be downloaded underneath.

Fork on Github!

or

Get Processing version!

Overview

The objective of this prototype was to create separately showcase the various components that make up the game loop.

For the techperson in the team (August), this prototype was a chance to experiment with another game engine: Pygame, and start building up a framework to create the game.

The result is Chaos Chamber, envisioned as a 2D platformer taking place in a single room.

The idea is that the player fights his/her way through progressively harder levels, with each level showcasing a separate aspect of the game loop.

At the end of each level, a flag should appear, and when the player reaches it the next level is loaded, with the starting point at that position.

Examples of level types include maze levels (puzzles), pit levels (platforming), battle levels (fighting) and upgrade levels (rewards).

Examples of rewards include health recover/upgrades, increased jumping distance, damage or speed.

The original goal was to get through as many rounds as possible without dying.

Idea

The intended basic core loops in the game was simplified to being two actions: Jump and Shoot.

The different levels should then focus entirely on those simpel actions and the level design and applied challenges should provide a varied gameplay and enforce the core loops. A simple task of picking up flags in order to proceed to the next level should inform the player of a goal and make for a clear intention from the designers.

The first level design should have been clear and only include the player and a flag to be picked up. Next level could include a hole in the platform, forcing the player to jump. Next the platform could elevate, making the player jump on that and get the flag. Next loop should include an enemy which the player would have to shoot. and from there the two elements should be mixed.

Level design

All the graphical elements in the game was made from scratch. The visual expression was a raw graytoned world with roughly drawn edges. The level elements consisted of smaller movable elements for a functional and narratively understandable variation in levels - as the elements would be moved to create the levels.

Installation

To install, first make sure python 2.7 and pygame is installed on the computer. Then download the project from github and either run chaos-chamber or run main.py using python.

Controls

Move - Arrow Keys

Jump - Left Shift

Shoot - Spacebar

Evaluation

The player has an arsenal of actions available including walking, running, jumping, shooting and climbing.

Unfortunately, however, the proposed functionality was somewhat overambitious, and as a result it is not entirely implemented at this point. Notably, flags which load the next level and rewards/powerups are not yet implemented.

The collision detection could also be improved.

This being said, the engine is structured in a way which makes it very easy to rapidly play around with new ideas, which was also a major reason behind decideding to develop the game using python and pygame, as these are very well suited to rapid prototyping.

Architecturally, the game uses an entity graph similar to Unity, with subclasses such as Player, Level, Sprite and Tile extending and Entity class. Entities may implement various methods including __init__, update, render, keydown, keyup and collide, which are invoked at the appropriate times. Each entity in turn contains a list of entities, which are called recursively. All callback functions have two versions - one which is called before iterating over an entity's children, and one that's called after.

Entities may also have multiple states, which can be used to further fine tune behavior. This is demonstrated in the player and enemy classes, where each type of action (stand, run, jump, fall, ...) has an associated state. As with entities, a state contains an update, keydown and keyup function, as well as an enter and exit function which is used to handle state transitions. This approach is also used for enemies, proving that the approach can be generalized.

The game uses a tile-based approach to levels. This was chosen mainly due to simplicity - it is by no means inherent in the engine. Animations are abstracted into a Sprite class which extends Entity, and which in turn may be extended by other classes. Each state also contains a Sprite along with its callback functions, making it easy to show a different animation depending on what state the player or a monster is in, for example.

While this game was overscoped given the limited time available to implement it, building a simple game engine like this was an enlightning experience, and while the game still needs improvements, the work put into developing it will make future prototyping easier due to the generality of the concepts behind the game engine.