Rogue-Lite Platformer Game

Rogue-Lite Platformer Game - Description

This project is still in progress


This project is my first attempt to create a full game from start to finish, as opposed to just a tech demo like my other projects. So far, with the exception of a couple of functions I copied-and-pasted for parsing DDS Texture headers, every piece of code has been written from scratch by me, and uses my Direct3D 11 Game Engine.

Game Description

This game is a 2D platforming game with Rogue-Like (or Rogue-Lite) gameplay. It features permanent death and extreme difficulty, with a focus on exploration. The levels will be procedurally generated, and there will be no real end to the game -- the goal is to make it as far as possible while unlocking permanent perks to be used for your next character. The standout-feature of this game compared to other 2D Rogue-Lite games is how character progression and destruction is handled.

This game uses a voxel system for rendering and collision. Each character's constituent voxels can be destroyed when taking damage, and collision with the environment is directly based on the character's actual voxel model. All properties of a character are based on the voxels which comprise it; players are able to add additional blocks (such as armor blocks, gun blocks, thruster blocks, etc) to their character whenever they acquire the materials to do so. When a block that's part of a character is destroyed, the character loses the properties brought upon by the destroyed block.

Unlike most other games with a voxel aesthetic, this game uses true voxel animation. The idea for this game was originally inspired by the Lego Movie -- all rendering is tied to a discrete grid. There are no inbetween spaces -- even explosions are aligned.

Combat Details

All characters have a blue "Heart" block as part of their model. If this block is destroyed by an attack, the entire character is destroyed. All blocks that are part of a character must have a path to the Heart block at all times (either directly adjacent, or through any other sequence of surrounding blocks). If a character is struck by a projectile, and some blocks (but not the Heart) are destroyed, any remaining blocks which have become isolated from a path connecting to the Heart are also destroyed.

Picture Showing Blocks

The blue block is the character's Heart; The green blocks are guns. The grey blocks are fodder.
This video shows a short demo of the combat prototype. It also shows a short demonstration of character building.

Character Building

As the player kills more bad guys, resources are collected. These resources can be used in exchange for more blocks to attach to their character. Pressing tab brings up the inventory screen with a selection of block types and the number of these blocks contained in the character's inventory. Selecting a block type, then clicking adjacent to a block on the character will remove the block from the character's inventory and add it to the character's model. Blocks must be attached directly adjacent to existing blocks (or diagonal).

The game will feature many different types of blocks, allowing the player to create uniquely customized characters to approach the game in new ways each playthrough. It is intended that the player can determine completely the properties of any character by looking at the blocks which comprise it.

Some Example Planned Block Types

(?) Denotes that I have not yet chosen a color for this block type.
  • Regular Blocks (Grey): Regular blocks are good for ensuring redundant connections to the Heart block for more important, special blocks (such as gun blocks).
  • Gun Blocks (Green): All shooting is done through gun blocks. When a character attacks, all gun blocks fire simultaneously.
  • Armor Blocks (White): Armor blocks can take increased damage, and prevent explosions from passing through them to damage blocks on their other side.
  • Thruster Blocks (?): Thruster blocks can be assigned a thrust direction and a hotkey; pressing this key will propel the character in the direction assigned when the block is created.
  • Ammo Storage Blocks (?): All ammo used by the character must be stored in blocks on the character.
  • Fuel Storage Blocks (?): All fuel used by additional thrusters must be stored in blocks on the character.
  • Reduced Friction Blocks (?): These blocks will have reduced friction against surfaces, allowing the character to build up more speed while moving along the ground, possibly to perform stunts to reach otherwise difficult to find locations.
  • Lightning Blocks (?): Lightning blocks launch bolts of lightning at nearby enemies.
  • More (?): There will also be other good blocks.

Character Upgrading

In addition to placing additional block onto their character, the player is able to upgrade existing blocks by placing blocks from their inventory on top of existing blocks. Blocks eligible for upgrades show a blue cursor when hovering over them. Blocks may only be upgraded by placing blocks of an identical type.

In keeping with the mantra that all properties of a character can be determined just by lookinga its block composition, the upgrade level of a specific block is shown by how filled in the block is with a pulsing graphic.

Upgraded blocks lose a single upgrade level when taking damage. If a block's upgrade level is zero when taking damage, the block will be destroyed. This is interesting because the player can do things such as build a wall of upgraded blocks at the sides of their characters.

Upgrading things like guns have additional effects. For example, upgrading a gun block increase the radius of its projectile's explosion.

This video demonstrates the process of upgrading blocks on a character, and shows how upgraded blocks affect combat.

Character Animation

I am currently experimenting with the concept of animating the player's character. Animating NPC characters is easy. However, allowing the player's character to be animated poses a unique challenge because the player can add an arbitrary number of additional blocks, which may conflict with existing animations.

The solution I came up with is to allow players to manually animate the blocks on their character. The player does so using a UI that allows the player to scroll through each animation frame on the character. Players may scroll to a particular frame, then set the new location that each block will be starting at that frame by selecting blocks and then selecting their new location. The player may then scroll additional frames and set the next location for each block. Animations have the constraint that the last stage of a particular block's animation must return the block to its original location. This is enforced to make sure a block's animation is always a loop. The constraint also is enforced that all frames of a character's animation produce a valid block configuration: No overlapping blocks, and blocks must be always adjacent to at least one other block. Lastly, it is enforced that a block can only translate at most one square in any direction per animation stage. However, as many animation stages as needed can be added per block, with any number of frames between each stage.

Picture Showing Blocks

This picture shows the prototype UI for animation.
This video demonstrates the process of animating the player's character.

More Gameplay Details

This game is intended to be difficult. When a character takes a hit, it can lose several blocks. Players are intended to have to add more blocks to their character after every encounter they take damage from. Players will be required to exercise great care and strategy in their character's block configuration so that a single deadly blow does not destroy too many of their more valuable blocks.

Because the game engine handles collision detection directly based on the voxels on a character, players attaching enough blocks to their character can make it too wide to fit through certain passageways. Players with the skill to survive with fewer blocks will be able to fit into more secret areas. In addition, collision detection is handled on a block-by-block basis, so when a character moves along the ground, the friction from all blocks touching the surface is accounted for. Characters with fewer blocks on the bottom will have less friction. Each block also contributes to character weight, slowing it down.

I am considering the idea that there will be "personality" blocks that make up AI characters. There will be "pleasant" blocks and "unpleasant" blocks. If an AI character is comprised of a higher number of unpleasant blocks than pleasant blocks, it will attempt to murder you upon seeing you. AI characters comprised of mostly pleasant blocks will attempt to invite the player to dinner parties.

When the AI character is damaged, if the number of each block type changes so that the other block type is more prevalent, the character's disposition could change as a result. This can allow for interesting strategy, where attacking certain parts of an enemy character will cause it to ally the player if the player manages to destroy the enemy's unpleasant blocks.