Articy: Please introduce yourselves and tell us about the team at Angry Goat Games working on Just Another Life.
Mary: We’re a small studio consisting of (currently!) two developers, working on games that we hope will not only entertain but change lives. We believe in our work so much that we decided to quit our comfortable software engineering jobs in big tech last year to go full-time game development – in fact, “Just Another Life” marked the change in our focus from pure entertainment to change and impact through entertainment. And for personal reasons, we released “Just Another Life” as a free game.
As fate would have it, our skills complement each other in such a way that we could produce “Just Another Life” with just the two of us. However, it also meant we had to be very careful with the tools we chose to use – using an inefficient tool could mean months of extra work. In the future, we plan to expand and hire more people – stably so.
Articy: So in “Just Another Life” players get to help “John Doe” live his life in the town of “Hope” where funnily enough the residents don’t actually have high hopes for their future. We’d love to know the story behind the game story. How did the team come up with it?
Mary: We came up with the core idea during the politically charged time preceding the 2020 election. To be honest, the game had developed far differently from our original conception. However, the core idea is still the same.
During 2020, especially preceding the 2020 election, there were many problems going on. Many people were angry, afraid, worried, and overwhelmed. Mental health took a horrible downturn, and in many ways, the effects are still here today. At the same time though, blaming it all on Covid, the election, etc. is a bit like blaming a financial problem for divorce. All these external factors only serve to bring out the internal discontentment that already existed.
Thus, “Just Another Life” was born. At the beginning of the game, John is just another life. However, as the game progresses, as he overcomes his own internal struggles, he brings his internal contentment out into the world, changing not just his own life but the lives of those around him as well. And he does this not by transforming situations but by transforming hearts, changing his “just another life” into an extraordinary life.
Articy: In this narrative-driven “life simulation” it is up to the players to decide whether they will help John put his life back together or give up on him. How much do the player choices influence the flow of the story?
Mary: In a typical narrative game, choices are usually presented as dialogue options. In “Just Another Life,” choices are presented as reactions to gaming instincts, and so the choices are intimately connected to the player’s character – it’s closer to what players would likely do rather than what players want to do as in the case of dialogue options.
For example, gamer rage is actually harnessed in the game. A player’s response to their own rage will influence the gameplay as well as the story.
There are three endings for the game, reflecting real life:
1. The player makes decisions which help John in a positive way, resulting in a good ending.
2. The player makes bad decisions and has to deal with the aftermath of those decisions affecting the gameplay.
3. The player gives up on finishing the game because they make too many bad decisions and don’t know how to recover from them all. Of course, we have designed the game such that the player can always recover, but the choice to do so or give up is dependent on the player.
Articy: At which point in development did you decide you need to use a professional tool and what made you opt for articy:draft?
Billy: From the very beginning. We knew we wanted our game to be heavily dialogue and story-driven, and from the start we wanted to use a tool which would allow us to draft our story end-to-end, refine it by iterating on details and dialogue, and integrate the entire dialogue directly into our game engine code. Since we are a small team of 2 people, the ability of the tool to do all three of these things as efficiently and easily as possible was extremely important to us.
We actually looked into a few different tools to get this job done. The tools we looked at were either not built with massive amounts of dialogue in mind, targeted towards other forms of media other than games, or didn’t have good Unity integration.
Articy was the only tool we found that checked all of our boxes. Articy:draft allowed us to split development between 1 team member working in Articy:draft writing the story and dialogue, and the other team member working inside Unity to integrate the Articy project with the game code. Additionally, the Articy:draft Unity plugin was a killer feature that made exporting our massive dialogue tree into Unity possible. Without the Unity plugin, we would have had to build a lot more infrastructure to pull the story into Unity – fortunately, Articy built it for us!
Articy: What kind of impact did articy:draft have on your development process?
Billy: Being a team of two people, we had to be extremely cautious about where we spent our time. Since handling the story was done completely through Articy, and the coding done completely in Unity, at the end of the day we were able to just export the Articy:draft file into Unity and hit “play” to test our changes without colliding into each other too much.
One of the best features about Articy for us was its Unity plugin. Not only does it handle all the hard work of importing an Articy exports file, it also makes global variable handling super simple. We were able to access global variables from our Articy:draft dialogue trees directly in code in Unity. We were also able to update Articy:draft variables directly from within Unity C# code, allowing us to programmatically influence the direction of the dialogue trees from within Unity. After experimenting with this plugin for a while, we chose to make it standard practice that all story-based global variables in our game would reside completely inside Articy:draft and not within Unity. This clean separation made it a lot easier to debug (all we had to do to see the state of the entire game was to inspect the Articy:draft global variables). This also made save games super simple: we just write out the state of every global variable from Articy:draft to disk and the game is effectively saved.
We also chose to build our own dialogue system (UI, flow control, etc) in Unity using the Articy:draft plugin, but we have noticed that there are great third-party dialogue systems on the Unity asset store that have Articy:draft integration, so we may look into those in the future. Since we have already invested so much time into learning Articy:draft, it will be easier for us to adopt third-party Unity packages that support Articy.
Articy: What features of articy:draft did you use the most and how?
Billy: On the Articy:draft side, we definitely used the Flow and Global Variables features the most. Because we knew we wanted to direct the flow of our dialogue from within Unity programmatically, we decided to create a single dialogue element for every character. Within that dialogue element we have dozens of sub-dialogue elements that are chosen based on the state of global variables. In Unity, this allowed us to direct the Articy flow player into a character’s single dialogue element whenever the player would talk to that NPC in-game. Then we let Articy pick which paths to take based on the global variable state and just let the Flow player in Unity “play” through the dialogue until finish. Once a conversation is finished, the global variables are updated within Articy to account for that. This method turned out to be extremely useful for our type of game.
Another unexpected feature we used was the ability to clone the Articy:draft global variable within Unity during game execution. This was important when we were trying to find a way to indicate new dialogue with a glowing symbol above an NPC’s head. In our project, we often update global variables inside our Articy dialogue tree as we walk down a path. A simple example could be a counter variable designed to keep track of how many times a character’s dialogue has been played. In order to determine if the character has new dialogue or not, it required us to walk through the dialogue tree, but we also didn’t want to actually have Articy update the global counters as we walked the tree! What we were able to do was create a clone of the global variables on the Unity side, then use that clone to walk down the dialogue. After walking through the dialogue, we are able to discard the cloned global variables, effectively ignoring any variables updates done by walking the Articy tree. We were also able to compare the cloned global variables to the real global variables to see how the game state would have changed if we walked down a certain dialogue path. This was all coded up in Unity with Articy:draft’s Unity plugin and didn’t require modifying the plugin at all.
In the early stage of our project, we also utilized the Articy:draft’s Document feature. We would draft up the dialogue in a Document, which basically looks like a movie script. After we were satisfied, we just exported the Document elements to the Flow (individual dialogues and dialogue fragments) section of Articy:draft. This was easier than writing things in a Google doc and copy-pasting all the time.
Articy: If you were to give a small piece of wisdom to a new studio, what would that be?
Billy: Don’t do everything yourself! Find a few good tools that get the job done and consider paying for them if you are able to. As a small team you will not have time to focus on coding your own tools/systems when there are industry standard solutions already out there. Articy:draft is one such tool, especially if you are working on a dialogue-heavy system. There are also some Unity Asset store tools, such as the Dialogue System asset, that are worth it and will save you tons of time. Any of the best ones all have Articy:draft integration that comes with them. Also make sure to flesh out your story as completely as possible in a way that can be integrated easily into your game engine – it saves a lot of headache in the future. Don’t invest too much time in the beginning figuring out the details of your story/game logic since that will change during development – instead focus on the story and the big arks, and do so in a way that makes experimenting within your game easy. Once you have the big arks down, get more detailed. This will let you iterate quickly which will be way more important for your development.
“Just Another Life” is available
Free On SteamIf you loved the soundtrack, find it on Soundcloud
