Looking Forward to the Future of Gaming Graphics
July 17, 2008
I am not easily impressed by the technical aspects of graphics in computer games, but every few years a game comes along that really blows me away. In 1993 it was Doom, in 1995 it was Descent, in 1996 it was Quake, in 1999 it was Quake 3, in 2004 it was Doom 3 (and Far Cry, but mostly for the AI). In 2008 it was Metal Gear Solid 4.
It may sound harsh to say I’m not impressed by the technology used in games—because many do have great graphics—but since game developers are limited by the hardware currently available on the mass market, they usually can not use the latest rendering techniques right away. They have to wait until the players have the required hardware. Because of this, new visual effects are often seen in white papers and technical demos years before they appear in mainstream games.
Even if a few games do use the latest technology available when released, they will often be alone to do so for a long of time, and the number of players able to take advantage of the new features will be limited. For example, Age of Conan has been developed with DirectX 10 features, but they were not enabled when the game was released. And even when the game is updated, it will only benefit players who are running Windows Vista with the latest graphics hardware.
Maybe I have not been paying attention to the gaming scene the past few years, but Metal Gear Solid 4 caught me totally off guard. I did not expect to see so many advanced rendering techniques in one place at the same time. They were using all the neat tricks I had been waiting for since the introduction of pixel shader 2.0, and they were using them well. I knew the PlayStation 3 was powerful, but the previous games I had played apparently used very little of that power.
I think it’s very exciting that this kind of graphics power is now finally available to mainstream games, because it allows much greater creative flexibility than before. Techniques such as high dynamic range rendering, out of focus blurring, reduced depth of field and full screen filters—previously only possible in movies, photography and pre-rendered animations—can now be used extensively in computer games, taking us one step closer to the interactive movie.
Here’s some of the things I found especially fascinating in Metal Gear Solid 4:
-
The in-game engine is used for rendering all non-interactive scenes. This improves the feeling of the interactive movie concept by blurring the lines between interactive and non-interactive content. For example, if you decide to put on a mask right before a cutscene, the mask will stay on during the entire scene. Sometimes this rule is broken by the script (i.e. the character will switch to a certain weapon for a specific scene), but it still adds a nice touch to the game.
-
When you turn the camera around fast, the screen gets blurred, just like it would if you were using a real camera.
-
When a car drives past the camera in high speed while it’s raining, water drops will hit the camera. In the same way, if you are in the middle of a building falling apart, dust and sand will cover the camera lens. The effect is also used with blood and snow in various scenes around the game. Although some people don’t like this effect—because it breaks the illusion by revealing the presence of a camera—I think it’s rather cool. It gives a sort of documentary, “fly on the wall”, feeling to the scene.
-
When people talk in cutscenes, the camera shifts focus depending on who’s talking. In fact, this is so common in the movies, many people may not even notice it on a conscious level. However, it does make the scene appear more realistic.
-
Very good use of high dynamic range rendering and pixel shaders for lighting and other effects. For example, when you encounter a helicopter, a pixel shader is applied to distort the image in the same way heat would affect the air around a real engine.
-
Impressive texture and model detail. This is especially noticeable during cutscenes, when you can literally read the labels on people’s clothing and see their hair and clothes move as they walk around.
-
Extensive use of well-known Hollywood movie techniques, such as color tinting, camera shake, panning, zooming, slow motion, selective focus, reduced depth of field and ambient lighting. Some are more subtle than others, and some may even be considered clichés, but I think they add great value to the interactive movie concept.
-
Realistic physics and animation. It’s as if you’re watching a real-time rendering of a Pixar movie.
None of these things are unique in themselves. In fact, most, if not all, have been seen in games before. What makes Metal Gear Solid 4 stand out is how they use all the techniques in the same game, at the same time! It’s also showing that they spent a lot of time (and money) on directing the game as if it was a movie, with, in my opinion, great success.
I am looking forward to more of this kind of gamemaking in the upcoming titles Rage and Mirror’s Edge. Things can only get better after this.
Related Links:
A Tribute to Snake
June 30, 2008
In the history of computer games, I think Snake might be one of the most cloned games ever. At least, it has always been my favorite game to implement when learning a new programming langauge or trying a new platform. To me, Snake is the “Hello, World” of game programming.
Even though other classics like Pong, Space Invaders and Tetris are also fun to program, I always preferred Snake for its simplicity. The game is so simple, it can be implemented in less than 50 bytes on a PC, yet even the most minimalistic version still has good entertainment value. Also, considering that you can get it on anything from calculators and mobile phones to advanced gaming consoles, I guess I can’t be the only fan.
I think one of the main reasons I like Snake as a programming exercise is because it’s an easy way of applying known algorithms and concepts in a new environment. I already know where I’m going, I just have to find out how to get there.
Most of my Snake implementations require a minimum of capabilities from the programming language or operating environment, like:
- Drawing characters or pixels at given coordinates on screen1.
- Reading characters or pixels at given coordinates on screen (not required, see below).
- Accepting input from keyboard.
- Invoking a real-time rendering loop or frequent events/callbacks.
- Obtaining (pseudo)random numbers (for placing food).
If I’m able to implement Snake in a new programming langauge, at least I know the language is not completely useless. I may not know if it’s turing complete, but at least I know it’s “Snake complete”.
Limitations
Another reason I like to program Snake in different languages is the fun of the challenge when there are limitations in your environment. If you are a seasoned programmer, doing Snake in mainstream languages like Assembler, C/C++, Java, Visual Basic, C#, Python or Perl may be a trivial task. However, if you try setting some boundaries for your program, things might change. For example, Snake is an excellent candidate for size optimizing, both for smallest binary and smallest source code. Or how about programming a Snake in Excel, using the cells for “pixels”? Personally, I find the “odd ones” the most fun to write.
For example, the 4DOS batch processing language doesn’t allow reading characters from arbitrary locations on the screen. Unfortunately, the only storage space provided by the language is environment variables (and files, but I didn’t want my program to have “external dependencies”). However, the game only operates in 80×50 resolution, so the screen is small. I was therefore able to encode the entire screen into strings stored in environment variables and updating them whenever the snake moved. This allowed me to check for collisions in much the same way as reading a character from the screen would2.
snake.bat, a snake game implemented in the 4DOS batch file processing language.
I also implemented the Snake in the mIRC scripting language3, but this provides functioanlity to read pixels from the screen, so the screen array was not required.
snake.ini, a snake game implemented in the mIRC scripting language.
Extensions
If you want to go beyond the basics, you can easily extend the game with more features as your experience level with the language, toolkit or platform increases. For example, you may add things like:
- computer opponent(s) with AI.
- two-player or multiplayer mode (with networking).
- sound effects.
- improved graphics and visual effects.
- barriers and other obstacles, like walls or enemies (extended collision detection).
- guns and ammunition.
- support for peripheral input devices.
So, do you have any game, algorithm or concept you like to implement to learn a new language, toolkit, platform or system? Is Snake still a usable “Hello, World” exercise for people learning programming today, or are there better ways?
Please share your thoughts on this. All comments are welcome.
Notes:
- OK, I have to admit, I did implement a Snake in PHP and JavaScript that would redraw the entire screen (HTML page) on the server side, but you get the idea.
- The tail array could also have been be implemented in this way to remove the current length limit.
- In case you are wondering, yes, I did have a lot of spare time when I wrote these. Both the 4DOS and mIRC snakes were written about ten years ago, when I was still in high school.
