UNIVERSITAS GUNDARMA
FAKULTAS TEKNOLOGI INDUSTRI
PENGANTAR TEKNOLOGI GAME
GAME ENGINE ARCHITECTURE
Nama : Aldo Sudibyo, Arman Maulana,
Fajar Setiawan,
I Kadek Arya Yogimiyaantara,
I Made Shabda Krisna A
Fakultas : Teknologi Industri
Jurusan : Teknik Informatika
Pembimbing : Adriani Yulida Kusuma
Diajukan Guna Melengkapi Sebagian Syarat
Dalam Menyelesaikan Tugas Softskill Pengantar
Teknologi Game
BEKASI
2018
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.
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.
Fighting
Games
Fighting
games are typically two-player games involving humanoid char-acters pummeling
each other in a ring of some sort. The genre is typified by games like Soul
Calibur and Tekken
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.
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.
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).
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 1.13, 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 1.14. 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 1.15. 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 :
v 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
v OpenGL
is a widely used portable 3D graphics SDK
v DirectX
is Microsoft’s 3D graphics SDK and primary rival to OpenGL
v 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 alterna-tive to OpenGL
v 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
v Collision
detection and rigid body dynamics (known simply as “physics” in the game
development community) are provided by the following well-known SDKs.
v Havok
is a popular industrial-strength physics and collision engine.
v PhysX
is another popular industrial-strength physics and collision en-gine, available
for free download from NVIDIA.
v Open
Dynamics Engine (ODE) is a well-known open source physics/col-lisionp ackage.
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.
Youtube : https://youtu.be/Du44rW3O20o
