Co-Rope (FGJ 2015) Postmortem

This weekend I participated in the Finnish Game Jam in Helsinki. This year I wanted to get back to gamejams. Past October I was a volunteer on the Junior Game Jam and, besides helping the kids, the idea was that the adults also made their own games, so I had some warm-up, but this GGJ was quite interesting, so much that I think it deserves a postmortem. This is my own personal opinion, and I figure that the other five members of the team may see things different, but this is my take out of the weekend.

During the ideation phase, four of the six members of the team (myself included) worked together on the same pitch about the theme What do we do now? Our initial pitch was a very abstract idea of a co-op infinite runner about two cubes tied by a rope. I think that this process went so smothly that only one of the people involved in the pitch decided to go elsewhere.

The result of two days of work was Co-Rope. It was quite obvious since the pitch phase that this project would be 3d and made with Unity. I haven’t used Unity on a Game Jam before, and we made a lot of first timers mistake, but after using it I feel that is an engine that can be used successfully on a game jam, because most of this problems are quite easy to solve if you are aware of them.

What went wrong

Art asset integration: My bad, because I thought of it just when we were going to start, but I ended up being caught in the fun of coding and we ended up with assets with weird scales and incorrect axis. This was a problem because we had to expend time tweaking the game when we put the right models in. The worst part was that I didn’t manage to do a fancy animation when picking up coins because the transform needed so the model displayed properly was a little funky.

For my next jam I will encourage not using any Unity basic 3D objects but request the artist to make placeholder assets with proper sizes, scales and axis. .

No time for iteration on levels (and a lot of lost content): The current version submitted at the GGJ website has six “chunks” of content. If you poke at our Github repository you will see that we had six extra medium difficulty levels and six extra hard levels. We end up not using them because we were not happy with the easy ones.

The initial idea was to have a lot of things that hit you and make you lose rope and a small amount of holes and saws (different flavours of instant death, one by hiting it with the player and the other if the rope it it). The artists used the “puddle” a lot because it kinda fitted the theme, but the game was too hard.

We cut the jump, because we wanted to focus on left-right, but with the current layouts would add quite a lot because it would let you avoid puddles even if you don’t have rope (which you cannot regain) to go through the other path.

This is probably the part of our game that would have improved drastically if, we would have added stuff to the game progressively and not a big data dump at the end of Saturday.

Having a single scene: Without it being as big problem as the asset integration, having only a main.scene file proved to be not the best, specially when we had to configure something there.

Probably the solution would be to have either multiple scenes that are loaded additively or, at least, use prefabs to configure all the parts of the game. So if somebody changes the scene, recreating it it’s just drag and droping the Prefabs there.

Optimizing for “weird setup”: Starting with the small issues I have with the end result, I am not sure that the work to tune the game to be played with two Xbox controllers was worth it. I feel that the most common setup the game will be played is the split screen keyboard and I think we should have put more love to it instead of a last minute hack.

Lack of debug options: Not as big as the other ones, but as a small advice for the future. If you do a hack more than two times, consider exposing a switch to enable/disable it when it is needed again. I don’t know how many times I hacked myself invincible to test things like rope render and coin animations.

Logistics: As a first timer in a on-site game jam, I didn’t really think much about food supplies or equipment. Wasn’t a big problem, because our site was located on Sörnäinen and it has Fafa’s Kallio around the corner and a very convenient K-Market just outside the metro station, but when you are working it’s hard to find the right moment to go to the store. I already planed for a late lunch on Sunday, but we didn’t have a proper “lunch break” (luckily my team covered for me on video/website duty).

Hardware side there was plenty of network cables and mouses (I didn’t bring one) at the site. My only regret is installing everything on my laptop on Friday night. Even if I was planing of using one of the computers on the site, I didn’t thought of the possibility that my full team was going to use laptops.

What went right

Good team: I think we formed a very nice team. Most of them were experienced game developers, so it was quite easy to work with them. We settled on using Github for sharing code and we worked on things as we found they were needed. I don’t think more organization was needed because all of us could have made anything.

Scope: Maybe we were the “boring” ones, and maybe our professional experience betrayed us in this point, but we were very humble with our project ambition and we didn’t try to bit more than we could chew. Before starting working we talked about the resources we had and organized work as we thought we would be more productive. I put all the assets into the game because with three programmers and our game being a infinite runner in 3d, the work load was on the art department, so I did some “technical art” and some simple object animation (our only skeletal animation is the run cycle) so the artists could focus on modelling.

Theme: The basic pitch was completely abstract, and our first idea was using that the characters would be humanoid blocks (a little like Blocks That Matter) that were crazy and they would be causing mayhem in block world. One of the first tasks the artists made was finding a proper art style for the game, and while thinking about the crazy characters idea they stumbled on Japanese game shows a la Takeshi’s Castle which added a lot of flavour to a gameplay mechanic that we thought it was fun.

Productivity: Before starting I had already decided that I wouldn’t do crazy hours. I had to go to work on Monday so I cannot afford two days of extreme coding. I also don’t think I would have gotten much more work done because at 10PM, after being there for 14 hours, working started to be a little hard. I think going home, taking a shower and sleeping 6–7 hours, was worth more that what could be achieved with the extra hours.

Conclusion

Although there is a lot of things that went wrong, I am quite satisfied with the experience. I met a lot of new people and I learned a lot during those two intense days of game development. In every game jam I have learned something new. And, if only for that, the experience was worth it.

Working with other five people in a jam is a new experience for me. I think that I prefer working with somebody doing art than making games all by myself. Not that I don’t enjoy doing crappy pixel art, but I am not skilled enough on it to do it efficiently and, with the small time frame of a game jam, I miss having time to push myself to try new things or to polish the end result.

Will I do it again? Hell yeah! I have already reserved the weekend of the Ludum Dare 32 to do something. Not sure if I will have a team but, at the very least, I will be back with programmer graphics.