Meetings…

February 29, 2008 4:32 am Sir Haxington Game Development

So, I’m not a big fan of meetings. Actually, I like some meetings, just not most. For example, when we get talk about cool shit like weapons and give input on how they feel, that’s a good meeting. Hands on meetings, where you get to play the game, those are awesome.

The problem is that most meetings I take part in aren’t typically about cool shit. They’re usually about addressing on-going problems. That’s all good if we actually get to the root of the problem. What isn’t good is when people have to leave at a certain time, but we “have to get through this” before they leave. Those kind of meetings tend to waste peoples time.

I’ve been reading a lot of Joel Spolsky’s book called “Joel on Software.” If you haven’t read it and you’re in the games / software industry, you’re missing something huge. Anyway, one of the core points he drives home is to fix code before moving onto something new. The idea is that if you’re working on some problem, and you encounter some bugs, it’s better to deal with them now instead of having to relearn the problem later which takes way more time from polishing the game or adding new features. It hits home for me since I’ve been through that many times. The other nice thing is that you get an awesome, stable base to build things on. Also, if you have to cut some features because you ran out of time on the schedule, at least what you have is solid.

So, I don’t see why meetings can’t be run the same way. Basically, you say “Okay, here’s a bunch of stuff we want to get through, but we’re going in order of priority and we won’t move on until everyone in the room is satisfied.” Then, if the meeting runs long, at least you have marching orders and clear direction on all the things you were able to get to, instead of a smattering of bullet points here and there on various topics. You can always get to other stuff later.

Which brings up another point. We need to work on making sure we get to the root of problems as much as possible. Identifying the high level problem is a good start, but really, I think people should get down to what is at the root of the problem.

For example, lets say the contact distances are too far apart between the enemies and the player. Okay, we found out high level problem. Now, what does this stem from? Is it that the physical distance in the level too far? Maybe the enemies damage the player from too far away and force the player into cover too soon? If the physical distance is too far, is is because the enemies are spawning in too far, or is it there there isn’t enough cover between the player and the enemies?

I guess what I’m getting at is sometimes in meetings, I get into situations where we identify the larger problem and start patting ourselves on the back and move onto the next thing. Or worse, we get tracked with “blue-sky” ideas (don’t get me wrong, this isn’t always bad, but when people need to leave and we’re trying to get going on some serious issues, I start thinking I’m going to have a seizure). I think if you want to be successful and solving problems, you have to attempt to break it down as far as possible and really get to the root of what’s causing it. The reason being is that eventually, someone is going to have to fix the problem, and if you get break it down into the core, you be able to easily identify who is best suited to fix it.