The Game Process
View Single Post
February 27th, 2013 (12:57 PM).
Lead Dev of Pokémon Essentials
Join Date: Jan 2008
In that setting, out of those two options, I think I'd prefer the first one (team first, build build build). It's more productive that way, and a game can be developed more by multiple people working on it from the start.
The second option limits how a game can progress due to being started by just one person. There's not much room to change things afterwards, since by the time other people come along with their (possibly better) approaches, you're over halfway through your allotted time. The presentations are no more than an extended brainstorming-and-team-gathering session that the first option's teams will get done much more quickly. There's also the fact that 75% of the students will end up being forced to abandon the project they've worked for 2 months on, which won't cause good feelings. There's also less opportunity in the second option to make sure the teams are built well - quite aside from the lack of time, projects will gain people based on the project rather than the team members, which means the people could very well not get on, which is obviously bad all round.
Just as I'd expect from artsy people. They don't think things through.
Now, let's get more generalised.
Out here, there isn't a demand that a game
to be made, and there's no expectation that a game will be worked on and succeed, and there's no guarantee of teams forming and help being provided, so the rules are different.
For game projects here, I would say the best approach is to start something yourself, and gather people along the way to help you. No one's being forced into a project, so you'll only get people who actually want to be there. It's a fact that getting ideas is easy - everyone has a novel in them, etc. etc - so the important thing is to be dedicated, productive and to show progress. You need to attract team members by playing on their desire to be a part of something that gets
, not by getting their imagination going (although that does help). You need to prove to others that your project is actually going somewhere, which means you need to show it going (via screenshots, videos, plans, demos, whatever). If all you have is a two-paragraph plot about saving the world, you're not going to get any help, because everyone can come up with their own idea that they'd rather work on, or at least find a better project to join instead.
Besides, productivity isn't linear. You can't have a status report every week and show off some new flashy thing each time. In one week you may have added half a dozen important menus, while in the next you may have fixed a lot of bugs which don't sound interesting but just needed to be done. If you announce a game right at the start, progress reports are going to be unsteady at best, and that will put people off if they're naive and expect big new things consistently (which most people do). in their mind, if you've worked for two weeks but don't have something fancy to show off by the end of it, they're going to wonder what you were actually doing and start to think your dedication is wavering (which can only mean that the game isn't that good). That's why you should hold off until you get at least something done, and preferably until you get to a stage where you know you'll get consistent flashy updates (e.g. new maps).
So yes, in the real world (or at least, in the Game Dev section), the second option OP mentioned is closer to reality. However, reality and OP's game designing course are two different things. Working for a gaming studio is a third different thing, and I have no experience of that so I can't comment on it.
The Pokémon Essentials Wiki
All Animations Project
Follow me on Twitter:
View Public Profile
Send a private message to Maruno
Find all posts by Maruno
Find threads started by Maruno