Narrative in video game design is much more important than in table top game design. In table top games, narrative is generally limited to providing a motive for the player to play the game. It explains why the player wants the most points, to control the most territory, or to complete some goal before everyone else. In video games, narrative is not a static answer to the questions, "Who am I?" and "Why am I here?" in the context of the game. In video games, the narrative is the story the player is either playing through or creating.
Some games do not need narratives. An excellent example of this is Tetris. There is neither room nor need for narrative in Tetris. Unlike table top games though, most video games are designed to be played for more than just an hour or two. Many games have transitions between levels, regions, or even activities, and each transition often needs some kind of narrative. Because the narratives for a particular game need to be associated with each other, that means games need stories, where each narrative is a progression of the previous narrative. While not all video games need narratives, most do, and many need narratives that fit together into a whole coherent story.
Video games are a form of art that turns many different artistic elements into complex compositions. The obvious artistic elements in video games are visual art, music, and sound effects. Stories are art too though, and many of the best games integrate narrative art forms into themselves. Unfortunately, narrative is frequently added to games as an afterthought. This can result in games with awesome graphics, audio, game mechanics, and so on, but with terrible, unmotivating stories. Narrative is often an essential element in the composition of video games, but it also tends to be overlooked, resulting in mediocre games.
Narrative in a game should answer a few basic questions. It should explain who the character is and why the character is there. This, in turn, should provide at least initial answers to the question of what the immediate goals of the character are, and ideally it should motivate the player to want to achieve those goals. In video games, the narrative should form a story, that explores the goals of the character, revealing new goals when necessary and helping the player understand how his or her actions are helping the character to achieve those goals.
Especially good narratives also explore the development of the character, and they can even ask hard questions designed to make the player think. For example, in a serious game, the narrative might prompt the player to consider whether the things the character is doing are wrong or right. It might ask questions that encourage the player to reconsider his or her point of view on something.
As with books, television shows, or movies, narratives can add spice by throwing in plot twists. Engaging the player with narrative is often just as important or even more important than engaging the player with pretty graphics, good music and sound effects, and well designed game mechanics.
Narrative also provides an additional setting for exploration, which can be a very strong motivator. Players like to explore, because they can find interesting things. This may be new scenery, interesting locations in the game, new items, new friends, or new enemies. A good narrative also provides room for exploration. The Myst series is an excellent example of this. There are many places where you can find books or other text that reveals back story, information about the relationships of the characters, how things work in the game worlds, and more. There are also occasional opportunities to explore narrative by talking to people in the game. A vast majority of the narrative, however, is revealed through settings found during physical exploration. In the original Myst, you can learn about the personalities of the brothers by exploring their dwellings in the various Ages that are available for you to explore. This provides more motivation for physical exploration. In Myst 3: Exile, a man that got caught up in the schemes of the brothers reveals back story and plot information at various points during the early and late game. This narrative exploration is at least as interesting as the physical exploration of the game. Wanting to know more of the story can be a very strong driving force, when the narrative is well designed.
For many genres of video game, narrative is critical. Not all games need narrative, but when a game needs narrative, it is important to do it well. Just like artists do not put epic paintings in crummy frames, because the frame will detract from the painting, game designers should not combine poor narratives with epic graphics, sound, and game mechanics, because the narrative will devalue all of the higher quality art work. The popularity of retro games has also shown that narrative quality is often more important to players than the quality of other art in a game. Good narrative might be hard to do, but it is very important to many kinds of video games.
Monday, April 16, 2018
Thursday, April 12, 2018
Video Game Development: Cameras
If you have not read Video Game Development: Relativity, you might want to do so, before reading this article. If you don't have a solid grasp of basic relativity, this article may be confusing and hard to follow.
While the concept of cameras is generally only a major topic in 3D graphics, this discussion is going to be limited to cameras looking at 2D game worlds. The reason for this is that cameras in 3D space is a whole, fairly complex topic of its own, and a full explanation would take many, fairly long articles. The purpose of this article is to explain how cameras work in 2D and why we need them.
One of the most important places for understanding relativity in video game development is in cameras. The most obvious reference frame for games is the screen or window, where the upper left corner is (0, 0). This works fine, until your game area is larger than the screen. What happens when your game is on an 800 by 600 screen, but the game map is several thousand pixels wide and tall? In most video games, a majority of the game map is off of the screen at any given time. To view the entire map, we have to be able to change where on the map the screen is looking. In my experience teaching video game design, the most obvious solution is to move the map around, keeping the screen as the reference frame. This is like the pre-Copernican heliocentric model of the solar system though. Every time the player wants to see a different area of the map, every single entity on the map has to be moved. This even includes entities that are not supposed to be able to move, like trees or buildings. As with the heliocentric model of the solar system, this results in a lot of extra math, and that can be very expensive when it comes to performance. The fact is, the screen makes a pretty poor reference frame, when the map is larger than the screen.
If there is a main character, it might be tempting to make the main character the reference frame. Unfortunately, this is no better than making the screen the reference frame. In fact, generally these are identical, as the screen is generally always centered on the character, and if the character is the reference frame, the position of the screen never moves. So again, we are back to the heliocentric analog, where we have to move everything, including stationary objects, whenever the character moves. As before, the character is a pretty poor reference frame as well.
What if we make the reference frame the thing that is supposed to be stationary? If everything is supposed to appear to be moving relative to the map, then maybe the map should be the reference frame. This allows stationary things to remain stationary, instead of wasting processing time to move with reference to the character or screen. But now we have a problem: How do we move everything relative to the screen, so we can see different parts of the map? This is the wrong question. This is like ancient astronomers asking, "How does everything move relative to the Earth?", and it is what resulted in the heliocentric model in the first place. The answer that lead to the truth was that we are moving, relative to something else that makes a better reference frame.
What if we allow the player to move? (It is important to distinguish here between character and player. The character is an entity in the game that is controlled by the player. The player is the person sitting at the desk in front of the computer.) The player's eyes, in the game world, are essentially the screen. So what I am suggesting is, what if the screen moves relative to the world? It turns out this is the right solution.
In a video game, the screen represents the player looking into the game world. It essentially represents a camera in the game world that is transmitting what it sees to the players screen. In this context, if we want the player to see a different part of the world, we just move the camera. In 2D games, the camera can be represented by a rectangle. Typically the rectangle will be the size of the screen (if it is not, that generally represents scaling), and the position of the rectangle in the game world determines what part of the world the player sees.
Implementation of a camera is actually fairly simple. The camera data structure contains four elements. It contains an x and y coordinate that together represent its position in the game world, and it contains a height and width, that represent the area in the game world that it can see. If that area is larger than the screen, that represents scaling down the image to fit that area onto the screen (essentially zooming out), and if that area is smaller than the screen, that represents scaling up the image to fill the screen area (zooming in). Typically, however, the camera size is either the same size as the screen, or it is the size of the portion of the screen where the game world will be displayed.
Once you have a rectangular representation of your camera, all that is necessary is a little bit of additional math when rendering. Consider, if an entity in the game is at (0, 0), and the camera is at (10, 10), then the entity will be rendered 10 pixels past the top and 10 pixels past the left of the camera. This position is (-10, -10). This suggests that all that is necessary to apply the camera is to subtract the camera from the position of each entity as it is being rendered. It turns out this will get the correct results. All you need to implement a camera is a representation of the camera as a rectangle and two subtractions for each entity being rendered.
Scaling requires a little bit more work. Typically, the camera is the same size as the area of the screen where the image will be rendered, but sometimes we want to make the camera smaller or larger, to scale the image. This allows the ability to zoom in or out. To scale, we have to divide the screen area by the camera area, and then scale the image being rendered by that value. For example, if our window is 100 by 100, and the camera is 200 by 200, then we need to scale the image by 0.5 by 0.5 (that is (100/200, 100/200)), for it to fit. Some rendering libraries will handle this automatically, if you tell them what size you want the source and destination to be. Others provide scaling functions that may be used by the developer, if desired. In 2D games, zooming is not a terribly common feature, but with a well implemented camera, it is not hard to accomplish.
Cameras come with some additional advantages. For example, if you perform collision detection of each game entity with the camera, you can avoid rendering things that are not on the screen, by only rendering entities that collide with the camera. This can result in significant performance improvements, as rendering is generally far more expensive than collision detections.
Another advantage of cameras is that the view is not bound to the map or any other game entity. For a game where the player controls a single character, keeping the character in the middle of the screen is as easy as centering the camera around the character each time the character moves. If you want the player to see some other part of the map for some reason though, it is easy to move the camera to see that location for as long as necessary. In games where the player should be able to view any part of the map as desired (real-time strategy, for example), the player can have complete control over the camera position. Adding this flexibility to a game that uses the screen or character as the reference frame is significantly more work than just moving a camera around. In addition, handling this with a camera is significantly more efficient.
Cameras are the simplest and most efficient way of providing a means for the player to view different parts of a game world. They are not initially obvious to everyone though. With a basic understanding of relativity, cameras are quite easy to implement, and they come with many benefits.
While the concept of cameras is generally only a major topic in 3D graphics, this discussion is going to be limited to cameras looking at 2D game worlds. The reason for this is that cameras in 3D space is a whole, fairly complex topic of its own, and a full explanation would take many, fairly long articles. The purpose of this article is to explain how cameras work in 2D and why we need them.
One of the most important places for understanding relativity in video game development is in cameras. The most obvious reference frame for games is the screen or window, where the upper left corner is (0, 0). This works fine, until your game area is larger than the screen. What happens when your game is on an 800 by 600 screen, but the game map is several thousand pixels wide and tall? In most video games, a majority of the game map is off of the screen at any given time. To view the entire map, we have to be able to change where on the map the screen is looking. In my experience teaching video game design, the most obvious solution is to move the map around, keeping the screen as the reference frame. This is like the pre-Copernican heliocentric model of the solar system though. Every time the player wants to see a different area of the map, every single entity on the map has to be moved. This even includes entities that are not supposed to be able to move, like trees or buildings. As with the heliocentric model of the solar system, this results in a lot of extra math, and that can be very expensive when it comes to performance. The fact is, the screen makes a pretty poor reference frame, when the map is larger than the screen.
If there is a main character, it might be tempting to make the main character the reference frame. Unfortunately, this is no better than making the screen the reference frame. In fact, generally these are identical, as the screen is generally always centered on the character, and if the character is the reference frame, the position of the screen never moves. So again, we are back to the heliocentric analog, where we have to move everything, including stationary objects, whenever the character moves. As before, the character is a pretty poor reference frame as well.
What if we make the reference frame the thing that is supposed to be stationary? If everything is supposed to appear to be moving relative to the map, then maybe the map should be the reference frame. This allows stationary things to remain stationary, instead of wasting processing time to move with reference to the character or screen. But now we have a problem: How do we move everything relative to the screen, so we can see different parts of the map? This is the wrong question. This is like ancient astronomers asking, "How does everything move relative to the Earth?", and it is what resulted in the heliocentric model in the first place. The answer that lead to the truth was that we are moving, relative to something else that makes a better reference frame.
What if we allow the player to move? (It is important to distinguish here between character and player. The character is an entity in the game that is controlled by the player. The player is the person sitting at the desk in front of the computer.) The player's eyes, in the game world, are essentially the screen. So what I am suggesting is, what if the screen moves relative to the world? It turns out this is the right solution.
In a video game, the screen represents the player looking into the game world. It essentially represents a camera in the game world that is transmitting what it sees to the players screen. In this context, if we want the player to see a different part of the world, we just move the camera. In 2D games, the camera can be represented by a rectangle. Typically the rectangle will be the size of the screen (if it is not, that generally represents scaling), and the position of the rectangle in the game world determines what part of the world the player sees.
Implementation of a camera is actually fairly simple. The camera data structure contains four elements. It contains an x and y coordinate that together represent its position in the game world, and it contains a height and width, that represent the area in the game world that it can see. If that area is larger than the screen, that represents scaling down the image to fit that area onto the screen (essentially zooming out), and if that area is smaller than the screen, that represents scaling up the image to fill the screen area (zooming in). Typically, however, the camera size is either the same size as the screen, or it is the size of the portion of the screen where the game world will be displayed.
Once you have a rectangular representation of your camera, all that is necessary is a little bit of additional math when rendering. Consider, if an entity in the game is at (0, 0), and the camera is at (10, 10), then the entity will be rendered 10 pixels past the top and 10 pixels past the left of the camera. This position is (-10, -10). This suggests that all that is necessary to apply the camera is to subtract the camera from the position of each entity as it is being rendered. It turns out this will get the correct results. All you need to implement a camera is a representation of the camera as a rectangle and two subtractions for each entity being rendered.
Scaling requires a little bit more work. Typically, the camera is the same size as the area of the screen where the image will be rendered, but sometimes we want to make the camera smaller or larger, to scale the image. This allows the ability to zoom in or out. To scale, we have to divide the screen area by the camera area, and then scale the image being rendered by that value. For example, if our window is 100 by 100, and the camera is 200 by 200, then we need to scale the image by 0.5 by 0.5 (that is (100/200, 100/200)), for it to fit. Some rendering libraries will handle this automatically, if you tell them what size you want the source and destination to be. Others provide scaling functions that may be used by the developer, if desired. In 2D games, zooming is not a terribly common feature, but with a well implemented camera, it is not hard to accomplish.
Cameras come with some additional advantages. For example, if you perform collision detection of each game entity with the camera, you can avoid rendering things that are not on the screen, by only rendering entities that collide with the camera. This can result in significant performance improvements, as rendering is generally far more expensive than collision detections.
Another advantage of cameras is that the view is not bound to the map or any other game entity. For a game where the player controls a single character, keeping the character in the middle of the screen is as easy as centering the camera around the character each time the character moves. If you want the player to see some other part of the map for some reason though, it is easy to move the camera to see that location for as long as necessary. In games where the player should be able to view any part of the map as desired (real-time strategy, for example), the player can have complete control over the camera position. Adding this flexibility to a game that uses the screen or character as the reference frame is significantly more work than just moving a camera around. In addition, handling this with a camera is significantly more efficient.
Cameras are the simplest and most efficient way of providing a means for the player to view different parts of a game world. They are not initially obvious to everyone though. With a basic understanding of relativity, cameras are quite easy to implement, and they come with many benefits.
Video Game Development: Relativity
Relativity is an important concept to understand in video game development. Yes, I am talking about Einstein's relativity. Don't worry, this will be fairly painless, because we don't need to get into the hard stuff. Relativity in general is something valuable to understand when developing video games. In some places it is even critical.
Relativity comes from the word "relative", and the initial assertion made by relativity is that everything on a material level is relative. More succinctly, there is no universal landmark. In a programming context, there is no detectable (0, 0) coordinate in real space. All spacial coordinate systems are relative to some reference frame. The reference frame is the landmark from which everything else is measured. In physics, this reference frame may be moving in space relative to something else, but because it is the reference frame, we treat it as stationary.
Copernicus and Galileo were instrumental in Western astronomy in the idea that the Sun is the center of the solar system, instead of the Earth being the center of the universe. But they were wrong. Yes, if the Sun is used as the reference frame, we can treat it as the center of the universe. But previous assumptions that everything orbited the Earth in strange heliocentric orbits were not strictly wrong. Using the Earth as a reference frame, they were actually just as correct as the Sun-centric models. The reason the Sun-centric model was superior was efficiency. For the solar system, the Earth centered model required a lot of excessively complex math to describe the orbits of other planets. The Sun centered model was far more efficient. But, when we look at bodies outside of our solar system, the Sun centered model is no better than the Earth centered model for things within our solar system. For this, the superior model is using the center of the galaxy as the reference frame. But, increasing scale is not inherently superior. A galaxy centered model for our solar system has the planets in complex helical orbits again. The ideal reference frame depends on what you are trying to measure, and it can be vastly different for different things.
This is what relativity is. It is the idea that there is no universal reference frame, and the ideal reference frame depends on what you are measuring. This idea is critical in video game development, and every game uses it, whether the developers realize it or not.
The most obvious reference frame for games is the screen or window, where the upper left corner is (0, 0). This fails, however, when game entities interact with each other. For example, when we do collision detection, we do not generally compare positions relative to (0, 0) to determine if there is a collision or not. It is possible, but the math is complex and hard to understand. Instead, we choose one object as a reference frame, and then we subtract its position from that of the second object. This subtraction is what makes the first object the reference frame, because the result of that subtraction is the position of the second object relative to the first. When we subtract like this, we shift the reference frame from the (0, 0) position on the screen or map, to the first object. From there, all we have to do is some simple size and position calculations to determine if there is a collision or not.
This extends beyond just collision detection. When we do any kind of physics or vector math to resolve interactions, we start by picking a reference frame object and subtracting it from any other object, to get the positions of each object with reference to the reference frame object. Again, it is possible in these interactions to use the screen or map as the reference frame, but it makes the math more complex and more difficult to understand. It can also make it less efficient. In some cases, using the wrong reference frame can serious impact game performance.
In video game development, relativity is essential. It is often used without even realizing it, but understanding how and why it works can provide a significant advantage in finding the best solution to difficult problems.
Relativity comes from the word "relative", and the initial assertion made by relativity is that everything on a material level is relative. More succinctly, there is no universal landmark. In a programming context, there is no detectable (0, 0) coordinate in real space. All spacial coordinate systems are relative to some reference frame. The reference frame is the landmark from which everything else is measured. In physics, this reference frame may be moving in space relative to something else, but because it is the reference frame, we treat it as stationary.
Copernicus and Galileo were instrumental in Western astronomy in the idea that the Sun is the center of the solar system, instead of the Earth being the center of the universe. But they were wrong. Yes, if the Sun is used as the reference frame, we can treat it as the center of the universe. But previous assumptions that everything orbited the Earth in strange heliocentric orbits were not strictly wrong. Using the Earth as a reference frame, they were actually just as correct as the Sun-centric models. The reason the Sun-centric model was superior was efficiency. For the solar system, the Earth centered model required a lot of excessively complex math to describe the orbits of other planets. The Sun centered model was far more efficient. But, when we look at bodies outside of our solar system, the Sun centered model is no better than the Earth centered model for things within our solar system. For this, the superior model is using the center of the galaxy as the reference frame. But, increasing scale is not inherently superior. A galaxy centered model for our solar system has the planets in complex helical orbits again. The ideal reference frame depends on what you are trying to measure, and it can be vastly different for different things.
This is what relativity is. It is the idea that there is no universal reference frame, and the ideal reference frame depends on what you are measuring. This idea is critical in video game development, and every game uses it, whether the developers realize it or not.
The most obvious reference frame for games is the screen or window, where the upper left corner is (0, 0). This fails, however, when game entities interact with each other. For example, when we do collision detection, we do not generally compare positions relative to (0, 0) to determine if there is a collision or not. It is possible, but the math is complex and hard to understand. Instead, we choose one object as a reference frame, and then we subtract its position from that of the second object. This subtraction is what makes the first object the reference frame, because the result of that subtraction is the position of the second object relative to the first. When we subtract like this, we shift the reference frame from the (0, 0) position on the screen or map, to the first object. From there, all we have to do is some simple size and position calculations to determine if there is a collision or not.
This extends beyond just collision detection. When we do any kind of physics or vector math to resolve interactions, we start by picking a reference frame object and subtracting it from any other object, to get the positions of each object with reference to the reference frame object. Again, it is possible in these interactions to use the screen or map as the reference frame, but it makes the math more complex and more difficult to understand. It can also make it less efficient. In some cases, using the wrong reference frame can serious impact game performance.
In video game development, relativity is essential. It is often used without even realizing it, but understanding how and why it works can provide a significant advantage in finding the best solution to difficult problems.
Subscribe to:
Posts (Atom)