This video provides an introduction to the long awaited XNA 'Drum Game' and the smaller projects that will be created along the way.
As a part of the first project of the Drum Game lessons, we will use SlimDX to provide DirectX access within XNA. Here we download and set up SlimDX.
We're just about ready to start coding. First, however, we need to set up the appropriate content files, as well as our XACT sound project files.
We are now ready to begin coding our first class. Here, we create the SoundEngine class, which will serve as a skeleton for any implemented sound APIs.
In this video we code the SoundEngineXact class, which will provide our sound engine with functionality from the internal XNA sound API.
Before we code the DirectSound version of the engine, an introduction to how DirectSound works and how we will use it is in order.
With an overview out of the way, we now code the necessary classes to add DirectSound functionality to our sound engine.
Before we jump in and start coding out the music engine, it is important that we take some time to cover the key concepts behind the system. We do this here.
Coding begins on the MusicEngine system. To begin, we create a basic metronome and note description fields. We then play some procedural drum loops!
Now that we have created some procedural drum loops, we can move on to creating manually placed note compositions, creating our own music beat-by-beat.
With our two concept projects finished, it's time for us to begin on the actual drum game. We begin the process in this video, first by setting up the project.
The first class we code in the Drum Game is the GlobalState class, which will give us access to global fields that will be necessary for access by many other classes.
In this video we code the style class, which will handle the "skin" information of our game, its textures, and other visual aspects.
To assist with debugging, we will now begin the Log class, which will allow us to print customized messages to the screen upon events such as inputs and exceptions.
Now that the base log class is constructed, we need to add in some functionality, allowing it to actually write some messages to the screen.
Finally, we implement the log into our game, setting up some tests that allow it to write messages to the game screen based on game events.
We now move on to the Config system, which will allow us to read a list of initial game settings from an XML file, which is created in this video.
In this video we add in the necessary functionality for the Config class methods created in the previous video.
It's time to put our Config system to work! In this video, we demonstrate how to initialize the config system and how to load values from the XML file.
Here we establish the base setup for the style configuration system, which will control the overall look of our game, similar to a "skinning" system.
At this point, the XML file has been augmented with many values that control the colors of many of our game aspects. We now use those values.
We now finish up the style configuration class by completing the method bodies of the class, and getting the system up and running within the game.
In this video we create the KeyboardInput class, which will take in key presses from the keyboard and send them into our game as generic events.
After creating the keyboard input class, our next step is to create the general input handling system which will take inputs from any number of devices.
Now that the Input class is set up, we can now add in the necessary functionality code for the system.
This video focuses on initializing the input system within our game, and takes a look at the configuration process for the system.
Our primary input system is now in place. Here, we shift focus back to the XML file, where we will begin the first part of the key binding process.
Our XML file now contains all of the various key bindings for the computer's keyboard. We now create a method in the Config class to load those bindings.
With keyboard bindings in place and fully functional, we now turn our attention over to the gamepad, creating the necessary class.
We now address the input system of our game, implementing the necessary functionaly to allow the game to be played with a gamepad.
All that is left to do to make the gamepad usable is to create a series of button bindings within the XML file. We address this in this video.
It is time to make our game play some sounds. In this video, we integrate the sound system we coded in a previous video and add in some sounds.
This whiteboard lesson discusses how the screen system will be implemented into our game, and how screens will be swapped during gameplay.
Our first step in creating the screen system is to code out the Screen class. This will be an abstract class, from which all game screens will descend.
The method skeleton for the Screen class is in place. We now focus on the functionality of the screen stack management methods.
We now put the screen system into use by linking it into the main game class, as well as creating our first actual screen.
This video is a whiteboard overview of the draw scaling process we will use to allow our game to handle multiple resolutions.
Here we begin the process of our draw scaling system by coding out the necessary values for our render target, as well as the switching system.
Once the draw scaling system is in place, we need to augment it to handle multiple aspect ratios by adding black bars. We cover this process here.
In this video we put in the architecture code to handle the creation of menus which will be a special type of screen containing a list of options.
The menu system is now put into action by implementing the main screen, which will contain options for which game mode the player would like to use.
This whiteboard lesson walks you through a standard screen progression for single and multiplayer gameplay, showing how screens will swap.
With the concept of screen progression out of the way, we can now add the necessary code to handle that progression within our game.
We now shift the focus of our game's progress back over to the world of music. In this video, we set up the Note class, which stores key music info.
Now that we have coded the necessary class for notes, we now move on to create the Song class, which is essentially a container of notes.
Our Song class now has all of its fields in place. In this video, we move on to the methods and functionality for the Song class itself.
We now demonstrate what our Song class can do by creating our first actual song. This will use many of the skills learned in the MusicEngine project.
In this video we handle song playback with the SongPlay class, which will allow time to progress and cause our notes to move across the screen.
Now that we have a system that will play back notes and songs, we now need to add in the necessary interaction functionality to allow for game play.
Here we create and setup the BeatGenerator class, which will handle procedural song generation for our game. We also demonstrate compound timing.
It is now time for us to move on to the rendering system. Here, we create base rendering class, which will allow for multiple swappable renderers.
We now set up some of the primary code into our horizontal rendering system, allowing it to do more than just draw a few notes on the screen.
In this video we focus on note rendering in our horizontal rendering system. This will handle how notes are actually placed along our game's music staff.
Continuing with the horizontal renderer, we now set up track drawing, positioning the staff, drawing track labels, and dealing with time scaling.
We now move on to set up the background texture for our horizontal rendering system, allowing for a single repeatable texture to move with the notes.
With he background texture now sliding across the screen, we now need to set up the lines for the beats and measures of the song during game play.
In this video we create the necessary architecture to save out our generated songs as ".song" files, so they can be stored on the hard drive.
Once song saving is in place, the next logival step is to create the necessary loading code so that the songs can be pulled in from their files.
The SongLibrary class will be used to populate the main list of songs used for the Song Selection screen later.
Here we create the Song Selection menu screen, which will allow the player to choose which screen they'd like to play in the drum game.
We now need to add multiplayer support. Fortunately, due to the modular nature of the game's systems thus far, this will be an easy task
Once the player finishes a song on the game screen, we need to show them a score result. Here we establish the score screen and work it into the game.
During game play, it will be necessary to allow the player to pause the action. In this video we create the pause screen and it's included menu.
To aid the player in keeping rhythm, we now add in a metronome that ticks out every beat during gameplay, as a way to help practice.
When a player strikes a note, we want there to be a special particle effect that explodes from the note's location. Here we set up the base behavior for this.
In order to keep the particle system simple and fast, we set up a management system that controls the order in which the particle instances are called.
In this video we make song selection easier for those players using drum kit controllers, by allowing the navigation of menus using the drums.
It is now time for us to move on to Freeplay mode, which allows the player to create their own songs. Here, we create he method skeleton for this mode.
With our method skeleton in place, we can now finish off Freeplay mode by implementing the functionality of each of the methods.
This video addresses the idea of snapping notes along the timeline, rather than allowing them to be slightly off the beat lines as you place them.
We now move on to the Save Prompt screen, which will ask the player if they want to save out their creations from Freeplay mode.
We are now ready to move on to our Song Editor. Here we set up some of the basic systems that allow us to put the Song Editor in place.
In this whiteboard-style lecture, we provide a general overview of Edit Mode and how it works, before we jump in and actually start coding it.
In this video we start adding in the base functionality needed for Edit Mode. The first thing we need to address are the various input modes used with the game.
Here, we take a look at adding in our first input mode, which will be Note Edit Mode. This allows us to move the cursor and place notes at the cursor location.
In this video we take a look at note sorting, which allows us to fix a bug in which the default order of notes will cause a song to stop playing when new notes are added.
We now create the visual editing grid that will be used for note positioning. Currently, the cursor already snaps, but we need a grid that the user can see.
There are three modes remaining for Edit Mode, being Seek Mode, Tempo Mode, and Song Shift Mode. In this video, we wrap up each of these modes.
By now the main core of the drum game is complete. Please note that the MIDI lessons mentioned in this video are exclusive to the DVD for XNA Durm Game.
In this first bonus lesson, we start putting together a vertical renderer for the drum game, swiching the visual aspect of the game from side-to-side to top-down.
Here, we add in some of the rendering code for our vertical renderer. We will be borrowing a lot of our code from the horizontal rendering system.
We are just about finished with the vertical renderer. In this video, we add in the measure lines for the system and cleanup the code for finalization.
We are now ready to move on to our second set of bonus lessons. Here, we overview our goal of getting a Rock Band 2 drum controller to function with Drum Game.
In this video we begin working on a system to implement drum state. This allows us to see exactly which button was pressed on the controller.
Throughout this video we will be creating a drum input class which reads in the states of each of the drums and fires out events based on those states.
It's time for us to get our new DrumInput class fully implemented into the game, including adjusting our config file to handle the inputs from the Rock Band 2 kit.
Here, we look at the final decoding logic for our DrumState struct. This allows us to decode the various button combinations that come through on the cymbals.