March 21, 2008
Game Development
1 Comment
This is pretty straight forward, but creating something for your game and bringing it to a finished, shippable state is the only way to go.
“But Jesse, we don’t have time to get it finished! We need to just get it working and move on!”
Bzzzzt. I’ve seen it time and time again. We’ll create some half-baked prototype feature, get an event “working,” put in a temp animation, or place a temp texture. Then, people on the team will start complaing about it, laughing about it, or whatever. Placeholders tend to stay in the game for way to long, and it starts demotivating people. It’s really hard for people, even those working on the game everyday, to see past temporary and placeholder assets. And that’s really bad for team morale. Above all, everyone on the team should believe in the game you’re working on, and placeholders won’t help with that.
Okay, not all holders are bad. I think in some cases, if they look really close to final, that’s an okay thing, especially if you’re placeholdering for memory concerns. I think this is espeiclaly true for sound and VO. However, really bad, or even medicore placeholders will damage team morale, and I think hurt the overall quality of the game in the long run.
> – – – Read the rest – –
February 29, 2008
Game Development
No Comments
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.
> – – – Read the rest – –