Postmortem


Postmortem

Team Jaguar, a cast of 6 strangers joining together to create “Rocket Jump”, a 3D puzzle-platformer to explore game mechanics. We created this project over the span of 3 weeks in the month of August 2018. The 6 strangers all live in different places across the United States.

What went right?

1. Despite being long distance, communication was strong with Discord and Asana

Communicating took a long time in our first week; waiting for opinions and determining the direction of the project breakdown. It was a struggle at first but by the final week, we were able to streamline opinions and keep the direction of the team together. We started using Asana, a workflow management application and that helped keep everyone on a task.

2. We all got to explore roles

I started this project primarily as a programmer and developed the mechanic for "gravity inversion". I then switched to a level designer once my mechanic was cut. My teammates experienced similar experimentation with various contributions. I enjoyed being the level designer, testing the limits of the mechanic. I really enjoyed making areas and when they are played as intended, they give me a certain type of satisfaction.

3. Expandable

I can think of a few other things to add to the project. I can continue to play around with the level design and explore the limits of the mechanic. Every time I play through this game, I think, "Oh, I can add this...and that...".

4. Easy exploration vs challenge

On one had, I want to give the players free exploration opportunities but on the other, I want to challenge them. I never wanted to build one of those stress games but the beginning portion of the secret section ended up being hardest because of how specific the player's actions need to be. I basically had to learn maximum values and translate that into a challenging level. Building level constraints based on the character's maximum values forces players to proceed in the direction I wanted them to end up. It was a bit like making decisions for the player and I don't like that. So there ended up being opportunities that could be completely skipped depending on your decisions. I think to myself, "but wait, there's this awesome section that you should see, just to see what I made for you!" and then there's the nagging feeling, "is this fun?" or "shouldn't there be a reward?" So there ended up being plenty of different paths a player can explore and that is why there is a linear playthrough path which is about 10% of the level and then there is the secret section which has but one specific goal of testing the jetpack's limits that makes up 90% of the level that can be completely overlooked.

What went wrong?

1. Changing mechanics

At the start, we each decided on a separate mechanic to implement. The first iteration of the game was a toggle switch that allowed a standalone behavior of each one. There was a teleporter, a time slow, a jetpack, a gravity inversion, a wall run, and a double jump. None of the mechanics were dependent on each other so it was less of a game and more of a demonstration. The second week, the number of mechanics was reduced by half, but they tied together cohesively unlike before. Then by the third week, we cut two mechanics and focused solely on the most exciting one. This production cycle felt a little like "chasing one's own tail" and that leads me to the next point...

2. Wasted(?) development time.

Cut mechanics means lost development time. Regarding mine, "gravity inversion": It was a cool and entertaining mechanic which opened the doors for some fun game ideas. Except I ran into several issues: because this was a 3rd person perspective, players can see the character and we needed to flip him too in a separate function (script). I also needed to adjust the camera to keep it "floating" above the character's head (In hindsight, I also realize that I needed to flip the camera too). This was eventually working but there were two bugs: One we worked around by preventing the player from flipping while transitioning from one gravity input change to another. This detracted a little from the fun factor as the player loses control temporarily. The second bug was that the character could face North, West, or East to experience a perfectly working gravity inversion; but not South. We designed the level to work around this but it was a game breaking bug so we chose to cut the mechanic entirely. Therefore, the final product indicates that I did not work on the project for a week. However, I feel I learned a great deal about programming so it was not a complete loss.

3. Changing numbers / maximums

At the beginning of our third week, I started designing the level based on the current iteration of our rocket jump. Over the course of the week, the power numbers would change and therefore, the level had to change again. At first, the rocket jump could take the character 600 units on a single tank of fuel. Platforms were largely spaced out. Then the rocket jump could only reach 129 units on a single tank. This gave the rocket jump a better feel, as far as input goes, but it forced the level to change drastically. It was a little frustrating to redo work but the final result is stronger and more linear. I can see this is how companies can fall victim to the crunch phase.

4. Level designing as we go

As a designer, I believe that my games should start easy and grow in difficulty because all the skills previously learned will be needed towards the end. So I went into this with the intention to make a plan first. I drew up a brainstorm sketch but I could not translate any 3D ideas onto Google draw. So I abandoned the sketch and designed directly in Unity. As I was turning, rotating, and zooming in/out, I said to myself, "that would be cool if I did ___(insert action)____ here." This method created a level that was substantially particular in certain areas with unexpected paths to open up. This slowed down production because all I wanted was to have one simple path that leads to ending. However, building such a path that was interesting (to me) was a struggle because I was constantly having to test if unexpected paths opened up, as they inevitably would. In a way, my level designing was... like a tree that starts out from the trunk and heads up into a branch that leads to many other branches.Then all those branches could lead to either leaf nodes (dead ends) or back onto other branches instead of going straight for the apple.  Confusing, right? I think the only way to counteract this drawback, is to have a good plan.

Final Comments

John M: "Good Job! We did great! Thank you for everything. Good luck in this month and following with your games!"

Andrew W: "Good job on the final milestone guys!"

Data Box:

Developer

  • Team Jaguar
    • Geoffrey Brackett
    • Jakub Cislak
    • John Morey
    • Gary Nuckles
    • Andrew Waslo
    • Me (Chris Zapata)

Release Date

  • August 21th, 2018

Platforms:

  • Windows

Number of Developers

  • 6

Length of Development

  • 3-4 weeks

Budget

  • $0

Lines of Code

  • 608 Lines of Written Code
  • 1184 Lines for Character Controller and Camera from Invector

Development Tools

  • Unity 3D version 2017.3.1f
  • Google Drive
  • Discord
  • Asana

Files

Rocket Jump.zip Play in browser
Sep 14, 2018

Leave a comment

Log in with itch.io to leave a comment.