Project Overview

Basic Information

• Project: Dungeon Game Maker
• Author: Yang Hu, Hang Zhou, Shang Lyu, Qikun Xu
• Credit to: Jiangchuan Wang - lots of contributions during the engine structure designing and coding.
• Institution: Northeastern University
• Class: CS5850 - Building Game Engine
• Instructor: Mike Shah

Game Introduction

This project is a 2D dungeon game maker implemented with a component pattern and many essential structures for other extensions. With a low-coupling programming principle, the game could be easily used as a game engine that supports various 2D game development.

Here is a list of what we have did in this project.

Features:

1. Component pattern: All functionalities, like animation, are attachable to game objects.
2. GUI editors: An editor that support game-object (like enemy) editing.
3. Resource manager: A singleton resource manager holds and manages all loaded resources.
4. GUI-based object editor: We used the KISS library to build a GUI for editing game objects, like enemies, without compilation.
5. Data Driven: Data like level maps and enemy info and are loaded during the compilation. We also implemented a basic Object Pool for managing enemies. The enemies will be instanciated together when the engine starts. Defeating an enemy triggers a deactivate, instead of a destroy.
6. Animator: A customized animator component that manages animations with respective states.
7. Pathfinding: A pathfinding component that provides optimized A* pathing and guide the owner to the desired destination.
8. Auto Tiling: A set of handful auto-tiling functions that automatically draws all the corners, walls, floors and corridors with customizeable settings.
9. Auto Map Generation: A dungeon map generator that produces a dungeon with random rooms, hallways, start/end rooms and stairs.

How to play:

1. Title Screen: When the game start, use up or down arrow to select between level editor and game. Press Enter to confirm.
2. Movement: WASD to move.
3. Attack: Use arrow keys to attack.
4. Switch Mode: Use Q on your keyboard to quit the game or back to the menu.
5. Edit and Play: In the editor, player can customize tilemap with mouse. You can save your tilemap to the local file or load it to the game.
6. Clear Map: (Editor only) Press Esc to clear up the canvas.
7. Generate Map: Use Space key to generate a new map. By doing this, player will be trasported to the start room, and all enemies will be re-allocated to valid positions.
8. Travel Between Maps: Walk on the stair to enter the next map
9. Use GUI editor: build the editor by puthon buildGUI.py

Tools:

1. Sprite Editor: ./lib/spriteEditor: a simple sprite editor. Compile with python build.py
2. Level Editor: Select "Editor" in game title screen.
3. Object Editor: The editor could run and edit game object when the game is running. The executable in in ./lib

Game Demonstration

Game play

Screen shots

Title screen

Generated Map

Gameplay

Editor

Game build and executable

GitHub Repository

Map generation

We implemented a procedural map generation and an auto-tiling system.

With a binary space partitioning tree, we devide the map area randomly into leaf spaces and generate random rooms and hallways within these spaces. The auto-tiling functions then recognize all corners, floors and directional wall sprites.

This short clip shows the new map generation.

Learn more about map generation here.

Enemy AI

We implemented an enemy AI with pathfinding.

The enemy comes with a pathfinder component for chasing player or traveling to a random destination.

The enemy changes between walk and rest states based on fixed time schedule. The player detection runs with highest priority, and will change the enemy state to attack when the player is in sight.

Learn more about A* algorithm here.

We implemented a simple Raycast() function for detecting player.

Collision check

The collision check method is adapted from the Separating Axis Theorem (SAT) in Austin Morlan 's tutorial.

Project documentation

Documentation

Engine Architecture

Possible improvements with 8 extra weeks

A more "engine-like" design:

The current build is still more "game-like" instead of "engine-like". But, most of the game is coded as we are using an engine, which makes the update a easier task. For example, all sprite loading and resource configurations are written in Config.hpp, with strict formats. Also, all the game objects, including player and enemy, can be easily updated with new sprites, attributes and behaviors (like collider). (2 week)

Add A better GUI system, the engine could looked more like an application build that support a relatively complete development work. This could support managing game objects as in a file system, managing resources like sprite and configuring tile palette. (2 week)

More script supporting:

Create more possibilities for other users to write all kinds of scripts changing the game state. For example, be able to specify game ending by writing purely in scripts. (2 weeks)

Support game progress editing:

Allow player to control the engine behavior, like switching between scenes, to support game start/end coding.(1 week)

Support more text and image editing:

So that users could drop more textx/images and even buttons to create their own menus. (1 week)

Email:

Yang Hu

hu.ya@northeastern.edu

Zhou Hang

zhou.han@northeastern.edu

Shang Lyu

lyu.sha@northeastern.edu

Qikun Xu

xu.qik@northeastern.edu

Jiangchuan Wang

wang.jiangch@northeastern.edu