Last weekend, I went ahead and attended that Game Jam thing I mentioned a few posts ago. The idea was you have 48 hours to make a game based on a certain theme. I’d never been to anything like this before, and I can’t wait to do it again. So here are some random observations & things I learned.

the most good

I had every intention of going to this thing and not programming; I wanted to do music or illustration instead.

So at the start of the event, we were given the theme, and started exploring approaches to it. I started talking with some random people and came up with a unique idea for a game mechanic that I thought would fit the theme well… but of all the people in my newly found team, I thought I was the most likely to be able to implement the mechanic as originally conceived.

So I went ahead and filled the role of programmer in my newly found team because that’s what the project needed. Those of you who know me might be a little surprised by that. I’m generally happy to put visuals and other aesthetic considerations above mechanics, and for the most part, I enjoy creative endeavors more than programming.

I think — but I’m not absolutely certain — that was the right call; the mechanic seemed to be well received.

right the first time

Unfortunately, while I eventually did get the game engine doing what it was supposed to do, it took longer than expected and my code was never as stable or maintainable as it needed to be. What I usually do is, I’ll quickly try to get something basically working, and then do multiple passes at making the code better and better; writing something perfect the first time just isn’t something I do. It’s not about planning for me. The process of iterating over the code and refining it makes it good, makes me comfortable with it, makes me able to really quickly make changes to it later on. I’m breaking it in. Getting code that happens to work is the beginning of the process, not the end.

There was a lot of pressure to just get something that worked and move on, and things probably would have moved faster if I didn’t cave in to it, strangely enough.

I suppose you could say this was a learning experience about the importance of planning then, but I’m still happy with my hands-on, slow-at-first, fast-later-on approach, thankyouverymuch. There are certainly many things I could improve about the way I do things, but I suspect that changing my habits in response to some blunders during a weekend jam would be overreacting. Though next time, if I’m working with other programmers, even as an artist, I’d like to discuss the programming approach being taken before diving in.

part of the team

Sadly, being heads down with the code the whole time, I felt kind of separated from my team. And culturally, I wasn’t a great fit, so I was content to let the other people handle every aspect of the theme, presentation and story.

But… in some ways that was kind of cool, not knowing what my teammates were going to come up with. And it’s not like I was unprepared for the possibility that I would be in a team where I wasn’t a perfect fit.

I sort of thought that, as one of the few self-identified creatives at the event, I’d simply be auctioned off to a random team without much in the way of personal input. So I didn’t give it much thought. Next time I’d like to put more effort into evaluating my compatibility with prospective teammates before committing to being part of a team. Splitting into groups is, after all, part of this process.

next time

So who wants to do this with/near me at Notacon in April? 😉