Repository navigation
Architecture and Design
Fire Emblem is a singleplayer turn-based tile tactics game.
Levels are controller classes wrapping both map data and unit state, while also containing methods for unit interaction and the gameplay loop. Maps are made up of a data layer that includes vertex data for various terrain types to shift the tile-picking work from the developer to the codebase, while we use a custom build function, (toTscn()) to leverage the builtin Godot classes for tile based maps generated from that data layer for the visual components and unit interactions in Level.
MapData holds the vertex layers of the map and the data used to instantiate units. Levels can be serialized and deserialized to and from JSON for human readability and portability. Unit movement is also currently calculated here since movement requires terrain data, and since both the unit state and the interactive map are instantiated and stored in Level this was the most convenient place to put it.
Level
MapData
MapLayersData
[MapLayer]
units (reference)
units (state)
toTscn() (view)
Level -> toTscn() -> level .tscn file includes the components drawn by the game engine
Units are split into visual, state and reference data classes. Stateful units are instantiated and stored by Level from information in map data.
Players move their units until all of their units have taken an action. Once all of a player’s units have moved, their turn ends and the game moves to the next player. Players may be controlled by the actual human player or an AI.
User interface components include the main menu, unit action menu, movement overlays and battle forecast.
-
Reliability - The game is simple enough at the moment that although much of the functionality is currently concentrated in a few classes everything works consistently. To make testing easier and the architecture simpler we may further flatten or expand each classes’ responsibilities to separate and/or consolidate concerns in a more logical way.
-
Performance - Godot enables performant rendering of hundreds to thousands of sprites and efficient pathfinding operations on tile based maps. Our system allows us to easily reason about and create maps and levels while also maintaining compatibility with Godot's built in features.
-
Functionality - Features will be fleshed out as development progresses.
-
Competitiveness - Tile and turn based games are a long and well documented video game tradition, but the efficiency of a map system that skips almost all manual tile placement radically frees up developer resources. Our method, although more complicated than some ways of doing things makes designing and testing the actual content of the game much, much faster and easier than traditional techniques that rely more heavily on manual interaction with the game engine and IDE. A developer now only needs to place a single vertex in our map editor for all the surrounding tiles to automatically update to the correct sprite and terrain.
-
Compatibility - The way we have our code set up, the Godot view trees and nodes are generated and need no interaction from the developer. While this does add some complexity to the initial process of setting up a game's map, it abstracts away all of the duplication and manual fiddling that interacting with Godot usually demands. We still rely on some of Godot's features without being chained to its clunkiness.
-
Lifespan - We expect this version of the design to be updated and modified weekly as we introduce new features and tests, but the basic ideas are sensible enough to last the duration of the project.
-
Deployment - We are already deploying and testing builds live during the development process. Agile development demands that developers are able to see what they've built before everything is set in stone.
-
Support - Testing is more difficult when functionality is concentrated, but mocks and dependency injection make unit tests doable. The flexibility and efficiency of the basic concepts is more important than the actual structure of the codebase.
-
Cost -