Devlog 2 Prototype

57 days ago by cakcay

Share this post:

Dev-vlog 2: Prototype

This week was dedicated to working on the ArtBible, working on the game design, refining the technical document, and bringing prototypes to live.

Art

We worked on the ArtBible during this week, our goal was to get it fifty percent done. The part that we covered during this week on the ArtBible was proportions, color, rfx, environment light, and shapes. For the rest, we are planning to finish working on it next week.

The technical document was fixed by the feedback from the supervisors. The missing part of the document will be completed after finishing prototypes. Most of the missing information is about coding guidelines and controller guides. The reason why we left these parts empty is that our programmers can have more freedom to explore before we set sail and keep going.

Our artists also came up with some various types of blockout for character. The main idea is that the character will be a robot wearing a cowboy hat and cape. The movement of the character will be done by a wheel which we are planning to animate on Maya.

Art-Research

We tried out different Materials/Shaders in a small UE scene and compared how they would work in Deferred or in Forward Rendering Mode.

Since we will use a quite simple shader the only problem we ran into thus far was with unlit Materials that had an Opacity Input, even if that Input was not used every model we put the Material on kept flickering in and out of existence.

Coding

Unity vs unreal

After diving into both engines, we decided to go with Unity for this project.

On the one hand, Unreal is suited for high-demanding games, has a great system for creating shaders/graphics, and works with the wonderful high-performant C++ language. This is great for graphically demanding games. For our game, it is not really needed. Our environments, Lighting, and gameplay are designed to run on Mid-Range PCs and potentially, consoles like the PS5/Xbox One X but also the less graphically mobile Nintendo Switch.

Things took quite a while to set up, were slower to implement in C++ compared to Unity which uses C# and Unreal does not provide any real advantage over Unity for this game. Unreal engine's controller input system has changed in version 5.0 and is already advanced, but we had a harder time implementing playable characters with it. Unity allows for full control over what happens with each controller, making it perfect for our game. As for implementing code, it went faster and easier in Unity compared to Unreal.

If Unreal had things that would benefit us in a major way, we still would have chosen Unreal, but for this project, Unity takes the cake.

Character movement and laser prototypes Unreal - Even here we had trouble combining the laser and the player due to the way unreal works with actors and components.

Camera

If you look at our Unity build, there is a difference in how the camera works compared to Unreal. It was decided to change the way it works. It is still from a top-down perspective, but it now follows the players around. If the players go far away from each other or come close, the camera will automatically adjust itself to make all the players visible in the game in the best way possible. This was already in the Unity build, but we had to make it clear that this is the way we want to go for now.