Hail to the Rainbow. Game development takes forever

Introduction.

Hi all! My name is Sergey Noskov, I am an indie game developer. For the fifth year now I have been developing my project called Hail to The Rainbow. I have in my portfolio such games as The Light, 35MM, The Train, as well as 7th Sector. The current work has been going on since 2020, a very long period of time, long and painstaking work, which is finally coming to an end. Hail to the Rainbow is a sci-fi adventure game in the setting of the Russian cyberpunk post-apocalypse. The story of a lonely young man named Ignat, surviving in the difficult conditions of the new reality.

Since the finale of my work is already visible somewhere on the horizon, and a few days ago a DEMO of the project was released on Steam (you can already touch the game), I decided to create a series of articles on the topic of development, where I would like to share the history of creation, technical aspects, cases, associated with unexpected difficulties, etc. Also, I would like to touch on the moral aspect; such long work inevitably awakens a whole ensemble of emotions, moods, sensations, ups and downs. I must say that sometimes this is very difficult to cope with and the process requires a lot of endurance.

A little background.

In 2018, I released the 7th Sector project. It was an experimental genre for me, a cyberpunk platformer with puzzles on logic and reaction speed. The game didn't live up to expectations and didn't generate much response, but it was a big deal for me personally. If previous projects in terms of elaboration of the universe were quite superficial, a lot was done on a whim, the logic of the world was not thought out in detail, then in the case of the 7th Sector the universe had a good basis. Although not everything was fully revealed in the project, the character had motivation, the world and some of the characters had a backstory, and there was a certain logic to what was happening, at least in my mind. It was a story about a dark futuristic world in cyberpunk style, with robots, strange technologies and a totalitarian system included.

However, the work didn’t take off and didn’t really grab the attention of the public. The failure was disappointing, but for some reason it fueled even more interest in the topic. This prompted the creation of a new, fifth game, Hail to the Rainbow. Now this is not a platformer, but a first-person adventure with shooter elements. I decided to use those techniques that had already worked well in my previous games: emphasis on atmosphere, immersion in the story from the perspective of the main character, horror elements, the dramatic component of the story.

Work began immediately after the release of the remake of The Light in 2019. It so happened that I conduct development almost solo. Of course, to say that the game was created by one person, as is sometimes written, would be incorrect; the project involves a composer, voice actors, and sometimes there is outside help in modeling, but this is a small percentage. All the main content of the game is traditionally created independently. People sometimes wonder why they should do it alone, if they can cooperate with someone else and do it better and faster. Comments often suggest contacting the studio for high-quality animations and cut scenes, hiring a programmer, etc. But for me this is exactly the point, I like the process, I like to immerse myself in each area, be it working with graphics or scripts. When working on a game, I fully experience its entire history, work out every detail and receive a specific moral benefit from completed tasks.

In addition, the feeling that you are gaining experience and skills in different areas of activity and raising your level is inspiring. An interesting feature: when starting a new project, every time there is an illusion that now I will use my new skills and the work will go faster. But as experience grows, so does the demand for results. As a result, development time only stretches out. By comparison, my first projects took from six months to two years. The current game has been in production for five years now… That’s a long time, during which time we’ve gone through a lot.

Preparation.

Let's return directly to the project; I decided to continue development using the Unity engine, as is the case with all previous projects. Over the years of work, you get used to the tool and the developed methods; it’s quite difficult for me to change habits, so I decided to postpone the transition to Unreal (which I’ve been thinking about for a long time). Previously, I started projects from the specific to the general, sometimes literally the creation of a game began with modeling some location or object, and only then I built the project structure, management, plot, etc. In the case of “Rainbow” I went from the general to the specific. Initially, there was a concept of what the game would be, what the idea was, who the main character was and what the main mechanics were. For a long time I wrote out the plot in different forms, in phone notes, in a document file and handwritten in a notebook. I was constantly making some sketches, small notes and notes.

From the very beginning, I intended this game to be a very dark and dramatic story. This time the main character was a young boy named Ignat. It seemed to me an interesting idea to make the hero not a strong masculine fighter against evil, but a completely vulnerable boy, for whom any skirmish with the enemy could pose a serious danger. At the same time, the player can truly immerse himself in such a character, remembering himself at a young age and how we fantasized about playing out some adventure scenes on playgrounds. As references for the surroundings and the universe as a whole, images of the world of Half-Life 2, Blade Runner, the works of Simon Stallenhug and much more were used; I will not list everything, since there were truly a great many sources of inspiration. All the sketches and ideas periodically had to be raked into one pile and tried to be structured, we also had to immediately focus on the possibilities, something was eliminated due to the high complexity of execution, something was put off “to think about.”

First steps.

