However I recently thought about the feasibility of adding Windows 8 support to ScriptTD with SharpDX. Right now ScriptTD is written using XNA, and for the phone this is the only option. If the core of ScriptTD can be separated from the XNA libraries with appropriate wrapping, it will certainly be possible to add simultaneous support for both systems, and right now this looks like the best way forward.

That all said, this means that work will need to be done on the wrapping layers, and I will need to talk to Microsoft about the idea, to see if they want to help create or extend the sample for Windows 8, as this would require higher resolution art assets for the generally higher resolutions Windows 8 enjoys.

Thankfully Alexandre (the creator of SlimDX) has announced that SlimDX 2.1 would go live this week, so I can start working against that version soon.

More progress as it happens, hopefully sooner rather than later.

Accounts in the app don’t need a specific type, so they can be used for Cash, Credit Cards, Keycards, and even Gift Cards. (A great way to track how much you have on that gift card you received for Christmas)

The app makes use of live tiles which let you see how much remains in each account from your Start Screen, and you can email yourself a list of the transactions you recently made, so it is easier to note these down in whatever application you use to track your overall spending.

I recently submitted a 1.1 update to fix a rare crash I noticed on AppHub, as well as a light re-style to take into account things like the accent colour. (Hopefully this lets my app fit the Metro theme a bit more)

Any and all feedback is welcome. The official support email is mtsupport at mquandt dot com, or you can post in the comments here, or contact me via Twitter.

This time around the app will be released in all regions as well. (I must have missed that setting before)

I found that to get the correct X/Y/Z values, you need to make use of a constant defined in the C++ SDK, called the Inverse Focal Length, which is defined in pixels for our purposes.

float invFocalLength = 3.501e-3f;

Once you have this, you need to go through every pixel in the depth map, and first divide the depth value by 1000 to take it from mm to meters. Then you use the following expressions to get your X and Y values:

z = inputZ / 1000.0f;
outputX = (inputX - 0.5f) * (invFocalLength * z);
outputY = (0.5f - inputY) * (invFocalLength * z);

If you want to use this directly in a 3D scene, it is recommended that you multiply the resulting values by 320 and 240 for X and Y respectively; if you just want to process it, you should leave the data as is.

Note that the X and Y input values are normalised in the range [0, 1] before being used in that equation.

If you have anything you want to see in v2 or in the future, please head over to the discussion board, specifically this post: http://scripttd.codeplex.com/discussions/277634 and give your feedback. I probably won’t do anything too unique as this is still supposed to be a general engine, but if you feel there were features important to the Tower Defense genre that were missing from v1.x, please let me know, and vote in the Trello board if they’re already there.

ScriptTD is a project I have been working on for the past year now, although we officially launched a couple of months ago, I’m still working on v2.0. The goal was to create a Tower Defense game engine for Windows Phone 7, allowing people with no coding knowledge to change the data files and art/sounds to create their own Tower Defense game. This was an interesting challenge to work on, and I’m reasonably happy with the first result, however there is still plenty to add and refine.

You can get the source code for the project at http://scripttd.codeplex.com/ and there is quite a bit of information about what each XML file does. I also wrote an article which is located at http://channel9.msdn.com/coding4fun/articles/ScriptTD-Tower-Defense-Made-Easy and covers how to extend the code (C#) to create a new weapon type.

For those interested in trying out the game on their Windows Phone 7 devices, you can get it from the following marketplace link:

http://www.windowsphone.com/en-GB/apps/ee836335-27a7-e011-986b-78e7d1fa76f8

Be aware: it is quite challenging, but free for everyone. The game is compiled for WP7.0, so you don’t have to have Mango to run it.

He currently has two parts complete, covering the UI and UV Mapping, with more on the way.

You can read the series at his blog on the XNA UK User Group here:

Part I – UI and Exporting

Part II – UV Mapping

Part III – Normal Maps

The first step is deciding which side will create the session and which side will join. Considering we only have the option of working with the Xbox 360, and you might not want to include any debug views or information in your Xbox code, the option I chose is to have the Xbox create the session. The code is compatible on both platforms so if you’re willing to add some system to find and join an active session, you can easily change this to create the session on the PC. For the purposes of this article the session will only contain two “Players” and the Xbox will create whilst the PC side joins.

Creating

We start by creating a session, in XNA you can do this with the NetworkSession.Create() command, which creates a NetworkSession object that maintains the session. Then specify session.AllowJoinInProgress to be true, this lets you create the session and at any time join or rejoin from the PC side.

_session = NetworkSession.Create(NetworkSessionType.SystemLink, 1, 2);
_session.AllowJoinInProgress = true;

Another key thing to note here is that you will want to specify the network session type as SystemLink, this lets you sign in with your Creators Club gamer tag on the Xbox, and use a local player on the PC side – no extra accounts!
We then specify a maximum of one local gamer on the Xbox side, and a total of two gamers in the session. (Change as needed)
Finally we handle the session.GamerJoined event and in the handler we start the game if the current session state is set to Lobby.

Receiving

At this time you might want to also create a PacketReader and PacketWriter, as we will be using these to do our communication. These can be created at any time, and are not tied to a session, so it is a good idea to create them once and re-use over multiple sessions/games.

