My recent XNA game (Taptitude) on Windows Phone 7 is doing pretty good now that we’ve released the first 4 mini-games free. In making Taptitude we decided to use WCF REST’ful web services to implement leaderboards. Being a total n00b at writing web services we incorrectly assumed everything was working perfectly and went ahead an released the game.

A few days later we started seeing some ridiculously high scores in the leaderboard. At first we didn’t know what the issue was and thought someone had found some clever way to cheat. This was on our ‘Draw a Circle’ mini-game, so maybe someone was tracing a circle and getting crazy scores?

A few days later we released “Stay Inside” and times like 23 minutes were getting submitted (a good time is more like 20 seconds). Now we knew something was up because the same user was submitting scores like that every couple minutes…not even possible.

At this point, Nate realized that all of the crazy scores were from the de-DE locale. What could be so special about de-DE? We started by repro’ing the problem by setting Thread.Current.CurrentCulture to de-DE. Sure enough we started seeing the problem (among other issues). A little bit of debugging later and we narrowed in on the root cause.

Q: What does the floating point number half way between 1 and 2 look like in the de-DE locale?
A: 15 if you’re an idiot and parse it using the en-US locale.

It it’s still not obvious what I’m talking about, consider these unfortunate facts:
1) Germans (among other regions) write decimal points using a comma, where as the US uses a period.
2) When parsing a float from a string using the en-US culture, comma’s are ignored.

Combine these and you get something like “1020.56” in English becoming “1020,56” in German, and then our en-US web service parsing it as “102056.0”!

We had other issues as well with Dates, but I’ll save that for another post.

Moral of the story: Test on every locale you plan to ship to, even if you’re not localizing. Oh, and make your services culture insensitive too.

My first XNA game for Windows Phone 7 is out the door.  One thing that is nice about XNA is that I was able to leverage a ton of code from my previous Xbox 360 game (Wayne The Brain).  This time around we decided to do a collection of mini-games with online leaderboards.  Taptitude is the name of the collection and Taptitude: Volume 1 contains the first 5 mini games.

Screenshots:
https://wpappshub.com/games/taptitude-volume-1

Description:

One common issue we’re seeing is that games assume Guide.IsTrialMode will be fast.  Fast enough to call every frame.  Please don’t do this!  While it is fast on your unlocked developer phone, you will be surprised by how expensive this call is when your game has an actual trial license.  I think Klucher did a good job of explaining the issue, so I’ll just send you his way:

https://klucher.com/blog/trials-and-tribulations/

The short story is that you should not assume this call will be fast, and thus only call it at ‘load time’ in your game.  Whatever that means depends on your game.

Happy coding!

So what’s changed?

Nothing really, I just got bored and needed an excuse to write a language.  In retrospect I’m considering it for use as a game scripting system, but I’m not yet convinced it’s a good idea.

The language I wrote is LISP-like although I played around a bit with the syntax.  I chose this style of language for a few reasons:

1. I don’t know squat about writing languages, and this seemed easy to write.  It was.
2. It’s a dynamic language, which for a scripting language is a good thing IMO.
3. I’ve never used LISP before, but I’ve heard good things.  What better way to learn it than to write it?
4. I like the quoting feature of LISP.  It might come in handy in places where I’ve previously used XML.

It looks a bit like this:

