Embedded Files
Connect the Dots
In NEBIO you and a friend can embark on a mission to manage an organism and help it grow.
Connect to food sources and manage to survive as long as possible, while fending off enemies. The game operates on a three-second tick system, adding a layer of strategic timing as resources are managed.
Engine: Unreal Engine 5
Platform: PC (local multiplayer)
Extent: Game Jam, 3 weeks
Year of launch: 2024
Average session: ~ 10 mins
Genre: Strategy, Resource-Management, Co-op
Language: Blueprints
Short Summary
NEBIO
Three Week Game Jam
Co-op multiplayer
Two players cooperate in controlling an organism
Survive as long as possible
Each player has their role
Role 1: The Builder
Role 2: The Protector
My Responsibilites
Programming
Game Design
Lead Sound Design
User Experience
Quality Assurance
Technical Art
Learnings Programming
Local multiplayer with Unreal Engine
Learned about Clients, Servers, Replication and RPCs
Deeper understanding of Unreal Engine's structure
Gained further skills in Blueprints
Served as a link between teammates and engine
UI Programming
Perforce
Learnings Game Design
First strategy game
Lots of Balancing
Keeping track of the game feel
Adding as much to the UX as possible
Organizing and reviewing Playtesting
Content
Introduction
In NEBIO two players cooperate in controlling an organism, that wants to survive as long as possible. They each have their seperate roles in trying to make it.
Player 1: The Builder
This player continuously expands the organism, balancing growth with the rising cost of survival. They can also repair destroyed dots.
Player 2: The Protector
The other player focuses on defending against enemy attacks and maintaining the organisms efficiency by trimming unnecessary strands.
Every action is centered around the ressource, that the organism needs to live. The main goal is finding food sources and staying efficient in doing so. This is necessary, since the cost of living gets higher, the larger the organism gets.
Technical Aspects
The most interesting technical aspects of NEBIO
A teammate and I coded the game together and also took care of UX, QA or Balancing and took part in Game Design
Multiplayer Implementation
When we implemented a new feature, it was always best to ask oneself, if it is better solved with Replication of the Actor, Replication of a Variable or with RPCs (Remove Procedure Calls).
If we take the generation of dots for example: This event is called every three seconds. It is highly critical to gameplay and both clients must have a reference to it. Now it would be possible to generate a random position, replicate that vector as a variable and let each client generate and save the dot in an array themselves. But this will not actually replicate the actor and lead to unnecessary difficulties and RPC-calls down the line, once one player manipulates their dot.
The better option here is to just leave the generation to the server and replicate the actor itself. This way all clients have the exact same dot and can reference it easily by communicating with game state or similar classes.
Now, if for example the reference is called, before the replication went through. How can we make sure that call does not get lost, once the reference is valid? One solution we found to work for us, was once the call happens, to call an event by timer as a Multicast RPC and repetedly ask, if the clients reference is valid. When the validation was true, the client could continue with the logic.
Which brings us to the next topic, which we learned a lot abou: RPCs. These were helpful in cases where there was an actor, that already existed at all clients and some logic was to be carried out there, that could not be solved by replication. For example sounds or visual effects. Here we had a simple setup.
a) Pawns
When dealing with calls on Pawns, we always had the same routine. Ask if the call was made by the server. If no let the server call a multicast, that executes the desired function on every client.
To further ease the workflow I created a custom Macro Library with functionalities like checking for a possessed pawn, checking for a local player controller or if the pawn is locally controlled.
b) Actors
When calling RPCs on actors, it was crucial that the actor has the "replicated" bool on true. Here it was once again best practice to let the server handle most replication. That way one could change and replicate variables, by asking for authority and only let the server change it, if you know the actor already exists on the client side. Otherwise calling Multicast as server is also possible.
Process
We organized ourselves on Miro with timelines and To-Do-lists.
The Source Control was done with Helix Perforce,
Seperation of tasks and reviewing each others progress and code was done in small daily meetings and over Miro.
A plan I made before we started coding
Blueprint Code Style
Game Design
Ideation
In Ideation we first discussed multiple ideas and after Day 1 decided to seperately work on our preferred idea. We then slowly eliminated one after the other and luckily NEBIO's concept stuck.
We then went on to "playtest" our concept, by drawing the actions out in real-time in abstracted 2D. Here we already could see the appeal of the game and what would be challenging for us to design.
Discussing the concept in the ideation phase
An short analysis of our concept I quickly drew up on the first jam evening:
Experience Essence: Slime growth, squishiness and pulsation, sense of control
Surprise Moments: Where will the next source spawn, does the current path fit well? Should paths be rerouted?
Fun: Time pressure, seeing growth/size, strategy pays off
Curiosity: Time pressure, exploration, cool fantasy, visuals
Scoring System: Size = points. No food means game over
The Balancing was fully my responsibility and I made it easy for myself, by putting all relevant values in seperate Data-Tables. For example food or generation related variables, were stored in seperate tables.
That way, when I noticed that the game was not what I envisioned in that area, I could quickly open up the related Data-Table and find the perfect value to tweak. This also made it easy to share the same value, without referencing an Actor.
Our goal with the game was to get the players to talk to each other and understand what it means to share a resource. We designed every action to influence and to be dependend on the others persons plans. Since you were so co-dependend you needed to talk. We noticed that this worked out and when we first playtested, players were in lively exchange.
The Stages of the Game
Week 1: Ideation
Week 2: Pre-Production
Week 2: Production
Week 3: Finished Product
Reflection
This project was such an incredible rollercoaster ride. I had so much fun with the game and I often felt really excited and proud of the project, wanting to show it to everyone and talk about it all the time.
This showed me that we were onto something special. The concept with the threads and resource suction is incredibly satisfying - fully supported by the sound design and feedback effects. I had a lot of fun working with Samuel to implement our completely absurd scope.
Many thanks to this outstanding team.
What was good about this project?
Unique and fun concept
Feedback effects and UX overall are great
Everything about the game feels non-generic
Perfect mix between weird and satisfying
Coding together flowed very well and we complemented each other perfectly
Impressive productivity in three weeks
Working together every day helped us bond and communicate well
What could have been better in this project?
Complex concept to grasp at first
Hand eye coordination and the mouse controls were difficult for some testers
The game could just as well work as a singleplayer
The games colors might be uninviting for some
I want to thank the coaches Prof. Susanne Brandhorst, Prof. Thomas Bremer and David Witzgall for their valuable insights and feedback.
Google Sites
Report abuse