After looking through what is available and what we plan on doing, I think that I have refined my idea of what the engine will do. Here's my specification. I hope that is exact enough to significantly drop the option, where they will be in the range of only a few possibilities.
If this doesn't cut the mustard for you, let me know and I'll review and refine.
-nick
I decided to offer a simple list and an explanation of what I decided on. I did this just so you know why I did it. Once again, if you see a logic error or some other glaring oversight, tell me.
In addition, though you may already know this. The sites for these engines seem to all carry the same format. You have toolbar with links to a lot of aspects of the engine, but specifically a specs sheet bragging the computer's features, a screenshots page, and a download page. Appropriately, those are three pages to look at. You can a really good idea of what's available on the specs page and download the product on the dl page. You can also look at the pictures and figure out if it's really doing a good job on the screenshots page.
First off, we need to look at the APIs that the program involves. OpenGL handles everything we want to do for both hardware (pretty much every video card made in the last few years implements OpenGL) and software (which is what happens if you have no hardware acceleration or your programs can't access those features of your video card). OpenGL is required.
However, to take it that far is not far enough. We want this program to run within a windows environment and we want to be able to take advantage of Windows programming. OpenGL, which is entirely device-independent, doesn't use Windows commands. However, DirectX does. DirectX can be used for some graphics handling, especially if we have a sticky Windows/OpenGl interface problem. In addition, DirectX also has controls for input devices (keyboard, mouse, joystick, etc) and audio output (both standard and 3D sound). We'll be taking advantage of sound controls later. DirectX is required, though I don't know what version is. That will take me some research time.
OK, well both of those act as wrappers with a C++ programming enviroment. You simply tell the computer to use the OpenGL libraries and DirectX libraries, and have include statements for appropriate header files, and your program is ready to implement these tools. However, not all C/C++ compilers are equal. Three of the largest are Watcom C++, Borland C++, and Microsoft Visual C++. At DePaul, we have Visual C++ on every computer. Therefore, I wouldn't worry about members complaining about accessibility. In addition, one compiler may work differently than another. There are levels and levels of difference (and I could write my master's thesis on the differences). Anyway, Visual C++ has a plethora of good extras that others don't cover. Visual C++ code is required.
Now, as you come along, you find yourself staring at a lot of source code. Well, that's what this is all about. We need complete source code. We would also like the code to be inexpensive or free. No matter what, we need to be able to hack into the code and redistribute it without breaking any user agreements. Therefore, we need to be able to alter or edit code and distribute with the only limit of having to give credit to the engine and original designer.
You may also find support for graphics card-specific handling. Tow that particularly come to mind are 3Dfx and GLIDE. They are bad news for people like me who's card is from the early 90s. There are also special software suites you can purchase that are not device specific but require the installation of special drivers. For example, WinG is a Microsoft graphics handling environment, which may or may not be very nice, but either way is not what we want. Therefore, no device-dependent or other development apps.
Eventually, we'll have a working game, where we will be able to run around and interact and everything. However, the game won't become really interesting unless we have sound. DirectX has a variety of sound components and we would like our engine to be using them. Therefore, we need engine to have some sound capabilities implemented.
We also want to be able to add smoke, fog, explosions, and those things that look cool but require access to the frame buffer. Though we can write an implementation ourselves, it would be nasty. Therefore, I'm putting a strongly recommend priority to alpha blending.
Like we said in the meeting, we will run the game within Windows (rather than DOS) and so we need to open a window, resize, etc. A lot of thise stuff is implemented nicely in Microsoft Foundation Classes. Even if we don't see the use immediately, eventually we will save time and effort. Therefore, I am writing a strong recommend for MFC being already implemented.
This should break our lists down to a small, managable group. After all of that, I think it will then be time to get into these engines and find the differences. We will choose the engine based on a best combination of extensibility, strength, speed, and error handling.
Extensibility and StrengthWe will determine these factors by locating some key functions and analyzing how they run. These functions will be the graphics subsystem, the collision detection system, and maintenance of a character's properties. Assuming these engines employ a decent amount of documentation and a good function naming schema, finding the functions won't be so bad. Once we find them, I can analyze the graphics system. If you want to delve into one of the other two, that would be fine.
Speed and Error HandlingUsing some trial amount of data, we can determine speed. The speed test should make use of these algorithms above. Error handling could be evoked through analyzation, but we really can't see what it'll do unless we do it. Error handling will be controlled through windows commands and amy use MFC.
You know, eventually, we will be another name on that list of sites. I can see how we could take our CSS Beer-Powered engine and make it available to others.
Well, tell me what you think.