Introduction:

We’re five students following the DAE course in Howest, University of Applied Sciences. This is our game project for the Game Projects course that we’re doing in the 2nd semester of our 2nd year. We’re made up out of 3 people from the Game Developer course that will work as programmers; Mikhail Lukach, Cristian Dontu, Raphael Pluvinage. Then two from Game Graphics Production who will be working as the artists; Matteo Tillmann, Tommy Claeys.

The game that we’ll be making for this course is a 4-player versus game where every player plays a robber with their own agenda, that agenda is stealing every valuable they can find in the manor and bring it to a designated window where an accomplice is waiting to pick it up for you. Sadly enough, the other player’s are there in the mansion and there’s not enough loot to go around between all of them.

Each round, the players have a limited amount of time to find and bring back valuable items that are scattered around the entire map. The player at the end of the round with the most amount of items in cash stolen will win. However, getting to these items won’t be easy, the mansion is filled with patrolling guards that can catch you, forcing you to drop whatever valuable item you are currently holding and respawning back at the initial spawn point. Along with them, the mansion is filled with traps and cameras that can impede your movement, call in a guard to come and check the room or just forcing you to respawn.

The way the players can avoid these guards is to stay out of the light view cone and definitely make sure to keep out of the light spots that will make it easy for the guards to see you. Along with that, any sound made within the level will attract a guard to come and inspect the area. So players must be aware of all the forces and going-on’s within the level.

To make it even more difficult, players can ruin each other day by sabotaging each other’s progress using items that they can find within the level. Traps that will alert guards to their location, throwables that make noise or things that will stun the players and force them to drop their currently held valuable item.

In summary, we’re looking for a tense stealth game and enough opportunities for the players to satisfy their schadenfreude.

For the first addition of our devlog, the artists will take you through the beginning of the art bible for our main game as well as other game ideas that we were considering to go for; the references, mood boards, along with blockouts for the possible maps that each of the game. When it comes to the programmers, each will go over the prototypes for each of the game idea that they were working on, and the questions that we had about the game mechanics and how we finally solve that. Along with this, going over some of their findings that they found while working on both engines, and their final preferences to which engine and why. Hopefully from this, we’ll be able to settle on which engine we’ll use.

Art Section:

Lighting & Rendering Prototype report:

For this run of prototypes, my focus was mainly on the stealth game concept and general art style of our games, as well as lights and render pipelines. This is a 4 player PvPvE Extraction game, where the main goal of the game is to steal as many valuables from the mansion you broke into as possible. The main mechanic of this game is based on light values. In addition to this the players will have to dodge multiple guards, lights, cameras and more. After stealing an object of value the other players can try to steal it from the player that currently carries the item. Each player has a designated spot to bring his or her item to. The main question I spent my time with is about render-pipelines in Unreal Engine and Unity, as well as different light settings, like real-time or baked and more. Since the Engine has not been decided yet, I created a document about lights and pipelines for Unreal Engine and Unity, here are the results broken down:

With an Unity Base:

The Stealth Game: Since the whole game is based of a light value system, the High-Definition Render Pipeline seems like a good choice in combination with Realtime lights. This is supported by the fact that we use a more simple art style. The Universal Render Pipeline with mixed lights is not out of the question yet.

The Boat Game: The High-Definition Render Pipeline with Realtime lights are most likely the most useful option.

The Beer Game: With this game we can be more flexible, Realtime lights or mixed lights and either the High-Definition Render Pipeline or the Universal Render Pipeline. This would need more in-depth testing towards the map dressing stage.

With an Unreal Engine Base:

The Stealth Game: Moveable lights and Lumen seem like a good choice for the amount of lights we use. There is the option for "Megalights" as well.

The Boat Game: Here as well, a dynamic light scene is required. Therefor Lumen is a good option in combination with moveable lights.