I started working directly in the engine by creating a polygon and blocking levels. From your own experience, over time you understand how important these aspects are. The game is a first-person view and at first the main character controller was created with a minimum of functions, which was later acquired with more and more new elements. I had experience using a simple capsule with a Rigidbody, but this time I used the Character Controller as a basis. At the training ground, we practiced character movement, jumping, overcoming obstacles, reactions to landing, etc. The height of the character himself and the basic heights of various elements of locations were also adjusted: doorways, objects under which you can pass in a squat, for example tables, objects on which you can immediately jump.

At the same time, I moved on to another important point. As they say, “the theater begins with a coat rack,” and the game, in a sense, begins with the menu. Based on previous experience, again, I realized that it is extremely convenient at the very beginning to create a basic menu structure, loading scenes and saves, settings, etc. All this initially looks like rough stubs and blanks. I outlined the structure of the main system components; each component was attached to its own object so that it would be easier to search by search. First there was an object and a script responsible for the menu itself, buttons, icons, settings. Next is the saving object, in its component everything related to saving data happened (for my tasks the Player Prefs system was quite sufficient). Then the localization object, its component, read the localization file and created a list, something like a library with texts of different categories. Later I will return to the topic of localization in more detail.

After creating a menu, a couple of test levels, and creating a prefab for the character itself, you can normally launch the game, the desired level, and work out some functionality on it. At each level there was also a component that controlled the scene; various events were written in it; with its help, cut scenes and animations were launched, characters spawned (there is also a separate component for spawning), triggers were activated, etc. The stage also had its own object for save management. It contained lists for several main categories of scene objects: doors and their states (open/closed, if closed then how exactly), objects that can be picked up and objects with which you can interact, such as technical puzzles. The state of triggers on the stage, for example, triggers of some events or monologues of a partner, was also saved. Yes, like in Atomic Heart, the main character has a partner talking to him via radio, but keep in mind that I started development long before Atomic was released 🙂

In general, for me, the saving system is still a rather complex topic, so I will not describe my principle in detail, so as not to throw up erroneous and crooked ideas. Let me just say that to simplify the task, I again decided to use the checkpoint system. In this case, there is no need to record a large amount of data at any random moment in the game, and I simply wrote some events and changes at new checkpoints in the script, without relying on saves. Character data, availability of items, number of lives, etc. were recorded with an individual ID for each checkpoint. For example, for chapter 2 and checkpoint 5 in this chapter, we write the hero’s life level in a variable called – health_2_5, which goes to Player Prefs.

Character.

Overall, the character system was quite confusing for me this time. Since it had to contain a large number of variables and states, its controller swelled over time to gigantic volumes. In addition to the level of life, the hero had a temperature indicator, battery charge level (it is used to interact with instruments, technical puzzles and devices, as well as to operate a flashlight), fatigue level, several basic inventory items that can be used regularly, a detector, a drone, a weapon, as well as a large number of different items, quest and ordinary, including consumables. There are also a number of permanent features, such as raycast checking for obstacles ahead, checking the collider above the character so that the player can get up from a sitting position, checking the surface the character is walking on to play footstep sounds, and much more. In everything described above, a rather noticeable problem is the lack of order, when the controller of the inventory and character states is overloaded with functions (and in my case there is little order and the scripts are designed very chaotically), confusion begins and you yourself sometimes cease to understand where and what is. Therefore, it is important to maintain structure and hierarchy.

Structurally, the character in Hail to the Rainbow also turned out to be very complex. As mentioned earlier, the Character Controller was used to control the movement. The character component has a mode of full control over the controls, as well as partial, when at a certain moment the hero smoothly freezes and his camera turns in the desired direction, for example, to emphasize an event or object. The same mode is used when interacting with devices and puzzles, when the character freezes and looks at the target object, such as a computer monitor, e-book, etc.

Many people know the difficulty of implementing hands with a first-person view; sometimes an object in the hands, such as a weapon, passes through objects in front of the player. To avoid this, you either have to make the hands very small, or add animation for pressing the hands closer to the player’s body, or resort to other more tricky methods. I monitored some options, there were proposals for rendering on different layers with two cameras, there was also an option to change the sequence of drawing hands using a script and a special shader, but unfortunately in my case, these methods revealed pitfalls that were not obvious at first glance. I had to go with the original version with a small scale and retraction animation. I prepared the hands themselves at the initial stages of development in order to gradually update them and add new animations. Over time, the number of animations approached a hundred. These included interacting with some quest items, managing basic inventory items such as a first aid kit, detector and weapons, moving over the rungs of stairs while going up and down, interacting with some puzzles, etc. The tree of hand animations in the animator has grown to impressive proportions. For a long time, in previous projects I continued to use the old Unity animation system, but in such a complex movement structure it was impossible to do without the Animator system.

That's probably all. In the next article I will touch on the topic of visuals and lighting in the project in more detail. Since the game did not use modern global illumination techniques and everything was done according to old principles, many interesting techniques were used related to lightmaps and realtime lamps. Non-standard technical solutions are always interesting to examine.

Thank you all for your attention! I will be glad to have guests on social networks and grateful for adding the project to the wishlist!