• entries
    1212
  • comments
    1738
  • views
    1140291

Reason number one

Sign in to follow this  
johnhattan

113 views

Well, it appears that a couple of you need a bit more than "I know what I'm talking about", so I'll enumerate the reasons as I have the opportunity.

And if you're champing at the bit to tell me that Id writes game engines and is more successful than I am, be aware of one thing. I know Id. I've met Id. I live in the same town as Id. You, sir, are no Id.


That being said, here's Reason Number One To Avoid Writing A Game Engine.

Maturity of tools. The whole "developing tools to make tools" mentality is terrific if your industry or platform is in its infancy. Problem is, it's not. You're developing for a very mature platform using even more mature tools. You're developing at the end of the chain of toolmaking, not the middle. You've got the tools at your disposal to make the end-result of efforts, which is an application for end-users (i.e. a game), not more tools for yourself.

As an analogy, let's imagine for a moment that you're repairing the roof of your house. Now the general game-engine-builder mentality would necessitate that one look at the task at hand, figure out the tools necessary to solve the problem and construct the tools without regard to tools available, no matter their level of maturity, because existing tools will be assumed to be inadequate from the onset and should only be used to construct further tools.

In this instance, you notice that nails must be hammered into your the shingles six inches apart, so you decide that a tool that could better perform the job than the one at hand (namely a hammer) would be a two-headed hammer with heads six inches apart. You immediately set about to constructing this two-headed hammer.

Problem is, unless you intend to hammer in an amount of nails with the two-headed hammer that will justify not only the time taken to hammer the nails but also the time and effort required to construct the hammer, you're wasting your time. More likely than not, you could hammer in all the nails "the old fashioned way" and complete the entire roof-job in the same or less time than it would have taken to construct the two-headed hammer.

Furthermore, you're taking an enormous risk in developing the two-headed hammer, because there's a reasonable chance that, upon completing it, you discover that two-headed hammers don't exist because they don't work as you thought they would, and existing hammers made by tool builders with far more experience than you are good enough to do the job.

That's why people who build end-user products don't waste lots of time at the onset building specialized tools. If you see people building a house, they use tools at hand, even though they're not always 100% suited to the task at hand. If a homebuilder does make a tool for a job (like a cardboard template for some scrolling window-work, for example), it's done very quickly and simply and is intended to be discarded after its use.

Even worse, most of the people I've seen who are developing game engines are developing 'em without even having a well-defined end use for it. That's like making a two-headed hammer just because you're assuming that two-headed hammers are better, and not because you think your roof repair job necessitates it.

Bottom line is that you've got time-tested tools at your disposal, from computers to operating systems to graphics subsystems to 3D hardware to graphics libraries to compilers to level-building tools. You can pretend that STL is a poor tool and you can make a better one that'll be better suited to your games, but you're wrong.

In other words, If you're planning to write a game engine or are in the process of writing a game engine, stop now.


And since I'm feeling charitable, here's Reason Number Two To Avoid Writing A Game Engine.

Reusability is a myth. If you make a game-engine, you will use it to develop one game at most. Pretend that you'll use your magnum opus engine to develop a whole series of robust games, but you won't. The one thing you'll learn in the development of your engine is that your engine is inadequate and must be rewritten.

And this fact will remain no matter how many times your engine is written. If you do end up writing a game with your newly-completed engine, all you'll think is how your project would be more satisfying if you just added one more feature or structured things just a bit differently. If you do manage to complete your game, your next project will inevitably be an improved engine, thus giving your engine a duty-cycle of one game, which negates the entire point of having a reusable engine.

More likely than that, though, you'll grow frustrated with engine-design decisions that you made early on. They'll gnaw at you. You'll feel assured that the project will go smoother with an improved engine. And you'll abandon the work you've done to improve your engine. And that's even worse than the previous scenario. At least in the previous scenario you developed one game, albeit in an unsatisfying way. In this scenario, you developed an engine for which there exists zero games.

So the end result is that you'll have one unsatisfying game or zero games. And that's a lousy choice to make.

If you want an engine that can be used to make reusable games, get one. There are lots of 'em out there nowadays. A good number of 'em were written by people more talented than you and are being used to make games better than yours.

In other words, If you're planning to write a game engine or are in the process of writing a game engine, stop now.
Sign in to follow this  


8 Comments


Recommended Comments

Excellent analogies.

Quote:
If you want an engine that can be used to make reusable games, get one. There are lots of 'em out there nowadays. A good number of 'em were written by people more talented than you and are being used to make games better than yours.


More importantly, these have been proven to work and/or be 'geeral purpose'. Quite simply, if they weren't - people wouldn't be using them.

Share this comment


Link to comment
Quote:
If you're planning to write a game engine or are in the process of writing a game engine, stop now.
I agree completely! You should all stop working on your engines immediately. Get used to using well established tools. Surrender! Don't be daring or try to make something new. Stay in your home. Be afraid. Be very afraid!!

Edit: Seriously. Stop. Now.

Edit2: Making engines is a waste of time. Really! So just quit.

Share this comment


Link to comment
Or you could say, work on technology demos and engines if that's what you enjoy doing and don't plan on making games.

But if you do want to make games, then don't bother with technology demos and game engines and use the tools, libraries, and existing engines out there.

Kevin

Share this comment


Link to comment
Now I understand where you're coming from, I guess I didn't understand at first because I was in a different mindset, I think of my game "engine" as the backbone of my game, not as a set if tools and generic classes that I can reuse for multiple game projects, this doesn't mean that everything is hard coded and wired in a way that I can't harvest bits and pieces of code and use them in a different project.

I agree with what you're saying, except for the case of doing it for the educational value of it. If you just want to learn to make games, want to learn how to make generic algorithms and data structures and even tools that can "theoretically" be reused, then there is a lot to gain. But if you're interested in making a game and shipping it, then what you're saying is true.

Share this comment


Link to comment
Of course I'm not working on a game engine. I'm still working on writing the device drivers for the OS I'm going to write for the 733t hardware I'm working on!

Share this comment


Link to comment
Wow, that just knocked me down a peg.

I think I'm just going to have to accept that you either make games or you make engines and not try to do both.

Share this comment


Link to comment
Quote:
I agree with what you're saying, except for the case of doing it for the educational value of it.
I'll likely be tackling the "educational value" argument as Reason Three, which will be posted sometime after the GDC. . .unless I get distracted by a shiny object, in which case I'll never post it. Suffice it to say, it still doesn't make it worth it.
Quote:
Don't be daring or try to make something new.
You're not being daring or trying to make something new. You're making a game engine, which are nowadays as daring and new as btree-based database libraries.

Share this comment


Link to comment
Quote:
You're not being daring or trying to make something new. You're making a game engine, which are nowadays as daring and new as btree-based database libraries.

Innovation always comes from new developers. Engines are advancing all the time, we've DEFINITELY not reached the "it's all been done before" stage. Where's the engine that supports 100% dynamic, detailed, destructible worlds?

Throughout time, various efforts improved engines in many different ways. I mean, things like:
CroTeam: Huge monsters and landscapes with Serious Sam
Rockstar: GTA
Torque
Crytek and FarCry
Valve and Source
Epic and Unreal

(I'm sure I could come up with a longer list later, I'm kinda short on time right now [smile]).

Most of those started from the ground-up, and came with truly innovative things. With the exception of Valve and Rockstar, who developed their engines after having huge success (i.e. with steady footing), everyone else started from scratch. And made a difference.

Also, I don't think an independent engine programmer or a wannabe should focus himself on making a game. Doesn't make sense. He's not a designer. He's not an artists. What he wants is a job making engines. He should train for that.

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