Time to take a look at the other major project I undertook this summer. This one’s as big, if not bigger than the other, so I’ll be spacing this out over several posts in the coming week(s) starting here with an overview.
A group of 8, including myself, was selected from applicants to work on a 4x game for Canada’s 150th Anniversary that was going to be shown at this year’s Canadian Video Game Awards before the event was unfortunately cancelled. We gave our little Canadian 4x game the working title 3xEh / 3xA.
Part of what made this such a great, and unique experience of a class was how it was structured. We used a very rough, improvised version of Scrum importantly featuring a product owner who dictated the high-level goals for the product we were to create. We had a lot of opportunities for creativity in the implementation, but had to work within the restrictions, and goals provided to us, and run any high-level ideas of our own through the product owner.
The game we were assigned to craft was to be a Canadian-themed simplified 4x game (it was suggested it might be like King of Dragon Pass). The theme would be rebuilding a post-apocalyptic Canada ravaged by some future plague. The seasons were to play an important role with the summers having the worst plague effects, and winters providing natural hindrances to survival given the state of society. Some of the central themes were to be Canadian values, the sheer scale of the country, recognizable landmarks, rebuilding, and scarcity. The last point was emphasized in the intended feel and structure of the game as being heavily inspired by rogue-lites. Players were expected to fail regularly in learning the game, and it would feature a degree of random generation to keep it interesting through this. The central mechanic for the game was to explore cities you’re in, discover serviceable buildings, and commit resources to repair them to be used for various tasks like housing, food generation or storage, government, etc.
Through the project my primary roles were design, art, and dev. In accordance with Scrum we didn’t have explicit, or strict roles, but it worked out that I was effectively the design lead, art lead, and contributed to dev engine-side for a variety of individual game mechanics. Again, there were no formal roles, but based on preference, and existing skill specializations the
team breakdown was roughly as follows:
me: design, art (UI and game), dev (adding mechanics to engine)
1: UI (design, dev, and art)
2: UI (design, dev, and art)
3: dev (engine, and UI integration)
4: dev (engine, and data)
5: dev (engine, data, and integration / repository management)
6: dev (mechanics)
7: generalist (mix of design, dev, and UI)
Note that the above are generalizations. The project was a very collaborative, and communicative process. We had effective specialties, and areas in which we did the bulk of the work, but everything was discussed, and debated with the group, particularly high level design, and dev decisions.
In following posts I’m going to look at the project as a whole, and particularly my contributions in more detail. Art and dev parts will probably be small enough for a post each. But given how much writing, in addition to just the work, went into the design I’ll probably split that part up.