DEVLOG 3

Guess who’s back, back again… We are, with more exciting developments! This week we mainly focused on wrapping up our art bible and tech doc, the design of our titan and getting a prototype built for our game. 

Aside from that, we also set up a backlog with all our future tasks and discussed how much time it would take for us to complete them. 

ART BIBLE

In this document, we compiled all our style references, basically what we want our game to look like. It will be a good tool for us to fall back on during the production process of our game. 

As much as the major focus of our project is the main gameplay loop, we believe it’s important that it is complemented by visuals. This means we strive for our game to be chaotic, but not overstimulating with a shed ton of stuff happening on screen at once. 

This included coming up with a clear and readable UI, deliberate choices in colour and shape of our various types of assets, and the overall mood. 

The art team had previously looked into asset pipelines and some of our game engine’s features, so we already had a rough idea of what we were capable of and what we wanted to portray - even though we believe some small amount of deviating from the art bible will be inevitable in the future. 

CHARACTERS AND ASSETS

Even though we are far from settling for our player characters’ final design, we started narrowing down our collective vision.

Somehow the idea of the player taking the role of a small, agile raccoon struck us as the obvious choice from the start, and after some pondering we decided to settle for that. 

The players would each control a small raccoon character with a bright-coloured, cute bomber jacket (using the colours to tell the players apart). The character shape language from the games we took as reference for environments, assets and lighting was already fitting for our game. We wanted simple but distinct shapes that would stand out in an enormous environment. 

Based on this, we dipped our toe into designing our character.

On a similar note, the assets that would feature in the background (and occasionally in the foreground) were of importance. While the players climb the robot there will be a backdrop of a human city - post some terrible mass-extinction event. Ruined buildings, abandoned cars and overgrowth will all be clearly recognizable by silhouette.

Over all that, to unify the background and to separate it from the level in front, a stylized blue fog shader will cover the assets in distinct steps - the layers of 3d assets losing more and more texture definition and getting paler to exaggerate atmospheric perspective.

Last but not least, the most important part of our game = the level itself.

We finally started properly iterating on how the robot parts will look and work - once we decided on the main platform types we began putting them together in a way that would be fun and interesting, while also looking like a cohesive mechanical structure.

It was very important to think of the look of the platforms and how the player would interpret their function to be. Therefore we were careful to consider different ways to communicate this as efficiently as possible.

DESIGN ELEMENTS UI

Some design elements for the UI were also discussed already. We wish to opt for an almost seamless transition into playing. One player would press ‘X’, each player would see their assigned color and the game would immediately start. 

Through the ‘Pause’-menu the player would see three options: settings, controls and exit. 

Doing it this way would fit with the chaotic nature of our game, players would not have time to be idle before starting the game, but would immediately need to be in that focused mindset. 

We hoped to keep the overall UI to a minimum so that the player only looks away from what they’re doing if absolutely necessary.

For this we thought a minimalistic approach with white comic-style UI elements (as well as RFX) to be most fitting. To illustrate this we did a quick overdraw on a screenshot from The Last Campfire - a game we intend to use as reference for our soft-shaded environments.

TECH DOC 

To avoid confusion regarding the naming conventions section within the tech doc, some asset type prefixes and descriptors were added. 

Aside from that, some small additions were made here and there and the tech doc was proof-read to weed out any spelling mistakes that might have been lurking about. 

TEST LEVEL

Although it is not a representation of what our robot will look like, we wanted to get the overall feel of a level and therefore made a little level design.

LEVEL PROTOTYPE

This week, we started making a prototype level to test all our features together to see what works and what doesn’t. This allowed us to see how all the different elements of the game come together as a whole and identify any potential issues or areas for improvement before moving forward with further development.

TRAPPED PLATFORMS

We also further iterated on the trapped platforms. The platforms can now be activated with a button. This button can be placed anywhere in the level and is activated by grabbing it. By placing the buttons in strategic places, this will allow our players to hinder other players. For example, the player in first place can activate a disappearing platform to block off the faster path and furthering their lead. Or the player in last place can activate a slippery platform and make players ahead of them slip off and lose their lead.

Multi controller support

This is a local multiplayer game after all, so it is important to get a feel for how the game plays in multiplayer, the best way to do this is to just implement multi controller support. We added this allowing 2 characters to get controller by 2 different controllers (player 2 can also be controlled with the limited keyboard controls) due to how the previous character controller was implemented a large part of it had to also be re-written, but over all the code now is more intuitive and stable for this prototype

Multi controller support

With multiple players now in the scene able to move on their own it is important to be able to view both of them fully at all time (in this prototype of course as falling out of the camera bounds will be a gameplay element later) . We implemented a camera that keeps track of both players and calculates a relative distance between both players . it can also be easily adapted for more than 2 players if needed. It then also of course applies an offset away and up from the players to get the desired angle

Grabbing Players

Since last week, we changed the way our grab mechanic works, and it now picks up another player when you grab them. You can then throw the grabbed player in the direction you are running. When grabbed, the player can break free by mashing the jump button.

Respawning Players

Finally, we made a simple respawn mechanism for the prototype that will respawn a player if they fall off the map. After falling off the map, the player will be respawned back to the origin of the level.