Starbot (Play it if you haven’t) was the result of the 26 hour Game Jam. First off, congrats to all the other teams for their games. You can check out the results of the Jam here. (eventually)
Here is a quick postmortem about the experience.
What Went Right
- Using Unity
Unity was great for me. It took about 10 seconds to get a live build of the game and put it up online for everyone to see. As well, Unity’s use of components made it really easy to create several similar pieces and just attach slightly different properties to them to make them behave differently. An example is that the teeth are just blocks that chase you instead of the core and hurt you when they touch you. The development environment of Unity is really great for a designer as it lets you really layout your folders and active game elements fairly simply. - Scaleable Design
We had some really cool ideas of where to expand on this idea, but from years past I know that just getting the core gameplay down is key. Even though we wrote down all the other cool ideas, we set out to have a very bare minimum functionality. My advice for Game Jammers is to try and have you game’s core mechanic functional and fun about 1/3rd of the way through the night. I also find that you always underestimate your own work time by 3. So in the end… we got the core mechanic functional. - Live Updating
The great thing about live updating is that it forces you to get the build to a running state. Since I tried to update every hour or so, this helped keep us focused to some degree. Plus it felt good. - Team Allocation
Everyone on the team was working the whole time. We did a decent job of managing ourselves. The artists spent a lot of time on the assets because we couldn’t really take in too many at a time. And Mike and I seemed to do a good job taking the programming tasks. It went much better than the year where I sat around as a “producer.” - Version Control
Mike and I used Git for version control. If you don’t know what version control is… The basic idea is that it’s easy to work on the same files at the same time and you have access to all revisions of your work. I honestly cannot image programming a game without it (Despite the free version of Unity being designed to break when you use version control (Hey, I have a great idea. Let’s fuck anyone that wants to use the free version of our game development tool that also works on a team (It totally wont piss them off and make them find an alternative before they learn the tools.)))
What Went Wrong
- Using Unity
Mike seems to hate Unity with a burning passion. It’s understandable, I think it was made for designers. I don’t really know how to program, I just type like they do on TV and stuff starts moving around the screen. Mike had some strange occurrences; like an if{} else{} statment that would hit both sides of the operation. Which brings us to our next problem… - Physics
I think Unity came up with a new kind of math that it neglected to tell us about. It’s hard to tell if working with Quaternions is always that messed up or if Unity just has no idea how to convert that shit to Euler angles. We ended up having so many weird occurrences with angles and collisions and junk that Mike spent a few hours of the night writing his own physics code. The game is pretty much a bunch of cubes flying around and colliding. We just hide the cubes and draw sprites over them. - Beautiful Assets Wasted
The artists, Benn (with two “n”s) and Tim, spent a lot of time making some high res models and art assets that I took and shrunk down to 32×32 sprites. It’s a total waste because they spend so much time painting renders of the models and junk like that. But in the end, they didn’t have a lot to do and they found a way to make sure they were always busy, so it’s not so bad. The main issue here is that we were constrained to the resolution I picked for the web which was too small to show the art up close and let you see what was going on around you at the same time. There was also a random angle bug (curse you Quaternions!) that broke some code for letting Starbot’s head rotate independently of his body. Benn was sad. - Scope
Even though we technically had a playable game, it was lacking a lot of polish. It’s way too hard. The instructions go away really fast. The objective isn’t clear. A last minute bug made blocks stop attaching to the core which makes it super hard. We didn’t get the physics to work how I had envisioned. We only did 1 level. There is no sound. There is no damage feedback. We didn’t really get to play with any game balancing or interesting mechanics. - Coming Prepared
While we were exceptionally prepared, there were two snags. One of our artist’s didn’t have Photoshop on the laptop he borrowed for the event. Luckily, our friend Jared brought an extra laptop with Photoshop on it. We got to use that most of the event. As well, the artists weren’t setup for Git/Version Control. Mike tried to setup the artists with Git near the beginning but it’s complicated. It felt like a waste of precious time because Mike is a Dark Wizard, and every moment he isn’t programming is like some sort of simile where I stress how important his work is. My suggestion from the beginning was that we just pass around a USB or hard-drive. Mike brought a 1Tb hard-drive with him which was great, but we had some issues with setting it up as a shared drive over the network. We were prepared. We did a good job with that. We just weren’t PERFECT prepared.
If you want to scope out a video of us talking during the Jam, watch this! (We skipped to the handsome part for you)