What is the line between in-game tool and engine?

Posts: 353
Joined: 2002.04
Post: #1
There seems to be a bit of discussion about whether it is a good idea to write an engine or not, with most people saying it takes too much time to bother as a hobbyist programmer. Which I agree with.

But it leads me to another question. I have been doing some planning work for my next game and essentially the plan is to write a very complete editor environment, the code from which will then form the basis for the game. The editor will be complete enough to be able to be used for any game which uses the same gameplay and structure, i.e. it will be content independant.

Does that make it an editor or an engine?
Quote this message in a reply
Post: #2
It doesn't really matter whether what you're doing is an editor, an engine or whatever. The point I was trying to get across was that if you want to write a game, write a game.

In your case if the major goal is to write an editor, just do that. Otherwise get on with your game and if you need an editor at some point write it then. Once you've got a working game you'll have a far better idea of what you are going to need in your editor anyway. It doesn't matter how much planning you do at the start you wont be able to foresee all the things you will need your editor to do.

The approach I've taken with the game I'm working on is probably the reverse of what most people think is 'correct' but it's working far better than methods I've used in the past.
I started by searching the net for content. I found some car and track models, reversed engineered the file format and wrote some code to render them. Instant content and instant satisfaction. Next I wrote the input stuff so I could drive the car around. Then the physics. Now I'm working on the collision detection. Every step of the way I've had something to look at and play with which gives huge amounts of satisfaction.
Sure I'll replace the models with my own later, maybe write an editor or a plugin for someone else's but only after I've got everything else sorted. And I have a far better idea of what makes a good file format for my style of coding than I did when I started.
If I had taken the 'traditional' approach I would have started with an engine, then I'd have moved on to an editor and then maybe I'd have something to play with. By this time I'd probably still be working on the 'world's best engine' or, more likely, I would have got bored and moved on to something else.

Don't get hung up on design, just get on with it. It's not a crime to make mistakes or change your mind. The crime is spending hours writing something that you will never use.
Quote this message in a reply
Post: #3
Well not everybody flakes out mid-project. It seems to me that flaking out is an unrelated problem to the method of producing a game. If someone has a short attention span, or is simply new, they should set realistic goals. That has nothing to do with software development. That's life.

If someone has a good idea, then they have to figure out a realistic timeline and how much work is really involved. Sure, that takes experience, and new developers shouldn't jump into really hard tasks unless they're willing to do intermediary work to develop their skills. You can't just sit down one day and start making a killer game. It takes planning. Part of that planning is off-loading the work you'd rather not do: building an engine, creating content, etc. if those aren't your thing. If you're a game designer only, you're in trouble, but I doubt monteboyd has that problem. You can, however, be a generalist (or a "game designer") or a specialist in a one or more areas and utilize outside resources as required, as henryj suggests.

As for the engine question... I think an engine is a tool for turning raw content into something more usable. An editor is not an engine, but you will inevitably write an engine for use in your editor. Even a text editor has an engine. It's not really a subtle concept. You have to build an engine for any program that's going to process a lot of data in order to present it, but that doesn't mean write it from scratch. You can usually find most of the components already out there, and adapt them to your needs.

For most 3D games, the editor will use code that is similar to, and maybe even the same as, the game code, if the editor has to present the game world in the same way as the game for the artist's benefit. Old time editors didn't do that -- they had to run the level through the game to see how it played. (Some games didn't even *have* level editors -- unless you count a text editor).

For HailStone, I'm probably going to use a number of similar components, but generally the editor's engine will be pretty different than the game's engine. The editor has to be flexible, the game has to be streamlined. But it's entirely possible to have a game and editor united in one application, since they will share a certain amount of code.

These days, an engine has almost come to mean the game code itself, totally, but usually you don't count the parts that do file access, user input, and those other components -- they feed the engine, which is the core, the part that works most intimately with the data. An editor is much more about the other parts, so the engine is de-emphasized.

Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #4
I suspect you have a different definition of "Engine" in mind than I do, FÎanor.

To me, an engine must be at least flexible, and reusable in a context other than the original one (how different? Well, that's personal opinion). An engine is also an application template -- that is, engine + content = application. No extra code required. I've probably got more criteria, but those are the ones at the top of my mind.

Anything less is a program or a library. For example, some common code shared between a game and its editor(s) would probably count as a library.


The issue of not sticking to a project is entirely related to the approach taken to development. Even the most committed and motivated people (and I admit I'm not one of them) become depressed when they don't see progress for a while. Some may be able to fight through that -- and good for them -- but I doubt you'll argue that their productivity doesn't suffer; and I doubt that you'll argue they're in the majority.

My own feeling is that any development approach which doesn't show you something new on your screen for every couple of hours you put into your project can probably be improved.

You don't need a timeline to be a successful developer -- at least not for more than the immediately forseeable future. Likewise, you don't need to know how much work is involved. Nobody can predict that for even moderate-sized projects, and you'll figure it out as you go along, anyway. As long as you do the important things first, you'll have the best product you could have created in any given amount of time.
Quote this message in a reply
Post: #5
Well, it's certainly a personal thing isn't it? My initial work on the design for the "engine" in HailStone (which exists in two different design incarnations, each at a higher level of complexity) was almost a year of thinking, researching, reading code, writing sample applications and drawing a lot of diagrams. Apparently I'm a minority, so that's fine.

The more I think about the term "engine", the more I realize it's really just there for the benefit of the news media. Any application developer is going to really think in terms of discreet tasks that the application performs. The genericness of the "engine" concept has become connected to the concept of a particular kind of application which works with game data in order to produce a game world experience, but I don't know that the Quake application would be literally equated with the Quake engine. But close enough, I guess.

I don't use the term "engine" for the system I'm working on now (HailStone is a test-bed for it). I think in terms of discreet modules with defined interfaces, and some application-specific code for connecting those separate "engines". But that's a personal bias against monolith code in preference for components which are interchangeable depending on the situation.

I'm a structuralist -- just a personal philosophy. I think everything in the world should be modular, and all the interfaces should be standardized. Not that that is going to happen! But the world I create in my computer will be totally pre-fab, both code and data, and then I'll have pre-fab code modules which assemble other modules into new applications, dynamically, according to the interfaces I define and the tasks that users want to accomplish. This is clearly not the common vision for computer software.

Anyway, I'm feeling like I should start a new thread in the design forum Smile.

-- FÎanor
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Game Engine Design / DLL Loading Mutle 4 6,342 Jul 5, 2002 08:59 AM
Last Post: Feanor