The Beer Game: Now we can continue the trend as before, or we can used mixed lights with dynamic and baked lighting, using Deferred Rendering In combination with the research I looked into Unity materials and how I am able to use Substance Painter and Substance Designer to create Materials for our game. I am used to Unreal Engine texture packing, therefor I looked up if there is something alike in Unity.

Here are my finds for potential Unity texture packing for materials: 

BaseColor & Opacity => Base Color (RGB & Alpha) 

Normal => Normal (RGB)

 Height => Height (RGB) 

Metallic & Smoothness => Metallic (RGB & Alpha) - Smoothness in Substance Painter is also known as Glossiness.

Blockout Prototype report:

Beer game map:

Map needs tables, bar, shop stands where beer can spawn for players to pick up. These are the only spots beer will spawn in during the game and where the players will have to go to and get it.

Map needs to look simple at first but tricky to move around when character becomes more drunk. Like NPC walking around trash on the ground where players can trip over.

Can be a small or big location depending on how many players are connected to the game.  Map size may also be more crowded with NPC if there aren’t 4 players so that the map size doesn’t have to change every time.

Will the map layout stay the same or do the tables and other things get random placed after starting up the level. This will make the game more fun because you will get something different every time you play.

Stealth Game:

What I found out when I made the block out is that it’s better to have a big map on this game. This makes it’s harder for the players to find each other. this because the UI would be split screen based so every player only knows where they are at the moment and will have to find out where the loot is and where the other players are to eventually steal their loot.

Was thinking to place hiding spots around the map. So if you got caught by a guard you could try to hide there until the guard lost you. This will make it a bit easier for the player to get to the loot.

Location would be a rich persons house ( mansion, manor, castle,…) So it should be a big place with lots of rooms. Where the player can get trough and find loot to bring back to his own drop point.

Every player has his own drop point where he can store his loot. This loot can be stolen by other players if they find it and bring it to their own drop point. These will be marked with the player their color so they know its theirs and not the other players once.

Map layout in rings (from outside to center -> increase in value):

Ring. 1: outside.

Ring. 2: hallways and first rooms -> cheap value -> low/no light.

Ring. 3: storages, bathrooms, guestrooms, kids room, kitchen -> medium value -> low light, light spots.

Ring. 4: hobby room, living room, master bathrooms, storages -> good value -> light spots, cams.

Ring. 5: master bedrooms, master wardrobe, picture gallery, -> very good value -> cams, major light sources.

Ring. 6: safe, relic gallery -> maximum value -> cams, traps/alarms, constant light potentially add garden and weed spots to create more outside areas to traverse.

Boat game:

Map will be mostly water with now and then crates, rocks and other stuff passing through.  This will make it more like the boat is moving and isn’t stationary.

Random encounters can happen:

Kraken attack: will spawn tentacles around the boat that the players will have to destroy.

Shark attacks: boat will be damaged and players have to repair the boat.

Wild fish: fish will fly over the boat that the players have to dodge.

We can use a generator to spawn  in the oncoming recourses.  This will it more random so the resource spawn will be more balanced and doesn’t give too much or too few of them during the playtime.

Player can fall into the water and dragged away to the waves. Other players can save them or they drown and have to wait an amount of time until they can respawn. Boat moves with the waves. Players will also have to balance the ship so it doesn’t sick or catch to much water. This will also move things around on the boat so players will also have to look out for those so they don’t get hit and fall overboard.

Programmer Section: 

BeerGame Prototype report:

For my prototypes, my focus was on the game idea for a 4-player versus game where each player plays as a homeless man and have to keep themselves drunk as long as possible by collecting bottles of beer in the level. Our idea for the main mechanic was movement controls that inherently felt sluggish and drunken. This was my primary question I needed to answer; how can I achieve these drunken controls and are they fun to play with? What is the best engine to implement them; Unreal or Unity? What can be added to these drunken movement to make it more challenging?

How did I implement the drunken movement.

