C-Robots Development

Some Early thoughts (Thursday, September 09, 1999 02:41 AM)

I'll present here a few of the early thoughts I've had on how the game should be designed and implemented. These are very tentative, especially since i haven't even talked to the other people who will be participating on this project....

2d or 3d?

One of the first issues that came up in my mind was whether to do 3d or 2d graphics for the display. My initial thought was that we should definitely use 2d, but the more I thought about it, 3d seemed like a perfect choice:
• It allows arbitrary direction of facing. With bitmapped graphics there is a necessary quantization effect as a result of limited memory, because only so many images of the ship can be stored. Let's say we used a scheme where the ship could face sixteen different ways (the same number, I believe, as was used in the original Star Control). Then there would be sixteen different bitmapped images in memory for each type of ship we would want. Depending on the video resolution and bit-depth used for the game, this could take up quite a lot of space. Assuming sprites of 32x32 squares with 16-bit color, that would be 32 kilobytes per ship.
• Of course, that assumes that there wouldn't be any interresting effects such as independent laser turrets or lighting effects when launching a missile. These things could rocket the number of images into the hundreds or maybe even thousands if all the combinations were rendered before-hand. Imagine having a megabyte of images in memory for each space ship... kinda extreme, especially if we want to have a modicum of backward compatibility.
• On the other hand, why talk about backward compatibility if we're also talking about 3d? Any computer capable of rendering 3d stuff fast enough to make a game out of it would certainly have lots of memory. 3d rendering hardware has only been common in PCs for the last two years or so. Do we want to limit our audience to only having modern, light-speed computers?
• Okay, so another possibility would be to set the game up to have an arbitrary display -- useable with as little as text-mode/curses, but also with up to OpenGL-level 3d rendering with cool models and textrues and everything.... Well, to be honest, I would probably write it that way anyway to allow of third-party developers to more easily port it and make higher-/lower-res versions.
• Coming back to 2d. It might be possible, especially in 16- or 24-bit graphics modes (i.e. non-palette-based), to use some sort of graphics hogery-pogery to create lighting effects, and to have moving parts, and so on. Partial transparency could be used (full alpha channel) to create smooth transitions on overlayed images. With, say, a top-mounted laser turret, there could be 16 images for the ship itsself, and 16 other ones for the turret, the the overlay done dynamically. Lighting effects could be done... I don't know how, but I think I might be able to think of something. It might depend heavily on the form of rendering used -- computer generated, hand-drawn, claymation, model animation, and so on. The algorithms to be used might only work with a given set of ship images.

With this we come to an arbitrary stop. There are any number of reasons to go either way -- 2d or 3d. Right now I'm leaning toward 2d. I think that the speed constraint is important. I want people to be able to run this game on anything down to a pentium-60, perhaps even a 486. I'm not sure at this point how fast these things I'm talking about will be, so I don't know if a 486-enabled display is possible with the level of graphics sophistication I'm thinking about....

The Level of Graphics Sophistication I'm Thinking About

Let's see here. I have in mind a beautiful, ambitious pixel-based rendering engine the likes of which has perhaps not been seen before now. I think the reason it hasen't been seen is that 3d games have taken over the game market, and modern computing power has effectively been under-utilized for 2d realtime rendering systems. I think that great things could be accomplished with partial transparency and perhaps a few other tricks. I'm thinking dynamic clouds of smoke that billow when a ship zips though them, that kind of thing.... Maybe I'm being too ambitious, but visual and audial stimulation is one of the main goals of this project.

The Target Audience

The question arrises of what the target audience should be on this project, both in terms of the people who will play it and of the computers they will play it on. I'll address those topics seperately.

Human Audience

Computer Audience

A good way to approach the estimation of the audience computer's power is to estimate what the most powerful computer will be at the time of release. That will be the most power that anyone will have. The game should run exceptionally will on a computer like that. Now, I would say that a good measure of how well the game runs on a given computer would be the frame rate it is able to attain. The game will have adaptive rendering, giving a frame rate which will be faster on a faster computer, but overall game speed (how fast things happen in the game universe) staying exactly the same (as long as it is run on a computer fast enough to run the game at full speed with no rendering at all).

------ A Brief Aside ------

I want to talk about metaphors for a moment. Games are metaphors. When you play racing game, zooming your car down the track under the hot New Mexico sun, you aren't really zooming a car down the track under the hot New Mexican sun. You adapting to and following a set of ruls made up by a game designer somewhere. Those rules happen to identify in your mind with the idea of driving a car -- sometimes quite realistically. But just as a picture of a pipe isn't really a pipe, a game of a car is not really a car.

Now this may seem obvious or academic to you, but it is something that I think is important to understand about computer games (or just about any computer program or board game or whatever). Sometimes it is useful to talk in terms of the metaphor, and other times in terms of the actual rule set. So, for instance, in the preceding talk about frame rates, it would have been clearer to say that in the metaphor the speed stayed exactly the same, but in the rule set the extra speed made available by the faster computer was used up to make more rendered frames per second on the display.

------ End Of Aside ------

Unfortunately, I'm not familiar with current details about new computer statistics, and I don't have access to a net connection at this moment to go find out. Well, if I remember correctly, the fastest chip right now is something like a Pentium III 500MHz or something like that. Of course, things will change a lot in the six months between now and the end of Winter term. If we believe Moore's law, we would get 2^1/3 multiplication in processor speed by that time, or ~1.26. That would be... um... let's see here... really bloody fast. Add in advances in video hardware, memory speed, hard drive speed, and any number of other effects, and we get an even greater change.

Now determining a lower limit for the computer audience is more difficult. I stated earlier that I would like to target a Pentium-60 as a minimum. The Pentium-60 came out in '94, I think, or maybe '95. Hey, that's not bad, now that I think about it, for it to work on a computer as much as five years old. Probably what we'll have to do is just go with a certain kind of rendering, and go with that, trying to eke out the best timing we can to get the lower limit as low as possible.... That seems kind of random and clumsy, but at the moment I don't really see another way to do it. On the other hand, at the moment it's 2:30 in the morning, so my brain isn't operating at top efficiency.