Trebuchet Rivalry
4 weeks
6 collaborators
Unreal Engine 5
Perforce manager
Programmer lead
Scrum master
Buildings
The building system gives the player a temp mesh for each building types without any of the anchor fields or destruction. It uses a simple clear material that toggles red or green depending on valid placement.
When the player finds a valid place and wants to spawn one of the building, the server gets notified and spawns the last selected building using the transform from the temp mesh.
Scrum Master
Scrum master was a demanding but also fun and rewarding task. My main goal from the start was to make everyone feel included and not to overscope our project.
​
To get the tasks more organized we used Trello and color coded the tasks red, yellow and green to mark importance. The bigger tasks had sub-tasks that could be checked when done.
​
The most important and heavy features for our game was the destruction system, economy / building system and the physics driven trebuchet. We discussed adding multiplayer day one but since no one had worked with anything similar before, we as a team felt it was ambitious so we scrapped it, only to add it to our top priority with 2 weeks remaining.
​
We only had two active programmers at this point in development and we both had plenty to do, so we scrapped different ammunition types, the AI and decided the destruction system was completed in its current state.
It was hard to getting everything to sync and to adapt all the other programmers system to work and to be replicated correctly. What made it harder was that our base systems was written by a programmer sick with Corona, and the code was all the way back from our rushed prototype phase.
​
In retrospect I was very happy with my team and the results we produced. I learned a lot, especially to work with different personalities and to adapt accordingly. I was always open to talk and often had one-on-ones to keep everyone engaged and included without stealing too much time.
Some students in the group suffered from burnout, others insomnia and we also had a bad case of Covid. The group didn't have a project owner for the longest time but still we managed because we had awesome communication and did the best we could given the circumstances.
Multiplayer
Multiplayer was demanding but necessary for our project. It was never our main goal to have multiplayer but since everyone who tested the game said it lacked fun factor and it was like playing battle ship solo, so we decided to add it very late in development.
​
I made the server handle anything gameplay related, and it would broadcast it to the relevant clients. For example, when the projectile detonated, the impact would only be handled on the server, and when the location and direction of the impact was set, it would spawn the detonation on all clients to get the same impact location and direction to make the destruction look alike for all players or when the player fired the trebuchet,
​
If given more time I would make sure to test more on higher latency and do more multiplayer tests with the team.
Game Mode
The game mode started as player vs building real time but was converted by me to turn based after some reoccurring feedback. It is divided into phases, one for setting up the game, building placement and the combat phase.
​
The server controls the phases. When a player joins it will get a player index to keep tabs on the players to avoid mixing up the score or spawn locations. The player first spawn in with a simple floating pawn and the building UI. After all buildings are spent, the pawn is destroyed and the player possesses their animated character.
​
The turn is switched when a valid interaction with the fire leaver is made until all buildings are gone on the opposing side.
Wind
The wind was originally designed by another programmer who was kept busy by our big economic system. The old wind was a component attached to the trebuchet itself, that checked for the child component projectile when applying the wind. The wind never updated and didn't translate well with multiplayer and the new turn based system so it had to be updated.
My new wind is updated between player shots and handled by the game mode server side. To avoid to sharp changes to the wind, the current wind direction and strength is updated using a lerp towards a new random with a timeline.
If the other player is quick to respond and the turn is switched before the value is fully realized, it will restart the timeline, and use the current wind and lerp it towards a new random.