The primary idea that I had for how to add a movement that feels drunken to the player character was to have a tripping mechanic added on top of it, whereby if a player keeps going in the same direction, they’ll eventually fall flat on their face. Doing some extra research online I found some extra ideas from other developers, like adding random drift and overextending sways to the character. This makes for a pretty fun mechanic, but however it sometimes isn’t really visually telling. I tried to kind of solve this in Unity by having the player capsule tilt towards where its about to fall but its also pretty unnoticeable thanks to the camera. This is something that I’m hoping can be fixed with animations in possible future production of this idea.

When it comes to production of it in both engines, Unity was definitely the easiest to make it in thanks to the pretty good inbuilt physics they have for the rigidbody. Also, and this is a general thing I noticed, there was a lot more available community documentation and resources than there is for C++ in Unreal since most people in Unreal program with blueprints. Here and there it was a struggle to get things to correctly work in Unreal. For instance, getting the launch function was a real pain and at the end of it I had to come up with an alternative by using Unreal’s skeletal mesh and applying a ragdoll to it to simulate tripping. I do have to admit, it made watching the tripping more enjoyable than it is with Unity and I also generally felt that you have more control over you character in Unreal than in Unity.

At the end of the day, I do just have a personal preference for Unity in general but I do think we’ll get opportunities to have fun with physics thanks to the rigidbody system than we do with Unreal.

What did I add to make my drunken movement more challenging.

Basing of two other ideas I found on the internet, purposeful input delay and inverse controls. The idea is that the more the player becomes drunk they’ll start going through two phases, at the first phase the input delay will be applied to the previously mentioned drunken controls, for the second phase the inverse controls will be applied along side the drunken movement and input delay.

Both were pretty easy to add, however the drunken movement had to be modified a bit to work with these new additions. In general, funny enough the Unreal version was easier to modify thanks to more of the locality I get when working with directions and inputs in Unreal, with Unity it was pretty all over the place.

Testing them out, they really did add more of a challenging edge to it and imagining it in a 4 player setting, it can really add some much needed chaos to everything.

StealthGame Prototype report:

Prototype 1: The Guard AI.

Our goal with this prototype was to figure out 3 main questions. Which engine it’s better for our needs? How would we do light detection as the guard can only see the player when he’s lit?  And how fun would It be running from the guards? We have made 1 prototype in each engine and we found that working with Unity would be better in our case for one main reason, the amount of documentation. Doing the Unreal Engine prototype was a pain and by the end of it all we couldn’t get Light detection working in it. For Unity however we found a solution while reading through some forums and we got it working smooth like butter.

We were able to get light detection working with a secondary camera which would render to a specific texture. Then check the light levels in the texture.

While messing around running from the guards we found it really fun and enjoying, just as it is and that’s without any of the other extra features

Prototype 2: The Hook.

This prototype wasn’t engine specific so for this one we had diff questions. How do we design the hook mechanic, do we use a raycast or do we implement a Physics based one. In the end we settled on a physics based one as it felt more natural and more fun to use. Also the raycast one felt too instantaneous and clunky.

BoatGame Prototype report:

We also prototyped a split screen camera in unreal and unity which was easier in Unreal but still not very difficult in Unity. 

We also explored the idea of a local coop ship game where you are trying to survive a storm while hunting a whale. On the ship everything moves around and the ships leans from one side to the other and if too much weight is on one side it will tip over. So you need to drag stuff around to keep the boat in balance while waves might come on board to drag stuff or your boat might gets hit with lightning or similar random events. Basically you are on a boat where it is chaos because of a storm and you need to work together with the other people to keep it under control and hunt the whale.

For this we tried a prototype in unreal where we tried out the boat physics to see how viable the idea. But the floating and all the physics are hard to work with and the waves are not really controllable so we would have to fake it or write them completely custom which would both need a separate prototype.

In the end we decided to not go for this game idea so we did not do those prototypes. One of the reasons we didn’t is because another group has almost the same idea and they are working it out and we didn’t want there to be almost the same games.

This will be it for this addition of the devlog. Until next week.