CMSC 425 Lecture Notes - Lecture 2: Unreal Engine, Graphics Device Interface, Java Class Library

25 views8 pages
CMSC 425 Dave Mount & Roger Eastman
CMSC 425: Lecture 2
Computer Game and Graphics System Architectures
Reading: The first half of the lecture is taken from Chapt 1 of Gregory, Game Engine Architecture.
The second half comes from standard computer graphics texts.
Origins of Computer Game Engines: A large computer game is a significant technical under-
taking, involving a large number of interacting components. Of course, not all computer
games require the same level of complexity. Different genres of games require different capa-
bilities. The combination of components used for a simple casual 2-dimensional game is very
different from a high-end AAA 3-dimensional game.
One way to better understand the software structure underlying a generic game is to un-
derstand the structure of a typical game engines. Game engines arose in the mid-1990s. In
particular, the software for the popular game Doom provided a separation between:
core game components (such as the rendering system, collision detection system, audio
system)
art assets (models, textures, animations)
rules of play
This separation made it easy for users to modify, or “modding,” the game, and provided
a framework for adding new elements. This model was extended to other games, including
Quake,Unreal, and Unreal Tournament (all FPS games). At some point, these simple “mod-
ding systems” became generic enough that it was possible to implement a wide variety of
very different games based on a common core set of components, the game engine. Examples
of modern game engines include Unity 3D and Unreal Engine 4 .
Game engines vary along a spectrum of ease of use and flexibility. Simple game engines can
generate only a single type of game (e.g., 2-dimensional games), but are generally easy to
pick up and use. Complex game engines can generate a great variety of games, but it can
take quite a bit of time to master their various capabilities.
The following is a summary of the basic components of a modern game engine. We think of
the engine as being designed in a number of layers, ranging from the lower levels (hardware
and operating system) up to the higher levels (game specific entities like rules). Here is a
summary of the levels, from low to high. These are illustrated in the figure below.
System: This includes low-level software for interacting with the operating system on which
the game engine runs as well as the target system on which the game executes. Tar-
get systems can include general personal computers (running, say, Microsoft Windows,
Linux, or Mac OS), game consoles (e.g., XBox, Playstation, Wii), or mobile devices (e.g.,
hand-held game consoles, tablets, and smart phones).
Third-Party SDKs and Middleware: These are libraries and sofware development toolk-
its (SDKs), usually provided from a third party. Examples include graphics (e.g.,
OpenGL and DirectX), physics (e.g., Havok, PhysX, and Bullet), basic algorithms and
data structures (e.g., Java Class Library, C++ STL, Boost++), character animation
(e.g., Granny), networking support (e.g., Unix sockets).
Lecture 2 1 Spring 2018
Unlock document

This preview shows pages 1-3 of the document.
Unlock all 8 pages and 3 million more documents.

Already have an account? Log in
CMSC 425 Dave Mount & Roger Eastman
Game-Specific Rendering
Terrain Rendering
Player Mechanics
State machine &
Collision Manifold Movement
Camera-Relative
Controls (HID)
Animation
Game-Specific Subsytems
Game Cameras
Fixed Cameras
Player-Follow Debug Fly-
Scripted/Anim.
Cameras
AI
Goals & Decision
Sight Traces & Path Finding
Actions
Engine InterfaceMaking
Through Camera
Camera Perception (ASearch)
Weapons Power-ups Vehicles Puzzles etc.
Front End
Heads-Up Display
(HUD)
Full-Motion Video
(FMV)
In-Game
Wrappers/Attract
Mode
In-Game MenusIn-Game GUI
Cinematics (IGC)
Visual Effects
Light Mapping &
Dynamic Shadows HDR Lighting PRT Lighting
Environment
Mapping
Post Effects
Subsurf Scatter
Particle & Decal
Systems
World Loading/
Streaming
Static/World
Elements
Dynamic Game
Object Model
Real-Time Agent-
Based Simulation
Even/Messaging
System
Gameplay Foundations
High-Level Game Flow System/FSM
Scripting System
Animation State
Tree & Layers
Inverse
Kinematics (IK)
Game-Specific
Post-Processing
Sub-skeletal
Animation
Animation
Playback
LERP &
Additive Blending
Animation
Decompression
Hierarchical
Object Attachment
Skeletal Animation Online Multiplayer Audio
Object Authority
Policy
Game State
Replication
Match-Making &
Game Mgmt.
Audio Playback/
Management
3D Audio Model
DSP/Effects
Scene Graph / Culling Optimizations
Low-Level Renderer
Materials &
Shaders
Static and Dynamic
Lighting
Primitive
Submission
Viewports &
Virtual Screens
Texture &
Surface Mgmt.
Debug Drawing
(Lines etc.)
Cameras Text & Fonts
Skeletal Mesh
Rendering
Ragdoll
Physics
Graphics Device Interface
Recording &
Playback
Profile & Debug
Memory &
Perf. Stats
In-Game Menus
or Console
Forces &
Constraints
Shapes/
Collidables
3D Model
Resource
Parser (CSV,
XML, etc.)
Ray/Shapes
Casting (Queries)
Physics/Collision
World
Phantoms
Collision and Physics
Texture
Resource
Material
Resource
Font
Resource
Skeleton
Resource
Collision
Resource
Physics
Parameters
Game
World/Map etc.
Resource Manager
Resources (Game Assets)
Human Interface
Devices (HID)
Game-Specific
Interface
Physical Device
I/O
Module Start-Up
and Shut-Down
Profiling/Stats
Gathering
Engine
Configuration
Random Number
Generator
Memory
Allocation
Curves &
Surfaces Library
RTTI/Reflection
& Serialization
Strings &
Hash String IDs
Object Handles
Unique IDs
Debug Printing
& Logging
Asynchronous
File I/O
Localization
Services
Optimal Media
I/O
Movie
Player
Core Systems
Rigid Bodies
Platform Independence Layer
Platform
Detection
Atomic Data
Types
Collections &
Iterators
Network Transp.
Layer (UDP/TCP)
Threading
Library
Graphics
Wrappers
Physics/Coll.
Wrapper
Math LibraryUnit Testing
Assertions
File System Hi-Res Timer
3rd-Party SDKs
DirectX, OpenGL
libgcm, Edge, etc
Havok, PhysX
ODE, etc.
Granny, Havok
Animation, etc
Boost++ STL/STLPort AI middleware Euphoria etc.
OS
Hardware (PC, Game Console, etc.)
Drivers
Water Simulation
and Rendering
etc.
Spatial Indices
(BSP/Quad-Tree)
Level-of-Detail
System
Occlusion & PVS
Culling
Source: Jason Gregory
Game Engine Architecture
Lecture 2 2 Spring 2018
Unlock document

