At last year's TGA Awards, the co-op adventure game "Two-Player Trip" won the Game of the Year award. While the game's variety of gameplay and mechanics has stunned the game circle, it has also made peers curious, how did the development team perfectly integrate multiple game mechanics into a game?
At the 2022 N.GAME NetEase Game Developer Summit held by NetEase on the 18th, Filip Coulianos, founder and game director of Keepsake games and the main planner of "Two-Player Trip", shared the team's design and development concept for such multiplayer cooperative games.
The following is a transcript of Filip Coulianos' speech:
Hello everyone, my name is Filip Coulianos. Keepsake Games, founded by me and a few old friends, is a game company from Stockholm, Sweden. Today I want to talk about the development team's experience in making "Two-Player Trip", and I will introduce how the development team can effectively collaborate from the perspective of planning to better integrate a variety of gameplay and mechanics into the game.
First, I'll introduce the background to the birth of Duo Trip and share some of the techniques behind game development. Finally, I will use a design case to detail the creation process of part of "Two-Person Trip".
So let's talk about the background first. The studio responsible for developing The Two-Man Trip is Hazelight, who is also in Stockholm. Hazelight was founded about 8 years ago, and the first game the studio made was called A WAY OUT, which was a two-player co-op game like Two-Player Trip. Its unique selling point is that it requires the cooperation of multiple players to complete the game.
After the game was released, we found that players liked this multiplayer co-op mode very much, and the game stood out. Thanks to the positive feedback from players, the development team followed this pattern in "Two-Player Trip".
The process of developing Escape Day actually has many points to learn from, for example, Escape Day is a multiplayer game, which requires players to play with friends. In addition, we also support the network cooperation model, which is a relatively big technical challenge, and the same is true of "Two-Person Trip".
And both games use split-screen displays, and both are linear narratives, the former is a story about two criminals escaping from prison and revenge, mainly around the protagonist's revenge to lock them up, which is a linear story similar to the movie. "Two-Player Trip" also inherits this narrative mode, so both games are linear, telling a story from beginning to end. However, "Double Trip" is more diverse in terms of gameplay, you may not have noticed, but in fact, the new gameplay accounts for a large part of the game.
I emphasize this point separately because from a technical point of view, "Escape" and "Double Trip" have many similarities at the technical level. In the final stage of the development of "Escape Day", the program team encountered a relatively large problem, and their speed could not keep up with the development requirements, because there were many types of gameplay of "Escape Day", including shooting battles, drag racing chases, etc., and many unique gameplay methods were made only once.
Moreover, the design team is constantly modifying the needs and often changing the design direction, which makes it difficult to carry out the program development work efficiently. So the team set out to develop something new.
Both Escape and Twins were developed in Unreal Engine 4 (UE4), and the team in charge of the program created a plugin that allowed UE4 to write the AngelScript scripting language as a quick scripting layer between C++ and the Blueprint Editor. This allows the development team to quickly program in a scripting language, modify the script and save the script while the game is running, and the changes will immediately appear on the screen. This feature is amazing and very reliable.
This thing also caught the attention of me and the design team, and this scripting language seems very useful. Personally, I've taught myself programming before and done mod and indie game development, so I think AngelScript scripting is useful not only for programmers, but also for designers, and can help us prototype gameplay. I feel like most of the people on the team should be interested, at least I'm interested.
In the early stages of the development of "Two-Person Trip", the program colleagues will give us the basics of popular science script programming, teach us how to program, how to use this magical tool. So from the early stages, AngelScript was integrated into our prototyping phase.
In the early days of the development of "Two-Man Trip", when the design was not yet formed, we would try various ways to play and did not care too much about feasibility. Instead, focus on whether this co-op gameplay is fun or not. We then use AngelScript to write out our own ideas to exercise our ability to use tools. By shaping various ways of playing and trying to express various ideas, we begin to understand the fun points of the game, and the game gradually takes shape.
That's when we realized that those scripting system prototypes allowed our designers to be involved in the development of gameplay throughout the process. Usually, the designer can make a small prototype at most, and then give the rest of the program development, during which there will inevitably be a handover. But now we don't have to, it's a huge turnaround. Because this means that the person who came up with the idea can participate in the whole process from the idea to the landing process.
Another important advantage is that the programmer in charge of the gameplay and the colleague in charge of the design of the level use the same set of tools. This change is also very good, now the level design team can design while programming, the professional boundaries of designers and programmers have become more blurred, and everyone has become the person responsible for the idea, while conceiving and realizing.
I think it's a great change. Usually everyone has a specific distinction, and then they work around their own field, for example, I am an animator, and I don't think about non-animation things. When this consideration becomes blurred, everyone thinks about the user experience. So I think this change is very beneficial.
So what has become of our workflow? We can use an example to illustrate from start to finish how we used AngelScript to assist in the development of the two-person process.
Start with a storyboard. We'll make a storyboard that provides background information for the entire game. The storyboard focuses on the storyline, rather than focusing on the specific gameplay and level design, mainly about the background setting of the game.
We will divide the story into several chapters, using "Ross's Room Dinosaur Paradise" as an example. According to the progress of the game, at this time, the player or the character in the game has not yet reconciled, and has not yet adapted to this wonderful world after the body is reduced. So our idea in the early stage of the game is to keep the level unchanged while adding some new gameplay to make players get used to the operation.
Referring to the setting of the storyboard, we know that Rose's room is a dollhouse, so what will be fun about the dollhouse? We thought about various themes and then thought of toy dinosaurs. This is a very common toy that everyone loves. Then we brainstormed around dinosaurs, and I remember mentioning a lot about the long-necked Thundersaurus.
And, from the story's point of view, we've established the initial idea: a toy train runs through the room while the player rides the train through the levels. During this time, the train tracks will be blocked by various things, and the player will need to remove the obstacles to continue. We thought how cool it would be to be able to use this long-necked dinosaur to clear the track and remove debris, which were some of the ideas that were thrown out randomly at the beginning.
Of course, another key point is that one of the things that's very important for multiplayer co-op games is that we noticed during the prototype phase that if one player has a unique ability, such as controlling a giraffe, then the other player needs something to do as well. Then I wondered if I could get another little dinosaur and have it go on a rampage, push things up and flip them over so that both players had something to do.
Of course, this stage is still just a casual idea, but then we will immediately start to make prototypes. I would sit down with a programmer and divide the work. I make one of the dinosaurs and he makes the other, and it only takes two people to do it.
Another feature of games like ours is that almost every level has a unique gameplay. We had to limit the time spent on each module and schedule it strictly. Because when you're making gameplay from scratch, it's easy to spend weeks exploring what this giraffe dinosaur could do. But we have to make sure that time is spent on the cutting edge and there is no time for trial and error. So we have a weekly schedule, something to accomplish this week. It actually took us only a few weeks to make this whole scene.
The next step was to start landing, and given the time constraints, we realized that to significantly limit the scope of development, we had to make the functionality simple enough. If the long-necked dinosaur could walk around and move things elsewhere at will, it would be a huge technical challenge. So we decided to limit it to 2D plane movement, so that the amount of development becomes controllable. For players, the picture will be more readable and easier to operate.
After identifying these simplifications, we began to evaluate another small dinosaur that flipped over objects. We realized that having this dinosaur move around would also be a problem, so we limited it. This dinosaur can only move on a 2D plane.
By this time, we already had some technical implementation ideas. The next difficulty is that the development time is too small, we don't even have time to add a jump or other skills to the baby dinosaur, it can only move back and forth on the track, and the collision action is more difficult to do. So we decided to replace it with a ground collision, and when we hit the ground, the obstacles would be thrown up, and finally it started to progress a little.
A week went by, we were programming, assembling the various modules and getting a rough level that we could use for testing. We also realized that some icing on the cake was needed to make some extra improvements to the co-op gameplay so that the two dinosaurs could have a complementary relationship —the big dinosaur could remove objects and help the small dinosaur advance.
But we added a highlight that allowed the big dinosaurs to grab certain objects and prevent them from being lifted off. In this way, I as a designer can add some interesting decryption elements, because the big dinosaur can control the state of the obstacle, and it needs to cooperate with the small dinosaur, that is, the communication between the player.
After perfecting these designs, the whole idea looks good. We started putting it into reality, making a small scene that put together the levels and creative gameplay. From the designer's point of view, the follow-up is some standard routine. Start with instruction, let the player operate the first dinosaur, and help another player get the second dinosaur. The second dinosaur is responsible for hitting the ground. Once the player understands, the difficulty is increased step by step.
When these scenarios are made and the gameplay feels good, we start to invite players to test them. We'll ask people outside of the studio to play it and then see how they react to the level.
What we focus on is whether they understand the process we designed and whether they understand the gameplay. Through the trial, we will find some places that need to be guided, such as the camera should be shifted a little, the screen should be prompted, the corresponding operation of the buttons should be displayed, etc., but in general, the level feels very good.
So based on this "early" feedback — and I want to emphasize that it was in the early days — we mainly look at whether the player understands the gameplay, but doesn't pay much attention to whether they find it interesting, and then we continue to think about the story setting: how the player gets to this level, the cutscenes, and so on, which happen along the way, to provide the background for the gameplay, to make it fit into the whole story.
Throughout the process, there are a few things that I am particularly pleased with. The first is that I can work with the program, we use the same tools, and the efficiency is greatly improved; the other thing is that I can keep pace with the development process from the initial idea to the final finished product, which is also a huge benefit. Of course, some specific systems need to be left to the program to do, because the logic is more complicated. But tools allow designers to be involved, and I think this new process is great.
You might be thinking: That's a big risk, right? You're a level designer who was originally only responsible for the level, and then suddenly attached so many other responsibilities to you, in addition to the level design, there are also gameplay, programming, etc., is this not risky? I admit there is. But a game like this one needs to break the mold in order to be successful.
For me I have a credo: if you go to the gym every day and only maintain the same intensity of training, you won't be able to reach your full potential. So I think one of the things that's special about this new process is that it takes everybody out of their comfort zone a little bit and allows them to reach more of their potential.
As a leader, I naturally do the same, seeing the team put their heart and soul into their work and everyone growing in the process. Everyone took the work as their own business and worked hard to improve themselves, during which the team gained a lot of practical experience.
Finally, there is the problem of simplifying the gameplay that I just mentioned. By limiting the scope and simplifying the functionality, this also brings two benefits - the first is development time, we don't have a lot of time for each play, and the other is that it is easier to communicate after the gameplay is simpler. After all, if the game only needs to press one button, it becomes easier to teach the player, so this is also a good added role.