Tag Archives: wp7

Garbage detector from my Gamefest Slides

One of the last things in my slides for Gamefest was a simple little object I had written to help us detect when our code was allocating memory we weren’t expecting. Due to the size limitations of slides I had attempted to to shorten the object to the minimalist version, and in doing so lost a few things. Here is the object I used in its entirety:

Not very much different than what’s in the slides, but a few subtle differences. The most important being whether or not ‘true’ or “false” is passed in during the two calls to GetTotalMemory. What does this code actually do though?

I wrote it basically to allow myself to “wrap” a section of code and measure any allocations from it. At the constructor of the helper object I measure the total memory in use and store how much allocation (in bytes) I expect the code block to take. Then at the end I measure the memory once more and if more memory was allocated than I was expecting I break into the debugger.

A few things to note. First, when you pass in ‘true’ to GetTotalMemory a full collection will occur, so if you are doing this often you will dramatically slow down your application.

Second, you’ll notice that the slides pass in ‘true’ in both spots which is probably not the behavior you want (you’ll notice in the code above that ‘false’ is passed at the end in the second constructor). If you pass in true in both spots, you will only catch allocations that were not garbage because any garbage would have been collected due to the ‘true’ being passed in!

Now, there are times when you do want to know this, so having the option is certainly fine, but the majority of time you want to know about allocations that create garbage, in which case you need to pass in false to the second call.

Another point I brought up during the talk that isn’t obvious is that this code completely ignores other threads. Which means if you have another thread allocating memory in between the two calls, you will get “false positives” that can prove difficult to track down. When I used this method I kept the code I wrapped in this object small to help eliminate them.

To see an example of using this helper in code see below:

Game development is still hard…

It’s hard to believe that over ten years ago I joined the DirectX team with a goal of making game development easier. Back then, being a game developer was a relatively “exclusive” club. The barrier to entry for developers who wanted to make games was very high in all aspects.

