Sgt. Conker We are "absolutely fine"

1Sep/104

Article: Node-Based Scripting

by Blecki

Node Based Scripting

Node-based scripting is not a traditional scripting language. And it's not a new idea, though it seems like people have forgotten about it. New systems appear - see Unreal Engine's Kismet - which people think are amazing new technologies. They aren't new; just amazing. I first encountered this scripting system in the quake engine. It was very crude, and limited, but it had all the basic properties of the system I am about to describe.

A brief note : Throughout this article, I use my own engine, Jemgine, and it's level editor for my examples. Jemgine is available at http://jemgine.codeplex.com You'll need to have XNA Gamestudio 3.1 installed to compile it, and to run the editor.

The target user of a node-based scripting system isn't the programmer, it's the level designer. The level designer might not know how to program. They might be constantly bothering a programmer to write scripts for them. Node-based scripting is an attempt to give the non-programmer level designer tools they understand and can use to create interesting behavior in a level without involving the programmer, and without having to learn a complex scripting language.

24Aug/104

Article: Programming your first XNA 4.0 game for PC, Xbox 360 & Windows Phone 7: Pong

by Thomas "Mister Helmut" Altenburger

Programming your first XNA 4.0 game

I’d like to introduce the XNA framework to you with this very simple and straightforward tutorial. We will see what XNA is and how its basic features works to continue with the programming of your first game, a simple Pong clone for Windows. At last, we’ll try to convert it to the Xbox 360 and Windows Phone 7. This tutorial assumes that the readers have a basic C#/.Net understanding. I hope that it will help you to understand the basics of the framework and that it will motivate you to go further in. The article should be suitable to complete beginners in game programming.

About this tutorial: I wrote this tutorial back in the days of XNA 2.0 beta and used it as an introductory course I taught to master degree students. Since then, it evolved to support XNA 4.0 beta with added Window Phone 7 development.

English not being my native language, please forgive and/or report any English oddities.

This tutorial targets XNA 4.0 beta. It will be updated when the final version will be released. It uses some new features of XNA 4.0 so it will not run out-of-the-box on previous XNA version (mainly due to the usage of Viewport.Bounds and changed SpriteBatch.Draw arguments order).

24Aug/100

Nick Gravelyn’s Alien Aggressors Tutorial

Nick Gravelyn (no introduction needed) has been kind enough to send us his Alien Aggressors tutorial (for XNA Game Studio 2.0) and allow us to share it with the world.

You can get the tutorial here: AlienAggressors.pdf

And you might also need the AlienAggressorsContent.zip pack of content to be used with the tutorial.

Alien Aggressors

P.S. This article first appeared on Ziggyware (now defunct) a while ago.

17Aug/103

Article: Texture Modification using Render Targets, with some Stencil Buffer Action

by Dave Carlile

Planet Craters

Sometimes you need to modify a texture while your game is running, and there are a number of ways to do this. One of the first things newer game programmers often try to do is use Texture2D.GetData to copy the texture data from the GPU to an array on the CPU, modify the bytes, and then send it back to the GPU with Texture2D.SetData.

This is a bad idea on many, levels. Beyond issues with pipeline stalls, GetData and SetData can be slow, especially when working with a large texture. Any time you’re tempted grab data from the GPU for use on the CPU you should very carefully consider all of your options. There are often other solutions that let you keep the data entirely on the GPU and accomplish the same thing.

This tutorial will use an example that could be solved with GetData and SetData, and show you another alternative using render targets and the stencil buffer that will let you perform the same function entirely on the GPU.

14Aug/100

First two entries to our contest are online!

Hi all,

Two fine entries into our contest are now online.

Input Playback, by Jesse Chounard
Derived Effect Classes in XNA 4.0, by Dave Carlile

Do you like them? Submit your own! :)
Have a nice reading!

14Aug/105

Article: Derived Effect Classes in XNA 4

by Dave Carlile

One of the nice API changes in XNA 4.0 is the simplified syntax used when drawing with an Effect. In previous versions you would draw things like this:

effect.Begin();
foreach (EffectPass pass in effect.CurrentTechnique.Passes)
{
        pass.Begin();
        // draw your stuff
        pass.End();
}
effect.End();

Now you can draw things like this, with EffectPass.Apply handling all the magic:

foreach (EffectPass pass in effect.CurrentTechnique.Passes)
{
        pass.Apply();
        // draw your stuff
}

Related to this is the new Effect.OnApply virtual method which gets called by EffectPass.Apply. By overriding this method in a derived class you can do things like perform pre-shader calculations and set shader parameters from properties. This is how BasicEffect and the other new standard shaders work, and it would be nice to be able to duplicate that functionality in our own derived effects.
Ideally we would like to be able to do something like this:

        MyEffect effect = Content.Load<MyEffect>(“myeffect”);
        effect.World = Matrix.Identity;
        effect.Color = Color.Blue;
        ...
        effect.Apply();
        ...

The first line is where we begin running into issues. In order to load a derived class using the content pipeline you have to write your own content processor, reader, and writer, for every single class. You might think that you could load an Effect instance using the content manager, then create an instance of your derived Effect class and pass in the code. Unfortunately, there is no way to get at the code in the Effect instance (okay, that is not entirely true, but this solution requires the full Game Studio install).
If you want to store the class properties (e.g. MyEffect.World, MyEffect.Color) as content then extending the content pipeline for each class is your best option. But what if you don't need to store the properties? What if you just want a cleaner interface to your shaders? Extending the pipeline each time for these cases seems like a lot of unnecessary work.

A Solution

This remainder of this tutorial will show you how to load any derived Effect class from the content pipeline without having to extend the pipeline for each class. To accomplish this we're going to create a content pipeline extension library that will compile the effect into an intermediate object that will let us get at the compiled code. We will also create a game library that will define the intermediate class so we can get to it at run time. And finally we’ll add an extension method that will do the work of loading our derived Effect class.

14Aug/1011

Article: Input Playback

by Jesse Chounard

Input Playback

Lately I’ve noticed a trend in games to allow players to save and play back recordings of their play upon completion of a match.  This allows players to analyze their mistakes, as well as learn new tactics and techniques from their opponents.  This feature is becoming common in all sorts of games.  You can find it in real time strategy games like StarCraft, first person shooters like Halo 3, and fighting games like Super Street Fighter 4.

In many cases, these gameplay recordings are often uploaded to a server on the internet, and are available for download by anyone.  The recordings don’t require buffering or waiting for a big download to finish.  Instead, the playback just starts right up.  How is this possible?  Great looking high definition video files are gigantic.  Also, video compression takes a huge amount of computation, so wouldn’t it slow the gameplay down to record everything?

It turns out that there’s a really simple trick.  We’re not recording video.  Instead, we just store all of the user input, and then later we can use those inputs to exactly recreate the gameplay in our game engine.  So while it looks like we’re watching a stored video, instead we’re just watching the computer playing the game using our stored inputs instead of using the game controller for input.

In this tutorial, I’ll show you a simple method that you can use to achieve gameplay recording and playback, and also list a few other uses for this technique.

10Jul/105

Teaser: XNA tutorial contest

We have an important announcement to make! We are currently busy in the barracks with something we call "The Sgt. Conker 'Absolutely Fine' XNA Tutorial Contest" (temporary name).

I'm sure you can come up with some ideas about what the name means, and you can expect more details about the specifics sometime next week. Stay tuned because.... IT'S COMING!

25Jun/103

Video: Simple Component Model

This video is a 'program as I go' recording of creating a simple component system.

There wasn't really a design being followed so it may not be the most obvious implementation (or even very good). So I make no claim to it being the best or fastest way either.

You will need silverlight to view the video.

Simple Component System

Tagged as: 3 Comments
22Jun/104

Windows Phone 7 – XNA Brightness and Contrast

With the addition of Windows Phone 7 support to XNA comes some limitations. If one wanted to have brightness and contrast controls for their game, previous methods may not be available. Considering features such as programmable shaders or device gamma ramp to achieve such a task will leave you out of luck. However there is a simple (and perhaps old school) way of doing it, and that is blend states.

Click Continue reading to see how!