Jumat, 06 April 2018

Game Engine Architecture

Group Members
  • Aldo Sudibyo
  • Arman Maulana
  • Fajar Setiawan
  • I Kadek Arya Yogi
  • I Made Shabda Krisna A

Structure of a Typical Game Team
Before we delve into the structure of a typical game engine, let’s first take a brief look at the structure of a typical game development team. Game stu-dios are usually composed of five basic disciplines: engineers, artists, game designers, producers, and other management and support staff (marketing, legal, information technology/technical support, administrative, etc.). Each discipline can be divided into various subdisciplines. We’ll take a brief look at each below.
Engineers
The engineers design and implement the software that makes the game, and the tools, work. Engineers are often categorized into two basic groups: runtime programmers (who work on the engine and the game itself) and tools program-mers (who work on the off-line tools that allow the rest of the development team to work effectively). On both sides of the runtime/tools line, engineers have various specialties. Some engineers focus their careers on a single engine system, such as rendering, artificial intelligence, audio, or collision and phys-ics. Some focus on gameplay programming and scripting, while others prefer to work at the systems level and not get too involved in how the game actu-ally plays. Some engineers are generalists—jacks of all trades who can jump around and tackle whatever problems might arise during development.
Artist
As we say in the game industry, “content is king.” The artists produce all of the visual and audio content in the game, and the quality of their work can literally make or break a game. Concept artists produce sketches and paintings that provide the team with a vision of what the final game will look like. They start their work early in the concept phase of development, but usually continue to provide visual direction throughout a project’s life cycle. It is common for screen shots taken from a shipping game to bear an uncanny resemblance to the concept art.
Game Designers
The game designers’ job is to design the interactive portion of the player’s experience, typically known as gameplay. Different kinds of designers work at different levels of detail. Some (usually senior) game designers work at the macro level, determining the story arc, the overall sequence of chapters or levels, and the high-level goals and objectives of the player.
Producers
The role of producer is defined differently by different studios. In some game companies, the producer’s job is to manage the schedule and serve as a human resources manager. In other companies, producers serve in a senior game design capacity. Still other studios ask their producers to serve as liaisons be-tween the development team and the business unit of the company (finance, legal, marketing, etc).
Other Staff
The team of people who directly construct the game is typically supported by a crucial team of support staff. This includes the studio’s executive management team, the marketing department (or a team that liaises with an external marketing group), administrative staff, and the IT department, whose job is to purchase, install, and configure hardware and software for the team and to provide technical support.
What Is a Game
The general term “game” encompasses board games like chess and Monopoly, card games like poker and blackjack, casino games like roulette and slot machines, military war games, computer games, various kinds of play among children, and the list goes on. In academia we sometimes speak of “game theory,” in which multiple agents select strategies and tactics in order to maximize their gains within the framework of a well defined set of game rules. When used in the context of console or computer-based entertainment, the word “game” usually conjures images of a three dimensional virtual world featuring a humanoid, animal, or vehicle as the main character under player control.
What Is a Game Engine
The term “game engine” arose in the mid-1990s in reference to first-person shooter (FPS) games like the insanely popular Doom by id Software. Doom was architected with a reasonably well defined separation between its core software components (such as 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 value of this separation became evident as developers began licensing games and re-tooling them into new products by creating new art, world layouts, weapons, characters, vehicles, and game rules with only minimal changes to 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 provided by the original developers.





Engine Differences Across Genres

  • First-Person Shooters (FPS)
The first-person shooter (FPS) genre is typified by games like Quake, Unreal Tournament, Half-Life, Counter-Strike, and Call of Duty. These games have historically involved relatively slow on-foot roaming of a poten-tially large but primarily corridor-based world.
 Call of Duty 2

  • Platformers and Other Third-Person Games
“Platformer” is the term applied to third-person character-based action games where jumping from platform to platform is the primary gameplay mechanic. Typical games from the 2D era include Space Panic, Donkey Kong, Pitfall!, and Super Mario Brother.
jax & dexter : the precursor legacy
Gears of War

  • Fighting Games
Fighting games are typically two-player games involving humanoid characters pummeling each other in a ring of some sort. The genre is typified by games like Soul Calibur and Tekken.

Fight Night Round 3

Tekken 3

  • Racing Games
The racing genre encompasses all games whose primary task is driving a car or other vehicle on some kind of track. The genre has many subcategories. 
Grand Turismo 5

  • Real-Time Strategy (RTS)
The modern real-time strategy (RTS) genre was arguably defined by Dune II: The Building of a Dynasty (1992). Other games in this genre include Warcraft, Command & Conquer, Age of Empires, and Starcraft. In this genre, the player deploys the battle units in his or her arsenal strategically across a large play-ing field in an attempt to overwhelm his or her opponent.


Command and Conquer 3

Age of Empires


  • Massively Multiplayer Online Games (MMOG)
The massively multiplayer online game (MMOG) genre is typified by games like Neverwinter Nights, EverQuest, World of Warcraft, and Star Wars Galaxies, to name a few. An MMOG is defined as any game that supports huge numbers of simultaneous players (from thousands to hundreds of thousands), usually all playing in one very large, persistent virtual world (i.e., a world whose internal state persists for very long periods of time, far beyond that of any one player’s gameplay session).
World of Warcraft
The Unreal Family of Engines
Epic Games Inc. burst onto the FPS scene in 1998 with its legendary game Un-real. Since then, the Unreal Engine has become a major competitor to Quake technology in the FPS space. Unreal Engine 2 (UE2) is the basis for Unreal Tournament 2004 (UT2004) and has been used for countless “mods,” university projects, and commercial games. Unreal Engine 3 (UE3) is the next evolution-ary step, boasting some of the best tools and richest engine feature sets in the industry, including a convenient and powerful graphical user interface for creating shaders and a graphical user interface for game logic programming called Kismet. Many games are being developed with UE3 lately, including of course Epic’s popular Gears of War.
Open Source Engines
Open source 3D game engines are engines built by amateur and professional game developers and provided online for free. The term “open source” typi-cally implies that source code is freely available and that a somewhat open de-velopment model is employed, meaning almost anyone can contribute code. Li-censing, if it exists at all, is often provided under the Gnu Public License (GPL) or Lesser Gnu Public License (LGPL).
Runtime Engine Architecture
A game engine generally consists of a tool suite and a runtime component. We’ll explore the architecture of the runtime piece first and then get into tools architecture in the following section.
Likee all software systems, game engines are built in layers. Normally up-per layers depend on lower layers, but not vice versa. When a lower layer depends upon a higher layer, we call this a circular dependency. Dependency cycles are to be avoided in any software system, because they lead to un-desirable coupling between systems, make the software untestable, and in-hibit code reuse. This is especially true for a large-scale system like a game engine.



Target Hardware
The target hardware layer, shown in isolation in Figure represents the computer system or console on which the game will run. Typical platforms include Microsoft Windows- and Linux-based PCs, the Apple iPhone and Macintosh, Microsoft’s Xbox and Xbox 360, Sony’s PlayStation, PlayStation 2, PlayStation Portable (PSP), and PLAYSTATION 3, and Nintendo’s DS, Game-Cube, and Wii. Most of the topics in this book are platform-agnostic, but we’ll also touch on some of the design considerations peculiar to PC or console development, where the distinctions are relevant.
Device Drivers
As depicted in Figure, device drivers are low-level software components provided by the operating system or hardware vendor. Drivers manage hard-ware resources and shield the operating system and upper engine layers from the details of communicating with the myriad variants of hardware devices available.
Operating System
On a PC, the operating system (OS) is running all the time. It orchestrates the execution of multiple programs on a single computer, one of which is your game. The OS layer is shown in Figure. Operating systems like Microsoft Windows employ a time-sliced approach to sharing the hardware with mul-tiple running programs, known as pre-emptive multitasking. This means that a PC game can never assume it has full control of the hardware it must “play nice” with other programs in the system.
Third-Party SDKs and Middleware

Most game engines leverage a number of third-party software development kits (SDKs) and middleware, as shown in Figure. The functional or class-based interface provided by an SDK is often called an application program-ming interface (API). We will look at a few examples.



Data Structures and Algorithms
Like any software system, games depend heavily on collection data structures and algorithms to manipulate them. Here are a few examples of third-party libraries which provide these kinds of services
STL. The C++ standard template library provides a wealth of code and algorithms for managing data structures, strings, and stream-based I/O.
STLport. This is a portable, optimized implementation of STL.
Boost. Boost is a powerful data structures and algorithms library, designed in the style of STL. (The online documentation for Boost is also a great place to learn a great deal about computer science!)
Loki. Loki is a powerful generic programming template library which is exceedingly good at making your brain hurt.
Graphics
Most game rendering engines are built on top of a hardware interface library, such as the following :

  • Glide is the 3D graphics SDK for the old Voodoo graphics cards. This SDK was popular prior to the era of hardware transform and lighting (hardware T&L) which began with DirectX 8
  • OpenGL is a widely used portable 3D graphics SDK
  • DirectX is Microsoft’s 3D graphics SDK and primary rival to OpenGL
  • libgcm is a low-level direct interface to the PLAYSTATION 3’s RSX graph-ics hardware, which was provided by Sony as a more efficient alternative to OpenGL
  • Edge is a powerful and highly-efficient rendering and animation engine produced by Naughty Dog and Sony for the PLAYSTATION 3 and used by a number of first and third-party game studios

Collision and Physics
Collision detection and rigid body dynamics (known simply as “physics” in the game development community) are provided by the following well-known SDKs.
  • Havok is a popular industrial-strength physics and collision engine.
  • PhysX is another popular industrial-strength physics and collision en-gine, available for free download from NVIDIA.
  • Open Dynamics Engine (ODE) is a well-known open source physics/collisionp package.
Artificial Intelligence
Kynapse. Until recently, artificial intelligence (AI) was handled in a cus-tom manner for each game. However, a company called Kynogon has produced a middleware SDK called Kynapse. This SDK provides low-level AI building blocks such as path finding, static and dynamic object avoidance, identification of vulnerabilities within a space (e.g., an open window from which an ambush could come), and a reasonably good interface between AI and animation.
Platform Independence Layer
Most game engines are required to be capable of running on more than one hardware platform. Companies like Electronic Arts and Activision/Blizzard, for example, always target their games at a wide variety of platforms, because it exposes their games to the largest possible market. Typically, the only game studios that do not target at least two different platforms per game are first-party studios, like Sony’s Naughty Dog and Insomniac studios.
By wrapping or replacing the most commonly used standard C library functions, operating system calls, and other foundational application pro-gramming interfaces (APIs), the platform independence layer ensures consis-tent behavior across all hardware platforms. This is necessary because there is a good deal of variation across platforms, even among “standardized” librar-ies like the standard C library.


Resource 

Tidak ada komentar:

Posting Komentar