Definitely stay away from the open-sourced Quake engines. As mentioned above, they are not good examples of game engine design.

I'd also suggest to stay away from any existing game engine source code. Source code is an implementation detail. It won't help you understand a design. It will only hide the "forest for the trees."

The problem I find with most game engines, particularly engines that were designed in a vacuum and have not been used to ship serious, commercial games, is that they suffer from either over-design or a strong bottom-up design.

Over-designed engines try to be all things to all people. I generally feel that if you're calling something a "game engine" you're drawing a line in the sand and saying that this "bucket of bits" is good for a fairly narrow goal. I've seen many engines that over generalize to the point of essentially becoming a virtual machine. Except they're not that flexible, or powerful. The result is abstraction without effectively narrowing the problem domain (or doing so trivially).

Bottom-up design is also prevalent due to the programmer's natural tendancies. We want to sit down and start programming and start seeing tangible results. It's hard to get that instant gratification without starting at the bottom and working up. But this is a hard course to stay as your goal remains a game engine (or a game!), yet you'll spend an incredible amount of time filling out details and implementing tech that you've not yet defined whether or not you'll need it.

Returning to my first point on over-designed engines: think of a game engine as a tool. You don't want a hammer, a screwdriver and a chainsaw all combined into a single tool just because you may or may not need those. In fact, if you're a plumber you'll likely only need one of them, and your clearing a bunch of trees (so that you can see the forest, of course) you'll not find much use for the hammer...

...If you're wanting to make a 2D isometric game, create a 2D isometric game engine. Don't create a general purpose "game engine" and then, using the game engine, build your 2D isometric game on top of that.

My personal approach I've been applying lately has been to approach the task from the user's perspective (even if the user is you). I'm sure this is called customer-focused design or something like that. The important point is that any time that you're designing a tool you begin by asking yourself, "What do I want my experience to be?" Do the same thing with a game engine: ask yourself, when the engine is finished and done, when I become a user of the game engine, what do I want the experience to be?

This is the best tutorial that i have seen that teach the fundation for build 2d and 3d games:

http://www.tar.hu/gamealgorithms/index.html

Perhaps it would be easier for you to write a few games before deciding to create an engine. From my understanding, many engines are created from reusable code modules that have evolved over time. Eventually, all of the code modules "click" together to form a simple layer of abstraction - which is then considered to be the engine.

If you don't know what you need your engine to do to begin with, you're driving blind. Sure you might learn alot, but you won't have anything to show for it.

Hi

I also suggest you not to use any existing engine for learning. Ogre, Irilicht, Crystal Space are all great things but full of code that you wont use in your game. First of all make decission of what kind of game you are developing. It is not reasonable to use Quake 3 engine for logical game [smile]. Over years I saw lot of engines, I tried to implement them for my own games, BUT I always made a whole thing from the scratch, because I needed special approach for my development.
For start get familiar with core c++, then make next step to DirectX or OpenGL.
Try to make some simple 2D things, some simple 3D things and after getting some expirience points and being 10th level programmer [smile] make a simple core of engine you want to make. Then you will know the right way.
For OpenGL look at NeHe site, and for DirectX just download DirectX SDK it is full of examples. If you have ATI also download ATI SDK (I don't know about nVidia but I think nVidia have their own SDK).
Look, feel, understand and learn.

Quote:Original post by Anonymous Poster
This is the best tutorial that i have seen that teach the fundation for build 2d and 3d games:

http://www.tar.hu/gamealgorithms/index.html

I'm getting a 404 site not found on that link.

EDIT: Tried it again and it seems to be working, but that's a current production book, ripped to a webpage, and I'm pretty sure that's all kinds of illegal.

I watched a video clip I found on these forums (if I come acrost it again I will post it) of an interview with a Bungie programmer. I realized that I need to develope my games or engines from the top down not bottom up like stated previously in this thread. I used to create a window and start drawing polygons and then start classing things up so I could create instances of entitys or what not. But then by the time you get to the top every source file is including every other source file and its just a mess. So this time. I've started with a simple world object that either my game or my game designer tool will load and run.

I'm going to develop my game IDE at the same time I develope the engine and use a few techniques I got from the video. Such as the game file will just dump into the engine's memory and not load peice by peice. I'm going to do alot of preprocessing in my IDE to avoid it at game start.


0.) To start designing your app you are going to need a language, other people have gave you suggestions on that.

1.) Then just get a peice of paper and start writing down what you want it to do.

2.) Then create a list of objects where each object is assigned a task to get you the feature set you asked for in step one.

3.) Then figure out the relations between these objects as far as what data needs to be passed and how your going to declare them

4.) Then write all the code :)

5.) Then figure out 1,000 reasons why it sucks, start a new project, copy over the good bits, and go to step 1.

Quote:Original post by T1Oracle
^ It sounds like your going to the opposite extreme. If you ever work on more than one project or come up a new idea late in the design, that over-specialized engine design may turn around and bite you. I think that only the things that you're 90% sure will stay the same should be designed with a narrow focus.

Exactly, I didn't mean to imply otherwise. That's why I mentioned a "2D isometric game" as an example... if your plan diverges in such a way that a 2D isometric game engine no longer applies then you probably started with the wrong plan.

There's a lot of confusion (in professional game developers as much as hobbyists) about what a Game Engine is. While it's hard to be definitive, and it may sound like arguing semantics, there's an important distinction (one that my example above blurs a bit out of simplicity).

A Game Engine's purpose is to support the authoring of a game (obviously). For example, Unreal is a Game Engine for authoring FPS games. Never Winter Nights is a Game Engine (or I guess it's called Aurora?) for authoring RPG games. RenderWare is a game engine for authoring... wait, RenderWare is not a game engine. Torque is not a game engine. I'd argue that many of the references in this thread are not game engines. They're more general than that. They're equally applicable to creating an app like Google Earth as they are for making Doom 4. And that's the problem: they don't necessarily focus the problem domain as much as what's useful. I'd generally refer to products like these more as graphics engines, or toolkits, or middleware (to be most generic).

A Game Engine implies some vague structure of a game. Consider it to be almost a runtime (like the Flash player) that's completely data-driven.

Don't get me wrong, the more general purpose engines have their advantages. Particularly for hobbyists who are experimenting with various aspects of game development, having a playground of tech is great and flexible. But, if the goal is commercial/professional game development, more focus is essential to success.

One of the senior engineers I work with puts the best spin on it: think of it in terms of domain languages. Yes, C++ can be used to capture all of the details of your game. But, is it difficult to imagine a language that would more succinctly describe your requirements? Because that's really the desire of a good domain language (like a good class interface, not-so-conincidentally): minimal yet complete.

@honayboyz: I couldn't have said it better myself. That's exactly what I was trying to impart in this thread (or perhaps it was this thread on RTS Software Arhictecture).