This preview shows pages 1-3 of the document.
Unlock all 8 pages and 3 million more documents.

Already have an account? Log in
CMSC 425 Dave Mount & Roger Eastman
Platform Independence Layer: Since most games are developed to run on many different
platforms, this layer provides software to translate between game specific operations and
their system-dependent implementations.
Core System: These include basic tools necessary in any software development environ-
ment, including assertion testing, unit testing, memory allocation/deallocation, math-
ematics library, debugging aids, parsers and serializers (e.g., for xml-based import and
export), file I/O, video playback.
Resource Manager: Large graphics programs involve accessing various resources, such as
geometric models for characters and buildings, texture images for coloring these geomet-
ric models, maps representing the game’s world. The job of the resource manager is to
allow the program to load these resources. Since resources may be compressed to save
space, this may also involve decompression.
Rendering Engine: This is one of the largest and most complex components of any real-
time 3-dimensional game. This involves all aspects of drawing, and may involve close
interaction with the graphics hardware, or graphics processing unit (GPU), for the sake
of enhanced efficiency.
Low-Level Renderer: This comprises the most basic elements of producing images.
Your program interacts with the GPU by asking it to render objects. Each object
may be as simple as a single triangle but is more typically a mesh consisting of many
triangular/polygonal elements. Objects are specified according to their coordinates
in 3-dimensional space. Your program also informs the GPU what colors (or what
image textures) to apply to these objects, where lights are positioned, and where
the camera is positioned.
It is then the job of the GPU to perform the actual rendering (projection, coloring,
shading) of the objects. In particular, it determines where each object projects
onto the 2-dimensional image plane, which objects are visible and which are hidden
from view, what is the color and brightness of each object. Your program needs to
convey all this information to the GPU. This also includes elements like displaying
text messages and subdividing the window into subwindows (called viewports) for
the purposes of showing status information or maps. (Further details are provided
later in this lecture.)
Graphics Device Interface: Since the graphics device requires updating 30–100 times
per second, but some operations (such as displaying messages to the user) occurs at
a significantly different time scale (of multiple seconds), these components shield the
programmer from some of the low-level timing issues when dealing with the graphics
system.
Scene Graph: Game entities are naturally organized into hierarchical structures. This
is true for dynamic and static objects. For example, a human body consists of a
head, torso, arms, legs; an arm consists of a hand, lower-arm, and upper-arm; a
hand consists of fingers. Thus, there is a natural structure in the form of a rooted
tree.
In general, all the entities of the games world can be represented in a large tree,
where the root represents the entire world, and the nodes of the tree implicitly
represent the subtrees that are descended from these nodes. This makes it possible
Lecture 2 3 Spring 2018
Unlock document

This preview shows pages 1-3 of the document.
Unlock all 8 pages and 3 million more documents.

Already have an account? Log in

Document Summary

Reading: the rst half of the lecture is taken from chapt 1 of gregory, game engine architecture. The second half comes from standard computer graphics texts. Origins of computer game engines: a large computer game is a signi cant technical under- taking, involving a large number of interacting components. Of course, not all computer games require the same level of complexity. Di erent genres of games require di erent capa- bilities. The combination of components used for a simple casual 2-dimensional game is very di erent from a high-end aaa 3-dimensional game. One way to better understand the software structure underlying a generic game is to un- derstand the structure of a typical game engines. In particular, the software for the popular game doom provided a separation between: core game components (such as the rendering system, collision detection system, audio system, art assets (models, textures, animations, rules of play.

Get access

Grade+20% off
$8 USD/m$10 USD/m
Billed $96 USD annually
Grade+
Homework Help
Study Guides
Textbook Solutions
Class Notes
Textbook Notes
Booster Class
40 Verified Answers
Class+
$8 USD/m
Billed $96 USD annually
Class+
Homework Help
Study Guides
Textbook Solutions
Class Notes
Textbook Notes
Booster Class
30 Verified Answers

Related Documents