Well, this page is dedicated to describing in further detail the game engine I plan to start on as soon as possible. I assume you've read the (much too long) reference to this project on the Projects page. Anyway, I'll try not to make this take too long, but there are about a million things I have to say, and it's hard to describe them all. Bear with me here, it's really a cool idea. Honestly. ;-) Oh, one more thing. If you get bored of reading one section, please just go the next next one or skip to the end of it: You should get at least an idea of what each section says (each section actually has fairly revolutionary concepts and goals). I tend to write a lot, but there is a lot to write about, too. One more thing: This file, though it's long, does little more than scratch the surface of all the ideas I have. These are merely the main concepts, of which I have written pages and pages but don't have the time to type all of them into this file.
Many of the ideas on here are nearly impossible to implement and still be even near playable. Well, that's exactly the point. I hear you saying, "That's INSANE. There's no way you'll get that working, and playable." Well thank you, then I'm on my way to my goal.
Purpose:
To create a game engine that is very easy for not-so advanced programmers and advanced programmers alike to write incredibly complex and accurate virtual worlds. The concept is that everything in the real world is based upon a few simple things, namely gravity, mass (we separate them for greater flexibility), momentum vectors, and plane definitions (I'll describe later). Everything in both our Universe and in our virtual Universe is basically made up of these simple, fundamental parts, and all parts follow specific rules, and are incapable of breaking these rules. However, due to the nature of the fundamental parts, it is possible to make almost anything, fairly easily.
Another semi-purpose of this project is to create a game for tomorrow. When Quake came out, it ran fine on the computers of the day, but badly on the older ones. My goal is to make this game engine be as fine tuned and fast as I can, and yet have it run nearly unplayably slow on even the fastest computers around (ie my G3 266). Sure, you can bring the quality of the graphics (resolution, screen size, anti-aliasing, shadows, interlacing...) way down in order to be playable (on these beasts of computers) but to get the maximum quality you would need a computer of tomorrow, or just settle for *very* slow frame rates. You see, Quake, having been written a fairly long time ago, now runs at around 50 fps on some computers with 3D cards. That means it isn't taking advantage of all the power it has available to it. I, personally, would really prefer 25 fps but having much higher quality and much cooler features in the game. So if my game engine can't run NEAR playably at the highest quality on even the fastest computers, then we will have a great game engine for years to come. Another thing, id Software (they're a good example) would not DARE making a game that runs as slow as this one will, because they'd lose customers. But then by the time their games ship, computers could handle much more. I hope you get what I mean here. The game for tomorrow. And the next day. That's the point.
Rendering Engine:
As stated before, I plan to code a rendering engine based on OpenGL, thus enabling easy portability to other platforms, as well as 3D hardware acceleration on some operating systems. I currently want this game to run on BeOS, UNIX, *possibly* MacOS, Rhapsody as soon as I can get hold of some version of it, and *possibly* Windows 95/NT. A fast computer will not technically be required to run it, but there would be no point at all to try on anything other than an insanely fast computer.
I want to give programmers access to the screen image for effects. For example, in a game you bump your head on something hard. The view becomes blurry, you get dizzy and there is a vertigo effect (obtained by moving the camera back and zooming forward... very weird!). Or you spin around 20 times and get dizzy, so the camera appears to spin for a second and you lose balance. Or say you don your scuba gear, preparing to jump into the sea: An image of the diving mask appears on the perimeter of the screen. You jump in the water and come out again, and water droplets bead on your mask and roll down. You get the idea.
There will be complete choice in the quality of the rendered images, from anti-aliasing to interlacing to pixel doubling to pixel tripleing to shrinking the screen down. You get the idea. The only way it'll run on most computers is with all of these on the least-pleasing setting. However, I also plan to support VR glasses (if I can get some for my Mac), 3D glasses, and 3D TV (basically a darker filter over one eye making the rods and cones alternate which frame they see, giving a perception of depth. Very cool!). The added 3rd dimension of perception not only increases the effect of the game, but also makes even very low quality images much easier to see. So if you, say, pixel triple the image and put interlacing on, and use the 3D TV mode, you would see it in 3D and therefore make up for the lost resolution.
It will utilize a freeform rendering engine, thus being capable of rotating in any direction on any axis (few games can do this, Descent being a great example). DOOM could never hope to do this, and neither could Quake.
Physics:
This is the main feature of the game engine that really takes advantage of the power of a faster processor. Sure, it's nice to have great graphics, but who cares if the game is not realistic? The goal is to give easy, automatically realistic physics models to the average programmer.
Due to the nature of our virtual Universe, everything is made of the same stuff, and everything acts the same way. It does in reality, too. You might raise the point of certain chemical compounds that tend to act "differently." For example, a mixture of water and corn starch is liquid, but turns temporarily to a solid when force is applied to it. So? On the molecular level, it is not defying any laws of physics: It's basically acting the same way as anything else. Water molecules bead into drops, yet you can not grind a fine powder down until it becomes a liquid, and beads. So? All generalizations break down eventually, but water beads because of the shape of the molecules and the charges they have. Everything is physics, even chemistry. Everything follows the exact same rules, but has different traits (like the shape of the molecules, charges, etc.). Everything is composed of electrons, protons, and nutrons, all in different combinations. Our game engine won't go down into that detail, but we'll use a more generalize form of this concept to ensure that our worlds are realistic.
I've even thought of adding the possibility for developer-defined dimensions. According to the theories of quantum mechanics, the Universe apparently consists of 10 dimensions. Well, why shouldn't our game have 10 dimensions if we want? No reason at all. It's up to you to do what you want with them. In fact, who says we need to be limited to 10? How about infinite dimensions? Sure it's not real, but this is our Universe, right? Flexibility, that's my moto.
Objects will be merely groups of the fundamental parts clumped together in different ways, and having different values for the same traits. The actual physical "matter" will be made of, obviously, polygons. The simplest form of "virtual matter" will be a plane definition: Basically the mathematical equation for a plane. There are two sides on each plane, and everything on one side is empty, while everything on the other side is filled (with whatever material makes up the plane). A box, for example, would consist of 6 plane definitions, and all the planes would "face" inward, so it would be full. If all were facing outwards, the Universe would be filled, all except for the inside of the box. Reality doesn't work this way, but it gives us flexibility. This only works for convex objects, so unfortunately concave objects must be broken down into concave objects (which isn't really anything new for the games world). Basically, the material makeup of objects in our world is a defined by a set of inequalities. This set of inequalities is also used for collision detection, so you know when your ship crashes into an asteroid, or you won't quite fit through the door because you ate too much and are therefore too fat. There are problems with this method, but there are definite pluses as well. Comments/suggestions are welcome, as always.
Objects can be grouped together and can have the same traits as other objects in the group. For example, you make a "metal" group, in which all objects are very hard,
Intelligence:
I actually plan to work on an intelligence engine as a separate project, but since I'm not as into this as all the other stuff, I'd welcome any help you might give. Anyway, I plan to give each object a certain "trait," which would be a script. Every object has a script, and can therefore be given certain unusual properties. For example, a door might slide open when you touch it, or shoot it, or come close to it. And enemies would have a script that would tell them what to do, how to track you, which weapon to use in which case, where to get fusion fuel pellets when his blaster runs out. Another thing, though this is neither intelligence nor part of a game engine (but rather the individual game) would be a bleed factor type of thing: You manage to get one good shot on him, and he's still chasing you. But he can't go forever, right? Right. He will eventually bleed to death or fall unconscious.
Actually, I don't know much about artificial intelligence, but almost all of my ideas are right out of my head. For more info on my artificial intelligence ideas, go here (if it's up yet...sorry). It mainly focuses on human combat intelligence and the traits and drives people have while fighting for their lives (survival, fear, rage, bargaining...). For example, you point a gun at your enemy. In DOOM he runs after you, full steem ahead, while you proceed to blast him into pate. But in reality, you point your gun at him, and he hides behind a garbage can, maybe even decides to strike a deal with you, but NEVER runs after you. Or say you need a car, but can't find one. You stand in the road, and the man at the wheel of the car slams on the breaks (he doen't want to damage the car, right?). Before he can speed off, you jump in and point a gun to his head. In reality you don't have to kill him to get the car, just scare him. Like walking into a bank with a bazooka, and walking out with lots of cash. Why shouldn't the characters in a game know how people act? This is a tough one, but it has great potential for the future.
People:
Here, I am actually violating one of my own rules: NO SPECIAL CASES. Well, this is a problem though. Suppose you are in a subway station, pursued by angry Mafiosi. Well would you be the only one in there? Not on your life! The place would be covered with hundreds of people. So I'm still working on something to do to allow lots of people to be shown, going about their business, without saving individual people and without being TOO slow. I've thought of having a few "generic people," and then using my morphing engine to morph between them. So say it choses the "generic boy." It morphs him with "generic man #1," giving a completely new person (a teenager?). Anyway, this may be one thing I have to scrap until MUCH later (like when standard RAM configurations are 256 MB and stuff). It may be too tough for now, and be TOO demanding.
Morphing Engine:
This is a separate project of mine, but I've decided to try to make it one of the core parts of the game engine. It allows you to morph 3D objects. It is somewhat limited and very simple, but it's a feature I want to support. This, though not necessarily contributing to the "reality" of the game, does add an entirely new "gimmick" to games. So say you're playing a fantasy game, and you happen upon a small rock. You, being a wizard, decide to cast a spell on it. The rock then turns into a frog, which hops away. Or better yet, say you're fighting a wizard, and he turns himself into a bird, escaping your grasp. Then he turns into a giant boulder, and drops on your head. These are the more interesting ideas, but more realistic things could be done with it. For example, I've thought about using the morph engine to allow people to walk, and throw things, and shoot their guns at you. There could be different "frames" of motion, and it would morph between them to create the frames of the animation.
The main limitation of my engine is that it morphs corresponding vertices of objects. So say you're morphing one man into another. The engine will morph the first vertex of the first man to the firts vertex of the second man, and continue until the objects are morphed. The problem is, what if the vertex at the tip of man #1's nose is vertex 203, while the tip of the other man's nose is vertex 150. The engine doesn't know what a nose is, and would therefore morph vertex 203 of the first object (a man) to 203 of the second object. So you might get an animation like man #1, turning inside out, his smashing through until it pokes out his back, and finally amazingly becoming man #2. It would always give a smooth, accurate morph animation, but it may not be exactly how you want it to look. The solution is to use common vertex number for all objects you plan to morph. So all people have their noses at 203, their eyes at 100 and 110, their belly buttons at 75. This will give great looking morphs, just how you want them.
Scales and the Infinite Universe:
This is one of those features that may just be TOO much to ask for, at least in its full form. I want have the ability to merge multiple coordinate systems, and scale them as I like.
For example, normal computer math has a specific precision and has certain bounds. So say you make a simple model of Earth. You then make, in a separate file, a model of a person in a car. Now, you set the scale of the file that Earth is in to a gigantic number, and the one with the person to something very small. Then you merge them together, giving a full size human being, driving their car on a full size Earth. You could build the Moon, and have bases scattered all over it, and you have to fly your ship or drive your moon buggy CLEAR around the Moon!
Or say you are driving your virtual car from the grocery store, home. The roads are actually full size, and you actually have to drive (relatively, of course) 5 miles to get home? Now you're home, and you walk into your house. Your house is in it's own coordinate system, so it can be far more precise than the coordinate system that held the road you were jus driving on. Objects are far more detailed than on the road. You walk into your room, and climb inside the fishbowl. The fishbowl is in it's own coordinate system, so it can be incredibly precise. You swim around next to one of your fish, and then drift to the bottom and begin exploring the castle on the sand at the bottom. Inside, you find dozens of rooms.... You get the idea. As many coordinate systems as you want, and all can be scaled to whatever level you want.
Something else you could do with this: You make one coordinate system, and call it the Universe. You now have one building block. Then you make another Universe, your second building block. The first contains some planets. The second contains the rest, along with the sun. You keep building them and putting them together, as long as you want. A Universe of infite size, and infinite precision.
Such a scheme would take tremendous amounts of RAM and disk space, but if pulled off it would be amazing. Another possible means of doing this would be to use infinite precision math, allowing a single coordinate system to contain a Universe of infinite size. This would probably be much too slow, however.
That's enough for now. I hope you get an idea of what I want to strive for.
[Home]