How you want to receive the data is up to you, however I chose to allow the Xbox game to register some callbacks for named commands. That way the PC side can specify the name of the command and send data along, which can be passed through as a byte array. This is rather simple to setup, you simply maintain a Dictionary<string, Action<byte[]>> that contains all of the callback delegates and names. Then when a packet comes in it will have the name of the callback as well as the byte[] data, which lets you gets the callback from the Dictionary and call it, passing in the data as is.

On the PC side you simply send the callback name, length of the byte array and the bytes themselves, ready for the Xbox to accept and use.

I further split this into “Commands” and “Data”, to provide a clear separation of things like console commands, and raw data, but both use the same system of a Action<byte[]> delegate callback.

Joining

When joining, the PC needs to do two things:

1. Search for sessions
2. Join a chosen session

The NetworkSession.Find() method provides a list of available sessions currently running over SystemLink, which is usually going to be just one, however if you’re working in a larger team with multiple systems on the same network, you might want to list them and display the host gamertag, so that you can choose the right one.

Once you have chosen the network session, you pass that to NetworkSession.Join() which creates a NetworkSession object that you can use just like you do on the server – except this time you don’t worry about starting the game.

Updating

Once the session has been created and is up and running, on both platforms you need to call session.Update() in your update loop. This handles the networking side of things and gets/sends the packets as needed.

Once you have updated, you can make use of the PacketReader and PacketWriter objects to receive and send packets respectively. To receive the data, you need to first check if there is data available by checking the session.LocalGamers[0].IsDataAvailable flag. If there is data available, you can call session.LocalGamers[0].ReceiveData() passing in the PacketReader which you can then use to parse the packet and call the appropriate callback.

If you have data you want to send, you just need to call session.LocalGamers[0].SendData(), and pass in the PacketWriter with the data you want to send.

In the background XNA handles the network magic, so you just have to worry about handling the data on either end.

Code

I didn’t have time to put up a complete code sample for this article, however I hope you understand the general technique. Code for something like this really needs to be tailored to your purpose. If you are just writing a debug console or tweak system, you can just use the command system mentioned below. However if you want to write a sync system for your editor, with camera sync and everything else, you will probably want to change how you send and receive data to optimise for what you are sending.

Create

_session = NetworkSession.Create(NetworkSessionType.SystemLink, 1, 2);
_session.AllowHostMigration = false;
_session.AllowJoinInProgress = true;
_session.GamerJoined += (s, e) =>
{
    if (_session.SessionState == NetworkSessionState.Lobby)
        _session.StartGame();
};
_session.GamerLeft += (s, e) => _session.EndGame();

Find

AvailableNetworkSessionCollection sessions = NetworkSession.Find(NetworkSessionType.SystemLink, 1, null);

Join

(‘session’ is an AvailableNetworkSession taken from the collection in Find)

_session = NetworkSession.Join(session);

Update

if (_session != null)
{
    _session.Update();
    if (_writer.Length > 0)
        _session.LocalGamers[0].SendData(_writer, SendDataOptions.None);
    while (_session != null && _session.LocalGamers[0].IsDataAvailable)
    {
        NetworkGamer sender;
        int numBytes = _session.LocalGamers[0].ReceiveData(_reader, out sender);
        if (numBytes > 0 && !sender.IsLocal)
        {
            string methodName = _reader.ReadString();
            int numBytes = _reader.ReadInt32();
            var data = _reader.ReadBytes(numBytes);
            Action method;
            if (!string.IsNullOrEmpty(methodName) && _commands.TryGetValue(methodName, out method))
                method(data);
        }
    }
}

Sending

public void SendCommand(string methodName, byte[] data)
{
    _writer.Write(methodName.ToLower());
    if (data != null)
    {
        _writer.Write(data.Length);
        _writer.Write(data);
    }
    else
    {
        _writer.Write(0);
    }
}

When judging I attempt the following:

1. Test on Phone (HTC Mozart)
2. If that fails, Test in Emulator
3. If that fails, Watch Video

Now obviously the further I go along that list, the less you will receive in the polish section, and that varies based on which round it is, and when the game fails. (A game that times out during first load will lose more than a game that randomly crashes mid-game, my phone isn’t wildly different from most other phones out at the moment)

Now this is all well and fine you say, it works on my phone and unexpected crashes can occur early on in development. Sure, no problem, I can always test in the emulator, except of course if you put the game into the Games Hub. Whilst that will work on my phone, this unfortunately does not work on the stock emulator, which lacks the games hub. That means that it is impossible for me to test your game, and you will lose quite a bit more as I have to try and figure out the scores based off your gameplay video submission. It is after all impossible to get a good feel for the fun in a game from just a video. (or am I too jaded after many trailers that hype up modern games past their real level of fun?)

So please, if you’re developing a game for the competition, do *NOT* put your game into the games hub, because your game might crash, and I can only play (and judge) what is accessible.

When implementing the light pre-pass algorithm in XNA 4.0, I found that the alpha channel was messing around with my intermediate render targets.
To resolve this, you need to create a custom blend state object (cache it) with the colour and alpha destination and blend states set to BlendState.One.

This should prevent any modulation based on the alpha value in a texture when sampling.

*Edit* Small code sample:

var _alphaBlend = new BlendState()
            {
                AlphaDestinationBlend = Blend.One,
                AlphaSourceBlend = Blend.One,
                ColorDestinationBlend = Blend.One,
                ColorSourceBlend = Blend.One
            };