flipCode - Tech File - Phil Carlisle [an error occurred while processing this directive]
Phil Carlisle
Click the name for some bio info

E-Mail: phil.carlisle@team17.com



   02/23/2001, Tech File Update


Have any of you wondered where all these "killer" PC games have gone? things like Black and White, Duke Nukem Forever etc?

I was thinking about what actually makes a game project go astray and it seems to me, that one of the main factors in the mess of PC developments is publisher/press expectation.

I was talking to someone here a while ago, and we were discussing what is "required" to be in a modern game. My line was that people are actually happy with a LOT less than most people expect. Especially with multiplayer games. My contention is that games can actually be very simple things, without needing huge amounts of content, as long as they make the core aspects of the game playable.

Then the guy I was speaking to suggested that publishers would simply not be interested in a game that wasnt stuff full of content. I can understand the urge to do that, but I think its completely the wrong direction. What this means is that there is a cycle of games requiring bigger and bigger content. So you end up with the problems that B&W and DNF have suffered (huge teams, lack of focus and direction, slippage etc).

IMHO, the only people who have been able to pull this off are the japanese giants (nintendo, sega etc), and maybe thats partly because theyve got a LONG history in large development efforts.

I'm becoming more and more a fan of iterative development and design. That is, you create a single element, try it out, and if it works, move on (always focussing on wether things are actually WORKING).

I'll give you a good commercial example. Halflife, it was a great game, had a HUGE amount of content, and slipped a lot. You look now at the multiplayer section of halflife, and you see a whole bunch of VERY simple mods (counterstrike, wasteland etc etc). Obviously the mods are building on the technology of halflife, but in the end, they are just simple concepts (two teams shooting each other or whatever), and they seem MUCH more compelling than halflife itself for a lot of people. Cant remember the exact figures, but apparently CS is the most played quake type game on the internet.

My point is that people WILL play games that dont have 1000 objects, and 100 levels etc. I dont agree with publishers that more is better, I think that better is better :)

So this opens up a few questions in my mind, DO games have to be big to succeed?, can you successfully market a game thats not huge?, is there any place for small developers producing small games with small quality driven content? Is it only acceptable in multiplayer games (where in effect the other players ARE the content).

I saw a recent issue of a developer magazine, where a guy from Kuju interactive (who?) was bemoaning the fact that small developers were bringing the cost of development down, he was saying that small independant developers were BAD for the games industry. Well, as you can imagine, I agree with him completely (NOT!). Firstly, I can see his point, small developers tend to do things on a shoestring budget, and hence can undercut larger development studio's. But since when has being more efficient a crime?

What the guy was really saying was "I hate small developers because they make it so I cant charge as much". Simple really.. The point that small developers are BAD for the "industry" is insane, small developers have to rely on thought, design, innovation and luck to get by, but they have as much right to claim that they are part of the "industry" than anyone else.

Ive long held the thought that games are like music. A few big giants in the industry control 954576327f the "market", but that doesnt mean that small groups cant form a niche of thier own, or band together to form thier own market. And it certainly doesnt mean that bigger companies produce BETTER music. Far from it.

Phil.





  • 01/09/2002 - Tech File Update
  • 04/03/2001 - Tech File Update
  • 02/23/2001 - Tech File Update
  • 02/19/2001 - Tech File Update
  • 01/12/2001 - Tech File Update
  • 11/25/2000 - Tech File Update
  • 11/02/2000 - Tech File Update
  • 09/28/2000 - Tech File Update
  • 08/21/2000 - Tech File Update
  • 07/03/2000 - Tech File Update
  • 06/05/2000 - Tech File Update
  • 05/22/2000 - Tech File Update
  • 02/29/2000 - Tech File Update
  • 01/27/2000 - Just An Update For The Tech Files
  • 12/23/1999 - New Years Tech File Update
  • 12/08/1999 - Update To Techfile
  • 11/30/1999 - Introduction

  • This document may not be reproduced in any way without explicit permission from the author and flipCode. All Rights Reserved. Best viewed at a high resolution. The views expressed in this document are the views of the author and NOT neccesarily of anyone else associated with flipCode.

    [an error occurred while processing this directive]