Game developers share how to create scary games

At the beginning of this horror game project, I still heard my heart say aloud, "Let's create the scariest horror game in history." "Now that it's been 1.5 times since then, we're still in the development phase of the game, and I want to share the experience we've been working on to design this horror game called" Horrinth "after some challenges.

Ambition to defeat the Mystic Man

I remember it was 2013 May or June, and my brother Paul and I thought about creating a horror game. We all like the types of horror based on various forms (books, movies, games, theme parks, etc.). Paul and I thought we could be a great combination because I majored in game design and he majored in audio engines. If we can do that, it's a dream come true.

The idea of Horrinth was because Paul and I were frustrated by the popularity of the mystery man. We were amazed at the results of the game. "Mystery man" does not have excellent images, sound effects, optimizations and interesting gaming communities. It makes people feel like a game prototype in a hurry. However, it makes the player feel very frightened because of the constant triggering of nervousness and the possibility of being caught by the mysterious person. This is an interesting development of the type of horror game.

Paul and I believe we can create a better game. We think it would be interesting to create a horror game in a maze. We found some bad attempts after we studied the existing games in the maze, but we still have our own ideas.

Paul and I talked a lot about how to create this game. Paul told me he couldn't create a game without a story. Because Paul is not a game designer, but an audio engineer. I told him that most independent games don't have fun game loops or intuitive game mechanisms.

We like horror subjects such as exorcism, possession and supernatural activity. We decided that the game would contain all of these elements.

We've imprisoned our creativity from the very beginning.

In September 2013, we began the creation of this horror project from the table. We formed a team with a programmer, a concept art intern, and Paul's friends in music and sound professions.

We all believe that this game will be different from some of the current games. We are determined to create the most frightening game yet, but at that time we did not know how to choose.

We are constantly striving for the right concept. We are committed to certain concepts, discarding some of the designs and coming up with new designs. We always feel that every concept lacks compatibility, and there are reasons for this in the game, at least that's what we aim at.

In the October, we finally embarked on the right path and decided to start looking for investment in the project.

Concept

We have a great mechanism because when you are immersed in the game, you will remain "breathing" in the maze. Have you suffered a failure in your breathing pattern? The maze mapped above will gradually fall towards you. (This presents a constant pressure.) We also want to include the Oculus Rift and the personal information level in the game, which can be presented in a different form to the player's sense of horror.

Although we cannot believe it, the fund-funded organizations really decide to fund our prototype creation. They believe that the idea can expand the art of horror and will be a creative game design from Holland.

With sponsorship, we are able to expand our team and recruit interns to work with us on the project. We rented a small office and started making real games.

We use a class scrum framework to implement the agile approach to the project, which means we get a product after each sprint. This is a very effective way because it allows people to play our original prototypes and test whether the game can bring them fun and horror.

Respiratory mechanism

Obviously this mechanism is very annoying. In addition to our program-generated mechanisms, the maze does not provide any help. The player loses direction and constantly crushes the key to keep breathing mode running, and loses itself in the process of looking for an exit.

After some iterations, we thought we were missing a lot of consistency and story content. Especially since our main concept has been funded and we have an official deadline. Since then we have been committed to our mechanisms and maze environment.

The program based Maze is bad because:

– Players will always be disoriented

– It's almost impossible to notice the randomness in the maze.

-You can't control your level design

-You can't create an interesting environment

– it has a "boring" environment

The breathing mechanism is bad because:

– Players are constantly busy breathing

-Crushing breathing buttons will cause players to be exhausted

-Confusion and breathing are not effectively grouped together

-Very annoying breathing will blur the rest of the audio

-Death (for inability to breathe) is a very unfair punishment.

A trap called "research"

After a months development, one of our interns (graduate students) started a research project of horror type. We found some interesting facts about horror games that may sound straightforward, but not very obvious.

Good horror games do not rely on specific game loops or mechanisms. The horror game is dependent on the environment, suspense and horror of the atmosphere. People choose to play terror games because they like the sense of nervousness and adrenaline rush. This intense excitement is the most important element in a horror game. So this is completely different from FPS games. FPS games are always repeated using a simple game loop (game Bang Note: Killed, reloaded, killed again, and reborn).

