Sign in to follow this  
  • entries
    375
  • comments
    1136
  • views
    297496

Bad move

Sign in to follow this  
superpig

100 views

I've just read the esteemed Mr Hattan's piece on why writing a game engine is a bad idea.

Fundamentally, I agree with him. If you want to make a game, use technology that is already out there. Use the stuff that is best suited to your specifications. Using a 'game-maker program' isn't uncool, it's efficient, and anyone who wants to continue asserting that the only way to do anything is to write it all yourself (preferably in assembly) can GJOAC.

However, I disagree with a few points - mostly the one about our not needing to make tools because our existing ones are 'mature.' That's right, they are; they've been in development for years now, refining the arts of things like per-polygon character modelling.

Guess what? Per-polygon character modelling is useless in the long run.

As the standard polygon budget for a highest-detail character averages out at six figures, we can't continue using tools that were created to work using five-year-old paradigms. The same goes for engines that were designed without any concurrency - rumour has it that all the next gen consoles are going to be multiprocessing, and we've already got tech like hyperthreading / dual-core appearing on the PC.
Sign in to follow this  


6 Comments


Recommended Comments

Hey, I'm just here to have fun.

Writing my own engine is fun (hell, it's a lot more fun than doing the content, that part sucks ass).

Share this comment


Link to comment
Quote:
Writing my own engine is fun (hell, it's a lot more fun than doing the content, that part sucks ass).


I'm starting to believe that Game Programmers will fall into two categories; the Engine coder (mechanic) and the Game coder (person who does the bodywork). I love mucking around with engines, especially after reading stuff like Code on the Cob, Enginuity and the like. There's a certain art to software engineering, a beauty of a nice smooth system that does things 'our' way. It's the same reason people write their own scripting languages, engines, renderers and the rest. But the simple fact is, it doesn't get a 'game' created. At least, it doesn't for me =) However, as long as you're happy, does it really matter that much?

Share this comment


Link to comment
It's certainly true that time spent developing technology is usually not time spent making a game, because you could just go and buy/download the technology instead.

However, the issue I take is with the suggestion that all the technology we need is already out there. If you're trying to make a game engine that does the exact same things as Quake, then yes, you're wasting your time and should just use Quake - but if you're trying to develop new technology, then it definitely isn't. Granted, a lot of the time that technology can be developed as an independent component (and then you're not a game developer, you're a middleware developer) but some of the stuff I'm working with is fundamental to an engine to the point that it simply can't work as an independent component.

Examples of some of the things I want to be able to do:

  • Fully streaming game worlds. Dungeon Siege and Halo 2 are the two big titles to have done this (there are others, but those are the most well-known for it), and neither of their engines are available for licensing, to the best of my knowledge.
  • Really big animated entities. Painkiller had some nice huge demons, or so I gather from the trailer, but it didn't look like you got up very close. I want LOD solutions that will let me get up and see the wrinkles on his foot, and let me climb up his back and ride around on his head. (Ico 2 looks like it might be quite interesting in this regard).
  • Fully dynamic integration of physics into character animation. I want to be able to hand a character - or part of a character - to the physics system, and pull it back into animated routines at a moment's notice.


The first of those almost certainly wouldn't bear integration into an existing game engine, not without rewriting very large parts of it. True, I could probably take things like memory managers or audio systems from elsewhere, and by and large, I do. I use boost, loki, and the STL for most of my data structures; widely known and tested techniques like those from the GPG books where possible and applicable; and I try my best to stay abrest of the latest academic publications (though I really should see about joining ACM at some point). Remember, using premade tech isn't just a question of compiled code - it's established techniques as well, even if you have to implement them yourself.

Share this comment


Link to comment
I suppose it's where you draw the line with the term 'Engine' then. I see a modern game engine as being multi-faceted, you can have an engine for almost every component. You have your core routines which could be hand-crafted or brought in from the 3rd party coders (STL, SDL, Loki, etc); you then also have a graphics engine which could be Ogre, Irrlict, or hand-crafted. Then you come to physics, Havoc, ODE, Tomahawk (sp?) or again, hand-crafted; Networking: SDL_Net, RakNet, hand-crafted, etc; Scripting: Lua, GameMonkey, Python, home-brew... The lists are endless.

We have, basically, a multitude of choice on our hands. I think the point John was making was that we shouldn't concentrate on writing it all ourselves; we should use as much as we can from other vendors as it then allows us to focus on the parts we want or need to do ourselves. We're not reinventing the wheel, we're taking the pieces of the wheel, gluing them together and improving it. It's not like we're trying to make a square wheel, we're just giving the round wheel better treads.

I've had several similar conversations in the past and I believe it's all about focus. Sometimes we'll want to do things our way because it's the only way we can get things how we need to. I feel that John was implying that a lot of people, even new game programmers, feel as if they're obliged to create an 'engine' - perhaps not even obliged, perhaps they simply don't know there's another way. If this is the case, perhaps some GameDev.net articles on using existing engines would be beneficial?

Share this comment


Link to comment
Quote:
Original post by evolutional
I suppose it's where you draw the line with the term 'Engine' then. I see a modern game engine as being multi-faceted, you can have an engine for almost every component. You have your core routines which could be hand-crafted or brought in from the 3rd party coders (STL, SDL, Loki, etc); you then also have a graphics engine which could be Ogre, Irrlict, or hand-crafted. Then you come to physics, Havoc, ODE, Tomahawk (sp?) or again, hand-crafted; Networking: SDL_Net, RakNet, hand-crafted, etc; Scripting: Lua, GameMonkey, Python, home-brew... The lists are endless.
Right, and the key question is: what's in the engine and what isn't? It's not even granular at the system level - I'd consider project-specific networking messages to be part of the networking system. But if it's project-specific it's not part of the engine. Etcetera.

Quote:
We have, basically, a multitude of choice on our hands. I think the point John was making was that we shouldn't concentrate on writing it all ourselves; we should use as much as we can from other vendors as it then allows us to focus on the parts we want or need to do ourselves. We're not reinventing the wheel, we're taking the pieces of the wheel, gluing them together and improving it. It's not like we're trying to make a square wheel, we're just giving the round wheel better treads.
Which I agree with. Perhaps I just understood him differently - I read it as 'We already have wheels with perfect treads.' Which is definitely not true. Even, 'We have wheels with treads which are good enough' isn't something I'd hold to be true; the principle behind those wheels is time-tried and tested, but the roads are different now. The old wheels don't work so well.

Quote:
I've had several similar conversations in the past and I believe it's all about focus. Sometimes we'll want to do things our way because it's the only way we can get things how we need to. I feel that John was implying that a lot of people, even new game programmers, feel as if they're obliged to create an 'engine' - perhaps not even obliged, perhaps they simply don't know there's another way.
There's a large amount of Not Built Here syndrome, certainly. People who feel that using existing tech is 'cheating' somehow. Tell a producer that using pre-made tech is cheating and he laugh and say, "OK, make it yourself, but your schedule ain't changing."

Share this comment


Link to comment
Quote:
Even, 'We have wheels with treads which are good enough' isn't something I'd hold to be true; the principle behind those wheels is time-tried and tested, but the roads are different now. The old wheels don't work so well.


And I think here we start to get to one of the crux arguments that form in people's minds against using canned technology. If you're trying to push forward in some way or another you will hit the limitation of the components you're using. Your old wheels will get you there, perhaps causing you to avoid the rough patches in the road. But on a brand new set of wheels you've got free roam of the road, the rough patch isn't as rough and your tyres won't be wearing down as quickly. But then, perhaps these new wheels are bigger, causing you to modify the suspension to make them fit. Plus you have to learn to drive on an unproven set of tyres that could fail unexpectedly or slide off in a way you didn't anticipate.

But if you do make your run, boy would you impress the other people on the road.

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now