Hexpenditure
Hexpenditure is a casual strategy game inspired by Civilization, Anno and Islanders. On a hex grid, extract resources, produce some more, and SELL SELL SELL to maximise your profits and survive as long as you can!
This was a individual student project about developing a game from concepting all the way to release. I worked on every aspect of the project, from planning to concepting, technical implementation, documentation, QA and more. Over the course of the project I created several modular feature sets focused on flexibility and developer usability with the intention of possibly expanding on the game in the future, being able to use these feature sets to easily create new content.
Solo
~14 Weeks
Casual Strategy
Unreal Engine 5
PC (itch.io)
University Project
Project Planning
To facilitate a smooth course of the project, I employed production and planning frameworks such as Scrum. I planned splrints and tasks using velocity, priorities, sprint goals and more, held retrospectives and generally remained agile to serve the ever changing needs of the project.
Design & Implementation
I was inspired by my enjoyment of the early game of strategy games such as Civilization and wanted to create that fully encapsulates that experience in an accessible form. I verified this design with a paper prototype before delving into implementation, where I developed several modular featuresets making use of Unreal Engine’s visual scripting.
Throughout the course of the project, I made sure to keep up design and production relevant documentation at all times, with a special focus on QA with things such as a Conditions of Satisfaction document, a bug reporting pipeline and regular build reviews.
Documentation & QA
Project Planning
At the beginning of the project, I created a project plan outlining the major phases, sprints and milestones until the project deadline. This outline helped me structure and prioritise my work, and was a constant asset in evaluating my progress. As the project went on, in oder to stay agile, I iterate on my project plan based on changed priorities, progress and other relevant factors.
The sprints, which were themselves linked to project phases, milestones and deliverables, were facilitated using a Scrum board in Trello. This board consisted of individual lists for the project backlog, planned tasks for the current sprint, in progress tasks, tasks to be reviewed and finished tasks. These lists were filled with cards representing the tasks, which themselves consisted of a user story, definitions of done, a priority, story points and sub tasks. When planning a sprint, I would use the previous sprint’s velocity based on the number of story points reached and the next sprint’s duration to calculate the number of available story points. I would then create a list of sprint goals based on the milestones and deadlines from the project plan, which formed the basis of which tasks would be added to the sprint. The highest priority tasks that were needed to achieve the goals were added to the sprint backlog until the sprint’s scope of story points was reached.
Concepting
Early versions of the game’s concept initially resembled a mixture between the round structure and scope of Islanders and factory automation of Satisfactory. I was happy with the core structure, as the ideas of short bursts of casual strategic gameplay felt like a great fit for my personal cerative interests as well as the project’s scope, but after additional refernce research the concept moved more towards the core gamplay of games such as Civilization. In order to verify my ideas before commiting anything to code, I created a paper prototype which consisted of several permutations of different systems. This allowed me to investigate different aspects of the game individually, as well as different versions of several systems. As the style of the game lent itself to a paper prototype quite naturally, it was able to provide me with results that allowed me to confidently move into the next phase of the project.
Implementation
Resources: resource enum, structs for data table and production chains, created data table from struct, saving all information of every resource in there, accessed this DT any time I needed any information about a specific resource.
Buildings: all buildings inherit from parent base building, that has core functions and variables, one of them is about adjacency bonuses, variable map of adjacency bonuses enum and adjacecny bonus info map that would be filled for each inheritiing building, any time a building was being placed, for each of the adjacent tiles of the tile that was being hovered over (which are saved on grid spawn), each of the entries of the map is checked and if the adjacency bonus is active, a function from the base building calculating that tile’s adjacecny gold bonus would be triggered, adding its output to the total tile bonus.
UI, resource tooltip:
Testing & QA
Dedicated bug list on the Trello board
Bugs are a card in the board: epic, priority, description, location, repro steps, expected and actial result.
Bugs would be reported in multiple ways: noticed during development, end of sprint build review (which I used to note the development of my builds as well as note and report bugs), playtesting feedback form.
Cos document which was expanded to reflect any changes in the projects scope. New tabs were created for each build review, was filled in during each build review.
At the end of each sprint, I performed both a build review and sprint retrospective. During the sprint retrospective I would analyse the burndown chart of the previous sprint and calculate the available story points for the coming sprint in preparation for planning. I also reflected on the progress and process of the previous sprint. I noted the completion of the sprint goals and any leftover tasks and compiled a list of things that went well, things that didn’t go well and finally created a list of action points emerging from the retrospective. In retrospectives other than the first one I would also evaluate my progress on the action points from the previous retrospective, keeping the active if necessary. I also took this as an opportunity to add any tasks to the project backlog if my findings from the retrospective necessitated it.