On April 18-21, the 2022 N.GAME NetEase Game Developer Summit held by NetEase Interactive Entertainment Learning and Development was held online.
At the 2022 N.GAME, more than 50 guests from home and abroad participated in the sharing, including but not limited to Fillip Coulianos, the chief curator of the 2021 TGA annual game "Two-Player Trip", the producer of the "Rulong" and "Eye of Judgment" series named Yue Minoru, the producer of "Ace Racing" Jiang Yuyuan, and the main designer of "Endless Lagrange" Zhao Zhentao.
The agenda of the summit also revolves around different topics, including creative trends, technology-driven, artistic polishing, value exploration and other topics.
Under the theme of "Creative Trends" on April 18, the main planners of "Two-Man Trip" shared their experiences in developing this game of the year, including how they used scripts to achieve game design and programming to work together, and how to integrate gameplay and story, and finally landed.
In order to optimize the reading experience, the mobile game has deleted the content shared, and the following is the full text of the speech:
Hello everyone, my name is Filip Coulianos from a studio called Keepsake Games in Stockholm, Sweden. The studio was newly created with a few old friends, and we're currently working on a brand new sci-fi co-op adventure game that's worth looking forward to, but not what we're going to talk about today.
Today I'm going to talk about my experience in developing "Two-Person Trip", and I will introduce how I and the design team collaborated from the perspective of planning, and landed these various ways of playing and mechanics.
First, I will introduce the background of the birth of "Two-Person Trip", then some technical sharing in the production process, and finally, I will introduce the creation process in some games in combination with design cases.
So let's start at the beginning. About 8 years ago, Hazelight Studios, the developer of Trip for Two, was founded in Stockholm, Sweden. At that time, we were making a game called Escape, which was also a two-player cooperative game.
The special thing about Escape is that it requires the cooperation of multiple players to complete the level. After the game was released, it was also loved by players. It is also the appreciation of players that makes this game stand out. So "Two-Person Trip" follows the point of multi-person cooperation.
In the process of developing "Escape", there are actually many points that can be learned. Because Escape is a multiplayer game that must be played with friends, we also support the online co-op model, which is a technical challenge, and the same is true of "Two-Player Trip".
Moreover, both games are split-screen displays, both of which are linear narratives. The former is a story about two criminals escaping from prison and taking revenge because they want revenge on the people who put them in, so it's a very linear story with a narrative approach closer to the film. "Two-Person Trip" also inherits this narrative mode, so both games are linear, telling a story from beginning to end.
But "Two-Player Trip" has more tricks in terms of gameplay, you may not realize it, but the new gameplay does account for a large proportion. I emphasize this point alone because from a technical point of view, "Escape" and "Double Trip" have many similarities.
In the final stage of the development of "Escape Day", the program team encountered a relatively large problem and found that their speed could not keep up with the development needs, because there were many types of gameplay of "Escape Day", including shooting battles, drag racing chases, and many unique gameplay, but they could only be used once.
Moreover, the design team is constantly modifying the needs and changing the design direction frequently, which makes it difficult for the program to work at high speed. So they set out to develop something new, and they supported angelScript scripting language in Unreal Engine (UE4), which is the engine used in both Escape and Two-Person Journey.
Our program made a plugin that is actually a quick scripting layer between C++ and the Blueprint Editor so that AngelScript can be written in UE4. This is very interesting because we can do fast programming in a scripting language. While the game is running, modify the script and save it, and the modified content will appear on the screen immediately, and the feedback is very immediate.
This feature is great and very reliable.
Of course, this incident also caught the attention of me and the design team, and this scripting language is very useful. Personally, I taught myself to program in order to develop indie games. But I think AngelScript scripts are useful not only for programmers, but also for designers, and can help us prototype gameplay.
I feel like half the team should be interested in the script, at least I'm going to use it.
So 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 AngelScript was incorporated into our prototype stage process very early on.
In the early days of the development of The Two-Man Trip, the design was not yet formed, and we didn't know what the game would look like, so we would sit down and try out various ways of playing, not caring too much about the feasibility, but focusing on whether the cooperative play was interesting or not.
Then, we will use AngelScript to write out ideas, as a practice of exercising ourselves to use tools, by shaping various ways of playing, trying to express various ideas, we begin to understand the fun of the game, and the story of the game gradually takes shape.
That's when we realized that those scripting system prototypes allowed designers to participate in the development of gameplay throughout the process.
Usually, the designer makes a small prototype at most and then gives the rest of the program development. This handover process could not be avoided, but now we can not do it, which is a huge turning point. Because this means that the people who come up with this idea can participate from idea to landing.
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. The change is also very good, we are the level design team. But now, we can design while programming. The boundaries between designer and programming professions have blurred. Everyone becomes the person responsible for the idea, and the idea is realized.
I think it's a great change. Because usually everyone has a specific title, and then they work around some kind of boundary.
For example, I'm an animator and I don't think about non-animated 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? Here's an example of how we review our creative process from start to finish.
First of all, the game's story background. We'll do a framework background to inform the whole game. At this time, our focus is on the storyline, less on the specific gameplay and level design, mainly about the background setting and story.
Stories are usually divided into chapters, and here we look at one of the cases, "Ross's Room · Dinosaur Paradise". Depending on the progress of the game, the player at this time, or the character in the game, has not yet reconciled, and has not yet adapted to this wonderful world where the body is reduced.
So our idea in the early stage of the game is to keep the level unchanged, but add new gameplay, let players get used to the operation, and add some other content.
Referring to the setting of the story background, 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. It's a very common toy and everyone loves it. Then we brainstormed around dinosaurs, and I remember mentioning a lot about the long-necked Thundersaurus.
And, from a narrative point of view, we've set a toy train through the room, and the player will ride the train through the levels, at which point the train tracks will be blocked by various things, removing the obstacles to move on.
We thought, can we use this long-necked dinosaur to clear the track and remove the debris?
Then there's another key point, which is very important for multiplayer co-op games, which is that if one player has a special ability, then the other also needs to be engaged. Specific to the game, where one person controls the giraffe, the other player needs something to do.
Then we thought about whether we could make another little dinosaur and let it rampage, put things up and flip things 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 work together. I make one of the dinosaurs and he makes the other, and that's it, it only takes two people.
Another feature of "Two-Player Trip" is that almost every level has a unique gameplay. We had to limit the time each module took and have to schedule it strictly. Because when you're making gameplay from scratch, it's easy to spend weeks exploring what this giraffe dinosaur can 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 there's a weekly schedule, something to accomplish this week. It actually took us only a few weeks to make the whole scene, and the next step was to start landing.
Considering the time constraints, we realized that to significantly limit the scope of development, we must 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 say, OK, the object can only move in the 2D plane, so the amount of development becomes controllable. For players, the picture will be more readable and the operation will be easier.
After identifying these simplifications, we began to evaluate another small dinosaur that flipped over objects. We realized that having the dinosaur move around would also pose a problem, so we also restricted the dinosaur to move only on the 2D plane.
By this time, we already had some technical implementation ideas. The next difficulty is that there is really too little development time. We don't even have time to add a jump or something like that to the baby dinosaur, it can only move back and forth above the track.
And the head-on action is also more difficult to do. So we decided to replace it with a ground collision, where the obstacle would fly when it hit the ground. That's finally starting to progress a bit.
By this time a week had passed, and we had assembled the various modules during the programming process and got a rough level that we could test. We also realized that some icing on the cake was needed to make some extra improvements to the co-op gameplay and make the two dinosaurs feel complementary. Large dinosaurs can remove objects and help small dinosaurs advance.
So we added some highlight designs so that large dinosaurs could grasp certain objects and prevent them from being lifted over. 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, which requires communication between the players.
After perfecting these designs, the whole idea looks good. We started to make it all happen, making this little scene, putting together the levels and the gameplay we had come up with.
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. After the player learns this, increase the difficulty step by step.
When these scenes are made, and then the gameplay feels good, we feel that there is no problem, and we will start the player test. Invite someone outside of the studio to try it out and then watch how they react to the level.
What we focus on is whether they understand the process we designed and whether they understand the gameplay. By playing it out, we will find some places where we need to supplement the boot. For example, the lens should be offset a little, the screen should be prompted, and the corresponding operation of the button should be displayed, but in general, the level feels good.
In the early stages, we were more concerned with whether the player understood the gameplay than with whether the player would find the game interesting. When the player understands the gameplay, we continue to think about the story setting: how the player got to the level, the cutscenes, and so on, which will happen along the way. Enrich the gameplay and integrate the gameplay into the whole story.
Throughout the process, there are a few things that I am particularly pleased with and feel particularly good about.
The first is: I sit and work with the program, we use the same tools, and the efficiency is greatly improved. Another thing is that I can stay in control 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 because the logic is more complex, but I think the new process is great, and the tools we mentioned earlier allow designers to be involved.
You might be thinking, that's a big risk, right? Isn't it risky that you, a level designer, were originally only responsible for the level, and then suddenly gave you so many other responsibilities, in addition to the level design, there are also gameplay, programming, etc.? I also admit that there is. But a game like this one needs to break the mold in order to be successful.
I have a credo: if you go to the gym every day and only practice the same weight, you won't reach your full potential. So I think one of the better things about this process is to get everyone out of their comfort zone a little bit and let everyone reach more potential.
And so did I as a leader, seeing the team put it all in the work and everyone growing in the process. Everyone regards work as their own business, strives to improve themselves, and gained a lot of practical experience in the hands.
Finally, there's the issue of simplifying gameplay that I just mentioned, which also has two benefits by limiting the scope and simplifying functionality – the first is development time, which we don't have a lot of time to give to each play. Another benefit that few people mention is that after the gameplay is simpler, it is easier to communicate. If you only need to press a button, it becomes easy to teach the player, so this is also a good superposition.
I'll stop there, thank you for listening.
Q&A finishing
Question 1: How do you assess the difficulty of a level?
The evaluation of difficulty depends more on the feedback and suggestions of players, of course, from a statistical point of view.
For example, if you're a game that's already online, with thousands of players, or just a small percentage of people being invited to do a qualitative test, you're sitting behind the subjects and watching them do.
Of course it's important to decide what you want, is it easy or difficult? Whether the measure of difficulty is uniform in the team will make the assessment of difficulty easier to achieve.
Of course, some difficulty standards must also be appropriately set, such as in platform games, players who fall off the platform are even failures. If we wanted the game to be a little harder, we could set the player to die at most twice per challenge. At this time, the team needs to negotiate to determine a standard parameter, and then the implementation of the evaluation will be very simple. Because you only have to watch the player's reaction, if he keeps failing in a certain level, you have to think about whether the level is too difficult, or whether only this player finds it difficult. Then you have to think about whether this player can represent your target audience.
There are some different steps, such as puzzle levels. In this kind of puzzle solving game, you need to consider the situation where the player is overwhelmed, at this time, how long can the game give the player the most time to think? If it's too long, it's too hard.
So to sum up, first develop a difficulty standard that is acceptable within the team, then let the player test to see if the difficulty is in line with expectations, and then keep increasing to make the game closer to your expectations.
Question 2: What do you think is the key point of multi-person cooperation?
It's "cooperation" or "collaboration," of course.
This is very important for the player's gaming experience, as the person who designed the game, you have to give the player the ability and space to cooperate in the game, or give the player some tools that need to be used together, such as hammers and nails, you put the nails, I can nail the nails, which is very common collaborative content.
But there is a great need for encouragement in the game, sometimes even forcing players to cooperate to complete missions, and of course, advanced design, which is to add some operations that need to be opportunistic, such as you can't put the nails in place, and then come back ten minutes to nail the nails. You have to make sure the player is doing the work at hand at the same time, so that they communicate how to get the nails in.