Note: Even if I am targetting more video games, some concepts are transposable to board game design. See near the end.
I am trying to design a video game app, and it seems I need to put a lot of hat on my head, from programming to art/music selection and the design of the game itself. So it can become very confusing what and when it needs to be done. This is why I was exploring in various ways I could handle project management. I tried to list common task, make groups and I came up with 3 large categories of task to do:
A- Assets: This consist of creating or approving artwork, music, sounds, levels, maps, etc. Almost anything loaded from an external file.
G- Game: This is everything related to the game design of the game. It can be done on paper or in a word document. It includes data, formulas, mechanics, rules, etc. Anything that can be teached in a rule book or a design document goes there.
S- Software: This is everything related to programming, rendering engine, input reading, etc. If it must be computer programmed, it goes in that category.
Then I realised that composite catagories could be created. They are in fact in between 2 categories or in relationship with each other.
AG- Asset-Game: The game design will determine which asset will be required in the game. What kind of icons and how many icons will be necessary, what Is the a artistic style of the assets. It is what justify the requirement of an asset.
AS- Asset-Software: Defines how assets are loaded and accessed by the program. File formats, asset loading and disposal, database types and format. Mostly related to the management of external files.
GS- Game-software: Consist in programming the mechanics of the game into the software. Programming formulas, rules, behaviors, patterns, AI, etc. Generally this code is specific to a certain game.
After using this model as basis for project management, I came up with the following conclusions:
When designing a game engine, you will mostly likely touch aspects: Software,Asset-Software and a bit of Game-Software. So you only touch half of the graph.
My command line engine project, which include game demos, only touched aspects: Game, Software, Game-software, and a bit of Asset-Software for database and savegames. Which again touched almost only half of the graph.
I also tried to see if there was an optimal order to fulfill those aspects when creating a complete game from scratch as it could impact how a project is managed. But it seems that all aspects are interdependent, therefore, you will need to jump from 1 aspect to another throught the development. You could start from any of the 3 aspects:
Assets: You could start doing art for a game you have no idea how it plays but know the theme.
Game: You can start designing mechanics for your game without any software or art.
Software: You can start by designing a game engine without any game design in mind other than it's a side scroller.
Transposition to board games
This is indirectly related to the Theme vs Mechanics. Here assets are more related to theme, while mechanics are more related to game design. On the other hand Software, would be related to the assembly of the game. Which means printing, gluing, cutting, etc. It's just that most people don't assemble their game manually, unless for a personal copy.
Am I missing anything?
Well the grouping of the task seems to be done by activity type. Each activity type have different requirement in matter of tools and mind set.
When I am programming, I need a computer and I need to be in the mood to code. My mind must be sharp.
During the afternoon I am generally more tired, so it might be better to work on assets which will require drawing tools, file management, etc.
But if I am stuck in the bus with a pen and paper, I should be better be working on design and task planning.
So when I have time to invest in one of the 3 activities, I know exactly what needs to be done. This is the advantage of grouping them first.
You could see the work ahead in a category and decide to wait before spending time on it. You could also list related task when working on another category to make sure you dont forget anything.
I would also avoid wandering around and start looking for assets, when you actually intended to program.
Gitlab has some issue tracking system, but it is designed more for teams than solo people. The problem is that inserting those issues takes a lot of time, but the positive is that you can document those issues afterwards. I think I would prefer having a single line of text telling me what task needs to be done. Any documentation or reference could be placed elsewhere.
After making a simple task list test, I realised that it kind of group information on a different axis than features. So if I want to add a new feature to my game like propaganda. Well this feature will require certain game design rules, certain assets in the user interface, and some programming to implement this feature. So all those 3 tasks are grouped together from a feature axis, but are split in 3 different categories when changing axis.