Specialization
Recreating the gameplay of BOXBOY! + BOXGIRL! with gameplay network replication
Introduction
For my specialization course at The Game Assembly (7 weeks), I was tasked to develop a project of my own choosing.
Since I’m interested in many game-related topics, I had a difficult time figuring out what I wanted to develop for my specialization.
Box Creation
I chose BOXBOY! + BOXGIRL! because of the game’s main mechanic Box Creation.
This one mechanic is able to offer various ways of solving exciting puzzles.
I’ve always been very fond of co-op games, and this was a perfect opportunity to try out developing one.
I also wanted to use my knowledge gained from the network course and add online co-op features.
Showcase of Box Creation in BOXBOY! + BOXGIRL!
Showcase of BOXBOY! + BOXGIRL! features I want to implement
Goal
Features I wanted to implement:
Project setup
For this project, I chose to develop it using The Game Assembly’s in-house engine The Game Engine. The engine is based on C++ and DirectX. Unity was used as a level editor, and a Unity to JSON converter provided by The Game Assembly. The converter was modified to accommodate my needs for this project.
I continued working on a project from the network course and cleaned up code that wasn’t necessary for this project.
Objects placed in Unity and how they look in TGE
Network message data flow
Apart from recreating the gameplay of BOXBOY! + BOXGIRL! I also wanted to implement online co-op features. The goal was for players to be able to interact with each other and with each player’s created boxes exactly as they would if it were local co-op.
Each player is hosted on a separate client that connects to a server. Clients send the necessary data for the other client to mirror the action in its local environment.
The player’s position, the player-created boxes’ position, and their collision data flags get sent to the server. The server then sends it to the other client for it to be processed and used in collision checks and to visually replicate the other player’s actions.
Even tho the amount of data is small, it would still need to be sent out often for the co-op experience to be smooth, and this is why I chose to send data with the User Datagram Protocol (UDP). The UDP protocol doesn’t require opening and closing connections, which allows data to be sent out rapidly resluting in lower latency.
Diagram of the Data sent from Clients through the Server
Box Creation Ability
Create a Box
My first iteration of the Box Creation ability was simply spawning one box in front of the player that stayed attached when the player moved. If the player crouched, the box would detach, allowing the player to collide with it.
Next, I started working on the ability to push the created boxes. When the player collided with a box, it would not stop the player from moving instead, it would apply its movement speed to the box and move it.
This is where the first of the many problems I had with the collisions would come up. In the beginning, only the player did a collision check that checked for collisions with the terrain and created boxes.
When the player pushed a box right next to a wall, the box would continue through the wall until the player collided with a wall. To prevent this, I added so that the created box also did collision checks with the level.
Creating one box and pushing it
Creating multiple boxes
Multiple Boxes
After implementing the push feature made it possible for the player to create more than one box. The boxes would be able to be created in one of four directions (up, down, left, right), the newest box would be offset based on the last created box.
Collision problems
When the player would collide with a box that had other boxes next to it, the individual boxes would collide with each other and start to clip into one another as well as into the player.
However, when I made it so the player could spawn more boxes, if the player pushed a box that had another box next to it, they would collide with each other, and the player and blocks would start to stutter from the constant collision pushback.
Another problem when creating multiple boxes would be that if the player made a S-or Z-shape. Boxes that were on top of another box would still be subject to gravity and keep colliding with the box below, getting pushed back, causing it to stutter. And when they stopped stuttering, they would be misaligned. When the player tried to push the S-or Z-shape, the boxes needed to know about their neighbouring box and apply the player’s movement speed for them to move unanimously.
S-Shape and Z-Shape
Construct
Uniform Collisions & Alignment
The construct class has a vector of the maximum number of boxes a player can create, and when a player wants to create a box, the construct enables that box. I moved the collision check out of the individual boxes and into the construct, which allowed me to have a more uniform collision check, as well as more uniform movement and alignment of the boxes.
Construct aligning boxes and moving multiple boxes uniformly
CanCollideWithType enum and IgnoreCollisionFlag functions to add and remove collision types with bit-shift
Collision Flags
Now that multiple boxes could be pushed around and collided correctly, the next step was to let the player walk on top of the boxes. When a player wanted to move across boxes lying next to each other, the player would collide with the side of the boxes and get stuck.
I added an IgnoreCollisionFlag to the game object and used bit-shifting to determine if a collision should be ignored. And updated the collision system to check if a certain side was to be ignored.
Smooth Movement
The construct loops through all active boxes and checks if it has any neighbours, and disables the sides where boxes touch one another, allowing the player to smoothly move across.
Disabled colliders turn red and allow the player to move smoothly across
Slide Ability
Being able to disable collisions for certain sides also allowed players to push boxes on top of the terrain, and it also greatly eased in implementing the Slide ability.
Disabled colliders turn red and allow the player to move smoothly across
Pushback
The last feature missing from the Box creation ability is the pushback when the player is too close to a wall or creates a box downwards. I started by getting the box to lerp to its desired position instead of teleporting. While the box was “growing”, it checked for collisions, and if a collision occurred, it would stop the box’s position and move the player in the opposite growing direction.
Creating boxes with pushback
Result
Conclusion
Looking back on what I managed to develop within the given timeframe, I’m proud of the final result. Being able to create boxes and place, push and slide them around has been very fun and imagining different puzzles where players need to work together to advance has been such a motivator during the whole project. The joy I got from designing small levels to play around in and for testing and finding edge cases has just reinforced to me that developing games is exactly what I want to do.
With more time, I would have also wanted to implement the Up Hook ability, as well as design some cool levels to play around in.
The co-op implementation, however, is not exactly how I wanted it to be. It got sidelined due to the implementation of the Box Creation. In the final result, both players can move, create boxes, and interact with each other. However, some visual feedback is delayed, for example when the other player creates boxes, they only get visualized after they have been placed down.
I’m used to working in a team where I could discuss problems and solutions, so having to develop a project all by myself has been fun, challenging, and educational. If given the opportunity to redo the specialization project, I would have wanted to collaborate with a level designer who could create levels, which would also have helped discover even more edge cases. I also felt that wanting to implement online co-op features was a bit to ambitios of me, given the timeframe. I would still want co-op, but would have med it local co-op instead of online. I wouldn’t have to split my focus between implementing gameplay features and network-friendliness. It would also be easier to test and find bugs.
I am part of The Game Assembly’s internship program. As per the agreement between the Games Industry and The Game Assembly, neither student nor company may be in contact with one another regarding internships before April 15th. Any internship offers can be made on April 27th, at the earliest.
brandon.mach2003@gmail.com
(+46) 724317846