After research, we know that we have a bad game design method of terror. The first thing you need to do to create a horror game is to scare them by avoiding the player's intelligence. But "Horrinth" failed to do this because we were too focused on breathing mechanisms and process generation.

Our research is great, though it leads us to the wrong path. Most horror games are commodities, created by large teams that target larger audiences.

Our deadline has been postponed to the 1th day of September 2014, and we hope to be able to present a complete game prototype instead of a complete function in the semi-finished game. We are blinded by the business methods of the horror game and forget our independent methods. Logically, all elements should be independent, just as our breathing mechanisms and program generation gradually become the problem in our business game design. In addition, we also tortured ourselves by setting deadlines for "game trailers". Then we may be in a hurry to end the game creation. Because of the size of the project, we don't have enough time to iterate and test.

On the September 1, we created a prototype of the game with the environment we have been working on creating, playing games and stories. We have noticed many problems in the design and it is very difficult to design a trailer for game play without revealing them. October 27, we need to present a prototype of the game to the sponsoring companies to determine whether their investment is worthwhile.

We received positive and valuable feedback from the sponsoring company and, more specifically, a slap in the face. What direction are we going? Are we making a complete business game now? Or are we still creating a great horror game? Obviously we have to make a clear choice for the horrinth.

So what choice should we make?

Obviously, we can't create a business game that matches the AAA standard. It takes us years and it's too risky for a start-up gaming studio. I have agreed to the "great horror Game" approach (ie, the approach I took at the outset), but I would also like to discuss the horror game elements from business games. Are they suitable for such projects? Or should we come up with different solutions?

Fixed model

Most commercial horror games are based on some fixed models. As early as the old cabin, forest, monster, flash, sudden panic. From the recent survey we found that many people think these fixed models are good, or that someone doesn't care about them at all. Typically, business games use these models, while stand-alone projects use them less.

Commercial horror games can attract the attention of many people, while outstanding independent terror games are difficult to reach their target users. I would like to combine these two types, that is, the development of a specific business model to perform a good game of terror, but it is possible that these two types are not compatible?

Defense or combat?

The great trend of horror in games like amnesia: Dark descendants is that you can't defend yourself, but you have to keep running away to survive. This allows the player to be afraid of being caught or killed, so running away is the most effective and safest way to do it, but it keeps the player constantly on the alert, creating a sense of stress.

Some of the horror games also contain guns (but limit the use of ammunition). At some point we will still be scared, but we also believe that these guns can help us defend ourselves more easily. In fact, not having enough ammunition is the problem we should be worried about. We should collect more ammunition, which is also a way to help us get safe.

Both types of gameplay are presented to the players in the horror game with interesting effects. Research shows that many people are more afraid of playing games without any defensive mechanism. People also feel that games with guns or defense mechanisms are more interesting.

Conclusion

Obviously we need to redesign the game to narrow the scope. Our goal is to create a frightening experience of terror. We want players to feel that their input is worthwhile. The challenge is to create the necessary assets without spending years. I think we need to be more creative in terms of program elements, to make sure our mechanisms are interesting and meaningful, and to combine the visuals and animations you see in the triple-a gaming experience. With regard to rendering, we will use business methods, and with regard to game play, we will focus on more effective independent solutions, that is, the use of well-designed game mechanisms and program generation.

For this project, we used the "Class scrum (a project management)" approach, which means that the producer will list the product backlog, make plans, and assign tasks to the team. We have a stand-up meeting every week, which takes a lot of time. This makes people feel that the team is responsible for the producer. Performing such a scrum process can cause a lot of latency, inconsistencies, and confusion, which can put a huge strain on the development team.

And now we have the official Scrum master (game State Note: responsible for a team running the scrum) certification, and further understand the scrum framework. We recommend daily stand-up meetings more than weekly stand-up meetings. A daily stand-up meeting can expose a small problem before it becomes a big problem. Now the team needs to focus on generating "speed." Stand-up meetings are for the team and do not require the involvement of the producer or scrum master, they only need to be present at the final sprint stage.

We still believe that this game will be a different game, we must eliminate some old frames and add some clear goals for the game, most importantly, we need to focus on creating a very scary game. If the game can scare us, this is the best result.