Summary:

Grrrumble (Working Title) is a couch co-op game meant for a fun and relaxing time of messing around with friends.
In this game you will each play as an elderly person, battling each other to get all your groceries in the supermarket. There are limited supplies and limited time, so give it your all to get the most out of it! Chaos guaranteed!

The goal of the game is to gather as many of the groceries on your list and get them checked out at the cash register before time runs out! Don't expect your opponents to be kind however. Stealing, throwing over of carts and messing up the store is encouraged. Creating fun and meaningful conflict is thus also a core part of our design.

Unreal vs. Unity:

This build is the work of a week of research by the programmers, to see which engine we are going to use Unreal engine 5 or Unity.

In our research we have compared the two engines on cases like physics and setting up local-multiplayer to see which one worked beter/works with our workflow, we have learned that both seem to fit the bill, but we sadly learned that the current version of unreal has a bug that prevents use of setting up local-multiplayer, so currently it seems to be that unity is the beter choose.

We were excited to try our hand at c++ in unreal engine. The framework did not seem too complicated and actually easy to comprehend given time. However, debugging is a real hassle and something that would eat up too much time that we don't have. That said, our choice seems clear. We will be using Unity 2022.2

Console Limitations:

Since our game is a local multiplayer game, playing on a console seems to be the best environment for our game to be enjoyed to the fullest. Of course porting our game to console is something that will not happen, but we want to make it at least possible. To do that we need to know what limitations a console would bring. 

A computer is much more powerful than a console like an Xbox or PlayStation, so we will need to be smart about reducing performance costs. Here are a few ways we could do so:

• Static lighting over dynamic lighting. At least keep lights to a minimum.
• Low material count to avoid draw calls, especially on one object.
• Optimize the shader: Bake as much of the shadows and ambient occlusion in as possible. Especially AO is expensive. Outlining might become expensive, but that will need to be tested.
• Reduce polygon count: Someone gave an estimate of 80k at any point in the viewport max.
• Keep texture sizes small. Memory (both disk and RAM) might be limited
• Pathfinding can be slow, but as long as we stick with just a couple of NPCs it should be fine. This is especially a problem on CPUs with less cores.

Render Pipeline:

Which render pipeline should be used? Forward vs Deferred (Unreal) and Built-in vs. URP vs. HDRP (Unity)

• unity:

Unity consists out of 3 main render pipelines, which has to be chosen up front: The original Built-In Render Pipeline (consisting of a forward and deferred option), a Universal Render Pipeline (URP) and a High-Definition Render Pipeline (HDRP). 

It seems pretty straight-forward as to which one to use. The HDRP is tailored to higher-end platforms. As we are targeting low- to mid-end PCs and consoles, this one can immediately be eliminated. The built-in renderer, while default, is older and has less focus on an optimised performance. As we do not need the Asset Store, Unity recommends using URP. It is performance oriented and can be scaled from mobile to PC. It also gives us access to the Shader and VFX Graphs which will be very helpful considering our Toon-style art and the reliance on VFX and decals to make our store a mess.

URP comes in 3 different forms by itself: Forward, Forward+ and Deferred. Forward is the default. It is possible to have multiple URP assets and switch between them at later times.
The forward rendering path has a maximum of 9 real-time lights per object, this should definitely be enough for our project. As URP also has the option to create Depth Textures no matter the rendering type, there should be no need for the GBuffer either. As such the normal Forward rendering path will suffice.

• unreal:

As we are working with toon shaders and would like outlines around our characters, the depth and stencil buffer would be very interesting to us as well as possibly other Scenetextures like DiffuseColour, etc. Thus this would require the GBuffer and as such Deferred Rendering might be preferred. Most tutorials and information will also be using deferred rendering as this is the standard in Unreal.

As we are not using VR and are not planning on making a mobile game, the improved performance, reduced memory and MSAA that forward rendering provides might not be absolutely necessary. However it is good to keep in mind. We probably don't need a lot of lights or meshes in our scene, so if we can do our shaders without the GBuffer, forward rendering would be preferred, also for our splatter decals/VFX that shows the chaos.

Toon Shader:

Cart System:

Our cart will be a detachable component.  Naturally it has a bigger carry capacity than the player themselves. However you can only pick items of the ground or topple over other carts when you let go of your own.

Picking up a cart after it's been pushed down takes a bit of time. Not much of course, otherwise it will become very frustrating and will take you away too much from the actual gameplay. This will need to be play tested.

A cart with more groceries in them will become more difficult to  push over than an empty one, but it's also more difficult to move around with a fuller cart.

Also players will be able to steal others carts!

 This means the cart will become its own entity with its own physics.