The Project

The idea of the TimothE 2D project was to create a tilemap based 2D game framework that could be used to recreate a wide variety of projects within this genre. This project was undertaken as part of my Group Game Development module in my third year of university where we were tasked with creating a game framework and then creating a game within that framework. The timeframe for this was 6 months however at the start and end of this period we had a dedicated 3 weeks where this module would be only thing on our timetable and as such these were the dedicated development periods for this project.

Why this project was chosen

As previously stated this project was part of my GGD module at university. In our team consisting of 10 members, 8 programming students and 2 development students, we decided that given our rather limited 3d modelling and art experience that a 2d game would be the ideal project as the art can be simpler and will take less time. This was especially important as the art of the game was not a marked aspect of the project. Once we had decided on a 2D game we then started a discussion on what type of game we wanted to create and the general consensus came to an overhead, tile map based game that revolved around defending a farm you were building from hordes of bandits or raiders.

Project Specifics

Built in C++ using OpenGL 4.4, Dear ImGui, GLFW, FMOD

Built in 6 months. January 2022 - June 2022. With six dedicated weeks to the framework

Features

  • Tilemaps based on the tmx file format (created by the program Tiled)
  • Originally used a custom tilemap and editor however this was abandoned due to time constraints.
  • 2D Collisions “trigger” collisions between objects and physical collisions between objects and tilemap collision points.
  • Component based architecture
  • A* Pathfinding
  • “Unreal Engine” inspired Collision Channel System that allows collisions between compatible channels.
  • Batch Renderer
  • Scaleable UI Systems
  • Spritesheets and animations
  • A audio engine built using FMOD which allowed for multiple audio channels
  • A easy to use save and load system for handling player attributes, was originally also used for storing component attributes when the project also involved a editor.
  • “Stash”: This is where the player could stash various items at their hideout where they wouldn’t lose it if they died.
  • A screenshot of the game created in TimothE2D

    A small demonstration of how the scene render function worked with the batch renderer

    A explanation of the collision channel system created for TimothE2D

    Basic demonstration of some text UI being laid out

    What went well

  • Created a playable and enjoyable prototype of the original game idea
  • A relatively performant game could be created in this framework
  • What didn't go well

  • Lack of proper group communication
  • Mix of framework and game logic
  • Overscoping the project. The original project for TimothE 2D was a more game engine esque approach where we would have a editor with windows that would allow us to add new game objects to a scene and modify the attributes attached to them, these would then be saved and loaded by the engine. This ultimately fell through due to time constraints.
  • Lots of “Set it and change it later” code.
  • Spending too much time on features that should’ve been a lower priority.
  • What could be improved

  • Build the framework as a static library that can be attached to any project rather than having to have all of the frameworks source code within each project. This would also massively help with having separating game logic and framework logic.
  • Some form of threading module to handle the framework that would allow for a concurrent execution of different systems.
  • The editor. The original plans for TimothE did involve a editor however this fell through due to time constraints.
  • Collisions and proper 2D physics. There is the collision channel system in TimothE however it could still be improved to allow for more optimal collision checking with data structures like quadtrees. Proper collisions and physically accurate responses are also missing from the framework as they were not needed at the time of development.
  • Gameplay Video

    Technical Overview of my Involvement