Introduction

If you're reading this, we welcome you to our game project for the course Game Projects at DAE Howest.  Fasten up your seatbelts and join us on this amazing journey of how we develop a (self-proclaimed) masterpiece!

Before we get started, we would like to introduce ourselves. Our group consists of 3 big-brain developers and 3 majestical artists. As mentioned above we are all currently studying Digital Arts & Entertainment at Howest Belgium.
I present to you a high-resolution picture of our team:

Featuring:
The Devs - uWu Gilly, Mastermind Sasha, Senne The Village Idiot
The Artists - Stef The Stef, Christiane The Crazy Cat Lady, Kobie The Theorizer

Now that that's out of the way, we can start talking business! The core idea is to develop a platformer race game in which the camera decides your fate... [Cue unnecessarily dramatic sound-effect]

Let’s walk you through the intended game experience.

We start the race at one of the predefined positions in the level. The destination will be assigned to the players by displaying an image. When the signal is given, all players need to race to that target. Every time the destination is reached, a new one will be appointed. Simple, right...?
WRONG! The game camera follows the player upfront, which means that this pro-gamer can decide which path the group has to take and how fast everyone needs to go. If you can't keep up, you're out! Players that get out of the camera frame get eliminated. As we would say in Dutch "Take the ropes in your own hands!" Be the player that decides the pace and eliminate your foes.

But before anyone can brag about being the best in a game, there needs to be a game. So let's take care of that!

Art

Can you already imagine it? You and your friends racing through stages, while everyone is aiming for that sweet, sweet first place to make all others cry? No…? Well, that’s what this chapter is for! Let’s discuss the art style to give you a clearer image.

Art Style

First of all: 

"Hola, soy Dora! Can you tell me what will happen if multiple characters race through a level while gaining control of the camera? Can you? Yes! Great answer indeed! PURE CHAOS!!!"

As Dora has taught us, chaos will arise in such a hectic race. We will avoid this chaos by using a coherent, simplistic art style. Choosing this art style became one of the main topics of the past week and has been thoroughly discussed with all members of our team. A sneak peek at our references can be seen in the following image:

Sneek peek at a page of the first draft of the art bible.

Concerning the art style of the background, we aim for a low-poly approach with mostly flat colours. Stylized proportions will be used to clearly distinguish objects. On the other hand, we wouldn’t want to lose our glorious main characters in the background. That’s why we will slightly alter their style by adding more detail and depth to make them pop. All of us agreed that this approach currently fits this project the most.

Setting

The style is cool and all…, but what about the setting? Again good question! Dora would praise you, but she’s not here anymore. We tried our best to spice this up and went for a "Miniature" theme. The characters in our game will have the size of realistic dolls compared to the environment. This means that the props in the background will look gigantic! Our crazy cat lady Christiane tried her best to create a first draft of what this would look like.

Coding and Mechanics

Next to the art, we think it is important to mention some of the back-end decisions that we've made. In this part of the post, we'll talk a bit more seriously about some research questions regarding the engine and some of the core gameplay mechanics.

Unreal Engine 4 vs Unity

Let’s start with the biggest question of all, what engine will we use?
Obviously, we’re choosing between the 2 main competitors out there, namely Unity and Unreal Engine.
We decided to go with Unity for a number of reasons, however, there are some drawbacks as well. Let us explain the main differences between the two engines.

The biggest difference is the coding language, Unity uses C# while Unreal uses C++. Both, again, with their own pros and cons (we’re not going to go into too much depth about the differences between the 2 languages), but in short, C# is really user-friendly which can help speed up the development process. On the other hand, C++ is a lot more performant.  This means that Unity will speed up the development process, but at a performance cost. For the scope of this project,  the extra gain of performance won't be noticeable, so that’s not an issue.

On another note, for those who are actively watching developer videos on youtube, you’ve probably heard the phrase "Unreal looks prettier than Unity".  This isn't entirely wrong, but that doesn’t mean Unity’s graphics look bad. On the contrary, it still does a really good job of making your scene look pretty. Again, with the simplistic visual style that we’re aiming for in this project, this won't be a huge deal.

To summarize, we think that Unreal is arguably a better engine than Unity, but for the scope of this project and given the limited time, we think Unity is the right choice for us.

Forward vs deferred rendering 

We also went ahead and looked at the differences between the forward and deferred rendering path in Unity. After close inspection, we decided to use the forward rendering path, because it is a good general-purpose rendering path. We're not going to go too much into the specifics of all the differences, but in short, we can say that the forward rendering path gives us more control over the quality of our project. Furthermore, it has fewer potential artefacts than the deferred path. This, however, comes at a performance cost. As mentioned previously, we don’t think this extra performance will greatly influence our project.

Camera movement

The camera is at the core of our gameplay. This means that its movement will have a huge impact on the game.
We know that it needs to follow a player, but how exactly? These are our two main ideas.

1. As the players compete in a race to different locations, the camera targets the player in first place.
2. The camera focuses on a random player for a set amount of time and then switches to someone else.

In both cases, the targeted player needs to show off his parkour skills to try and shake off the others. This seems like a fun and interesting way to make everyone move, however, the second idea quickly gave us the feeling of unfairness. If a player, in this case, gets targeted by the camera they are effectively invulnerable during that time. Because of that, we liked the first idea more.

This brings up a question that we will try to answer by next week: "How do we decide who is in first place?" 
When all things are in place, we will make sure our gameplay won't be too "BoooOOoringg", so expect us to try to do some more interesting stuff, like rotating, shrinking. or even splitting the screen to add a little more flair!

Player Movement

Another important aspect of any platforming game is the player movement. (Duhhh...)
It needs to feel just right, or the whole game isn’t fun to play at all. So this was, together with the camera movement, the first thing that we prototyped. 

But what does a character need to be able to do? We have chaos in abundance, so we decided to make it nice and simple.
Our characters can run, jump, and to make traversing the level a bit more interesting, the player will also be able to wall-jump. 

The following gif shows all of this in action.

Wow, you read the whole post all the way to the end!? Kudos to you! 

We genuinely hope to see you again next week! Peace out!

-This text was funnyfied by uwu Gilly-