Introduction

Hello everyone and welcome to our first devlog!

We are a group of 5 students, studying at Digital Arts and Entertainment (DAE) in Kortrijk, Belgium and over the next several months, we'll be making a couch co-op game together.

Our team consists of 3 students from the Game Graphics Production major: Sakibe van Soest, Giulia De Medici and Maxime Wouters & 2 students from the Game Development major: Oliver Lambreghts and Gianni Walraet. 

The game we'll be making will be a fast-paced 3D platformer in which the goal is to beat your friends by being the first to reach the top of a bouncy tower. But getting there won't be as easy as it sounds. The players will have to avoid obstacles like spiky balls which can deflate you and at the same time they also quickly have to keep moving up in the tower to avoid getting killed at the bottom by a deadly substance!

Art (in Engine)

Which Engine is best suited for graphics (shaders)?

Basic Toon/Cel Shaders* tests have been prototyped both in Unreal Engine 4.27.2 and in Unity 3.30.

* “crush test” reference choice because of how this technique of shading deals with lighting.

Research goals:

- Understanding shader graph programming

- Observe engines lighting differences

- Compare available options, settings and user-friendliness

- Check time consumes 

Model and textures by Gianmarco: https://sketchfab.com/GianmArt

Conclusions:

Unreal results by far the friendliest to use and customize and the easiest to use to experiment. The Post Processing options included in Unreal, grants great control and speed over the creation of possibly specific effects.

Unity is not completely excluded, and if necessary, it will be possible to work with it. In that eventuality, it should be taken into account that the artistic style could be forced to bend to the shader programming, as specific effect results are particularly difficult to achieve in Unity. Also, more time than foreseen will probably be spent in the shader generation.

Art (Style)

(Mood Board, Conceptualizing, Blockout)

What is our game going to look like?

Right now our focus is on gathering as many influences and ideas to then combine them together and find just the right aesthetic for our game. 

-  The Mood Board has been set up with game and real-life references.

- Basic Shape Language guidelines were written down, while the study on how we will refine them to get the right feeling across currently going on, as well as the colour palette research.

- Blockout for in-engine mechanics playtest is ready.

- First level ideas were sketched down.

The game develops vertically, with the tower as our main stage. The tower is composed of levels, each one of them being an inflatable bouncy castle with several obstacles to overcome to pass through. The theme of this bouncy monstrosity is still to be finalized.

What's next?

Graphics in engine Prototypes:

• Explore shaders and texture rendering looks.
• Explore camera and shot compositions.

Art Style:

• Define Art Style.
• Define Shape Language.
• Pick colour palette.
• Start sketching props.
• Continue sketching levels layout.
• Planning and sketching of UI interface.

Programming

Do our mechanics work/are they fun?

We first started prototyping our core mechanics in Unity. We had to implement prototypes for:
- Grappling
- Bouncing
- Upward-panning camera

We started working on the grappling mechanic and the bounciness mechanic.

We ended up with several different prototypes for the grappling mechanic which felt really smooth and easy to use. This was already a great plus seeing as we didn't want to spend TOO much time focusing on rope physics or anything but really the movement itself caused by the grappling hook.

The first prototype we made was one in which you could grapple to the entire free environment:

This would give the player a lot of freedom in deciding their path, but it could also cause for a much more chaotic gameplay experience which we don't yet know would be positive or negative. So that requires some more playtesting to be able to answer that question.

The second prototype we made, was a grappling hook with a lock-on feature. This works by having different "grapple points" throughout the level. The grapple point that is in a certain range AND nearest to the direction the player is looking at, is the one that the player locks on to: 

This makes the mechanic feel a lot more controlled and "safe" as opposed to the chaotic movement with no lock-on. The only real downside to this version of the mechanic is the bigger movement restriction. But right now, this version does feel a lot more fun than the first one, so we'll keep iterating in combination with the other mechanics to see which one turns out to be the winner!

For the bounciness mechanic we had to decide whether we would make use of bouncy materials in the engine or script the bouncy movement ourselves. The main focus is to get smooth movement and to be able to control it as well.

The first bouncing prototype (Unity) made use of physics materials in the engine. 


For this prototype it seemed clear pretty quickly that bounciness using materials doesn't allow us to control the height at which the ball bounces. Setting restitution to 1 (max) also made the ball slowly bounce higher and higher which is not the intention of the mechanic.

For the 2nd prototype we used a script to control the bounciness of the ball.

There was a lot more control to give the ball the intended behaviour. Using scripts we could make the ball bounce at the desired speed/height of our choice, and also add gameobjects that give the ball more velocity upon collision. Overall there is a lot more freedom using this method.

One thing that could be seen as a disadvantage is that the ball currently uses raycasts to detects collision, so it is possible to get stuck in a corner. However, adding a couple more rays should fix this problem. We will also continue iterating on this prototype so we might find other solutions to this problem.

Using this method gives us a lot of options to add other objects that have different bouncing properties, so iterating upon it should be easy!

Which controls did we decide on?

For the grappling mechanic, we decided to test out both mouse controls and gamepad controls, but right off the bat we were obviously leaning into using gamepad controls seeing as we're making a couch co-op game and keyboard and mouse would be far too clunky for the game to work and be fun at the same time.

The grappling prototype with mouse support felt fine. Movement was smooth, both for the lock-on and the free environment versions. But the gamepad version felt a lot better. The right joystick controls the player's rotation (locked on the Z-axis to restrict the movement to 2D) and the bottom face button on the gamepad is to shoot your grappling hook towards the look-at direction of the player OR towards the locked on grappling point.

What is our current standing on engine choice?

Right now we're generally leaning more into using Unity, because Unreal's set-up has been filled with delays and errors. But we haven't really been able to create actual decent prototypes in Unreal yet. So after we've created those, we'll have a better view on which engine to use.

The programmers have currently decided on Unity as their preferred engine for several reasons. Firstly, it's very easy to iterate the mechanics very fast in Unity and it's very user-friendly. This allows for more playtesting in a shorter amount of time, more time for bug fixing to get a more polished version of the game in the end-phases of development. and more time to explore the engine library and refactor code that would've otherwise been left as is.

We also have to take into account the amount of time we actually have to create the entire game, it's only a couple of months. So choosing an engine that has a lot of artistic capabilities, but at the same time, is very time-consuming when it comes to building the core gameplay loop because it takes a long time to compile and build (Unreal), is a trade-off that we're not sure is worth it.

Unreal is a lot harder to use in this context. The build and compile times are very long which makes it so that we have a lot less time to iterate on mechanics and a lot less time for playtesting, which is a very important step to being able to make the game more fun! On the other hand we don't have that much experience in Unreal C++, so this would be a very good learning experience. But at the end of the day it's all about creating a fun user experience.

So from the programmers' point of view: Unity is the best engine choice for this project.

Which variation of the prototypes is best?

For the grappling mechanic, the prototype with the gamepad support currently feels the smoothest and the most fun. So that is the obvious choice.

What's next?

Throughout the next week we will focus on getting the mechanics fully prototyped in Unreal as well. Once we have the prototypes in 2 different engine ready, it will be time to decide which engine to choose to hop into the production phase. After we've chosen our preferred engine, we'll start by combining the previously prototyped mechanics in order to get a playable demo ready by the end of the week.

So stay tuned for future updates!