Hey again! 
With our production sprint officially set in, and things well on their way we got some updates for yall. So let's not waste time and get to it!

Art

Hey fellas, welcome to the art section of the devlog!

This week I (Laurens) continued on the work from last week, continued on the guns, unwrapped them, which was quite fast, easy and dirty due to the fact that we only have flat colors on our weapons without any detailed painting.

I did the same for the character, created the model and gave it a first base color pass, tho the character was unwrapped nicely due to the fact that there will perhaps be some detail painting in substance painting later. 

You might feel there is a lack of detail but we have to keep in mind that we see our characters from this distance, so there is not that much room for detail without destroying readability on the field.

Same for the weapons

I also prepared the base design for our chaos factors, purely for implementations sake, since the card art will come later.

That's all for me this week, now on to Mathis!

Thank you for the introduction Laurens. Now, let's take a look at what I did!

This week I focused more on level-building. Altho I did try to get the outliner to work already, sadly enough I wasn't able to get it working just yet, so stay tuned for that for next week ;).

First I worked on the Chaos Factor Selection Level, with this being the concept:

As you can see I made a concept for both situations the Chaos Factor Level can offer:

• 3 Cards, the usual options.
• 4 Cards, here the 'Party' card option is added. This has a lower change of triggering but is also not meant to be gamechanging.

From these concepts I then went into designing the level itself. 

My usual workflow for this is:

1. Blocking out in engine
2. Making the meshes
3. Placing them in engine
4. Texturing them
5. Add any final VFX and get the lighting just right

Now for this one I didn't get any WIP shots. It went pretty fast so the difference wouldn't be that noticeable regardless. However, here's the result: 

Now this however doesn't completely portray the mood, so I went and added some light flickering and some temporary audio to get an even better feeling of where we are ( The cafeteria, duh ):

Now fear not, that's not all! Besides the Main Level and this one, there are 2 more we still need:

• The Join Level
• The Podium Level

Now all of these levels have one thing in common: They take place in the same setting, our max security Space Prison.

Ofcourse when the first players first join, it resembles them entering the prison. The opposite is true for the Podium Level.

Therefore I decided that it would only make sense if both of these levels take place right in front of the prison. Altho the levels will differentiate a slight bit, they will still be pretty close to clearly show where the players are.

Once again I came up with a concept for the Podium Level that looks like this:

This was more of a general idea than it was an actual clear representation of what I want the level to look like. You'll see that reflected in the next screenshot.

In this level we allow players to brawl it out for a final time before transitioning back to the main screen. 

Now before that, they ofcourse need to be shown where they ended up placing on the leaderboard. Whilst the top 3 gets a nice podium, last place has to sit in the trash...

After making it halfway through the pipeline I am currently here:

The models are all the final ones, but as you can see the texturing isn't quite there yet. 

In the next week I'll definetely give this level some more love and finish it up nicely, stay tuned for that!

Mathis, out.

Technical

Dylan

Welcome to the technical section of this devlog!

Last week, I said, "By next week, we should be back to where our prototype left off."
Well... we're not quite there yet.

We are still missing:

• Dashing

• Throwing

• Aiming (blocked due to skeleton issues)

• Ragdolling (blocked due to skeleton issues)

• Melee Combat (blocked due to skeleton issues)

Unfortunately, our character's skeleton is broken, preventing us from making animations or physics assets. So aiming, ragdolling, and melee combat will have to wait.

What Did We Accomplish?

Multiplayer is back! And this time, it’s better than before. Since the game is 2-4 players, I created a joining menu where players can connect. We can now actually play with 2-4 players!

With multiplayer up and running, the game loop is also in place, this includes the card selection phase, podium, point system, and level transitions with doors opening/closing between rounds.

Here’s a quick look:

Now, let’s break it down.

Multiplayer

Local multiplayer is fairly simple, you just create multiple player characters and Unreal handles the rest. But since our game supports 2-4 players, we needed a way to control how many players are active.

The Joining Screen

A staple of local multiplayer games is a player joining screen, we decided on a Castle Crashers style screen.

For those unfamiliar, Castle Crashers lets players join by pressing a button, displaying their chosen character, and selecting their preferred character using the D-pad. The host can start the game when everyone is ready.

Here’s an example:

Our Implementation

I created a widget-based joining screen with 4 player slots.

• When a player presses the Join button, they are marked as joined.

• An Icon appears representing the player that joined.

• Players can navigate the Icon around.

• The game only begins if at least two players are present.

• To start, all players must hover over the Ready button with their Icon.
  

A little bit of friendly chaos is encouraged here!

Once the countdown ends, the number of joined players determines how many will play the match.

Point System

With multiplayer working, we needed a scoring system. The point system works as follows:

• 1st place → +3 points

• 2nd place → +2 points

• 3rd place → +1 point

• 4th place → 0 points

Since we now support 2-4 players, the highest possible score per round is (total players - 1).

Example:

• 2 players → Winner gets 1 point, loser gets 0.

• 3 players → 1st gets 2 points, 2nd gets 1, last gets 0.

• 4 players → Uses the default 3-2-1-0 system.

Once we had a working point system, we could implement the game loop. Detecting when players die, awarding points, and transitioning to the next level. Following our previous game loop system!

Card Selection

After the first round, we transition to the card selection phase. This is Sam’s domain, so my only responsibility was:

1. Loading the card selection level.

2. Assigning the correct controller to the card selection UI.

3.  Loading in the new level.

For now, the player with the lowest score selects a card. We’re considering changing this to the player who placed last in the most recent round instead.

Podium

What happens when the final round is over? The podium screen!

This is where we determine the winner and display the final ranking of all players.

• The game sorts players based on their total score.

• The final screen is a playable podium map where players can move around.

The logic is mostly done, but we’re still tweaking it to make it feel fast and responsive.

Level Transitions

By now, you’ve probably seen the level transitions in action.

At the start and end of each round, a set of doors opens and closes to smoothly transition to the next stage.

• Logic is complete, but the doors still need proper models.

• Implemented using Level Sequencer to animate objects based on time. Exactly what we need!

This creates seamless level transitions.

With that we have level transitions!

Closing Thoughts

Much like last week, this one was a bit slow. Our goal was to reach the same level as our playable demo, but real-life constraints as well as Engine constraints held us back a bit this week.

What’s Coming Next?

Next week, we aim to finally reach our prototype’s functionality, allowing us to start adding new content.

The planned features are:

• Dashing

• Throwing

• Resolving Skeleton issues

• Aiming

• Ragdolling

• Chaos Cards!

That wraps up this week’s devlog! If you’re here for more technical details, stick around below. Otherwise see you next week!

Technical Deep-Dive

Dylan

Welcome back to the Technical Deep-Dive!

This week, I'll walk you through the multiplayer logic, point system, and level transitions.

Multiplayer

Original Approach

My initial idea was to detect new controllers at runtime and dynamically create PlayerControllers. However, this turned out to be far more complicated than expected, and I still haven’t found a reliable way to do it.

Instead, I took a simpler approach: pre-create four PlayerControllers and let Unreal handle controller detection and management. This works well enough for now.

Handling Players Per Level

Each level automatically creates a Player and PlayerController if they are valid in the GameMode.

To support 2-4 players, I needed to:

1. Check the total player count.

2. Spawn (total - 1) additional players.

However, there was a big issue:

Persistent Players Across Levels
The CreateLocalPlayer() function creates persistent players. If I create 2 extra players in Round 1, then in Round 2, I now have 5 players! (1 default + 2 from Round 1 + 2 more from Round 2).

Solution

Two possible solutions:

1. Delete all local players when resetting to Round 1.

2. (Chosen Solution) Create players once and set a persistent bool to prevent duplicates.

This approach avoids the player ID mismatch issue that would happen if I deleted and recreated controllers before loading a level (at the end of the joining screen). In that case, the IDs would get reordered as Controllers 2-4 would be created first, breaking the point system.

Starting the Game

To begin the game, I implemented a custom AABB (Axis-Aligned Bounding Box) check, as I did not find any overlap related logic for widgets. This detects when player icons overlap the "Ready" button.

Point System

With multiplayer working, it was time to add persistent scoring across levels.

Persistence Across Levels

Since each level is loaded individually, player scores need to carry over. There were two possible ways to handle this:

1. Have each player track their own score (via async level loading).

2. Use a Singleton to manage scores for all players.

Since Unreal’s GameInstance already acts as a Singleton, I used that to store and manage the point system.

How It Works

• Scores are stored in an array, indexed by the PlayerController ID.

• Controller IDs start at 0 by default in Unreal and increment (0,1,2,3 for 4 players).

• If a controller is disconnected, the other IDs remain unchanged.

• If a new controller is plugged in, it takes the first available ID.

By storing scores in an array, I can easily retrieve a player’s score by accessing Scores[ControllerID]. Marking the controller as the "brain" of the player!

Level Transitions

To smoothly transition between levels, I used Unreal’s Level Sequencer.

This allows me to move object based on a timeline exactly what we need for a transitions! 

How It Works

• Doors start closed.

• Starting the timeline moving the doors.

• Doors open, triggering an event.

• The event pauses the timeline.

• At the end of the level the timeline is resumed.

• Doors close, completing the transition.

Implementation Details

1. On BeginPlay, create a Sequencer and play the sequence.

2. We could set it to autoplay, but we need a reference to pause it anyways.

3. To prevent doors from closing too early, we listen for an event triggered when they fully open.

4. When the level ends, simply play the sequence again to close the doors.

Final Words

That wraps up this week’s deep dive!

We accomplished even more than what I covered here, but I try to keep things interesting rather than bombarding you with every single detail.

If you have questions, comments, or suggestions, let us know!

See you next week! 🎮