Backstory
A week before Brackey’s Jam 23 I had no intentions of working a game jam, but a few pals were interested and that was enough to get me involved. Becoming entrenched in the week-long Brackey’s Jam 23 tested team determination, experience, cohesion, and strategies against our collective intentions behind the jam. We came together with the goal of completing a viable game loop with the jam theme “Diving Deeper”. During our initial design and feature meeting we devised a plan to build a game now titled “Ragnar’s Rock”, a game about an asteroid mining, space-dwarf wielding a throwable hammer.
Half of the eight-person team joined a day prior to the jam. Everyone had met one another previously, either in person or virtually. Our collective skillsets included audio engineering, programming across multiple game engines, project management, game design, and art/animation. For privacy purposes, I will refer to member functions/roles only.
Having determined as a group that we would start the project as a 2D Top-Down game, daringly using Unreal Engine 5 as a foundation, we were all in agreement on the initialization of the project. I know UE5 is a massive 3D engine, but we were agreeably open to the challenge and learning experience, which we will soon dive into more.
Our scope was quickly framed out by the team and road-mapped quite formidably by our lead project manager. A GIT repo had been established prior to the start of the project and merge strategies were discussed at that point as well. We had a solid foundation to start the project. As a team, we agreed to create a space-mining, 2D top-down, complete with 10 levels, a single common enemy, a boss battle, a simple GUI to display HP and the quantity of gold collected, a mining hammer, and a lite upgrade screen between levels. This hastily gathered team had immediate chemistry, outstanding communication, and a strong sense of unity on roles and scope.
Results
Despite our best intentions and greatest effort we did not complete Ragnar’s Rock in time to submit a game for Brackey’s Jam 23. I spoiled the result of the jam early in this post to help you understand the context moving forward. Everyone worked really hard on this project and each member respectively produced outstanding work. So why did the project fall short of meeting the scoped-out, road-mapped features? I’ll explain all of that shortly. First, I want you to know that despite having missed our deadline, I would work with any one of these members again with sharper focus and stronger frameworks for success. More time would have helped too, but it’s a game jam. They’re intentionally short. Yet another spoiler, the good news is that we do intend to complete the game and publish it publicly on itch.io.
What Went Right
I feel we went in the right direction on the game theme of Diving Deeper by having 10 mining levels. Where most developers would immediately go towards the obvious water diving parallel, early into ideation I had my fingers crossed that our team would not succumb to a water-based game theme direction. Members arrived at the decision to create a dwarven mining game with a vote of 5 for the miner game, 2 for a magic schoolbus-inspired game, and 1 no-vote due to absence. We established and agreed upon the theme and scope from the start, making the game development fun and motivating all team members to see it through. We were all constantly excited to see our character smash space rocks and defeat a nasty big bad. That synchronous spirit fueled cohesion and determination.
Out of our team of eight, several members had worked together before. From day one, we established the feature set for Ragnar’s Rock and quickly assigned roles. Some members had cross-roles, such as a programmer who would dual purpose as an artist. Moving into development, each member consented to their roles and tasks. There was no doubt about it.
The lead engineer on the team proved his experience in UE5 and was able to strategize building a 2D game in such a massive 3D engine. As the first member I recruited, it was his choice to use UE5 and thus his responsibility to live up to engineering the 2D world within. He quickly rangled together the powers of Paper2D and PaperZD in UE5 and with some of my old game art from another project, we had a defacto prototype.
I served as an alternate engineer along with our lead and two other members. One of our four engineers had no significant Unreal Engine experience. It’s impressive how swiftly he picked up on UE5. The character artist did an amazing job at an eight-direction character animation. Tileset textures by the environment artist were second to none and he put together a terrifying boss enemy! I was happy that the same artist working on the environment was also working on the enemy because Ragnar’s Rock was all about a space miner trying to survive the domain of this creepy spider queen while trying to do his work as a miner. I also did level design, and character grunts for SFX, and I led the initiative on GIT version control. The audio works were impressive and just as spooky as you would hope for in a deep-space, bug-infested asteroid miner game. Props to the entire creative team for producing standout, original content for this short-term project.
What Went Wrong
TL;DR Git version control! The stuff of nightmares!
The real story behind our shortcomings is all in the Git. I personally bear the responsibility of falling short of strong Git reinforcement. However, despite my best intentions and best efforts to encourage good practices, the hard truth is that every engineer defied those intentions. Sidenote to my team: I’m sorry boys, this is the hard truth of the matter. Forgive me in advance. This is what this reflection is all about, right? I truly wish we were tighter with version control.
Stepping back just a bit, it’s fair to mention that I’m an asphalt contractor full-time and my hobby game dev projects are a lower priority than running a business to provide for my family. Unfortunately for Ragnar’s Rock, I simultaneously started a 10-day project last week. Initially, I beat myself up thinking the frontload of the project could have used my guidance and aid a bit more. Retrospectively, it’s only partially true. I could have spent more time directing the engineering team on Git repo best practices. Despite the strong start, team members discarded the initial branch strategies and feature ownership halfway through the project.
Engineering members were outspokenly determined to work on the same features, down to manipulating the same file on separate branches asynchronously. Reflecting on the fact that I am still a rookie, I approached two external sources to discuss whether or not our merge strategies were solid. So far, the standard practice appears to be as follows: Establish who owns each feature. Map out how each feature will interact with all other features and who needs access to those features’ scripts/code. Determine how the logic will connect through encapsulation so as not to be forced to manipulate the contents of files you do not own. If you need more functionality or cannot move on without some work done on a feature you do not own, reach out to the owner and discuss strategies. Finally, commit and merge often to ensure everyone is current and the project features play nice when merged.
During development, we encountered several conflicts. I held meetings to remedy these conflicts, but the demand of attending to these issues and other acute matters weighed heavy on myself and the lead engineer. Eventually, the team outright rejected and abandoned the use of Git. If you know anything about Git and why you use it you may know what happened next. Sharing files over Google Drive on the last working day caused an inexplicable loss of my work and personally, I lost the motivation to continue. Feature creep was another leading factor in our demise.
The only other hitch we had was in character art. Our character artist worked longer than expected on the main character and burned out, rendering himself unable to complete the enemies and boss. Our environment artist took up his torch and finished strong with a bone-chilling queen spider boss and fantastic title cover art.
I can’t directly accuse communication failure of being a culprit in our shortcomings, but we could have used a tighter agreement on execution. Overall, members fulfilled their roles and responsibilities. If you asked anyone about our communication, they would confirm that we met regularly and discussed issues promptly via Discord. We simply lost too much time dealing with merge conflicts and feature creep.
Takeaway
It’s safe to stick to your lane sometimes, but you have to push the boundaries to grow. We started this project in UE5 because some of the initial members had experience in the engine and we did a 2D game because all members had experience with 2D. However, I personally will not be working with 2D games in UE5 in the future. For 2D top-down games, I will continue in Unity. The next jam I do with Unreal will be exclusively with 3D assets, which I’m comfortable with creating and texturing.
I will definitely be working with members of this team again. I don’t see any reason not to. Understandably, some of us got a little overambitious towards the end and Git got us pretty bad. Each member of Ragnar’s Rock rocked hard! Each member of my team had a skill set I would like to see in action again. Next time I take charge as a team lead or a project manager, I promise I’ll be a stronger leader. I hope each member felt supported by me during this jam. Even though I am still learning, I wanted to serve the team as a guiding light and a resource. See you all on the next one.