We probably all have a pretty good intuitive thought of what a game is. The term “game” encompasses boardgames like chess and Monopoly, cards like poker and blackjack, casino games like roulette and video poker machines, military war games, computer games, various kinds of play among children, along with the list goes on. In academia we occassionally speak of game theory, by which multiple agents select strategies and tactics in order to maximize their gains inside the framework of a well-defined pair of game rules. When utilized in the context of console or computer-based entertainment, the saying “game” usually conjures images of a three-dimensional virtual world with a humanoid, animal or vehicle since the main character under player control. (Or the old geezers among us, perhaps it produces in mind images of two-dimensional classics like Pong, Pac-Man, or Donkey Kong.) As part of his excellent book, A Theory of Fun for Game Design, Raph Koster defines a sport to be an interactive experience providing you with the player with an increasingly challenging sequence of patterns that they or she learns and in the end masters. Koster’s asser-tion is that the activities of learning and mastering are at the heart of what we call “fun,” just like a joke becomes funny currently we “get it” by recognizing the pattern.
Video Games as Soft Real-Time Simulations
Most two- and three-dimensional video gaming are examples of what computer scientists would call soft real-time interactive agent-based computer simulations. Let’s break this phrase down as a way to better understand what it implies. In most video games, some subset in the real world -or an imaginary world- is modeled mathematically then it can be manipulated by the computer. The model can be an approximation to and a simplification of reality (even though it’s an imaginary reality), because it’s clearly impractical to feature every detail down to the level of atoms or quarks. Hence, the mathematical model can be a simulation of the real or imagined game world. Approximation and simplification are a couple of of the game developer’s strongest tools. When used skillfully, even a greatly simplified model can often be almost indistinguishable from reality and more fun.
An agent-based simulation is certainly one in which a number of distinct entities called “agents” interact. This fits the outline of most three-dimensional computer games perfectly, where the agents are vehicles, characters, fireballs, power dots and the like. Given the agent-based nature of all games, it should be no surprise that most games nowadays are implemented within an object-oriented, or at least loosely object-based, programming language.
All interactive video games are temporal simulations, and therefore the vir- tual game world model is dynamic-the condition of the game world changes as time passes as the game’s events and story unfold. A relevant video game must also reply to unpredictable inputs from the human player(s)-thus interactive temporal simulations. Finally, most video games present their stories and answer player input instantly, making them interactive real-time simulations.
One notable exception is within the category of turn-based games like computerized chess or non-real-time strategy games. But even these types of games usually give you the user with some way of real-time graphical user interface.
What Is a Game Engine?
The phrase “game engine” arose in the mid-1990s in experience of first-person shooter (FPS) games such as the insanely popular Doom by id Software. Doom was architected with a reasonably well-defined separation between its core software components (for example the three-dimensional graphics rendering system, the collision detection system or the audio system) and the art assets, game worlds and rules of play that comprised the player’s gaming experience. The price of this separation became evident as developers began licensing games and retooling them into new services by creating new art, world layouts, weapons, characters, vehicles and game rules with simply minimal changes on the “engine” software. This marked the birth of the “mod community”-a group of individual gamers and small independent studios that built new games by modifying existing games, using free toolkits pro- vided by the original developers. Right at the end of the 1990s, some games like Quake III Arena and Unreal specified with reuse and “modding” in your mind. Engines were made highly customizable via scripting languages like id’s Quake C, and engine licensing has become a viable secondary revenue stream for your developers who created them. Today, game developers can license a sport engine and reuse significant portions of its key software components to be able to build games. Although this practice still involves considerable purchase of custom software engineering, it can be much more economical than developing all of the core engine components in-house. The line between a game and its engine is often blurry.
Some engines come up with a reasonably clear distinction, while some make almost no attempt to separate the two. In one game, the rendering code might “know” specifi-cally how you can draw an orc. In another game, the rendering engine might provide general-purpose material and shading facilities, and “orc-ness” might be defined entirely in data. No studio is really a perfectly clear separation between the game and the engine, which is understandable considering that the definitions present in components often shift because game’s design solidifies.
Arguably a data-driven architecture ‘s what differentiates a game engine coming from a piece of software that is a game however, not an engine. When a game contains hard-coded logic or game rules, or employs special-case code to render specific forms of game objects, it will become difficult or impossible to reuse that software to make a different game. We need to probably reserve the word “game engine” for software that is extensible and can be used as the building blocks for many different games without major modification.
Clearly this is simply not a black-and-white distinction. We can easily think of a gamut of reusability onto which every engine falls. You are likely to think that a game engine may be something akin to Apple QuickTime or Ms windows Media Player-a general-purpose piece of software capable of playing virtually any game content imaginable. However, this ideal has not yet been achieved (and might never be). Most game engines are carefully crafted and fine-tuned to perform a particular game on the particular hardware platform. And in many cases the most general-purpose multiplatform engines are very only suitable for building games in a single particular genre, for example first-person shooters or racing games. It’s pretty sure that the more general-purpose a game engine or middleware component is, the less optimal it’s for running a particular game with a particular platform.
This phenomenon occurs because designing any efficient piece of software invariably entails making trade-offs, and those trade-offs are based on assumptions about how precisely the software will be used and/or in regards to the target hardware on what it will run. By way of example, a rendering engine that was designed to handle intimate indoor environments will most likely not be very good at rendering vast outdoor environments. The indoor engine could use a binary space partitioning (BSP) tree or portal system to ensure no geometry is drawn which is being occluded by walls or objects which are closer to the camera. The outdoor engine, alternatively, might use a less-exact occlusion mechanism, or none in any respect, but it probably makes aggressive using level-of-detail (LOD) techniques to ensure that distant objects are rendered with a minimum number of triangles, with all the high-resolution triangle meshes for geome-try that is close to the camera.
The arrival of ever-faster computer hardware and specialized graphics cards, in addition to ever-more-efficient rendering algorithms and knowledge structures, is beginning to melt the differences involving the graphics engines of various genres. It is now very easy to use a first-person shooter engine to create a real-time strategy game, by way of example. However, the trade-off between generality and optimality still exists. A game title can always be made more impressive by fine-tuning the engine to the specific requirements and constraints of a particular game and/or hardware platform.