Afterciv: Moving into UE4
So in the past couple of days I've been studying the videos from Knut Øverbye for his Advanced Turn-Based Tiling Kit and ran it past some colleagues to see if it was a good idea to utilize it for digitizing the rules from paper into engine. With their assessment in mind, I started working on the project but had the task of covering the many hours of tutorials necessary to understand the inner workings of the kit.
The kit is quite advanced and offers a lot of flexibility, and it's quite well commented so that I can quickly determine which functions, variables, and BPs are used - and the demo projects included offer some interesting insights into tackling challenges.
This did bring me into a part of prototyping that I typically hope to always avoid - project management. I found myself staring at a pretty massive task, even to digitize the most basic rules, so I've decided to start piece-mealing the tasks into Trello. An important part of my development work is that I always keep a task-tracker about anything I care about - be it game prototypes, JIRA-based business development daily tasks or a Trello-based board I share with my partner.
So one of the challenges with my approach to this was in how I would tackle the task breakdown - base it on the rules, or interactions, or generalized 'features'? This is actually a problem/common issue I've encountered across a half dozen commercial/work-related projects and I really do prefer the agile methodology, but Trello is fast, dirty but not very structured.
For the first thing to tackle in my prototype, I think converting the rules into features and tasks is prudent, however I need to tackle the biggest things first. We know, for example, that the base opening move of the game is about movement and inhabiting a tile - but the tilekit project already takes care of that.
What we need now are three distinct features to appear that will help us establish the 'game loop':
- When the player hits 'end turn' button, the game will calculate values from different variables and return a sum - if the sum is less than 0, the player will be notified by GUI that they are in deficit. Or I'll pause/end game and make them press 'R' to restart just to shortcut this loop.
- When the player selects the Survivor unit, they're presented with GUI elements that enable them to select an option that swaps that asset with a 'Camp' static mesh. There are actually several parts to this.
- Each tile can have different properties defined by which static mesh inhabits it and different values assigned to variables such as 'Tile_Output_Food' etc. - having the Excel rules gives me a pretty clear picture of what this looks like, but it's still a huge task in itself.
Because I need even this high level management to go fast, I've separated my task tracking to only backlog, what I'm working on and completed. For the cards themselves, I'm currently going by this formula:
Prefix (Core Feature/Asset/Mechanic) : (Sub-feature, content, asset, interaction)
So for example: Tile Sets (Prefix): Grid Can Spawn Tiles with Different Meshes
This card is a sub-set of the overall 'Grid/Tiles' feature of the game and clearly states the completion conditions, the assets/procedures necessary, and metrics of success. When this task is completed, the Grid Manager should generate a new grid that has tiles with different biomes/meshes on them. This is the foundation of the game, so it is apt that we tackle this first.
By having this, we are able to also expand out to things like Tile Sets: Tiles Have Different Output Values or Tile Sets: Tile Types Impede/Bonus Movement. Now importantly, the toolkit already features the basic functions to assign movement values to tiles, so these are concepts that work within the tools/scope of what I already have.
For separation, I'm thinking that because 'You Don't Know What You Don't Know', I can't accurately work-hour estimate a lot of these tasks - instead I'm trying to break them down into logical 'interaction' stories that impact the game: It doesn't make sense to have a card that is based both on spawning meshes and impeding movement, as these two different features work together, but require separate efforts. Systematically I would define it as this:
(Feature): (Sub-feature)(Expected Outcome/Completion Metric)(Process)(Features/Assets/Content References) - another example of this may be:
Player Units: When Player Selects Unit, Action Option Buttons appear on UI
This way I know exactly what the referenced core feature/mechanic is, what the expected or intended outcome is and what the different assets I need are. I'm keeping in mind that this is a living document and process, which means that sometimes I'll overestimate (but mainly underestimate) the complexities of a specific card and will break it down further - but where appropriate, in-card checklists and notes can suffice.
Another important point about this is to have an ideas dump - don't think that 'ideas' are just wasted time, they may become important hooks or pivots in your future lists. I just don't like spending too much time coming up with ideas, so I just use the headings as 'sticky-notes' on random thoughts.
I might space these blogs out a bit more during the week and generally do an update every 2-3 days.