Tutorials

Unreal Tournament 3 vs UDK: What Should I Choose?

Matt Christian — Fri, 12 Mar 2010 14:23:19 GMT

Many people in the mod community were very excited to see the release of the Unreal Developer Kit (UDK) a few months ago. Along with generating excitement into a very dedicated community, it also introduced many new modders into a flourishing area of indie-development. However, since UDK is free, most beginners jump right into UDK, which is OK though you might just benefit more from purchasing a shelf-copy of Unreal Tournament 3.

UDK
UDK is a free full version of UnrealEd (the editor environment used to create games like Gears of War 1/2, Bioshock 1/2, and of course Unreal Tournament 3). The editor gives you all the features of the editor from the shelf-copy of the game plus some refinements in many of the tools. (One of the first things you'll find about UnrealEd is that it's a collection of tools grouped into the same editor so it really isn't a single 'tool')

Interestingly enough, Epic is allowing you to sell any game made in UDK with a few catches. First off, you must purchase a liscense for your game (which, I THINK is aproximately $99 starting). Secondly, you must pay 25% of all profits for the first $5,000 of your game revenue to them (about $1250). Finally, you cannot use any of the 'media' provided in UDK for your game. UDK provides sample meshes, textures, materials, sounds, and other sample pieces of media pulled (mostly) from Unreal Tournament 3.

The final point here will really determine whether you should use UDK. There is a very small amount of media provided in UDK for someone to go in and begin creating levels without first developing your own meshes, textures, and other media. Sure, you can slap together a few unique levels, though you will end up finding yourself restriced to the same items over and over and over. This is absolutely how professional game development is; you are 'given' (typically liscensed or built in-house) an engine/editor and you begin creating all the content for the game and placing it. UDK is aimed toward those who really want to build their game content from scratch with a currently existing engine. It is not suited for someone who would like to simply build levels and quick mods without learning external 3D programs and image editing software.

Unreal Tournament 3
Unless you have a serious grudge against FPS's, Epic, or your computer sucks, there really is no reason not to own this game for PC. You can pick it up on Steam or Amazon for around $20 brand new. Not only are you provided with a full single-player and multiplayer game, but you are given the entire UnrealEd 3.0 including all of the content used to build UT3. If you want to start building levels and mods quickly for UT3, you should absolutely pick up a shelf-copy.

However, as off-the-shelf UT3 is a few years old now, the tools have not been updated for quite a while. Compared to UDK, the menus are more difficult to navigate through and take more time getting used to. Since UDK is updated almost every month, there are new inclusions to the editor that may not be in UT3 (including the future addition of 3D!). I haven't worked enough with shelf UT3 to see if there are more features in UDK or if they both feature the same stuff in different forms, however you should remember that the Unreal Engine 3.0 has undergone numerous upgrades between it's launch and Gears of War 2 (in fact, Epic had a conference to show off what changed just between the Gears of Wars games).

Since UT3 has much more core content, someone who wants to focus on level editing or modding the core UT3 game may find their needs better suited with an off-the-shelf copy of UT3. If that level designer has a team that is generating custom assets, they may be better off with UDK.

The choice is now yours...

Unreal Engine Tip: Room Surroundings

Matt Christian — Mon, 01 Mar 2010 10:12:01 GMT

Here's a quick tip that you can add to your map to make it much more realistic and make the player "Oooo" and "Aaahh"!

When building a map or environment, consider adding areas the player can see but not go to. This gives your map a feeling of depth and that it is a location inside of a larger world and not a predefined layout.

For example, my current map, DM-Grime, is set within a dark, dingy basement. After I built my walls, added some static meshes, and tossed in a few lights the map was looking decent, however I wanted to give it a bit of a 'destroyed' or 'decayed' look. In the corner of an inner wall (between the wall and the ceiling) I added a rectangle subtraction brush and split the edges of it a few times. Manipulating the generated vertices up and down gave the wall the look it had been broken apart.

To add to this, I used a subtraction brush to generate a similar hole in the ceiling. At this point, a hole in my ceiling was looking up into an empty void since my level was shaped like a giant rectangle. I added a small room above the hole (just big enough to cover the hole). I textured the room with some basic textures and threw in a door for effect. To contrast the lighting in my level, which mostly consisted of yellowish ambient light, I added a bright red light to shine down which brings the player's attention to that spot.

I used 4 simple meshes to accent the destroyed area. From the Content Browser I picked up the I-beam mesh and added two of them. Where the two met, I rotated them downwards, giving the look they had bent down. Second, I added a generic pipe mesh and bent that down as well (though at a different angle). Third, I added a mesh that consisted of 3 smaller pipes and bent those around and down as well. Lastly, I added a crate that is nestled between the first broken pipe and the I-beam.

To make the destruction more apparent, I found some rock piles and broken tiles (my ceiling is made of tiles) and tossed them around on the ground. Finally, each corner of the room was held up by a pillar so for the destroyed corner I added a broken stone pillar and rotated it as if it had been knocked loose but was still standing.

I'll post some before/after photos of the area, happy mapping!

Game Trick: Randomizing Colors

Matt Christian — Wed, 06 Jan 2010 16:13:05 GMT

A cool trick to add to your game is to randomize a color and slowly fade to that color during gameplay. This can be used as the draw color for sprites, the screen background, or anything else that takes a Color. The code is pretty easy and only takes a few minutes to implement.

First, lets create a two variables; one to hold the new randomized color and one to hold the current color that is fading:

Color futureColor = Color.CornflowerBlue;
Color currentColor = Color.CornflowerBlue;

We'll set it to a default of the traditional CornflowerBlue. Next, we need to create a random variable and randomize the Red, Green, and Blue components of our color:

    Random rand = new Random();
    if (futureColor != currentColor)
    {
        futureColor = new Color(rand.Next(255), rand.Next(255), rand.Next(255));
    }

We also check before changing the future color since we only want to fade if they are the same color. Finally, you'll want to change the current color a little each time you update:

    if (currentColor.R != futureColor.R)
    {
        if (futureColor.R > currentColor.R)
        {
            currentColor.R += 1;
        }
        else
        {
            currentColor.R -= 1;
        }
    }

This is the code for the Red component. To update the entire color, you'll need two more sections similar to this for the green (Color.G) and blue (Color.B) components. Experiment with the amount you increment and with how you randomize the numbers for more interesting effects.

Learn XNA: Useful Types

Matt Christian — Wed, 11 Nov 2009 14:05:52 GMT

There are numerous useful types available in XNA that will significantly help you design and build your next game. Here are two of the most useful (in my opinion) and how you can use them in your game (I will focus on mostly 2-dimensional uses).

Vectors

Vectors are amazing! They are seriously, probably one of the coolest types on the block, especially when taking into account that they are used for almost everything in games. The most common forms of Vectors used in XNA are the Vector2 and the Vector3, which are defined as:

Vector2(float X, float Y)
Vector3(float X, float Y, float Z)

Also useful, is Vector4 which is similar to a Vector3, but adds a float W parameter on the end. Vector's are obviously useful anytime you need a small array of floats for any reason (movement speeds, health of 2-4 characters, etc...) The most practical and useful application of Vectors however is all the mathematical properties they work with. They are awesome for a quick matrix v. vector multiplication (primarily used in 3D), and are great in 2D for specifying a movement direction, position, and even a scale amount!

Rectangle

Rectangle's are an interesting type. It took me years before I understood how to effectively utilize the Rectangle type. There are lots of functions that take Rectangle's as parameters and the sooner you use them, the better your code will look. There is a default empty definition for a Rectangle, but the most useful in my mind is:

Rectangle(int X, int Y, int Width, int Height)

The X,Y coordinates are the X- and Y-coordinates for the left and the top edges of the rectangle, respectively. This essentially defines the upper left corner of the rectangle. The Width and Height obviously, determine the width and height. Now that you have Rectangle's being used, you can use them to store global variables useful for determining screen size, specifying the source rectangle from a content file, or useful as a bounding box for collision detection.

Development Diary: Pong RPG

Matt Christian — Fri, 06 Nov 2009 11:31:55 GMT

I have been hard at work recently porting Pong RPG from a PC-only XNA game to an Xbox 360 game in the hopes of potentially releasing it on the Xbox Indie Games Marketplace. Pong RPG (PC) was a great success in my mind because even though it was flawed, it was a full game product that I created from scratch (almost all by myself) since my days in High School (which was when I first created a full game). While it was great to finish the game, the code was extremely difficult to read and very static. I learned a lot from finishing that game and have been applying the recently learned techniques to every project since then. So now that I'm porting the game to Xbox, what exactly goes into porting bad code?

I have been fully re-designing all the code from scratch, essentially rewriting the whole game. The nice thing though is all the time I spent painfully positioning each sprite on the screen is already done since I'm using the old code as a reference (all my screen positions, rotations, scalings, etc... are there for me). At home I currently have a 32" plasma HDTV. When I first created Pong, I built the entire game using a square window and now that I'm in HD, I need to update my old artwork that was built for that screen size (for example, a 1024x768 piece of art with a 1.0 scaling factor won't fill a 1280x720. Thankfully most of the artwork is finished and only requires updates to shape it correctly and to swap out PC-specific art with Xbox-specific art.

How has the code been cleaned up? Almost all of the Sprite loading, storing, and rendering is handled by generic classes allowing me to re-use them in future projects. Here's the setup (class names may differ from my real code): there is a ContentProcessor class that parses '.LFI' files (simple .TXT files with a different extension standing for 'Load FIle'). Each line of the Load File defines either a SpriteSheet or a Sprite. A SpriteSheet is a single PNG file containing one or multiple pieces of artwork within. In Pong RPG (PC) every single sprite had it's own file and required a Content.Load<Texture2D>() call. The SpriteSheet load file commands simply specify a load file to process.

The Content Processor then takes the PNG file defined by the Sprite Sheet command and loads it into a TexturePool. A TexturePool is a class that inherits from List<Asset>. Asset is a custom struct that only holds two properties about a specific game asset: the Texture (Texture2D), and the Name (String). Here is the definition for the Load() function of the ContentProcessor class:

public void ContentProcessor.Load(String fileToLoad, ref TexturePool textures, ref SpritePool sprites)

Obviously the first defines which LoadFile to load. The second parameter, textures, defines where to store the Assets loaded by the ContentProcessor. We'll talk about the SpritePool stuff in a little while. As a side note, ContentProcessor is defined as a static class so we pass the TexturePool and SpritePool variables by reference to avoid requiring the programmer to create an instance of this class.

So ContentProcessor begins parsing the Load File and hits a SpriteSheet command (which should always be first since it's impossible to load a sprite without a related PNG file). Let's assume we're loading MainMenu.lfi (the Load File for the main menu) and there are 2 PNG's we need to load. We would have 2 load commands similar to the following:

SpriteSheet, Sprites\MainMenu\MenuBG
SpriteSheet, Sprites\MainMenu\MenuItems

In our case, MenuBG is a PNG with artwork that takes up the entire file, and MenuItems is a collection of pieces of art placed around in the file. After ContentProcessor parses these lines, our TexturePool variable should be populated with 2 items named MenuBG, and MenuItems (the name defaults to the filename).

Unfortunately that won't be entirely helpful since that only defines the textures and not which parts of them to draw. This is where Sprites come in and are extremely handy. After the first SpriteSheet command to load the MenuBG PNG file, we will call a Sprite command to tell the processor to load a sprite and place it in the supplied SpritePool. SpritePool is similar to TexturePool in that it inherits from the List class, however SpritePool inherits from List<Sprite>. Sprite is a custom class that holds information about the positioning, rotation, scale, boundingbox, and the source rectangle we use to pull from the SpriteSheets previously loaded. Here's an example of a Sprite ContentProcessor command:

Sprite, MenuBG, M-BG, CENTER, CENTER, 0, 1.0, 1.0, 0.1, true, 0, 0, WIDTH, HEIGHT

This looks very cryptic but is really easy to understand. All it does is define what the ContentProcessor should load, how it should load, and where it should place it. Here is the definition of this command:

Type, SpriteSheet Name, Sprite Name, Screen X-Position, Screen Y-Position, Rotation, ScaleX, ScaleY, Layer, Visible, SourceX, SourceY, Source Width, Source Height

The only commands there that may throw you off are the last four containing Source ____. When you create a new Rectangle in XNA it requires 4 parameters: the left side X-coord, the top Y-coord, the width, and the height. Essentially, the first two parameters define the upper left corner of the Rectangle. In our load command, things like CENTER, CENTER, WIDTH, HEIGHT, etc... are simply built in commands that define certain things about how to load it.

We will see more of this in a future code example with a more detailed tutorial!

Learn XNA: Starting Development

Matt Christian — Wed, 04 Nov 2009 13:34:27 GMT

Game development is a great career but we all can't be the next John Carmack. And let's be honest, even though you've got a great resume and a smashing portfolio, the odds are slim you'll get that coveted game programmer job. To sharpen your skills and expand your portfolio why not take a look at Microsoft's XNA Game Studio?

XNA Game Studio is a library built on top of the DirectX framework to ease game development for students and hobbyists while still providing enough flexibility to create games with the quality of some AAA-titles. As an added 'bonus', XNA developers can build games for the Xbox 360, distribute the game via the Xbox Live Marketplace, and even profit from their creations. All in due time young padawan, first you must crawl before you walk....

To get started, you'll need some software on your PC. The first is Microsoft's Visual Studio. Preferably 2008, XNA used to run in Visual Studio 2005 and will probably support 2010 in the near future. Now of course buying Visual Studio would be the best bet considering the quality of the product, but for a whopping $620 (Amazon.com) a lot of us can't afford it. Luckily, there are a few (legal) alternative methods of acquiring the software. If you are a student, you may be able to score a free ISO copy of Visual Studio 2008 Professional from Microsoft's Dreamspark Website. Dreamspark is a resource to provide free Microsoft technologies and software to students. For the rest of us, Microsoft has generously released slimmed-down versions of the Visual Studio products at their Express products website. XNA utilizes C# so for the Express products you should grab Visual C# 2008 Express Edition. Make sure, after you get your respective (legal) copy of the Visual Studio C# editor, that you also make sure you have the latest Service Packs and updates installed.

Next, you need to download and install XNA Game Studio 3.1 (the latest release of the XNA framework). You can find the download link for XNA GS 3.1 and the aforementioned Visual C# 2008 Express Edition at the Creator's Club website. Creator's Club is the definitive website for XNA development and your first (and best, in my opinion) resource for XNA development. The website features tutorials, examples, and starter kits (pre-built games for you to modify), and I can't reccomend it enough! Check the Resources at the end of this article for some other great websites for you to check out.

As for required software, this is generally all you need to start developing XNA games. However, if you want to develop for the Xbox 360 console, you'll need to sign-up for a premium membership which costs $49 for 3 months or $99 for a year. If you are a lucky Dreamspark student, you can grab a free trial membership from Dreamspark. While the trial will allow you to develop and deploy games to your Xbox console, you will need to purchase a paid membership before you are allowed to submit games for sale on the Xbox Marketplace. We will go into the process for submitting a game for sale in a future article.

If you are planning on providing all the artwork for your game as well, you will need some kind of image software. While Photoshop is one amazing program, it can cost between $200-$700 for the latest version. There is, however, a free program online called Gimp which should be a bit better than your old MSPaint.

By this point you should have stopped reading and started tinkering with all your new software. The best part? We have a quality programming environment, a library that supports easy game development, and a full fledged art program for FREE. You have all the tools to get you started, and this is exactly what Microsoft wanted. Oh no, we've fallen into a Microsoft trap!!! Don't fret, this was Microsoft's intention with XNA and it works to our benefit.

I've held your hand a bit during this first article, handing you links and fancy instructions on everything you need. While the instructions (and maybe the links) will continue in the future, I'm going to go forward assuming you have a familiarity with the C# language. There are tons of resources online for C# development, and hundreds of books on the subject. I will be focusing more on techniques used for game development and the XNA framework rather than introducing you to programming. Now go experiment with XNA you little John Carmack you!

Web Resources:

Microsoft Visual 2008 Express Editions
Microsoft Dreamspark
XNA Creator's Club
Gimp Image Editor

XNA Resources:

Ziggyware
XNA Development
XNA Development Tutorials (my old tutorials)
XNA Resources

Intro to SVN: Trunk, Tags, and Branches

Matt Christian — Wed, 30 Sep 2009 09:59:00 GMT

Subversion (SVN) is a popular tool used by many development teams as their primary way of versioning their code. Here are some of the basics to SVN.

Possibly one of SVN's best aspects is the ability to work on a shared code base. This shared code base is called the Trunk. This is typically where the full, buildable code resides. It may depend on your team, but this code may be the code you work on daily and commit to.

This leads into the idea of commits and updates. To illustrate this, let's imagine that you started a small project and had a decent amount of code developed by yourself. Recently, you've added members to your team and need to provide that code as the shared base (the Trunk). You've got yourself a server and through the advances in technology have SVN pre-installed and waiting to grab your code. After opening up your IDE of choice, you would create a Trunk based of the code you have on your machine. The code you have on your harddrive that is not shared is called your Local Version, or Working Version. SVN happily creates a Trunk and is ready to give your team the base code. Now, your team will perform an Update to grab the latest version of the code. An Update will bring the latest code from the repository to your Local Version. After that point, your team is able to work on their code on their own machines and work on different parts of the project. Each person will work on different files and have to submit their changes to the Trunk to create a new, updated version of the code base. To Commit, is the process of uploading your local changes to the code base to use the newly written code. When you created the trunk, you Commited your local 'changes' (the change was from nothing to your project) to the Trunk.

Commits and Updates are wonderful, but lead to a major issue. Let's assume two team members are working on the same file, HelloWorld.txt. Both team members come into work and grab the latest copy of that file within minutes and begin working on it. Team Member 1 types the words 'I Love SVN!' into the file and Commits the file. Meanwhile, Team Member 2 types the words, 'SVN Rules!' into the file and tries to Commit the file. Suddenly we've hit a snag because Team Member 2 wants to put his changes into the base code but hasn't Updated since Team Member 1 commited his file. This problem of being 'out-of-sync' is resolved via a process known as a Merge. A Merge is when a developer looks at the changes to his/her Local Version of a file and the changes made to a Trunk file that hasn't been Updated on the Local Version, and fixes the synchronization issue by ammending the code to include both updates or one of the updates. Here are Team Member 2's possible merge solutions:

Override and Update: In this case, the Local Version of the file is discarded and the Trunk code overwrites everything. HelloWorld.txt would contain the text 'I Love SVN!' from Team Member 1, but not the text 'SVN Rules!' from Team Member 2.
Override and Commit: This is similar to Override and Update, but the Trunk code is overwritten with the Local Version. HelloWorld.txt would not contain the text 'I Love SVN!' from Team Member 1, but would contain the text 'SVN Rules!' from Team Member 2.
Merge Changes: In this solution, both changes are merged into Team Member 2's Local Version and (s)he is able to commit the file and overwrite the Trunk file. HelloWorld.txt would contain both pieces of text from Team Member 1 and Team Member 2.

During the process of Commiting, Updating, and Merging, the code base can change quite drastically. As they teach in most computer classes, backing up your data is key to continuing a project without major losses. SVN handily provides a way to backup your code via Tags. A Tag is a snapshot of your code at a given time. It is similar to a Trunk but it is assumed a Tag will not change in the future. This is useful if a situation arises where it is necessary to revert your code base to a prior state. In larger environments, Tags are created with each build.

Many projects typically require temporary code written during development in order to test specific issues without a fully functioning product. Here's an example, assume that project we talked about earlier needs to test a function that calculates the amount of times a number can be divided by 2. In the final product, that value will be provided by an external system, but currently this system is not implemented. The plan is to develop a temporary text field that will accept a value and run the function. In the final product, there will be only a label with the value in it, not a text box. From what we've been told about SVN up to this point, we would go into the base code, insert our temporary field, and test the function. This is somewhat practical with a single field, but now let's assume there are 100 fields like this. Obviously, it would be a massive headache to Update, write the changes, Commit, and in the future have to Update, revert the changes, and Commit. Sure you could use a Tag, but why create a backup of code that is temporary?

Introducing Branches, a seperate Trunk-style project used for work on a project similar to this. If this team hires a new developer and wants to slowly introduce him to the project but doesn't want him developing on the Trunk, what can they do? Create a Branch for him/her to work on! Branches can be created from existing code bases, including the Trunk and Tags. Even better, you can Merge between a Branch and the Trunk to bring in changes from the temporary project that need to be implemented into the code base.

This is a lot of information, and is really basic when talking about SVN, but very helpful when someone asks you, "Are we going to make a Tag of the Branch before Merging into the Trunk?" Now, go say that to everyone you meet and see if they know their SVN.

Intro to Scrum Development

Matt Christian — Thu, 28 May 2009 19:38:45 GMT

Recently I read a portion of a good book ('Agile Software Development with Scrum' by Ken Schwaber with Mike Beedle). I read this book in order to understand the Agile/Scrum development style used at my new workplace. I took a course last semester in which we used a Scrum development style based on the input given by a student who worked where I've just started and while we seemed to grasp the idea of Scrum, we had it often incorrect according to the book. This is some of the basics of what I learned in the few chapters I read (no infringement intended!). Everything is in my own words (I don't even have the book anymore).

What is Scrum?

Scrum, in the sense I'll be talking about, is a development style of the 'agile' type. Agile development is a method of developing software iteratively, meaning you take your project, chop it up into pieces, and work on the pieces until the whole project is complete.

How does Scrum add onto Agile development? Scrum has multiple user roles defined with it and a specific technique for processing those 'pieces' of your project. Essentially, Scrum creates a bottleneck (in a good way!) between management and the development team in order to keep the development team focused on the current piece of work. For understanding, let's use the idea that your whole project is the engine of your car (or some vehicle). We'll build on this idea throughout this post.

Roles in Scrum Development

In Scrum development, the development team, is called the Scrum team or just team. Pretty simple, huh? The Scrum team is comprised of those in the workplace that focus on the development portion of the project. These include (but aren't limited to) engineers and designers. Anyone who will have to take an assignment and produce some kind of output directly effecting the project. (Note: In my description, directly effecting the project means something like a concept drawing, a demo build, code, etc... More on this in a bit.) In Scrum development a team of about 5-8 is used though if the team is too large, it becomes difficult to manage. If the team is too small, the work (which we'll talk about in a bit) probably won't be distributed or managed well enough between them. In our car symbolism, think of the scrum team as the pistons of the engine.

The Product Owner or Project Owner is the person at the head of the project, typically a project lead. The Project Owner should be a single person (not a team) for reasons we'll discuss later about work (suspense!). This person will delegate the work to the rest of the team. This introduces the idea of the Sprint Backlog. The backlog is a large topic, so we'll come back to the Product Owner after discussing the workflow of Scrum development.

Scrum Development Work-Flow

Remember all those times you've been working on a project (in a non-Scrum team) and someone walks up to you and says, "Could you do me a favor and add this feature?" You know in your mind that by accepting that person you'll be adding more to your workload and thus increasing your development time. Depending on when you start that feature-add, it could potentially increase the development time of whatever you were working on before your 'friend' came over and disturbed you. Not only does this make you less productive (being productive is a matter of quality, time taken, and other factors) but it could even lead you to the dreaded feature creep (something no project EVER wants!).

Scrum prevents this situation by creating a bottleneck (mentioned earlier) between you (the developer) and your feature-needing friend. Again, this bottleneck isn't a bad thing, it's in place to make your life easier by making you more productive. When a request for a feature is needed, the request is dropped into the Sprint Backlog, a list of all the features and work needed to be done before the project is finished. This can include bugs, new features, or changes to currently existing features. Before going on, what is this sprint thing?

A Sprint is a period of time the Scrum Team takes to work on a chunk of items that were placed in that backlog. Typically a Sprint is 30 days (about a month). A month typically is a long enough time to do a good amount of development but short enough that if time is spent during that month on a feature that gets scrapped, the time isn't 'wasted' time (since it was still used on the project and knowledge is gained). Notice I mentioned a 'chunk' of the backlog. This ties back to the idea of working on pieces of your project. So, the Sprint Backlog contains all the work needed to be done on the project and during each Sprint, the Scrum Team selects a portion of the backlog (NOT the whole backlog) to work on. In our engine idea, the Sprint Backlog is the fuel tank, holding the future fuel to be processed. Thinking at a higher-level, the Sprint is the time is takes to process a portion of that fuel. And finally, the 'bottleneck' holding back the fuel is the fuel-injection valve.

Roles in Scrum Development (cont'd)

Each item placed in the Sprint Backlog will typically have a different priority than any other item in the backlog. This is where the Project Owner comes back in. One of their primary roles in Scrum development is managing the Sprint Backlog. They should be labelling each item in the backlog as well as giving each a priority so the team knows when to work on each. Prior to each Sprint, the Project Owner and Scrum Team will meet in a Sprint Planning Meeting to determine which work from the backlog will be worked on during that Sprint. The Project Owner will say "I want this, this, and this done." And the Team will reply, "Well we can finish this and this during the Sprint." This defines the work that will be done in the future Sprint. Isn't it cool that the Team decides what to work on, instead of management?!

There is one more large player in Scrum development even though the system seems complete. The Scrum Master focuses on, well, keeping the team focused on the task at hand. Recall earlier I described the situation in which you as a developer are approached to put in a quick feature as a favor. From everything about Scrum that's been discussed, there is nothing to prevent that situation from happening once again. Sure, we can hope that all work gets put through the Sprint Backlog, but how can we be certain? This is the primary role of the Scrum Master. He/She makes sure the team is on task and following the work for the current Sprint. The Scrum Master accomplishes this tasks by typically having daily Scrums, a short 15-minute meeting where each person in the Scrum Team describes what they're working on.

To keep Scrums on topic, there are numerous things a Scrum Master will do to control the group including limiting the speaking participants to only those on the team (i.e. NO interrupting, suggesting non-teammates like management). One of the biggest ways to keep topic in a Scrum meeting is to only answer 3 key questions:

What have you done since our last Scrum meeting?
What are you going to do before the next meeting?
What is preventing you from completing your plan?

Obviously, if your friend stops by, asks for that favor, and you start working on it, it'll come up in the meeting and the Scrum Master has the task of putting you back on the Sprint work and stopping by your friends office for a little 'chat' about distractions. Essentially, Scrum Masters play the 'bodyguard' for the project by protecting the team from distraction. In our engine example, the Scrum Master is the metal housing the pistons, engine, and other items related to the engine.

Conclusion

So that, in a nutshell, is Agile development with Scrum. It probably seems like a lot of info but there really are only 3 primary roles. And the benefits are amazing! They give power to the team to control their work, not upper-upper management. If all this sounds interesting I'd consider grabbing a copy of that book, 'Agile Software Development with Scrum' by Ken Schwaber with Mike Beedle. They go into much more detail about their personal struggles with project teams and how Scrum development evolved.

XNA Links

Matt Christian — Mon, 06 Apr 2009 17:56:28 GMT

Here are some of the links I mentioned the other day during my TCCC 6 presentation:

Creators Club - XNA's main creator website where you can find tutorials, examples, starter kits, and great forums!
Dreamspark - Free software for registered students (free Creators Club trial account!)
Ziggyware - Great collection of tutorials and links!
Twin Cities XNA User Group - A great local group dedicated to presenting information on XNA.
Torque X - An 'editor' that can be used with XNA (I think it's free if you actually pay for your creators subscription)

There are probably a few more I'm forgetting and I'll see if I can remember them before I post the slides and code.

Loading From a Different Directory (C++ / DirectX)

Matt Christian — Tue, 21 Oct 2008 21:16:51 GMT

I've been struggling with this for probably the better part of a year and I feel it needs a bit of documentation. The problem is that in my past demos I needed all my model and texture files in the same location as the EXE because I didn't know how to read from a different directory. When loading something like a model, what you first do is store the current directory the computer is looking in (which is the base EXE directory). Then you can switch the directory (locally) and read that in. Then, when finished loading and doing whatever else you need, you can reset the directory to the original directory. Here's a code snippet used to store the current directory and set it to a subfolder:

TCHAR Buffer[MAX_PATH];

GetCurrentDirectory(MAX_PATH, Buffer);

std::string sData = "data";

SetCurrentDirectory(sData.c_str());

Now you can repeat the SetCurrentDirectory() call for any other sub folder you need to go into. In this case it goes into a subfolder named 'data'. Then after you're done doing whatever you need to do (load models, create files, etc...), you can call the following to restore to the directory you stored in Buffer:

SetCurrentDirectory(Buffer);