It’s been a while since my last update, but that just means we’ve been hard at work on our game! Action Cactus has had a really wild October developing (the newly named) Showstopper. This time, we’re going to talk about how Unreal has been a predictable roadblock up until this point, where the project is currently, and then we’ll close out with a look into our radical idea for our second semester. This is a look at the process we’ve taken to get where we’re at, and what decisions we had to make to get here. This is a long one, so buckle up.

So we’re starting with the elephant in our team’s room: Unreal. Going into the summer, we had already discussed as a team that we wanted to try using Unreal for our capstone. The goal was that we would learn the engine over the summer as to not waste time during the semester. I followed through with that plan, but Jacob and Andrew ran into life getting busy and were not able to start until the semester started. One programmer picked it up pretty quickly, but it took some time to get going. Unfortunately, the other was not working with Unreal as easily. He went about 3 weeks without completing any tasks, simply because we would either give him too difficult of tasks to be learning Unreal alongside, or he would work on something alone and get frustrated and stop.

We had a really tough meeting a few weeks ago where we essentially had to work on what our move was. It was too late to get rid of Unreal, but the programmer was clearly against using it because of his frustrations. Instead of just attacking him for his lack of work, I worked to think of ways we could make things easier for him. One solution we had was was to get all three of us programmers together more often to program alongside each other, and apparently that was all we needed. Once we had a meeting or two of doing this, all of his reservations and anger flew away because we could walk him through the problems he was facing. Our last sprint was our most productive yet simply because we had everyone firing at all cylinders. That meeting we had was extremely tough and demoralizing to sit through, but it was a necessary step to getting the team back on track, and I think it made us stronger as a group because we were able to talk through the problems, rather than hold grudges and ignore the feelings of someone.

So now that we’re back on track, where is the game at? Well we’re actually, surprisingly, still on track to deliver our core experience by midmortems. Jacob programmed the core loop of the experience in so that players could start the game, play through a best 3 of 5 round system where the stage layouts will switch, and a results screen will be shown. Andrew worked on converting some of the game’s back-end into C++ to give us more control, as well as adding the remaining parts of the player moveset to the game. I’ve been simultaneously doing documentation, running QA, and implementing the crowd favor system and rising ropes. What we have now, as seen in the gifs, is the players are able to move around, die on each others’ weapons, gain the favor of the crowd, and play again. We also have Michelle’s first iteration of the stage.

The curtain raises before a round and the player double jumps around.

The player “cuts” the rising rope and flies up to the upper level of the stage.

The player raises on the rising ropes and demonstrates the dash.

Our core experience for the game relies on the ability for up to four players to be able to play through a match where each round has a show objective somehow tied to dying on an enemy’s weapon. The players should also be able to do smaller tasks that contribute experience towards a bar that unlocks content for the player. We have a lot of random ideas and plans for second semester, but this is the core of what we are trying to deliver this semester. Our team works well by getting base of our systems in before we make them all visual in some way, which means that what we can show of the game is a bit slower, but we like to make sure our development is moving forward so that we don’t have to step backwards.

Something that the team, but specifically I, have to work on based on the feedback of our presentation is making our current work and plans clearer. We have been dinged for not showing what we’re planning and for planning too much ahead, so I think a lot of that stems from our class’s confusion with what is meant for midmortems and what i sjust being planned.  This week specifically I will be working on clarifying all of that.

Speaking of our plans, let’s discuss this crazy plan I have for next semester. As a team, we’ve discussed second semester as a chance to build the game out with more features and content, rather than just adding more of what’s already there like a level-based game might do. We also have our unlockables system that’s very akin to an XP bar or a free Battle Pass. Last week, an idea sparked into my mind that put a lot of pieces together and gave me a clear vision for where I see the game, so I organized my thoughts and brought them to the team.

Essentially, I wanted our team to do something wildly different with Senior Production for two reasons:

1. to stand out from the crowd in some way besides how cool our game is
2. to gain experience in an area that developers are having trouble finding students with, from what I’ve heard

We believe that Showstopper will have a solid base for the game done by midmortems. Our idea is to run our Senior Production team as a live game instead of just agile development towards finishing the game by the end of the semester. Senior Production essentially already facilitates this, with just continuing to make our game. However, there are key differences where we would be branching out and taking a risk.

At the end of this semester or beginning of next semester, we would launch Showstopper on itch.io for free. Brett would begin facilitating a community through Twitter and Discord, trying to get players to play our game and give us feedback on it. He would mainly target friends and family who might be interested in the game, but this would essentially give us a playerbase that an Early Access or Games as a Service game might have. We’d be able to run new features by these players and get feedback on the state of the game. However, since it would be hard to guarantee a playerbase outside of school, we would work with Professor Ferguson on waiving the QA requirement for a certain amount of students to instead have them be our local playerbase to meet with us weekly for similar reasons as the online playerbase.

The other major difference from Senior Production we are shooting for is to structure out semester into content drops. These would essentially be 4-6 week cycles where we plan everything we can do for our next update and work to develop, test, and polish that all in that timeframe before we ship it. Agile development is supposed to let you have a potentially-shippable project at the end of each sprint, but in actuality you only have shippable projects at major milestones. These content drops allow us to get a good feel for how companies update their games and take feedback to keep the game fresh and fair. The drops would include fresh content for our Battle Passes as well as new features and quality of life changes.

When I pitched the idea to the team, everyone seemed to be really excited about getting experience that recruiters were looking for as well as making ourselves standout with a unique experience. Developers I pitched this to, such as our design advisor Brenton Woodward from Bungie and David Nathanielsz from Velan, thought it was a really interesting experiment that they’d never seen before and were interested in seeing through. Finally, when we pitched it to our class, everyone seemed to think it was a risky option that could pay off massively if done well. Hearing all of the excitement about it meant we were pretty set into the concept, and now we’re working on our plans for how these systems would work to streamline our pitch moving forward.

Ultimately, I think we’re in a pretty good place with the project so far. Midmortems is fast approaching and a lot of our game is pitching well but taking time to implement, so we really just have to put our heads down and make sure our game can live up to the hype we’ve set for it. I’ll most likely be back next week to discuss how we worked to streamline how we’ve discussing the game in order to maximize clarity.