Introduction

Beyond Me is a story-heavy RPG game consisting of various visual genres. The player will act as a character in three different stories, one being created in another -- to make it simple, it is a game inside a game that is inside another game. Besides being contained by one another, the three sub-stories are similar in size, together telling a story about loneliness and loss.

The artistic concept of the game is discussed in this post.

Production management

The overall management of the development is what we did very well in this project. Besides the lack of the main menu and a meta style ending, we managed to make everything that was previously in our plan.

Throughout the development process, we used a timeline to track the progress and plan out versions. Four to five versions were done for each chapter, and we have playtested each version by ourselves. Dividing a big task into smaller ones and putting them into a checklist also helped to narrow down the collaboration a lot.

We also spent a long time in online meetings. Among 42 meetings in 23 days, we not only shared skills that we have with other group members (e.g. Alex helping Will with his self-made dialogue sequencer, Cecil helping Alex with Cinemachine skills, Will helps Nicky with expressive screenwriting, etc.), but also actively maintained good chemistry in our group. Although we are all working on different scenes, we all felt very engaged in the group and familiar with other group member’s development. After each meeting, Nicky recorded down a brief note about what happened in that meeting for future use.

For detailed development process documentation, each of us has written our own chapters below.

Chapter 1 Development  |  by Will Piao

I started off by making a general outline on a google doc. Once the outline is made I transferred to twine, in which I can map out the flow of the story as well as the different paths. 

Most of the changes to the story were made in this stage. The original narrative differs greatly from the final, and for time’s and narrative’s sake, many things were cut. The most time-consuming part would be the code. Transferring all the dialogue into the dialogue script took quite a substantial amount of time. According to how the story should flow I have to playtest and go back to decide if each line should be independent or grouped together with each other. 

The text sequencer is developed by Alex. I edited it so that it is controlled by buttons so that choices can be made between the different scenes. On top of that, I added 1000 lines of code for the different effects, the battle scripts, and also what happens in each individual scene. There are a total of 46 scenes, so many times issues will arise and they have to be nitpicked out of a sea of code. The battle script is something very new to me. All the movements and conditions need to be hardcoded. But the end result achieved the effect that I was looking for.

Lastly, particle effects were the easiest to create, but sometimes there are certain issues with how they appear. If the particles are attached to a moving object, it will cause the particles to stretch. Apparently, there is no real fix to this issue. The particles remain for now, but if the issue persists, it might be taken out of the final build. Overall, I think the particle effects turned out great. This is the first time I used text as particles, but I managed to make it look natural enough for specific cases. 

Chapter 2 Development  |  by Nicky Du and Alex Wang

Part 1: Overview  |  by Nicky Du

Before Alex went into the Unity editor, Nicky wrote a brief version of the plot. This original piece is very different from the final story, since it has been changed several times (e.g. In the final version, the main character is not the author of Chapter One anymore, but he rewrote the ending of it.).

At the beginning of the programming process, Alex made a 2D player controller with 8-direction movement driven by the default physics engine. Nicky designed the layout of the three main scenes, and Alex traced the scenes in unity using solid color colliders. Since we have never worked on a dialogue-intensive game before, we also planned out how to present dialogues smoothly, with animations, camera movements, and audio in between. Alex wrote a simple white-boxed version of the dialogue sequencer, which will be optimized afterward. That wraps up the first version.

The second version includes a re-written, modular-designed iteration of the dialogue sequencer. While Alex was working on the programming, Nicky wrote the corresponding dialogues and cut scenes in a table.

After the dialogues are ready, in the third version, Alex programmed out the in-game interactions, including scene transitions, camera movements, object selections and so on. He also changed the force-based movement of the main character into grid-based movement, just like the old fashioned way. Nicky drew all the pixel sprites to fill up the three scenes.

In the final version of the chapter, we managed to add in some between-scenes cuts, including a monologue on the train and in the taxi, to inform the player better about the relationship between Elliot and his father. We also added up many UI elements, and detailed animations such as sobbing, calling and car driving. To wrap up the version, we put royalty-free audios into the game, and made a test-run with the other two chapters roughly merged.

Part 2:  Programming  |  by Alex Wang

In terms of logic construction, The soul of programming in Chapter 2 is the creation of an “Event Sequencer”. I aim to make a sequencer that is: 1. Easily to modify, 2. Have the ability to undergo parallel editions, where I work on the code while my co-worker edits the dialogue on the fly. 3. Easily to expend the functionality associated with each action. 

To introduce modularity to my design, I incorporated the application of custom classes. I defined the basic logic unit of this chapter: “Sentence”. Inside each sentence class contains 3 pieces of data: 

1. The Topic of the sentence or dialogue; 

2. The content of the sentence;

3. The Action that is associated with this sentence (By default it would be executed before its sentence starts to show up on the screen, but it can also be modified to perform vice-versa). 

This class is then shared by two lists: 

1. The main plot list I called it All_Chapter. It is an event container that players have to go through. 

2. The side plot that I called All_Conversation. Just like the All_Chapter, it contains dialogue, but it also stores the interactive object name, and the player can choose to interact with them or not. I make them stand-alone with each other because they are looped differently.

