CSc303 GameDev Practical 1, 2014
Hand‐in deadline Tuesday September 2, at 23h59. We will not take in the answer to Q1, but may ask you to demonstrate what you've done, to run it, or to give you a mini‐test to make some changes.
1. Complete the readings in the prescribed book, and implement (or copy, read and understand the code thoroughly) his sprite game up to the end of chapter 8 (in the XNA 4 book). Here are the critical outcomes:
Some basic XNA framework ideas that you should be comfortable with: the game loop, polling for inputs, division of labour between Update and Draw, the separation of content, and the content pipeline. The Texture2D, the SpriteBatch, the useful abstraction and software wrapper around your graphicsDevice. Some of the different options for using the Draw method of the sprite batch.
OOP programming ideas that you should definitely master 100%, for all software, not just for these games: the high‐level organization. How we encapsulate state and behavior in an object. How we inherited basic game component functionality, and how we registered components to allow them to independently "plug in" to the game loop. How this "delegation" works and helps decouple
components. If you have any fuzziness around what it means to override a method in a subclass, or why we call base.Draw(gameTime) at the end of our own Draw method, use this opportunity to get your core programming ideas straightened out.
2. Consider whether your learning opportunities would be severely curtailed if your lecturer gave you unprofessional animations and ugly sprite sheets. Get over it, and download the RuBoTSpriteSheet.zip file from the course pracs directory.
a) Choose one of the background levels, and see how well you are able to make RuBoT appear to walk on the board in response to pressing the arrow keys. The sprite sheets are arranged in 4 rows of 8 patches each: the groups correspond to travelling west, north, south or east. Each patch is 64x128 pixels. There are 8 patches per walk cycle. You should try to arrange that RuBoT walks forward by exactly one board tile in one second on each cycle. Drive RuBoT by using three different keys on the keyboard: two keys to turn RuBoT to his left or right, and another key to initiate the walk animation (provided he is not already busy walking). Get him to walk to the next square. (It is probably okay at this stage to let him walk through walls or off the edge: but do consider where this kind of information should live: in the View / rendering logic, or in the business logic of the game. Also consider what information you'd need in your data structures about the state of the tile world to remedy this.)
b) If you have not done so already, refactor your code to create a class that encapsulates all of the RuBoT state and animation logic. Make this class inherit from DrawableGameComponent, so that it decouples from your main game as cleanly as possible. Then instantiate and register two RoBoT instances in your game (at different initial positions and headings), and allow a second player to drive the second robot with their own set of keyboard keys.
Notes:
a) Just copy and reuse whatever looks useful from question 1 to get started.
b) This prac is really about "Can you manage some non‐trivial inverted but stateful control logic in the game loop? i.e. control the robot state (including heading), have the animation rate different from the frame rate, complete one cycle of the animation per keypress", etc. So we'll look carefully at how neatly you organize and manage that logic.
c) What this prac also demonstrates is “Look how hard it is to fake 3D if you only use 2D tools”.
So the purpose is not to get the positioning absolutely perfect – the purpose is to make you sweat a bit. (I did have some geometry maniacs in the course one year: they managed to get really good positioning on the perspective background!)
d) 'Clean' the solution. Exit Visual Studio, zip it up, and submit it into your own folder at
\\ict\dfs\CSSubmissions\CS\CSc303. Regrettably, I think this submission can only be made if you're within the ICT domain, (logged onto the domain). The resources get big in this course, so email and submission to RUConnected don’t work.
Typical Test‐Yourself questions to add to those in the textbook at the end of each chapter:
Discuss the key elements of the XNA game loop. In particular, explain how this differs fundamentally from our more conventional event‐driven program. Also explain in detail the purpose of the gameTime value, and how a programmer would use this. Also explain what a frame rate is, how this differs from the Animation rate.
