Advertisement

Do what you're good at or change for learning?

Started by January 23, 2001 11:22 PM
2 comments, last by Paul Cunningham 23 years, 7 months ago
In terms of Development Houses, do you think developers should stick to making games in one genre that they are good at or try making games in different genres alot of the time? The upside is that if you stay doing what you''re good at then you master or nearly do master the genre of game that you work on. But if you change channels then you might learn something that could be very useful if you decide to one day go back to making the games you originally made. How would you like it if Square started making FPS''s or the makers of Fallout 1 or 2 started doing sports titles etc. Please note that i''m talking about the developers not the publishers as we all know the answer there. So should developers be risky and do different things or should they stick to the conservative life of repitition and gradual steady improvment hoping that know one elses risks payoff and put them in the red? A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew
Tough question. One thing to think about: Is it that certain developers are "good" at a certain genre, or is that they are just much more interested in a certain genre.

What if the developers of Fallout are not much of sports fans? They may not know how best to simulate the effect of playing a sport on a computer.

So, IMO, opening your mind to a totally different genre is not bad, but staying within a genre and still stretching yourself is not bad either.

Developers who just keep making the same game and just add features are really limiting their minds too much IMHO.

http://www15.brinkster.com/nazrix/main.html

"All you touch and all you see is all your life will ever be --Pink Floyd
Need help? Well, go FAQ yourself.
Need help? Well, go FAQ yourself. "Just don't look at the hole." -- Unspoken_Magi
Advertisement
Perhaps a cycling approach. Work on two different products of two different genres at the same time, with two seperate teams. When one product is completed on one line, move some of the developers to the other product line, and when the other product is completed, some of those developers also switch products. One product line could be single-genre, while the other line could be one of any number of genres.

This could allow for the developers to gain new perspectives from other genres, while maintaining a strong core product line. Also allows for different combinations of people working together on each product.

There is a lot of bleed-over in the genres now, and this is not necessarily a bad thing. We''re seeing RPG-like concepts in sports games and RTS games, and RTS like concepts beginning to appear in RPGs (ok, probably not too much sports in RPGs).

Also, not being a fan of a particular genre that you''re working on is not always a bad thing. You could bring in a truly fresh perspective to the product this way. And sometimes the genre will grow on you. But be sure to mix things up, the majority of a team should enjoy their genre, if possible.

-pwd
Tough questions are the best Nazrix In retrospec and after reading your (2) posts people i''d think the question is probably too open to be discussed in the way it was originally implied. It''s really a managment issue that would have to be applied separatly to every development house. Every individual developer would be different. Some may be more versatile while others will benefit from specialization. It all comes down to the individual staff member. I didn''t mean for this to sound like a trick question. I should have worded it better originally. Cheers for the feedback

A designer doesnt need to know everything about code, they just have to have an appreciation for its limitations and how those limitations affect features they may wish to include in their design. - Drew

This topic is closed to new replies.

Advertisement