DECISIONS

WHY UNREAL ENGINE?

In the end, we chose to use Unreal Engine instead of Unity. The reason behind this is a simple one: with Unity, the 3 Programmers in our 5 member team will have a lot more work to do than the 2 Artists, since shaders need to be coded and the Artists aren't familiar with Unity at all, so it will take a lot of time for them to get up to speed with it. By using Unreal Engine, the workload will be more evenly divided and the Artists can even do some basic programming by using Blueprints.

The first two weeks were a bit tough for the Programmers, since they were initially more familiar with Unity and C#, not C++, but they are getting more up to speed with Unreal Engine and managed to produce some great results in terms of coding the separate mechanics of the prototype.

WHY THIS GAME?

We chose the idea of a dynamic, competitive, racing game with a mix of fantasy for a multitude of reasons:

• We believe that there's nothing more fun than getting together with a group of friends on a Friday night, sitting on a couch with the controllers and competing against one another in a fast paced environment, ruthlessly sabotaging each others' characters and 
• We chose to have different characters, with their own special quirks and identity, because we believe the ability to consciously choose a character to play as will make the game a lot more fun and personal, and when there's a personal connection, there's more fun.

PROGRESS

CODE AND GAMEPLAY MECHANICS

The main mechanics we had to find a solution for were:

• The dynamic generation, falling and deletion of the tiles, forming the path on which the players will race
• The camera placement and dynamic adjustment to the characters' positions
• The base character class
• The base character movement
• The character pickup items

Tile generation

The base code of the tile generation was well established in the previous week of the prototyping phase and worked rather well. However, if the tiles were increased, it was producing a significant amount of lag. Luckily, the Programmer tasked with solving this issue managed to solve it beautifully, so that even increasing the amount of rows of tiles to 30 (when there were 10 before) and making the length of the path even 1000 (when it was a lot less before) produces no lag. 

An example with the goal amount of rows:

With a player (as a cube):

With 30 rows:

Camera placement

The camera placement was particularly tough due to the calculation of the players' positions and the dynamic adaptation associated with it. It was also an extremely important aspect of our game, since if the camera position didn't work well enough to show everything in all times, the game itself wouldn't work. The Programmer tasked with this managed to solve it by getting the average position of the players and having the camera point at it at all times, while also zooming out/in thew more far away/close they are to each other. The result is a view like this one:

The separate player classes and movements, camera angle as well as base UI were all implemented as well. The result is a view similar to this:

The pickups

The Programmer tasked with this mechanic also managed to make a basic version of it, as seen below:

The following features were added with the pickups:

• "Teleport feature" - The player who picks up this pickup will instantly jump a few meters to the front, getting ahead of other players
• "Ballon feature" - The player who picks up this pickup will float above the others for a short while, granting him short immunity to the falling tiles in a way 

All of the aforementioned features were put into a master project that you can play!

ASSETS

• Characters

One of the Artists took upon the task of creating some character concept sketches, in order to make the production phase a lot smoother. The goal was to come up with diverse, unique and fun characters to play as. Some of the (still very rough) sketches included these:

And as a way to concept in a faster and more efficient way, the Artist tested out using Oculus Medium, Quill and Gravity Sketch. Gravity sketch proved to be the most efficient for the task at hand. Using VR enabled fast concepting in 360 degrees, which is ideal for the quick visualization of a character from all sides. The results of this task were:

The geometry from Gravity Sketch will also be used as a base for the 3D modeling, which will make it a lot faster and more intuitive, unlike trying to decipher a 2D drawing and translate it into 3D space. 3D modeling will be done mostly in Max (for base) and Zbrush (for decimation to achieve the desired style/aesthetic)

• Shader

The other Artist was working on a prototype for the main shader of our game and the Cel post process shader. The result is a great, procedural shader which creates atlas textures for the characters, the colours of which can always be changed within the instance. It's a great solution and will speed up workflow greatly.

Example of bomb prop with the shader in-game:

• UI

The base UI design was also established. We chose to use a minimal, sleek UI, in order to avoid taking up too much space and attention on the screen. The result of the UI is seen in one of the gifs above.

WHAT COMES NEXT?

Production begins! This means the Artists will need to go into full gear and start producing all the necessary models, rigs, animations, shaders, particles, concept art and everything else needed. Some of those include: environment concept art and models, character concept art and models, skill animations, spell particles and so on. The Programmers will need to expand on the existing code and include all the character abilities, extra mechanics and optimization that comes along with that.

In the end we are hoping to make a very fun game that people will enjoy playing!