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).

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?

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.

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?

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."

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.