Finally, they all belong to another class - Dialogue_Event. This class is not derived from mono_Behavior to make it act purely as an information container. 

Each of the sentences has an index, and the index will increase by one until all the sentences have been looped through. A text type is responsible to show the characters on screen one by one, and an event caller will trigger the linked event prior to or after the typing animation depending on some tweak of parameters if the event is not Null.

The logic is basically set up well, and the order of execution is controlled by a state machine. Every game object in this game has different states. For example, the player has Move and Stop states; the dialogue sequencer has typing_Conversation, typing_Plot, and Idle states. Etc. It will make sure that player movement is disabled while certain events are executing; players will have to finish some specific side events to continue the main plot. The Escape key will only show up after the Camera finishes zooming... The game will run in perfect order, all the states, texts, and actions are not entangled which makes this game easily embrace future developments and adjustments.

Chapter 3 Development  |  by Cecil Boey

I started the very chapter itself by composing a script to it. The script is much more crucial and valuable than it may seem. Our game is built upon the nature of storytelling, but with very distinct realities within each of the chapters. I have to ensure the consistency and logic over the character’s choices and progressions while highlighting a very distinct storytelling of a new status-quo. Not only does the above has to be considered, the scripts contribute heavily to the manifestation and rendering of the environment and interactions built around the player for a believable, progressive, and a *not-out-of-place” experience. Thus, after careful discussions and alterations to the script between both Nicky and myself, the script is finalized to be on an off-course spaceship with four major segments to the explorable rooms: P’s room, hibernation hall, the cockpit, and the airlock, rather than an enormous abandoned space colony on an exo-planet. 

I took inspirations from images of the ISS, or International Space Station, for reference to create a more coherent cognition of the technicality of space stations for a fedile environment, but also it acts as a crucial architectural framework for my own creative approach on the composition that can invoke an environment that embeds claustrophobic and hopeless feedbacks, which are essential to the narrative. Therefore, I started modelling a space station with modular geography that not only does indicate where the player is with more clarity, but also acts as an effective tool for map guidings without extensive UIs. I also designed the geography of the station with extreme differentiations in the axis orientation, for the player starts off in their room with the default x-axis in perspective for the horizon, but will immediately enter the hibernation hall that is constructed perpendicular top the room in its y-axis, that not only impose visual shock to the players, but it also acts as an essential element that can  inform the players to their zero-G settings. 

Further details are added into the scene for environmental fidelity, and to also further complement to the game’s narratives with visual storytelling elements, such as that P’s room is contemplated with disorganization to indicate his lifestyle variations over the decades of solitude.

Timeline plays a very dominant and extremely efficient and effective role in this chapter. The best way to put it would be that Timeline is just like a Premiere Pro plugin for Unity. Although efficient to use, I have to carefully orchestrate the cutscene lengths, that must also go correspondent to its animations, which then must complement the sequencing and duration of the monologues; while all these must also be articulated to ensure the scenes are sincere and organic. The subtitle tracks are achieved with scripts to enable Premiere-like editing capability.

Lightings to bring the entire scene to life. 

Informative sprites made by Will. These sprites are carefully placed into the scene with high resolution to ensure their visibility to the players without the need to actively interact into the cutscenes to be able to interpret the information. All cutscenes are optional except the final cockpit cutscene that will enable the transition to the final scene. The cockpit is the only cutscene with all information necessary for the narrative to ensure the integrity of the game even if the players decide to skip all the optional cutscenes.

Reflection  |  by Nicky Du

This project is easily the biggest project we have ever done. Instead of making a game of normal scale like our previous ones, we decided to move out of our comfort zone, and make something that’s actually different. This is also because we want to have one game in our portfolios that is truly massive and impressive.

However, the scale of this project has also exposed some problems that we didn’t have on the previous projects. We started off with Unity Collab first, and after it crashed we moved to GitKraken. But at the time we were introduced to GitKraken, the project is already very big, and we have to test the scene merge in the most time-consuming way -- sending Unity packages. Because of the complexity of HDRP scenes, loading and debugging took such a long time that our final version got delayed into the 3-day buffer zone. When test-building the merged scenes, many unknown errors that kept stopping us from making a Windows build have taken us a lot of time to resolve. Because of these two accidents, we ran out of time even in our buffer zone and were not able to polish the whole playable loop.

With all that being said, we are still happy to have a lot of things that we had never done before in Beyond Me: Transitions between scenes, well-directed cut scenes, intensive writings, and the most important of all, a unique and meaningful storyline. We all believe that this game, once completed and polished, will have very high artistic value. This belief leads to our plans for development in the future:

1. Finish making the playable loop, including the menu, pause menu, level selection, local savings, meta ending, options menu, and a credits page;
2. Polish each scene, including debugging, extensive sound design, more cut scenes, and (maybe) branches on the storyline;
3. Adding more visualizations to Chapter 1, including monotone pixel illustrations;
4. Giving more free-to-explore time to the player in Chapter 2;
5. Optimize the UI in Chapter 3.

We hope that as our development continues, Beyond Me will get more recognition and be appreciated by the community.