Sgt. Conker We are "absolutely fine"

3Dec/104

Articles: MVC in games

by Roy Triesscheijn

MVC Primer

MVC stands for "Model View Controller" and has been an architectural pattern in software engineering for quite some time now. MVC allows decoupling between what 'the program is supposed to do' and how this is made visible and controlled.

In MVC the three main responsibilities of the application are handled by three separate parts:

  • The model houses the actual business logic. The model is totally decoupled from the controller and view.
  • The view observes the information from the model, and if needed request an update of the information. Data from the model is lightly massaged, formatted and then presented.
  • The controller controls the application by mapping different kinds of input to public methods available on the model. The model itself always has the final responsibility of doing something with the request made by the controller. In many form-based applications the view and controller are hard to distinguish from each other.

Using MVC will allow you to reuse your complex model in different scenarios. Want to prepare your program for a different kind of input? Just write a new controller. Want to visualize your data in another way, just write a new viewer. In a good application controllers and viewers can even be changed while the application is running.

21Sep/102

Let the voting begin!

We've finally managed to upload all 20 entries in our 'Absolutely Fine XNA Tutorial Contest' and prepare them for your viewing pleasure.

First, we want to start with a big Thank You! to all our entrants for their effort. We really appreciate your hard work, and your desire to enter our contest.

Thank You!

The full list of entries submitted to the article is below:

And now it's your chance to play favorites!

Besides the judges from inside our barracks, we will let the community act as a judge also. You can contribute to the community vote by sending an email to contest@sgtconker.com with your Top 3 favorite articles from the above list, in the order of preference. We know you like them all... We know you want everyone to win... But this time, you have to choose!

We will leave the voting channels open until Thursday, September 30th 23:59 GMT!

Have fun reading the articles and voting for them, and may the best articles win!

13Sep/100

Article: Arbitrarily Shaped Secondary 2D Viewports

by Harry Trautmann

This tutorial shows a technique to implement a secondary 2D viewport which has a shape that does not need to be rectangular, but can be customized by the programmer. Even moving sprite shapes are possible. Utilized code techniques: secondary rendertarget (of XNA Game Studio 3.1) and an alphamap by a pixelshader (PS 2.0).

This tutorial is for beginner to intermediate level programmers. At least you should know the oo basics and know the nitty-gritty about the XNA framework. Also, basic shader programming is explained somewhere else (e. g. here: http://www.sgtconker.com/2009/11/crash-course-in-hlsl/)

9Sep/106

Article: XNA Farseer Platform Physics Tutorial

by Roy Triesscheijn

Today I’m going to introduce you to a neat 2D physics engine for XNA called Farseer. With the help of this 2D physics engine we are going to create a small platform ‘game’ while introducing the important concepts of Farseer like bodies, geometry, joints and springs.

By the end of the tutorial, you'll be able to build something like:

8Sep/105

Article: Rolling World Tutorial

by Christian Schlager

When you look around the XBox Indie Games Channel, there aren't a lot of 3D games around. Most XNA games only feature 2D graphics. I hope to contribute with this tutorial to making 3D graphics a bit less intimidating. And maybe the little prototype we will create throughout the next pages will be the starting point of a great 3D indie game by one of you :)

We will make a prototype that features the kind of rolling world effect that you can see in games such as Animal Crossing or DeathSpank. We will also create the textures and 3D models that go along with the rolling effect and recreate the combination of 2D art with a 3D world you can see in the game DeathSpank.

5Sep/100

Article: I Can Has Platformer? (Part 4)

by Casey Young

I Can Has Platformer Part 4 Final ImageWelcome back to the fourth part of my series on how to create a simple platformer game. In this article, we give our hero a purpose to live.

3Sep/107

Article: Scripting on the Xbox 360, Windows Phone, and Beyond!

by UberGeekGames

Scripting

Scripting. It’s a recurring theme on the XNA forums: “Can I use Lua?” “Can I script on the Xbox 360?” “Scripting FTW! No, scripting FTL!”. Do a quick search for “scripting” on the XNA forums and you’ll find many threads with the preceding themes. There’s a lot of information about scripting, and it usually ends with “no, you can’t do scripting on the Xbox, and it’s probably not a good idea anyway”.
In this tutorial, I’m going to show you what scripting is, a very useful type of scripting that I’ve been using more and more, and how you can make your own scripting system and use it effectively.

1Sep/106

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.

17Aug/104

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/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.