Almost any game design can be executed in a 2D or 3D graphics engine. After all, PacMan_ was just a first generation shooter, wasn't it? I think it's a mistake to think that you have to choose a hot 3D graphics engine in order to sell more games. Instead, I'd like to believe that an excellent 2D game can set the world on fire simply due to a unique and focused game design. If you disagree with me you've probably never played Bedazzled or Tetris. The truth is that 2D and 3D graphics engines bring unique visualization possibilities to the table.
Before you read one more sentence make sure you understand an important point: camera perspective has very little to do with the display engine. This brash statement deserves repeating: Any game design requiring a particular perspective (first person, third person, and so on) can work in a 2D or 3D graphics engine if you are willing to make some concessions. The differences you'll find are primarily in five areas:
- Camera movement
- Game world design
- Art and animation
- Special effects
- Player expectation
- Cost and difficulty of production
Camera Movement
Camera movement is a primary constraint in a 2D engine. A 2D sprite engine can certainly depict a beautiful 3D world as was done in Myst or Riven, but it will never be able to move through that world like the player viewpoint in Unreal Tournament.
In Riven, the camera viewpoint didn't change in a continuous manner as you played the game. The camera position and orientation were locked down and the player would interact with items they could see directly in front of the camera. The immense detail of the scene was simply too expensive to draw in real time. Pre-rendered backgrounds and environments are a great compromise to get a fantastic look at the expense of freedom of movement; so adventure games or puzzle games can make great use of this technique.
Diablo II was a fast-paced fantasy adventure game and the camera followed the movements of the player as shown in. Because the camera never changed orientation, it was possible to draw the world with an enormous set of prebuilt pieces. Ultima games from Ultima I all the way to Ultima VIII were done in the same way.
It's important to note here that games like Ultima may have been drawn with sprites, but the game world had three dimensions. After all, how could the Avatar walk up a flight of stairs or climb on top of a roof if the world didn't have any depth?
Of course, lots more games use a simple sprite engine. This is quite common in kids games, trivia games, and other casual entertainment.
Games that use 3D engines, on the other hand, have little or no constraints on their camera movement. The only thing you have to do is make sure that if the camera can look straight up and see the sky, that you put one there worth looking at!
Game World Design
The constraint you'll find in 3D engines is on your game world design. Perhaps that's an unfair statement. 3D engines will draw all the polygons you stuff into the graphics processing unit (GPU) even if it takes them forever. Forever, by the way, is defined as anything more than 50ms. The real problem a 3D engine has is choosing which polygons to draw to make the most compelling scene.
Consider the problem of a fight simulator like Microsoft Flight Simulator. When the plane is on the ground, the display looks a lot like every other 3D game out there. You see a few buildings, a few other planes, and a runway. You might also see some scenery in the distance like a mountain range or a city skyline.
Once the plane is up in the air you have a different story altogether. You've increased the viewable surface by a few orders of magnitude, and therefore the potential viewable set of polygons. Anyone who attempts a naïve approach of simply drawing all the polygons will quickly learn that they can't get their plane more than 150 feet off the ground. The frame rate will fall in inverse geometric proportion to the altitude of the plane, because that's how many more polygons you have to draw to achieve a realistic look.
The actual approach to this problem uses different levels of detail to draw areas of terrain and objects depending on their distance from the viewer. On some flight simulators you can catch this happening. Simply begin a slow descent and watch as the terrain suddenly becomes better looking; the green patches will increase in detail and eventually become individual trees until you crash into them. One of the trickier parts of most 3D engines is getting the levels of detail to transition smoothly, avoiding the "popping" effect.
Another problem is avoiding overdraw. If your game is in a complex interior environment you'll achieve the fastest frame rate if you only draw the polygons that you can see. Again the naive approach is to simply draw all of the polygons in the view frustum, omitting any that are facing away from the camera. This solution will most likely result in extremely choppy frame rates in certain areas but not others, even if the camera is pointed straight at an interior wall. When the game is bogging down like this it is drawing an enormous number of polygons behind the wall, only to be covered up by the bigger polygons close to the camera. What a waste!
You'll need some advanced tools to help you analyze your level and calculate what areas can be seen given a particular viewing location. RenderwareTM has a pretty good tool to do this. This analysis takes a long time, but the increase in performance is critical. Competitive games are all pushing the envelope for the illusion of extremely complicated worlds. The trick is to create these worlds such that the lines of sight are very short in areas of dense geometry and very long in areas of sparse geometry. Add to that mix of technology some nice levels of detail, and you can get a game that looks as good as Grand Theft Auto: Vice City, as shown in.
Since 3D engines are only capable of drawing so much scenery per frame, an amazing amount of effort must go into creating the right level design. Any environment that is too dense must be fixed, or the frame rate will suffer and so will your reviews.
Art and Animation
A clear difference between 2D and 3D display technologies is the creation and presentation of art assets. While 2D sprites and 3D textures are quite similar, nothing in a 2D engine resembles animating or morphing 3D meshes. As you might expect, a 3D engine can use any 2D sprite trickery in its textures, making you think at first glance that a 3D engine will always be superior to a 2D engine.
A closer look at the visual results of a well directed 2D effort will cause you to think twice. Perhaps you'll come to believe that there is a place for 2D engines even in today's market. Now that I've confused you into second guessing your decision to go with the latest 3D engine, let's study the issues a bit and try to bring some focus to the problem. Technology aside, your decision to use 2D versus 3D will have interesting side effects:
- Storage requirements of dynamic objects, such as characters
- The "look and feel" of your game
Let's compare two games from Origin Systems: Ultima Online and Ultima IX. Ultima Online's technology was sprite based, while Ultima IX was a custom 3D engine. Both games are shown in .
What's interesting and somewhat unexpected is that the art for both games was created by 3D Studio Max. Given the same camera angle, both characters look very similar. When you watch them move, however, you can begin to understand what concessions you have to make if you choose 2D.
Ultima Online characters were pre-rendered, which means that every conceivable position of their bodies had to be saved in a huge set of sprites that would be animated in the right sequence to make them move. The only difference between that manner of animation and how Tex Avery brought Bugs Bunny to life was the fact that Tex used pen and ink instead of 3D Studio Max.
What made matters worse for the Ultima Online artists is that they had to pre-render all possible animations in each direction any character or monster could walk: sixteen points of the compass in all. Table 2.1 shows the ramifications of this.
| Activity | Storage |
|---|---|
| Total animations (walk, run, stand, idle, kick, jump, crouch, …) | 24 |
| Average frames of animation (2 seconds at 15 frames per second) | 30 |
| Total directions of the compass (N, NNW, NW, WNW, W, …) | 16 |
| Total frames of animation (24 * 30 * 16) | 11,520 |
| Uncompressed size of one frame of animation assuming 50x50 pixels, 8 bit art (50 * 50) | 2.44Kb |
| Total uncompressed animation size (11,520 * 2.44Kb) | 27.41 Mb |
This seems completely unreasonable, doesn't it? How can so many games fit so much animation data on the CD-ROM? A little compression and some cheating will cut that number down to size. Most compression techniques will give you at least a 3:1 compression ratio on sprites, especially since a good portion of those sprites are made up of the background color. You'll want a compression algorithm that has a blazing decompression solution or you'll notice some nasty slowdowns in your game. You'll also want to be smart about decompressing sprites only when you need to; preferably when a level is loading. Compressing the animation sprites brings our storage of the main character down to 9.13Mb:
Uncompressed animations @ 27.41 Mb compressed at 3:1 = 9.13 Mb
The next little trick requires a bit of concession on your part to make your characters ambidextrous. Take a look at the two characters shown in.
It's subtle, but notice that the same creature holds his weapon differently depending on what direction he's facing. Since the character is ventrally symmetrical it makes little difference if you draw a mirror image instead of an actual image. The only hang up is the handedness of the character. When the mirror image is drawn, a weapon that sits in the right hand will suddenly appear in the left hand. At first you might think this will detract from the game. When you consider this technique can store nearly twice the number of animations in the same space you'll come to the conclusion that gamers want those animations and could care less about whether they are beating you up left handed.
It turns out that all the eastward or westward sprites can be flipped, so our sixteen directions can drop to nine. This takes the total amount of storage space down to a much more reasonable number:
Dropping to 9 directions from the original 16 = 5.13Mb
Assuming that the main character has four or perhaps five times the number of animations as every other character in your game, you'll be happy to find that even 50Mb will give you plenty of room to store people, animals, monsters, and anything else you'd like to dream up. 3D games store their art very differently, as you would expect. The original dataset for a dynamic object in a 3D game contains, at a minimum, the following things:
- Mesh: A definition of the geometry of the character given by lists of vertices, triangles, and bones.
- Textures: A set of textures that will be applied to the mesh.
- Animation Data: Lists of positions, orientations, and timing that can be applied to some or all parts of the character mesh.
For comparison purposes let's construct a character similar to the sprite based one we just studied. This character should have similar animation characteristics.
A character rendered offline in 3D Studio Max can have tens of thousands of polygons. If you recall the number of actual pixels in the entire 2D sprite, 2,500, you'll quickly realize that there's no use in creating a model of that complexity for real-time display. In fact, you'll probably be satisfied with no more than 300 or 400 polygons if the character is only taking up l/10th of the screen height. I think the first rendering of the Avatar in Ultima XI was down to below 200 polygons, but it was pretty obvious in the joints and he was wearing a full-face helmet. The polygon count per character is purely a judgment call and there's no hard and fast rule except for get it as small as you can.
A 3D character of similar complexity to our 2D one would have very different storage characteristics as shown in Table 2.2.
Activity | Storage |
|---|---|
Total animations (walk, run, stand, idle, kick, jump, crouch, ...) | 24 |
Average keyframes per animation (1 keyframe every 100ms, average animation is 2 seconds long) | 20 |
Total directions of the compass | 1 |
Total animation keyframes (24 * 20 * 1) | 480 |
Uncompressed size of animation keyframe (25 bones with position and orientation data, 28 bytes each) | 700 bytes |
Total uncompressed animation size (240 * 700 bytes) | ~328 Kb |
Uncompressed size of the character mesh (400 polys @ ~20 bytes each) | 8,000 bytes |
Uncompressed size of the character texture (64x64, 16 bit) | 8,192 bytes |
Total uncompressed size of the character: | ~344 Kb |
It doesn't take a moron to notice the staggering difference in the space savings if you go for a 3D representation of your characters. You don't get any of this for free; the amount of CPU horsepower it takes to draw one horizontal line of pixels on a textured and lit polygon on a hierarchical 3D character running around a 3D world is a hell of a lot more than a mov instruction.
That extra CPU budget buys you plenty of things you simply can't get with a sprite engine. One of the best examples is mixing animations. Since animation data is stored as positions and orientations of the bones they affect from keyframe to keyframe it is a simple matter to mix two animations even if they affect the same bones. If the main character had a limping animation it could be mixed with the walk animation in varying degrees as the main character took damage. The effect is a subtle and continuous degradation of the character's walk. A sprite engine would simply use one animation or the other depending on the level of damage. Clearly the 3D engine provides a better solution.
Sprite games like Ultima Online: The Second Age put amazing effort into the ability for characters to wear different kinds of clothing or carry different weapons. Since it is a sprite game, each piece of clothing and each weapon must be pre-rendered in place for each possible animation. Imagine that the number of frames for every item in your game world had as many frames of animation as each main character. Ultima Online has tens of thousands of individual sprites to achieve this look.
A 3D game on the other hand can simply attach a weapon like a sword or a gun to an attachment point at the end of the main character's arm, essentially creating one more bone of animation data. This adds only about 13Kb to the animation data, and it works the same way for all weapons of that type.
~ Sumber : , 2003, Game Coding Complete. ~
Tidak ada komentar:
Posting Komentar