1 / 24

Animation and Games Development

Animation and Games Development. 242-515 , Semester 1 , 2014-2015. Objective to discuss some of the main game architecture elements, rendering, and the game loop. 5. Game Architecture. Overview. Simple Game Architecture More Detailed Game Architecture Graphics/Rendering

hu-grimes
Download Presentation

Animation and Games Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Animation and Games Development 242-515, Semester 1, 2014-2015 • Objective • to discuss some of the main game architecture elements, rendering, and the game loop 5. Game Architecture

  2. Overview • Simple Game Architecture • More Detailed Game Architecture • Graphics/Rendering • Game Programming

  3. 1. Simple Game Architecture 3

  4. I will focus on the graphics and maths techniques used inside the "Rendering Engine" box. • These include: • basic 3D graphics theory • 3D graphics programming with the JMonkeyEngine game engine • 3D rendering algorithms underlying 3D game engines • shader programming (maybe) 4

  5. 2. More Detailed Game Architecture

  6. 2.1. Core Systems • Elements used in most games: • startup and shutdown • file IO (loaders, writers, datafile parsers) • input controls (keyboard, mouse, touch) • window management • minimize, maximize, full-screen, resolution • maths (e.g. vectors, matrices) • data structures (e.g. linked lists) • In JMonkeyEngine, many of these come from the standard Java libraries

  7. 2.2. Resources (Assets) • These can be separated into game media (stuff visible to the player) and data resources (data used internally by the game). • Media Resources: • images / textures • audio • video • shaders • 3D models • Data Resources: • user settings • player items • high score table • game settings • fonts • physics map • platform settings • graphics and audio capabilities

  8. 2.3. Third-Party Libraries • The game engine will often reuse existing libraries: • GUI (in JMonkeyEngine (JME): Nifty GUI) • Physics (in JME: jBullet, a Java port of the Bullet Physics library) • skeletons (in JME: support for Blender joints) • AI • visual effects( in JME: OpenGL shaders, particle system) • terrain (in JME: the Ogre3D dotScene format) • scene graph (so important, that it's a part of the core in JME)

  9. 2.4. What is a Scene Graph? • A scene graph stores all the entities or objects in the scene, and the spatial relationship between them.

  10. The scene graph data structure simplifies the creation of a scene by the user, and also: • makes it easier to transform groups of objects • e.g. translate, rotate them • makes it easier to determine when objects are colliding and are visible to each other • makes it easier to display a scene with different Levels of Detail (LOD)

  11. 2.5. Visual Effects (in JME) • Particles • smoke, fire, explosions, etc. • Post processing / filter effects • reflective water, light scattering, fog • shadow mapping • High Dynamic Range (HDR) rendering • increased contrast for greater detail • ambient occlusion (blocking) • depth of field blur • etc.

  12. 2.6. Physics (in JME) • Java binding to the Bullet physics library • a collision detection and rigid body dynamics library • http://bulletphysics.org/wordpress/ • Features include: • collisions, gravity, forces • mesh-accurate collision shapes • rigid body dynamics for vehicles and characters • physical joints and hinges • Blender integration • Ragdoll physics • Multi-threaded physics

  13. 3. Graphics/Rendering • Almost every game engine utilizes either OpenGL or DirectX for its graphics processing and rendering. • JMonkeyEngine uses OpenGL. http://www.opengl.org/ http://msdn.microsoft.com/en-US/directx

  14. 3.1. OpenGL • A hardware-independent API, implemented on many different platforms. • Several hundred functions, with many language bindings. • An accepted industry standard: • evolves slowly • currently at version 4.2 • Widely used for: • games, modeling, scientific visualization, etc. 14

  15. 3.2. DirectX • DirectX is a Microsoft API providing direct access to hardware. • Only for Windows, currently at version 11.1 • DirectX components: • Direct Graphics – 2D and 3D graphics • DirectInput – interface to input devices • DirectAudio – play sound and music • DirectPlay – communication across networks • DirectShow – multimedia support 15

  16. 3.3. OpenGL vs. DirectX • OpenGL is aimed at 3D graphics only; DirectX is a more complete game development API. • OpenGL is portable across platforms; DirectX is only for Windows. 16

  17. 3.4. What is Rendering? render • Renderingis the process of converting a 3D scene into a 2D picture (raster image) on the computer screen: • The 3D scene is composed of 3D models (geometries). • A model is composed of 3D graphics primitives • e.g. triangles, quadrilaterals 17

  18. 4. Game Programming • Most games consist of an startup phase, a game loop, and a shutdown phase: • A game loop consists of three stages:

  19. Start End Display Startup GUI Initialization: Load assets Load levels … Read player input Update game state, using: Collision Detection, Game AI, Physics, etc Shutdown: store scores close files game over? Render (draw)game frame 4.1. A Detailed Game Flowchart

  20. 4.2. Frame Rates • An important element missing from the basic game loop is the need to keep the rate of frame drawing constant. • A frame rate is the average number of frames drawn by the game loop each second. • Typical frame rates: • 30 fps (i.e. 30 frames drawn in 1 second) • 50 fps • The frame rate should stay constant so that the user sees the game updating at a fixed rate.

  21. 4.3. Frame Rate Problem • The frame rate should be the same on fast and slow computers. • The problem is that a fast machine will carry out "updating" and "rendering" faster than a slow machine, and so the frame rate will be faster. • We must change the game loop so that the frame rate isn't affected by a computer's speed.

  22. One way to fix this speed problem is to add a "wait" stage in the loop: stop run Shutdown Startup Input Update game loop Wait Render delays the loop so the frame rate is not too fast

  23. Waiting deals with a loop that is too fast, but what about a loop that is too slow? • e.g. because the computer is slow • One solution is to skip the rendering (drawing) stage, making the loop faster: stop run Shutdown Startup Input Update Do we have extra time? no yes Wait Render game loop

  24. The good news is that JMonkeyEngine deals with maintaining a constant frame rate. • We only have to write the "update" code for the loop, not the "rendering" or timing parts, which are dealt with by the engine.

More Related