My first goal was to make the act of writing the code itself to be simpler. DirectX is very powerful, but was quite esoteric if you didn’t use it every day. At the time, it was C/C++ only as well, and while these are great languages the fact was that Visual Basic developers (C# didn’t exist at the time) outnumbered them five to one (at least). Over the next few years many VB (and some C/C++) developers migrated to C#, DXVB became Managed DirectX, which in turn morphed into XNA Game Studio. Through each of these iterations the act of writing the code for a game became easier and easier.

If my only goal was to make writing code easier, then by any measure I can think of I accomplished this goal, but it wasn’t. I wanted to expand beyond the PC as well, I wanted to allow every day folks to write code for their home consoles, and in 2006 (with the first version of XNA Game Studio) that goal was accomplished as well (followed by the ability to publish and make money a year later). People don’t think much about it now, but that was huge back then. Nowadays it seems every device has a public marketplace and an ability for anyone to write apps and make money from them (and you would dismiss them if they didn’t), but it wasn’t the landscape in 2006.

It was all of these “successes” that prompted my exodus away from the XNA team and into a game studio in 2010. I felt I had accomplished all of the goals I had in lowering the barrier to entry for game development and wanted to move on to my passion of actually creating them. The release of Beards and Beaks has given me a bit of time to be introspective somewhat (which isn’t to say I’m not busy, but still).

For all the successes that we’ve had though, the simple fact is that today, halfway through 2011, game development is still hard.  In some ways, I would argue that it is actually even harder today than it was when I started, albeit for completely different reasons.

While we certainly helped remove some of the barriers to entry over the last ten years, we didn’t remove them all, and we’ve actually added a few new ones. For example, it’s still extremely difficult for an up and coming game developer to hook up with an artist, just as it’s hard for that artist looking for things to stick in their portfolio to find a developer. People are still confused about what a good “game idea” is.

Actually, that’s a good enough side track that I need to break off for a moment for a mini-rant. I swear if I hear one more person tell me that they have a great idea for a game, and then begin describe some story I’m going to scream. In the majority of cases, the story is not what is going to make or break your game (and invariably when someone is describing a “game idea” to me in this fasion, they are not in the minority where it matters). You need to know what game mechanic makes your game interesting. Even in story heavy games, the game mechanic is what makes your game most times. If your game idea is essentially “all the game mechanics of Gears of War with a different story”, this isn’t a good idea.

Sorry, with that rant out of the way, I’ll continue. I believe the barrier to entry for a budding game developer is so low now that the real problems are no longer “how do I make games”, but instead “how do I stand out in the crowd”. The barrier is no longer to entry, the barrier is now to recognition. How can your shining gem of a game rise above the cess pool of thousands of terrible games?

If you ask me, this is an even harder problem to solve, and despite rambling on for all this time so far, I’m not about to say some magic incantation that solves it because truthfully, I don’t know how. Sure, I have some ideas which I’ll go into presently, but I have no delusions that they are a sure-fire way to success.

First, as I alluded to above, you need to have a good mechanic (and a fun game). If you’re trying to make a rip-off of Gears of War, well stop it because you’re not helping anyone and just adding to problem. Now, that isn’t to say that taking a formula that works and improving it is a bad thing, but don’t try to copy something whole-sale unless you can do it better. You want to make a game that’s like Gears of War but includes the ability to turn into a dinosaur and eat folks? Awesome! You want to make a copy of Gears of War with a budget of $30 and a diet coke? Get out of here.

When I say taking a copy of a game and making it better, what I really mean (most times) is “polishing” the game. The term is a little weird to begin with, but basically what it means is that the game looks and feels professional. It’s hard to describe, but you can see it when it’s there and will miss it when it’s not.

People think that polish doesn’t matter as much, but in reality it matters probably more than anything. Consumers can tell. Angry Birds is like a printing press that spits out money, but it isn’t an original idea or anything. The exact same game came out years before it, but that game was unpolished and forgotten to the sands of time. Rovio took the basic idea, polished the hell out of it and have made more money than they know what to do with.

Of course, once your amazing game is out, you then need to market yourself. I feel a bit sorry for the single guys (or small teams) in this regard. At Microsoft, we have entire marketting teams, and it’s still a difficult proposition! I hope one day soon to talk more about this and some ideas I have, but right now this post is already way longer than I was intending it to be.

As the title says, game development is still hard.. I suppose I have a lot more work to do..

Beards and Beaks!

If you follow me on twitter or the like, you may have heard by now that my latest Windows Phone game was just recently released called Beards and Beaks! I’m pretty happy with how the game has turned out, and thus far we’ve gotten pretty positive reviews with an average of four stars, and a large amount of the negative reviews were due to the fact that you can spend money beyond the actual cost of the game (which I can understand the reluctance there).

Beards and Beaks

Gameplay shot!

We had a lot of things we wanted to accomplish with this game, and while it isn’t perfect (what game is?) we did get the big ticket items we wanted in there! We wanted to come up with a game mechanic we hadn’t really seen before that worked well on the phone, and we wanted to enable premium downloadable content on the device. Based on the reviews so far, I think it’s safe to say we accomplished the former, and the latter is pretty easily quantifiable, so I feel really good about how the game ended up!

Meteor Power

Using the meteor power

There are also a lot of misconceptions though, or features people are just unaware of! One of the biggest complaints I see in the reviews is that people think that you have to spend actual money to use the mushroom powers, which simply isn’t true! Now granted, you certainly *can* spend money to use these powers more frequently, but your mushroom power bar slowly refills over time. If you played once a day, you would notice that every day you would have a new full mushroom bar!

Beards and Beaks

Attacking the crows base!

We also have quite a few more leaderboards than it seems most people realize. When you click the leaderboards button on the main menu you will see three leaderboards at first, but did you know the list of leaderboards at the bottom is scrollable? There are quite a few different leaderboards you can see if you scroll that list down! That isn’t even the start of it, every single level in the game has two leaderboards as well (best score and best time)! If you click the button next to the score or time on the level information tab, you will be taken to those leaderboards!

We also have quite a few levels. There are thirty in the base game when you first download it (seven in the trial), and another 15 in the first level pack (which is absolutely free)! Which brings the number of levels for free up to 45. There’s also currently another premium map pack available for $1 (another 15, up to 60 levels), and that isn’t the last map pack the game will see!

Anyone who’s seen my gamertag probably realizes that I love Xbox 360 achievements, and if you’re like me, you’ll be happy to know that getting all of the achievements in this game won’t be a lesson in frustration! It’s possible (albeit unlikely) to get every one of them in your first playthrough of all the levels if you know what you’re doing (and get a little lucky)!

I’m also giving a performance talk at Gamefest in Seattle next month in which I go into the nitty gritty details on the performance gotchas we ran into during development of the game, along with how I found them, and what I did to fix them.  The title of the talk is “Performance Patterns and Pitfalls for Windows Phone Games” if you want to find it in the list!

If you are going to be at Gamefest come find me to chat! Maybe by then someone will know what a Bleego is.

My new project!

After I left the XNA team last year, two of the most popular questions I was ask was why I left and what I was going to do next. It was hard to really formulate a good response to either given the general culture of secrecy that seems to always be around. However, now is the time to lay it all out on the line!

First, why did I leave to begin with? Philosophical differences I suppose you could call them. I was pushing very hard to get a LISP and COBOL version of the project out, and they didn’t think it would have a large enough audience. I still can’t believe they were so naive, but c’est la vie.

When I left I had a multitude of opportunities available to me, each of which were very compelling. Right when word got out I was leaving, I was contacted by the good folks at a new team that was forming. They had discovered that certain images in certain sequences could actually change the chemistry in the brain and give the user experiencing them a completely new outlook on life. The government wanted to get involved though, and I’ve worked with the government before. The technology was exciting, but not enough to work with them again.

Yet another group offered me a new job which sounded at first glance to be quite boring. Have you seen those big number signs where they’re constantly increasing with witty phrases such as “Your share of the national debt is <blah>”? Did you know that Microsoft wrote that software? I was offered the chance to be the guy who watches the numbers scroll by and make sure they stay accurate. Sure, it sounds boring, but you get to travel the world and see lots of numbers, how bad could have it been? Everyone loves numbers!

However, the job I finally took was over in Microsoft Game Studios working on an amazing new title. I probably shouldn’t be telling anyone this, but I’ve been holding it in so long, I just can’t wait anymore. What’s the worst they could do? I’m proud to announce our new game Kinectodeck. Everyone has seen how amazing it can be when you’re the controller, but we wanted to see how amazing it could be if you were actually in the game!  We use an amazing set of new technlogies to transform your living room into the actual game playing field. There are eight different Kinect sensors spread throughout the room along with sixteen mini-projectors which bring the game world directly there! It is a completely new innovative experience, where the possibilities are really limitless.  One of our recent test subjects was sent on an safari adventure where they were out riding a tiger through a lake:

We have a few bugs we still need to work out though. For example, due to our desire to have maximum realism, we may have went a little overboard. Shortly after the picture above was taken, the tiger ate our poor test subject. It’s ok though, she signed the release form. Minor setbacks, something you would expect from such an ambitious project. Major innovation doesn’t happen by being safe!  We’re moving quite fast though, and an expected release date should be just about a year from now, and I can’t tell you how excited I am.

You may be wondering how you write the games though? Why XNA of course!  You will of course need an AppHub membership to get the toolset. I’m also happy to announce that the toolset will be available for download (in a very early alpha form) next week! Stay tuned for more information, this is an exciting time in our industry and I am ecstatic to be a part of it.

Loading… I hate loading…

I guess I’m impatient, because there are very few things that annoy me more than loading screens. In a world of instant gratification, waiting for any significant amount of time is unacceptable. Hell, I’ve only just started typing this and I’m already annoyed that I’m not finished yet. Loading just bugs me, and I see it creep a lot on Windows Phone 7 games. Perhaps I should ramble on about that for a while.

The first goal of the game should be to show me something on screen as soon as possible. While you can “somewhat” use the splashscreen.jpg trick to show something quick, in XNA applications, it doesn’t stay on screen long enough and looks awkward (in my opinion).  I personally would rather show my splash screen on the first render.  However, that leads me to another common mistake I see people making, and that’s loading a bunch of content (or all!) in the LoadContent method.  This is certainly a bad idea if you want to show something on screen quickly. This is essentially the order you will see things happen at startup:

  1. Game’s Constructor is called
  2. Initialize is called
  3. LoadContent is called
  4. Update is called
  5. Draw is called
  6. Goto 4.

While there are certainly nuances here, that’s the basic order, and notice that Draw isn’t called until way at the end.  I’ve seen people decide that the best way to fix this would be to draw something in LoadContent, and then they implement that, see that it works and call it a success. If only it were so easy. If your application is starting up once more after being tombstoned, essentially the same sequence of events happens, however there is a caveat this time.  While the “startup sequence” is happening, the phone will be displaying the “Resuming…” screen (my how I dislike that screen), and will not show anything from your application until the “startup sequence” has finished. In this case, the sequence doesn’t finish until *after* LoadContent has finished. So if you showed something on screen early in your LoadContent method, and then loaded a bunch of content, it would work in the initial startup scenario, and potentially fail in the restore from tombstone scenarios.

The easy way to get around these issues is to do all of your content loading (aside from the first thing you want to see on screen, such as a splash screen) on the second update call.  This allows you to show something on screen quickly in both the initial startup and coming back from tombstoning cases, and if you don’t have much content, should be sufficient enough. Your splash screen image will stay static on screen (and your application is essentially non-interactive) while the content is loading. If it takes more than a few seconds to get to this state though (ie, you have too much content), you have more work to do.

The most common thing I see happening here is the game will load only the content needed for the main UI portions, and will force you behind a loading screen after you choose the level or what have you. Again, this works perfectly fine, but we can do so much better! Why can’t you load everything you need while I’m playing around with the UI? For ease of explanation, let’s say that you are making a 2D game, and you have a large list of strings that are all the sprite textures you will need to load. What if you had a class such as this:

So long as you called BackgroundLoad.Go(this); sometime after you started up, your game would dutifully start loading all of your assets behind the scenes in a background thread.  This isn’t a foolproof solution though. For one, you have very little control over background threads on Windows Phone 7. You cannot change priority, and you have no control over how much they will execute (although on average for every 4ms your main thread is executing your background thread will run for 2ms).  In this example, you are also using the graphics device on another thread, which will take out a lock to avoid multiple threads manipulating it at the same time. In the larger scheme of things though, it’s still probably faster in this mechanism than without.

You will notice two potentially useless pieces of code here as well. First, a property to dictate when the loading has been complete, and a second in which the actual asset load is happening within an action rather than directly in code. The property is self explanatory if you think about it, you still need to know when all of your content has been loaded so you can allow the user to start the game! This just gives you easy access to it.  The action delegate is slightly less obvious though.

What should you do when the user has gone through the UI and is ready to play the game but the content isn’t done loading? As was mentioned earlier, you don’t have any control over the background threads execution time, and because it is running half the speed as the main thread, as the code is written now, your loading time could potentially be *increased*! This is most definitely not what we wanted. What you really want is a mechanism where you would load things in the background if the user was still messing around with the UI, but will switch to loading in the foreground if the user was waiting on loading, and that is what the action delegate is for. If you replaced the code in the thread method with the following, you will get this behavior:

Now your code is loading in the background while the user is messing around with the UI and will switch to the foreground once they’re done. In the degenerate case, this is still slightly slower than simply forcing them to wait at a loading screen, but given the degenerate case is almost certain to never happen, a mechanism such as this will (for most intents and purposes) always be faster. It certainly took me long enough to exlain all this, I should have had a loading screen for this post…

As a final caveat, this was an extremely simple example of multithreading. If you do anything more complex and don’t have knowledge of multithreading (or what the ‘lock’ keyword does), you should probably read up a bit on that!

Artists wanted!

Oh yeah, are you a game artist and you want to see your art in an upcoming book?  Then you should contact me and we should chat!

A new book on Game Studio 4.0

It has been about five years since my last book came out.  During that time, a lot has happened.  Heck, that book was about Managed DirectX, and at the time it came out XNA Game Studio didn’t even exist as an idea, much less a product.  Since then, it’s not only been released, but we’ve announced the *fourth* version of the product!  We’ve added support for Windows, Xbox, Zune, and soon, Windows Phone 7.

So much has changed, so much time has passed, it was time to do a new book.  This new book will cover Game Studio 4.0 in its entirety, including Windows Phone 7, the new features, Xbox, everything.  While we haven’t announced any release dates for Game Studio, I’m spending my spare time (what little I have) to make sure the book will come out as close as possible to the release of the product.

I’m also having some help with this one, and will have a co-author, so that is a bit exciting too!  Writing has begun so if you have suggestions, now is the time!