(if (> time 90)
    (do
        (spawn-entity "goomba" `(100 200))
        (send-message self "disable")   
    )
)

As you can see, lists are formed via whitespace separated tokens surrounded in parenthesis.  The first item in a list should evaluate to a function which is then called with the rest of the items as the arguments.  The syntax takes a bit to get use to, but if you format it sanely it’s not too bad.  And it’s a hell of a lot easier to parse/interpret than a C-like language.

Possible uses in a game could be:

• Coordinating level-specific behavior such as scripting cutscenes
• Scripting level-specific entity behavior.  Something like “when the player presses this switch, raise that platform and enable that trigger”.
• In-game console used for debugging and such.

All stuff that could be done without a full blown scripting language…but that’s not really the point.  Sometimes it’s fun to do something just for the sake of experimentation.  You never know when it’s going to turn into something you hadn’t anticipated.

I’ve got a pretty good suite of unit tests going, but I’m still working on reducing garbage before I post it online.  I’ll save that for another post.

If you like fun physics games, then give it a try.  You can download it from the Marketplace->Indie Games section of the Xbox Dashboard, or queue up the download from xbox.com (link below).

Let me know what you think of the game in the comments.

Trailer:
https://www.youtube.com/watch?v=uGSCrymtZOQ

Download:
https://tinyurl.com/yl3wvkr

Screenshots:

For more information about how to tune in to this talk please visit the creators club site:

https://creators.xna.com/en-US/developerseries

My talk is focused on main menu animations, so it may be hard to pick up on the Live Meeting video stream.  If you are following along with the talk and would like to see the demo in action, please check out the video and/or demo code below:

If you can’t make it to today’s talk, I’ll be repeating the talk on Friday (3/26/2010) at 4pm PST.  After this talk I’ll post the slides online.

If you’re a creators club member, we would really appreciate a review: https://catalog.xna.com/en-US/GameDetails.aspx?catalogEntryId=86175871-8cf3-45c6-93cb-f21daee8a008&type=1

Here’s the official trailer:

In this post, I’d like to present an alternative method that has a number of advantages.  I call this ‘The Retained Sprite Method’.  This isn’t a new concept, and there is nothing magical or complicated about what I’m going to show you, but it will go along way to help clean up your code and make more reusable ‘engine’ components.

What is the retained sprite method?

The idea is that you put all of your drawing code in exactly one place.  I’ll call this the DrawingContext.  Furthermore, your game entities do not typically use the DrawingContext to draw anything…only Sprites do.  A Sprites is a ‘dumb’ (no Update) object that describes what/where to draw.  Your game entities (player, enemy, boss, etc) do all the ‘thinking’ (Update) and create/retain sprites in a sprite tree.  Each frame the entities do not have to do anything to draw the sprites, just being in the tree means the entity is drawn.

Lets look a class diagram:

What you see above is a very simple retained sprite system.  This system supports two types of Sprites. 

FrameSprite will draw a single image to the screen (a Frame describes the Texture, SourceRect, and SpriteEffect to use).

TextSprite will draw a string of text to the screen using a given font & alignment.

You can imagine how such a system could be extended.  In my game engine I have other types of sprites like AvatarSprite, AnimatedSprite, MovieSprite, etc.

You can then build higher level components on top of this.  For example, layout/controls framework uses the sprite tree for it’s rendering.

Some of the advantages of doing your drawing this way are:

1. You don’t have spriteBatch.Draw code sprinkled all over your codebase.  It’s all in DrawingContext, so you can upgrade/port to new rendering systems easily.
2. Your game code is more declarative (read ‘clean’), because you’re describing what to draw, instead of how to draw it.
3. Because it’s more declarative, it naturally lends itself to using an animation system as described in previous posts.
4. Things like layers, multiple cameras, culling, etc become much easier when you retain a sprite tree.
5. Sprites can have Children, so doing relative motion is trival.  Whenever a parent sprite moves/rotates, all children are also moved/rotated.  The same applies to Scale/Color.

The sample code below shows how to use this sprite system, and as a bonus I added plenty of animations to show how powerful the combinations of a retained sprite tree with an animation system can be.

If you’re not convinced that this is the way to go, then I invite you to re-create this sample without using the retained sprite tree & post it in the comments.

Lets start with the basic hierarchy of the objects you’ll be working with:
World – the root object for the physics simulation. Step this once a frame & you’re simulating physics! 
  Body – Multiple bodies can be added to the world.  These are the objects that interact with each other via collisions.
    Fixture – A body is made up of multiple fixtures.  Fixtures combine a shape with material properties to form the overall “look and feel” of the body.  An example of a fixtures is a bouncy, slippery circle that’s highly massive.
      Shape – Each fixture has a single shape object that defines its mathematical bounds.  Box2D supports circles and convex polygons.  Multiple fixtures can be added to a body to make more complicated shapes. 
  Joint – The world has a set of joints that bind Bodies together.  Different joints do this using various constraints.  For example a Distance joint will limit the distance that two points on two bodies can separate.  Box2D.XNA has lots of joint types that we can talk more about in another post.
  Contact – While stepping the world, Bodies will collide & respond to collisions realistically.  This is accomplished using Contacts.  You can listen in to the contact being generated and use this information in your game.  Want to know when the players sword strikes the skull of the final boss?  Listen for a contact between the two, and you’re good to go.

Now that we’re familiar with the basic objects of a physics simulation, lets get our hands dirty and make something cool! 

To get started you’ll need to download/install XNA Game Studio 3.1 if you don’t already have it.  Next extract the zip above and open the project in Visual Studio. 

I’ve included the latest Box2D.XNA source (as of this writing, changeset 34963), but if you’re planning on making your own physics project you’ll want to check for a newer version.

The goal for this project is to take an image and approximate it with little circles.  Then when a key is pressed we’ll start simulating the physics and the balls will drop/bounce all over the place.  Sounds like fun, lets get started…

The first thing we need to do is to create the physics World.  The first parameter is the gravity, and the second argument tells the simulation to make objects go to sleep if they aren’t interacting with anything.

I used a gravity of 100 because I’m dealing with pixels/s^2.  Normally you’d want to work in meters & seconds or else things get a bit unstable.

Next we need to add bodies to it.  In this case I will randomly position some circles…you can look at the code to see how I decide on a location, but here’s the code to add the Body.

Now we just need to step the simulation every update (after you press a key):

_physicsWorld.Step((float)gameTime.ElapsedGameTime.TotalSeconds, 10, 3);

The arguments to this method control the time step, and how accurate the simulation is.  Feel free to experiment with the last two for your scene.

That’s it!  We just made a really cool app in only 10 minutes of coding!  Feel free to use Box2D.XNA in your XNA projects, and if you make anything cool leave a comment with a link.