Peace in God,
Veritech

------------------
"Were plain lost Mr. Frodo" - JRR Tolkien

Direct X isn't an "engine" per se, it's a little too low-level to be called that. The difference is that an engine typically contains higher level routines to do things like collision detection, bounding volume hierarchies, animation, model loading, etc.

The point being that if you are going to start with Direct X you'll have a lot of work to do before you have an engine capable of driving a game.

If you aren't interested in learning how to build an engine and you want to jump straight to developing a game you might consider using a ready-made engine. These are usually layered on top of Direct X (or some other lower level API) but they provide extra functionality, saving you a lot of time. Some are commercial, some are shareware. Some are simple, some are sophisticated. Some are easy to learn, some require a PhD. Some are cheap, some are expensive. Some are even free. You'd have to hunt around to find one that suits your needs.

Of course it depends a lot on what you're hoping to achieve with your game. A simple 2D clone of Tetris doesn't need much of an "engine" at all. A full blown Quake-wannabe will need a lot more than just DirectX :-)

Personally I don't like using other people's code if I don't have to, so I'm writing my own game engine. Mine is 3D and it's based on OpenGL instead of DirectX because I need it to run on other operating systems besides Windows. (OpenGL may be a little easier to learn too, if you're new to 3D development you might want to consider it).

The server side depends on a lot of factors:
- How many simultaneous users do you want to support?
- What kind/size of data needs to be transmitted to and from the server and how often?
- What kinds of things does the server need to track and manipulate?
- What other things will be running on the server? (FTP server? Email? people compiling source code all the time?)

Regardless of the answers to these questions I'd definitely recommend a FreeBSD (or Linux) based server. The same hardware running Windows just isn't going to give you anywhere near the performance or stability. And that's an opinion based on extensive experience.

A mid range Pentium class box running FreeBSD or Linux can easily handle several hundred or even a thousand simultaneous users in a basic talker if it's written well. If you want to do the next Everquest and handle ten thousand simultaneous users or more you're going to have to look at a far more sophisticated networking engine (or take the easy way out and divide your players into different worlds and never let them switch).

Peace in God,
-Veritech

------------------
"Were plain lost Mr. Frodo" - JRR Tolkien

When it comes down to it OpenGL isn't better than DirectX or vice versa. There's very little that you can do with one and not the other. I personally prefer OpenGL because it's not Windows specific and I want my games to run on multiple platforms without rewriting it. OpenGL is, arguably, quicker and easier for beginners to learn, but that doesn't mean it's better.

The quality of your graphics have very little to do with the underlying API (ie: DirectX, OpenGL, GLide, etc). Final Fantasy could be written with OpenGL and look absolutely identical to the PC DirectX Version. It has more to do with how you use the API and how good your artwork is.

Before you can settle on an engine you need to define what kind of game you want to create. Is it a Final Fantasy style game with pre-rendered backdrops? A full fledged 3D game like Quake Arena? A 3D-looking isometric tile based game like Starcraft? A pseudo-3D game like Wolfenstein 3D? All of these will need a very different engine and design philosphy.

It's got a bunch of links in its Development Links section (http://www.flipcode.com/links/) and there's some pretty good articles there if you are interested. Some decent technical discussions are on there too sometimes.

I'm afraid I don't know of many books around the place that discuss it too much. I just used to read some Graphics Algorithms books, then some Math textbooks, and try and mish mash it all together

Have fun,
Phillip Martin

Ok, nuff questions for now, i know u guys are busy on ur own games. Thanks agai for ur help, and thanks for that link, it's a most excellent site.

Peace in God,
-Veritech

For OpenGL stuff the official site would be www.opengl.org and for a great beginner's site I'd suggest http://nehe.gamedev.net

Now, Final Fantasy uses pre-rendered scenes. I've never written one but I've thought about how it might be done:

As you learn about 3D graphics programming you'll come to understand what a "depth buffer" is. Imagine an array of numbers, one for each pixel on the screen. As you draw your scene, the depth buffer is also filled in with a number that corresponds to that pixel's Z value (ie: it's distance "into" the screen). If you try to draw a pixel the depth buffer for that pixel is tested first, and it is only drawn if it would be "closer" to the screen.

That's a very basic description, but hopefully it makes sense. A depth buffer allows you to draw all the objects in your scene without worrying about the order in which you draw them.

Without a depth buffer you have to draw the objects that are further away first so that nearer objects are drawn overtop. This is called the "painter's algorithm". Ick.

Ok, back to Final Fantasy. Instead of rendering the backgrounds in real time you can pre-render each scene *AND* the depth buffer.

When your character enters a room, you load in the picture and the depth buffer. Then you can draw your character at any X,Y,Z location in the scene and he will appear in front of, or behind objects just like you'd expect.

So instad of having a 3D model of each and every location in your world, you have a pre-rendered bitmap image of it. This could allow you to have a background image that is of ray-traced quality, better than what you could get in real time.

It also means that you can have more elaborate characters models because you don't have to render all the background stuff - your program can spend more time performing animation, facial expressions, whatever.

For each scene you'd also define a series of "hot spots" that link to other scenes. If your character walks into one of these spots, you fade out the current screen, put the next one in place, fade in... you get the idea.

The down side is that it's an awful lot of artwork, and not as dynamic.

In FF when you leave a city, they use a real 3D interface, but the quality of graphics is significantly lower. I think a game would work without this aspect though.

And of course they tie things together with a lot of pre-rendered cut scenes (mini movies), which are nice but hardly a requirement.

As for camera angles, if you're using pre-rendered backdrops like FF then you can't really let the user adjust it. Each scene has a fixed camera location and angle.

Peace in God,
- Veritech

------------------
"Were plain lost Mr. Frodo" - JRR Tolkien

Peace in God,
-Veritech