1. Lecture 13 --- Building a 3D-game using XNA 1Elias Holmlid

2.  First part  General thoughts on game engine architecture, and some XNA considerations  Second part  Adding a skybox and mouse-look to our previous code Elias Holmlid2

3.  Engine (library)  Shared package (library)  The actual game  Editor  Playpen (sandbox)  Content pipeline- extensions Elias Holmlid3

4.  Break down code into smaller components  RenderingComponent  PhysicsComponent ▪ Collision ▪ Response  SoundComponent  Components should not be aware of eachother  You might use the already existing GameComponent-class Elias Holmlid4

5.  When working in teams, naturally breaks down responsibilities  Easier to replace code  Alot easier to nail down bugs and performance problems Elias Holmlid5

6. 6

7.  Since components are not aware of eachother, they have to use an indirect way to communicate  This can be accomplished using events Elias Holmlid7

8.  EventManager  Basically contains a dictionary from event type to a list of listeners for each event  When an event is sent, all the listeners are notified Elias Holmlid8

9.  Examples  PlayerDiedEvent  GameAboutToPauseEvent  LevelCompletedEvent Elias Holmlid9

10.  Break it down into separable parts: Elias Holmlid10

11.  Find a good way to quickly add new effects  For example, decide upon common variable / semantic names for different common  The application can then set the parameters automatically for you Elias Holmlid11

12.  SceneManager  CameraManager  LightManager  EffectManager Elias Holmlid12

13.  A tree containing the entire scene  Objects can be placed and rotated relatively to eachother  Easy to group objects Elias Holmlid13

14. Elias Holmlid14

15. Elias Holmlid15

16.  Example1: EnemyObject  Contains common stuff like position, model etc  Enemies might have different behaviors: ChaseBehavior, JumpAroundBehavior...  Example2: Camera  Camera does not control itself, instead a CameraController-class is moving the camera Elias Holmlid16

17.  Use a fixed time-step or multiply all your movement calculations with the time passed since the last frame  Game.IsFixedTimeStep = true/false  No ”best” approach: Shawn Hargreaves has a good (as always) article about this: http://blogs.msdn.com/b/shawnhar/archive/200 7/07/25/understanding-gametime.aspx Elias Holmlid17

18.  Flips the back-buffer when the electron beam travels to the top-left of the screen (a state called vertical retrace)  SynchronizeWithVerticalRetrace property of GraphicsDeviceManager Elias Holmlid18

19.  The most important rule:  Never allocate reference type objects (classes) while the game is being played  Value types are ok (structs, primitive types...)  The garbage collector is a much bigger problem on the Xbox360 Elias Holmlid19

20.  Garbage collection  Memory allocated on the heap exceeds a given limit: ▪ GC kicks in to release unused memory  Unacceptable 1: GC triggers too often  Unacceptable 2: GC triggers infrequently but it takes a looong time for it to complete  Read more here: http://blogs.msdn.com/b/shawnhar/archive/2007 /07/02/twin-paths-to-garbage-collector- nirvana.aspx http://blogs.msdn.com/b/shawnhar/archive/2007 /07/02/twin-paths-to-garbage-collector- nirvana.aspx Elias Holmlid20

21.  Use pooling  For particle systems, enemies etc  Should use this in non-garbage collected environments anyway Elias Holmlid21

22.  So, allocate everything while the game is loading  You might also force garbage collection through System.GC.Collect() which will reset memory count to zero ▪ Do not do this while playing the game though! Elias Holmlid22

23.  CPU or GPU bound? Elias Holmlid23

24.  How can you tell if you are GPU/CPU bound?  Some detective work is needed  Example: run the game at a tiny resolution. Does the framerate improve?  In that case, you are bound by the pixel shader stage ▪ Try doing cheaper pixel calculations ▪ Or if you are happy with the framerate, you can do more heavy vertex processing for free Elias Holmlid24

25.  Two blog-posts I recommend:  http://blogs.msdn.com/b/shawnhar/archive/2008/ 03/31/an-elf-in-a-box.aspx http://blogs.msdn.com/b/shawnhar/archive/2008/ 03/31/an-elf-in-a-box.aspx  http://blogs.msdn.com/b/shawnhar/archive/2008/ 04/11/santa-s-production-line.aspx http://blogs.msdn.com/b/shawnhar/archive/2008/ 04/11/santa-s-production-line.aspx  (Read them in that order)  eholmlid@gmail.com Elias Holmlid25

26.  Subscribe to Shawn Hargreaves blog:  http://blogs.msdn.com/b/shawnhar/ http://blogs.msdn.com/b/shawnhar/  Hang around at the Creators Club Forum:  http://forums.xna.com/forums/ http://forums.xna.com/forums/  People there are really friendly, and if you’re lucky, Shawn himself will answer your questions Elias Holmlid26

27.  A cheap way to simulate scenery far far away  Imagine walking around in the center of a textured sphere, where the sphere is always moving along with you Elias Holmlid27

28.  We can use a cubemap for the sky-texture Elias Holmlid28

29. Elias Holmlid29  Use the local position of the vertex as a direction vector for lookup into the cube texture

30.  Turn off backside culling for sphere or change cullmode (we’ll be inside the sphere)  Always pass depth test and write maximum depth (1.0) for each pixel to depth-buffer  Nothing in the scene should be farther away than the sky Elias Holmlid30

31.  Cubemaps constructed with special tools  CubeMapGen is a free tool from AMD: http://developer.amd.com/gpu/cubemapgen/ pages/default.aspx http://developer.amd.com/gpu/cubemapgen/ pages/default.aspx Elias Holmlid31