XNA

XNA is a set of development tools built to facilitate PC, Xbox 360, and Windows Phone 7 game development.  XNA is a free download.  It extends Microsoft's Visual Studio IDE which is also free.  XNA games are built in C# which is a language very similar to Java, so if you know that, there isn't much syntax to learn.  I've been playing with XNA for about two months now, and have made some (very) small games.  My experience thus far is limited, but with the amount I feel I've accomplished thus far during my brief time with the tools, XNA gets a gold star from me

So, how does XNA facilitate game development?  First, creating a new XNA project creates a Game class for the developer to work in.  This Game class includes class-level variables to help interface with the graphics card of the targeted platform and draw sprites (basically, any 2D or 3D image in a scene).  The Game class includes methods to create and initialize a game as well as a method for loading any content (images, models, sounds, effects, fonts, etc.) a game requires.  Most importantly however, the Game class manages what is known as the game loop.

The game loop is a set of methods that are called continuously while the game is running.  In XNA, this loop consists of only two methods: Update and Draw.  Draw is used to draw any element in the scene seen by the player while everything needed to run a game that isn't drawing takes place in Update.  Typical actions housed in Update include moving objects, checking for collisions, updating scores, and checking for end-game logic.  The bulk of the logic housed in Update involves polling for events.  Polling is what differentiates the way games execute from that way many other types of software applications execute.  Polling is also why the game loop is such a vital part of game development.

Outside of games, a typical application might prompt the user to take some action, and then wait.  Once the user performs the prompted action, the application is notified, and execution continues.  Games never wait.  They perform actions constantly, and actively ask the system whether or not certain events have taken place.  For instance, the game is not notified by the system when a player moves the mouse.  Instead, every time the game updates, the game polls the mouse for its current position, and then checks this current position against the position of the mouse from the previous update.  Computers are quick, so it's not uncommon for a game to call it's Update method, where much of the polling takes place, 60 or more times a second.

My first XNA project involved displaying two animated sprites that bounce around the screen.  Among other tasks, this project involved making or finding a sprite sheet, loading the sprite sheet into a Texture2D variable, and in Draw, cycling through the images on the sprite sheet to simulate motion.  On each call to my games Update method, I adjusted each sprite's position on the screen based on an initial direction.  In Update, I also polled the sprites for their current positions within the game's window so that I knew when a sprite's bounds overlapped the bounds of the window.  When I detected this overlapping, I simply changed the sprite's direction.  Changing direction this way made is appear as if the sprites were colliding with the game's window, and ensured that the sprites always remained in view.

For the curious, here's a link [coming soon] to an executable of my first XNA project (Windows only).  For someone with zero game programming experience prior to XNA, not counting Stencyl or Twine, I can tell you it's easy to pick up, and it takes very little to make yourself feel super accomplished.  Don't forget about the gold star!

By far, the most difficult part of this project for me was finding useable sprite sheets.  If you need sprites for a project, Spriters Resource is a great place to start.  Also, many of the sprite sheets you'll find online will not have consistent spacing between sprites which is pretty important when calculating which pixels of the sprite sheet to draw in-game each frame.  So, if you find a bunch of sprites, but need to assemble the sprite sheet yourself, Alferd's Sprite Sheet Unpacker is great.  It might save you some time.

Cheers,

Danny

Advanced Game Programming

This semester, I'm taking a course called Advanced Game Programming.  The class serves as an introduction to 3D game programming using the XNA framework.  It's an introductory course.  The only reason "Advanced" is in the title is because this course is the second of only two game programming courses offered by my university's computer science department.

If you've read any part of my blog, you know that game programming is new for me.  The course may not be advanced, but I'm confident it will prove challenging enough to keep me up past my bedtime once or twice this semester.  It's been three weeks, and so far, I love it!  I've already learned enough to develop a complete (simple) 2D game: drawing sprites to the screen, detecting user input, calculating collisions, and playing sound effects and music.  I'm learning what a game looks like in code, how to code in C#, and how to use Microsoft's Visual Studio IDE.  There's a lot of real learning going on, and so far, I've been genuinely excited to work on all the assignments.  This isn't a feeling I've experienced often during my time at university.  It's nice.

Our current assignment, and last assignment before adding the third dimension, is the recreation of a classic arcade game.  The game must include:

• object interaction,
• background music,
• a variety of sound effects,
• character animations, and
• user control.

We are to keep the essence of the original game intact, but otherwise are free to explore and experiment.  I want to remake Breakout.  In my version, player movement will not be confined to the x-axis.  Players will be able to move their paddle to any point on the screen where there isn't already a brick.  Bricks will not disappear on contact with a ball.  On contact with a ball, they will fall from their starting position until they drop off the bottom of the screen.  If the paddle is struck by one of these falling bricks, the paddle will become unresponsive for a very brief period of time.  Players will start the game with three lives.  Each time a ball falls off the bottom of the screen, one life will be deducted, as in tradional Breakout.  Players are not limited to the number of balls in play at one time, however.  If a player feels up to it, he/she may try to play 20 or 30 balls at once.  Adding an additional ball to the play field will be mapped to a keystroke.  Once three balls make their way past the paddle though, the game ends.

That's my idea.  It's due on September 25.  That seems manageable.

Here's the syllabus for my Advanced Game Programming class, if you're interested in reading something uninteresting.

Cheers,

Danny