Olya Demina and her colleagues talked about their new upcoming project Forfeit. It’s a student game, inspired by Inside, which features some really nice visuals.
Olya Demina and her colleagues talked about their new upcoming project Forfeit. It’s a student game, inspired by Inside, which features some really nice visuals.
Introduction
Hello, my name is Olya and I am the leader of our development team which I call “The Dog Team”. We are Olya, Nasti, Nely, Lena, Tania and Alexey. Initially our project was an educational one during the course of game graphics and UE4, but with time, it became something bigger for us (and our friends of course!) and now we are struggling for our dream that is ultimately is to make the game to the Steam!
And we would like to thank everyone who helped us on a rocky road to desire: our school curators Dmitry and Vyacheslav; our instructors Alexey and David, work colleagues Andrey, Artem and Dmitry
Project
Our primary goal was to make a finished product. Not a technological demo, but a fully playable game. Moreover, polished — for the extra points.
During development we usually took an INSIDE game as a reference, which is in my opinion the greatest platformer game (after Super Mario, of course). To show each scene’s depth, not only the events that occur around our main hero (the dog), but the background is also constantly changing — it has vivid in some kind. We have made several levels with this effect, each with unique and distinguishable atmosphere and mood.
Side Scroller Template
The project is based on Side Scroller Template, mostly by historical reasons. Templates are incredible useful for UE4 newcomers, as they give an ability to jump into the process of creation without getting too into in Game Modes, Player Controllers, user input and other technical mumbo-jumbo which can be sort of scary at first. You click “Play” — and it just works.
In my opinion, production of UE4 titles do not depend on genre, mostly it depends on the organization of the process and on who does it. The main advice is: use version control systems (like SVN or Perforce, which is free of charge for small teams), even if you are working alone! This will save you a lot of time.
A screenshot of our P4 depot
Assets
First we make a playable “stub” with the maximum possible depth and level of detail, and then, by use of UE4’s Merge Actors instrument, we bake parts of the stub into placeholder models, which are then remodeled into final quality. All assets in game are divided into two major categories: indoor and outdoor, with the exception of a few assets that belong to both.
We mostly make use of low polygonal models with tiling textures, and this is intended because assets of this kind are quite cheap in production. We do not use LODs (everything is LOD0), because camera is fixed to character and distance to things is constant during gameplay, so LODs will not give any substantial performance effect. With same considerations we made use of one-sided assets with their back planes being cut. Also there are almost no translucent materials.
Lighting
Light is, in my opinion, one of the most powerful tools to feature the atmosphere. Even in architecture (I worked as an architect before) a large number of projects are made with focus on sunlight. We decided to use dynamic light in the gme, which made it possible to use it as a means of greater gameplay expressiveness.
Changing the time of day which is a transition between morning, afternoon, evening, night and dawn, immerse the player into a more vivid atmosphere and, supporting the plot component, divide the beginning, middle and end of the gate. For example, there is a sun in the first location, which sits over the horizon as the main character moves forward and eventually player sees the sunset. This was implemented via timeline in level blueprint, as you can see on a picture below, the position of the light source from the sun and its temperature changes based on the player’s position.
We make use of mostly stationary lights indoors (this is a kind of light sources in UE4, when the light itself is calculated dynamically, but the reflected light is baked into the lightmap) and dynamic lights outdoors. For example, we illuminate gameplay path of the player, and in addition colored lights are also used to denote interactive elements of the level and dangerous places.
Working with Blueprints
Almost all gameplay mechanics are implemented in Blueprints (and those few which are not will be discussed later).
One of the most challenging tasks was the AI for the Final Boss, mostly because the initial encounter design was confusing and not clear even for ourselves and this was our mistake. We had to tune the encounter, tune the boss, try this and that with his AI… And here is UE4’s behaviour tree to help. We’ve made a handful collection of different AI tasks (a task is an usually a quick detached action, i.e. cleave attack or a bite) and services (this can be described as a continuous action, like a ray chasing the dog) and then began to combine them in behavior tree until we get what we wanted.
Another technically difficult task was a impulse attack implementation, which is primarily used by the Final Boss, but is also used in one of the encounters right before it (as a so-called environment attack). Impulse attack is basically a wave which will kill you if you did not find a shelter like wall or another obstacle. It is designed to be accurate, so player should never die when he is behind the wall completely. This can be achieved by a serie of sphere sweeps, forming a rectangle in projection. There’s some linear algebra here and initially we implemented it in blueprints, but soon we ran into performance issues. So we had to reimplement it in C++. But now I believe the recent feature of blueprint nativization will give the same result. Also we have some service things implemented in C++, for example — loading screen on level transition.
Moreover, there is another AI case I would like to tell you about. In one of the game locations the main character (the Dog) appears along with his master and the player is given the opportunity to alternately play one or another character. While one of the characters is active, another becomes his companion and follows him around. Technically this is implemented via Posses/Unposses pawn (a method on the Player Controller object), so we replace pawn’s player controller to respective AI controller and vice versa. AI controller in its turn has a running behaviour tree, which is responsive for following the active character. Quite easy but useful trick. The essential blueprint nodes are shown on picture below.
Blueprints by themselves, in my opinion, became the right choice for the project since the implementation of gameplay mechanics in native C++ would take much longer due to increased iteration time. So blueprints are convenient — you change something, click Simulate, see what happens and go on.
We pushed hard to make the most of the mechanics already implemented: for example, all interactive objects have a base blueprint class, which exposes a lot of parameters and events you can subscribe via event dispatcher. This way, designers can easily tune mechanics and even create new mechanics without getting much into inwards. Lighting fast iteration times included.
After such a strong work it was necessary to finish with something beautiful, like master and the dog meeting. I wanted a lot of light and some such a salute joy. So we gathered with the team and began to recall the most inspiring movie moments.
You know, maybe you watched the Thor movie (if not, take a look) and so there is such a steep scene with Frigga, Thor’s mother, funeral. Sad moment, but also very beautiful. One of our team members, Nelly, said she went into 3D and gamedev because of this scene. Looking at all this magnificence we would like to reproduce it in our project. This is how we got a lake and beetles.
Fireflies