Forensic Friday 58: Reframing as a Story Generator, A Pre-life crisis
Hey Readers! #
Forensic Friday is here! Technically 2 days late, and we find ourselves in a more transitional week. Transitioning to what you may ask? Well, we have started to onboard our new developers and change the way we organise and split up tasks, hopefully, all for a serious sprint in January to March, which should hopefully take us from an unplayable non-game to a more gamey game! The main gameplay loop is still in the works but is near to completion. And we are having a Pre-life crisis. Containcorp is no longer a ‘game’ but a story generator!
Changing workflow #
We are about to make a large change in how we approach development as our team begins to grow. Until now, we’ve been very orderly in how features have been added to the game. As you can see on our roadmap, certain features are fully implemented until we start new ones. This used to make sense since the features we were adding were integral to any future work - you can’t do anything without Construction and building!
However, as the project has now matured, we are planning on taking the next step to accelerate our progress. As our team is expanding to at least 4 people we’re planning on working in an “agile” way, where features are split into smaller, atomic tasks. These tasks are then given a score by us (story points), for how long we expect them to take before being added to a backlog. Anyone on the development team can then choose one of these smaller tasks and complete them (varying from a few minutes of work to a couple of days). Jira is the tool that we’re using to keep track of all this.
There are a lot of reasons why this is exciting news. For one, this new way of working is designed so that everyone on the dev team can do whatever they’re most comfortable doing. For example, if someone was very proficient with UI and React, then they’d primarily just do UI tasks, without having to take on the baggage of the whole feature. Another advantage is that burnout will hopefully decrease, as people can jump between multiple tasks on different features. Further advantages include less duplication of code - since working on a larger team means people may not be aware of what other people have done - and also better forecasting for release dates. As we progress through the next month, we’ll see how many story points we’ll get through, and hopefully get better and better at predicting as time goes on!
What this means is that multiple features can be worked on simultaneously, and more efficiently than ever before. It’ll be a new process for most of us - but one that’ll hopefully be worth it!
Completing the Gameplay loop #
Over this week, I’ve been working on completing what is most likely the most important features the game needs. The very backbone of the game rests on these features, thus I think I can excuse myself for taking my sweet time on it! Well, currently the things that are left to do are as follows:
- Fixing outstanding bugs with anomaly transport vessels (not being hauled to the containment cell)
- Experiment Execution
- Experiment Result Handling
- Generating Research Points
Currently, the bug has given me a roadblock, and forced me to take a break and think deeply about… game design! I’ll talk about that in the next section, but for now, selecting regions! That is one of the main features that has been going through the development pipeline.
Well, not only that, I also spent some time thinking, designing and implementing the anomaly menu. A menu which shows all the anomalies on your site.
Quick sneak peak of the anomaly menu, with the classification cube…
I wonder what that weird-looking cube is though? Hmmm. Well, great you asked (I know you didn’t). Introducing the EATS classification cube, a new way for us to classify anomalies. Or at least the way I think the Corporation would classify anomalies! Below is a full breakdown of all the symbols and what they mean. However, I must stress that the names are currently placeholders, and none of them are set in place. A lot of them, it seems, is a bit hard to decipher, so we are going to think of more easily recognisable and sensical names. But for now, here all you lore lovers go:
Hopefully, this extensive diagram gives a good rundown of how the new EATS system works! We are still thinking of things that are yet to change, and of course, nothing is final. The hazard warnings aren’t going anywhere too, so don’t expect this to replace that!
As for why I feel like I needed to come up with this system… I wanted a way to easily communicate an anomaly’s significant attributes on the anomaly menu UI without having to click on the anomaly and see all its stats individually. Hopefully, this system provides a way of communicating the properties of an anomaly (the ones that significantly affect gameplay that is) quickly and easily! We would be open to feedback on the system, and definitely name suggestions!
A Shift in Game Design Focus #
All that out of the way, I thought it would be good to share my thoughts on a change of perspective I had concerning the game design of the… well… the game! One thing we never really thought about was the implications of switching from a game to a story generator. A game is not necessarily the right word to call this product at all! If we want to generate stories, then it informs the design of the product quite significantly, and a game is not necessarily the best way to put it.
The main difference is that a game is designed machine of systems that reward skilled players after completing a series of skill tests. This is coined as play or gameplay. In this framework, mechanics serve to provide compelling gameplay, that leads to a greater and deeper test of skill, and in turn, when a skill test is significantly failed, the game is concluded, and well… time to restart!
However, when you think of a story, a story is a series of events, events that generate emotions in the reader as they get attached to characters within the story going through hardships and challenges. In this framework, a game gets redefined quite significantly. Instead, a game as a story generator would be one where loss is an essential part of the story, not a fixed failure condition which has you restart. In turn, the player is not threatened with losing the game (thus real-like time investment), but instead with the loss of something within the story. So mechanics serve to generate diverse emotions in the characters and create loss and conflict. Highs and lows. Which all leads to an interesting story!
This is all well and good. A design methodology that makes sense, but how does this affect the game? Not significantly actually as it stands, but it justifies a lot of the things we were doing already. One example is the art style. The art style doesn’t need to be complex and super beautiful. Quite the opposite. The art style merely should act as a set of symbols which communicate the story. No different to the typeface of a novel’s prose.
So that’s something we have hit the nail on so far! But one thing that will affect features going forward is how we implement it, and how deeply. Features don’t need to be complex if they don’t contribute to the story generation. Features must serve this fact, our goal is not to make compelling features for gameplay, but for story generation! So we would never make construction deeper with cranes, foundations and such, because it would not necessarily have any greater impact on the story generation aspect.
This backtracks on some of the features we have already. Structural integrity and multiple floors. However one can argue having a whole other dimension to play with can contribute to the story generation aspect. One could imagine a player story where someone falls through the roof into a containment chamber, causing a massive containment breach. So we aren’t going to abandon these features (we are too deep in anyways), and one could look to Dwarf Fortress which does this expertly. They have multiple z-levels, and it only deepens the story generation, so we will very much stick to it.
But what I am trying to say is that we are going to start leaning on the game being a story generator, and having that inform all future design decisions. Which should make the game more streamlined in delivering its most interesting facet! Story generation!
Oh, and we need to add a feature where NPCs remember all the things that have happened to them and make it influence their actions! This preys into Apophenia, which is where the player perceives behaviour/functionality that isn’t implemented. This is a gold mine because it feeds into less is more, and practically makes our game deeper for free! To prey into this, it’s a combination of Abstracted feedback, and long-term relevance which cultivates in this zone of player interpretation we hope to hit.
Anyways, all of these thoughts were inspired by a GDC talk by Tynan Sylvester himself! And got me thinking about what the purpose of the game was and how it should be designed. Now I have a clear eye to which I can guide development towards hopefully a game even just half as good as Rimworld!
I supposed the ultimate aim is to combine the compelling gameplay of Prison Architect (which isn’t a story generator) and the story-generation potential of Rimworld. So in the end it’s a careful balancing act, where we want to be able to generate cool stories, but also appeal to that more gamey side of things.
Anyway, I have probably ranted too long about game design now, but any game developers/designers out there, feel free to watch the talk:
It’s a pretty amazing eye-opener! Thanks Tynan!
Maybe one day you’ll see me at GDC, giving a talk about this game. Hopefully not a post-mortem though (っ °Д °;)っ
Case Closed #
Phew, that was a long one! One filled with perhaps too much game design! But alas, another week, another dollar? (Do we get paid around here?) Well soon. Acquiring a publisher is in the works, and the lovely world of marketing is on its way…sooon.-
But I must file the case and archive, as I do every week. I’ll probably get a pay reduction for filing this case 2 days late but what can you do? In terms of what to expect next week diligent readers (is anyone out there!), I have a few assignments due in the next 2 weeks. So I will be taking an unofficial hiatus to work on these things. This means I can’t guarantee progress, but there likely will be. I am confident the main gameplay loop will be implemented come the 1st of December though! Which is an exciting prospect.
As always, thanks for reading! Ciao.
Case Closed.
The Team
Plasmarc Studios