Rising Tide

Introduction

This game served as an increase in difficulty from my previous projects, using Monogame and C++, I had to do most of the tasks an engine would handle such as collision and the camera, myself.

In terms of structure, this was an improvement from Last Stand, using base classes and less unneeded tasks. Equally, the way the game itself is setup is an improvement upon my last 2D platformer made without an engine, using PyGame. Within Rising Tide, the level uses singular images for each layer e.g. ground, background etc, meaning each collision tile does not need to be rendered / have an image attached, significantly improving performance.

My main focuses within the projects were the player, enemies, animation and collision. Collision was a focus as when using tiles, clipping can often occur, stopping movement unexpectedly, and when making custom collision in an environment where the level moves (simulating a camera) clipping can occur, resulting in unexpected results when performing X and Y checks out of order. 

Player & Upgrades

The Player Contains Save and Load Data to ensure that all variables are carried over from each room / level. Equally, previous level and door ID are stored to position the player in the appropriate position for rooms with multiple entrances / exits.

The movement system is fairly standard, with a simple dash on a cooldown and basic jump and movement. The System is a little strange, using both velocity and direction due to the method of moving the level to simulate a camera, meaning when the player is away from the edges of the level, the player is set to have no movement speed, and the level is moved instead of the player.

Animations simply take in the players current status and index within that animation and then render the associated image.

Enemies

Enemies use similar code to the player. The key differences being linear movement, moving in one direction until reaching a wall, then flipping direction. 

Collision code was handled within the level, this simply checked if the player was attacking or not before either taking or dealing damage.

Levels

Levels are setup using multiple CSV files to easily position tile collisions, hazards, upgrades, enemy spawns and level changes in the correct positions.

Collisions are also handled within the level allowing for different responses based on the tile group collided with.

What I Learned

Through this project, I learned how both using singular images for the level layers, and using individual levels for each room can improve performance on lower end systems.

Were I to redo this, I would look into making a camera class, improving performance as I wouldn't need to move the level and reducing the complexity of the player as there would be no need to set movement speed to 0. Equally, I would preload all animation frames into arrays, meaning I would then swap textures instead of loading from file on every use. I would also handle collision checks (attacking, invincible etc) and response within the player and enemy. Equally, I would use Broad-Phase collision detection in the level for all collidable objects, by grouping them by zones, this would reduce the amount of entities checked per update.