The Right Moves

Popfly Parting Present

Ben Anderson — Thu, 27 Aug 2009 00:30:27 GMT

http://www.popfly.com closed its doors for good this Monday. One of the questions we got quite a bit was whether we could release the source code in some form. Unfortunately for most of Popfly, this wasn’t really possible – it was either tightly coupled with internal Microsoft web services, contained code from other products, had other IP encumbrances, or otherwise wouldn’t be useful except in an MS data center.

However, we were able to put together something for you – the Popfly Game Engine. Now this is just the game engine – the part that plays the game data files. It doesn’t include the creator (although it does contain enough reference information on the data files that someone could create a new one), nor any server-side support code – I took out the portions of the code that communicated with popfly.com for high scores, badges and the like. However, I do think it’s an interesting bit of code showing how to create a simple game engine in C# on Silverlight. This should also provide an avenue for those of you who would like to take the leap from the world of the GUI game builder, look under the covers to see how things work and actually get your hands dirty with some real code!

When you check out the code, there’s a few steps described in the readme on obtaining some dependencies and game data files. If you used the Popfly Game Downloader we released a few weeks back to grab your games, there’s also instructions on how to crack them open and grab the data files.

With that, check out the Ms-PL licensed code at Codeplex!

Bye Bye Popfly

Ben Anderson — Thu, 23 Jul 2009 01:06:45 GMT

By now you’ve probably heard the sad news that come August, http://www.popfly.com will be shutting down. You can read more about the details here. While we’ll miss the site and working on it, the team has moved on to new and exciting projects which you’ll hear more about (here and elsewhere) as we get ready to talk about them.

In the meantime, one of the big pieces of feedback we got from users was a strong desire to be able to save the projects they made on the site. Unfortunately, that’s not really possible for a lot of project types as they depend heavily on services hosted on popfly.com. However, Adam and I spent some time thinking about what could be done for game projects and this is what we came up with:

Basically, this app connects to popfly.com, downloads your game and creates a Silverlight XAP you can use to run your game locally on your own machine. There’s also an option to download all your shared games at once. Details can be found here.

I’m very glad we were able to get this out so people can save their hard work, not least of which because I have some games I want to save! Please keep in mind this is something Adam and I did in our spare time (lots of Adam’s spare time – he created the nifty downloader app while I simply prepared a special version of the game engine that doesn’t require access to popfly.com). There are undoubtedly a number of issues and it may or may not work on every game and on every computer. Hopefully, in most cases it should “just work.”

Happy Downloading!

Circular References no More

Ben Anderson — Thu, 26 Feb 2009 03:01:59 GMT

So the thing I’ve always found to be the biggest PITA about “web app” development is the classic DOM/JavaScript circular reference issue (I’m pretty sure this applies to both Firefox and IE and probably others). The DOM is COM (or XPCOM) based and measures lifetime of objects by reference counting while JavaScript relies on a garbage collector. The problem in the past has been they have no insight into each others’ memory management so when you have an event handler which has a reference to a DOM object, the DOM object holds on to a reference to the handler and the handler holds a reference to the DOM meaning the JavaScript garbage collector can’t clean up since it knows there’s an external reference to the handler and the DOM can’t clean up since it knows there’s a reference to it from JavaScript that the handler’s holding. It can be pretty easy to end up in a situation like this when using closures as event handlers since closures keep a copy of all local variables from the function they are declared in. You wind up in similar situations when interacting with other COM based add ons like Silverlight 1.0 from JavaScript.

When I was looking around for tooling to help identify these leaks (they’re not always easy to find, even through thorough code inspection and best practices like eliminating closures as event handlers), I came across this IE8 whitepaper:

http://code.msdn.microsoft.com/Release/ProjectReleases.aspx?ProjectName=ie8whitepapers&ReleaseId=578

Not sure if the fix includes only DOM object relate leaks or fixes COM references more generally. Will try to find out and post an update if I find an answer.

I’m actually surprised I haven’t heard about this before. Memory leaks due to DOM/JavaScript interaction are one of the biggest headaches of anyone doing web “apps” like Popfly where the leakage really becomes noticeable as people interact with your pages extensively and for long periods of time. I don’t think Firefox did anything about the issue in 3.0 (but they might have, I admit that since I didn’t even know about this in another MS product – IE8, I could very well have missed Firefox fixing the problem as well). IE developer marketing folks – where are you? This is awesome.

Moving the Popfly Game Creator engine from Silverlight 1 to 2

Ben Anderson — Sat, 06 Dec 2008 05:52:00 GMT

In our most recent Popfly update, we shipped the project I’ve been working on for the last couple months (along with Patrick Wong, Tim Rice and help from the rest of the team), which is a fully backwards compatible game engine, completely rewritten from browser based JavaScript rendering using Silverlight 1 to a C# based engine using Silverlight 2. As noted elsewhere, the new engine is a heck of a lot faster than the old (both due to switching to a compiled language from an interpreted one, and due to many efficiency improvements), but the most impressive thing about the switch in my mind is the fact that it’s as fully backwards compatible as any incremental change we’ve made since the original release. Think about it – the engine’s written in C#, but all the custom code is still in JavaScript.

That is largely thanks to Patrick’s efforts. In order to keep custom code working, what we did was take the current version of the Silverlight version of the DLR (the “Silverlight Dynamic Languages SDK”). We did tweak the JavaScript implementation a bit to make code intended to work with the JavaScript Silverlight interfaces play nice with the managed interfaces, but overall, it was pretty much plug and play aside from all the hard work figuring out a largely undocumented piece of prerelease software :) (I think it’s on version 0.4.0 currently). If you haven’t checked it out, the DLR is a pretty slick piece of technology – despite the fact we’re running a bunch of JavaScript code, it’s still miles and away faster than the old engine which ran on the browser’s JavaScript engine (although I’m sure efforts in IE8, Chrome and Firefox 3.1 will narrow the gap).

What does this mean for you? If your a Popfly game creator, it means a much faster engine that is more consistent from browser to browser. That means you can add more actors and other craziness to your games. If your a software developer with a lot of code in Silverlight 1? Well, for you I’d say it means you should feel free to move to C# and Silverlight 2. It took me a couple months, largely on my own with about a month of help from Patrick to rewrite a large chunk of code that had been developed over the previous year or so by a team that grew from one to three (and occasionally more) devs. The cost was larger than it might have been because I also used it as an opportunity to re-architect and clean up the game engine, and I had to maintain compatibility with a large and complex set of existing data (the thousands of games already on popfly.com). I would expect that for most other Silverlight applications, the cost would be significantly less. What I got out of the experience was the vastly superior tooling experience of C# and Silverlight 2, a huge perf boost by moving to a compiled language, the maintainability of C#, the chance to follow the computer science adage of "throw one away”, and a much better code browsing and IntelliSense experience (again due to the fact that C# is strongly typed and compiled). My advice if your considering a similar move would be to take a look on what code you’re likely to touch again, and if you can see yourself working on it regularly, or if it has strong perf requirements take the leap.

If you’d like to hear more about Silverlight 2, working with the DLR, the port, or the engine, let me know in the comments and I can go into more details on the areas that interest you.

Performance Tips (Part 2)

Ben Anderson — Wed, 15 Oct 2008 01:25:52 GMT

Yesterday we began our discussion of performance optimizations in Popfly Game Creator. In that post we discussed how collision detection impacts performance as you add actors and ways to mitigate that impact. Today I’d like to talk a bit about the other bottleneck people hit and that is Silverlight drawing perf. along with some best practices in creating and using your actors to keep your games snappy. Today’s article contains discussion and techniques that are fairly advanced, so if you feel a little over your head, definitely try the tips outlined in Part 1 first.

Silverlight has great support for a number of drawing mechanisms. It supports static images in the form of jpegs and pngs, as well as XAML based vector art which can be generated either by hand, with a tool like Expression Blend or exported from art packages like Expression Design or Adobe Illustrator. Vector art has the advantage that it can be smoothly scaled (as well as rotated, skewed etc) as large as you want, and since it’s all computed geometry it will look as sharp as it did in it’s natural size. Some people also like to say that it has a smaller file size than traditional image files which define their content pixel by pixel, but this isn’t necessarily true. It’s more accurate to say that the file size remains more or less constant regardless of it’s final rendered size. With traditional image files, the file size grows as the image dimensions in pixels grows, however it shrinks when the dimensions shrink. There is plenty of vector art (XAML or otherwise) with file sizes at reasonable resolutions that far exceed the equivalent png or jpeg representation. This is because XAML file sizes grow as the complexity of the image they represent grows. Designers can easily create files that weigh in the megabyte range by adding more and more detail to their images. They can also create relatively small files by sticking to a few simple geometric shapes in their designs.

So what does that mean for all you budding Popfly game designers out there? Actors in Popfly are defined as XAML. First, realize that the complexity of a XAML file doesn’t just increase the file size, it also increases the amount of time it takes Silverlight to draw an image. So if you’re using XAML to draw your actors, you can shorten the time it takes Silverlight to draw them (and thereby increase your framerate) by simplifying their XAML – the fewer and the simpler elements the better. This also has the added benefit of reducing their download size for your users. Sometimes though, a complex image can do the job much better than a simple one. If that’s the case, realize that unless you are scaling your actors to fairly large sizes, you can simply use an Image element in the actor to incorporate a static .png file of the appropriate dimensions containing your actor’s appearance. Because with a static image, Silverlight can simply copy the bits to the appropriate location on the screen (an operation often called bit-blitting), it doesn’t have to do any processing to draw the image. This can dramatically increase the speed at which it draws as bit-blitting is an operation that is highly optimized and has been hardware accelerated by graphics cards for many years – since well before consumer 3D graphics accelerators even existed. Most Microsoft provided actors are XAML based so that they scale smoothly, but if you’re not using this functionality, you can always screenshot them while your game is running (press Print Screen to copy the current screen to the clipboard then paste the results into Paint or Paint.Net), fill in the background with transparency, then save the image as a png of the appropriate size and replace the actor’s appearance with the static image. Particularly with a scrolling viewport, this can save a lot of cycles.

Finally, if your game uses a tiled surface to represent areas of the game such as fences or the ground, you don’t necessarily have to tile multiple actors to achieve a tile effect. Doing so increases the number of actors active in the game which hurts performance as we discussed yesterday. Instead, you can tile the image in your XAML. This is especially easy with image elements since you can just copy the image element, change it’s Canvas.Left or Canvas.Top and tile the image to any length you want. To see an example of this technique check out the game I’ve shared here. If you rip the game you will notice that I did not use a single fence actor but rather several – Tall Fence, Wide Fence and Medium Fence. This is because I simply wanted the fence to stretch across the sides of the screen. If I just stretched the actor the image skewed and if I tiled the actor things slowed down. So instead I manually did the tiling. Click on the Wide Fence’s appearance and select XAML to see the technique. Tools like Expression Blend can help you do this if you’re having a hard time doing it in Popfly’s text editor:

Hopefully these articles will help out those of you who have been running into performance barriers when creating your games. To discuss these tips and tricks, to share your own tips or to get additional help, checkout the Popfly Game Creator forums. You can also check back at this blog for future tips and tricks.

Twitter Feed Gadget

Ben Anderson — Mon, 13 Oct 2008 22:44:54 GMT

I started playing around with Twitter recently and have been having a lot of fun. Some of you may have noticed that I added a Twitter gadget to the blog sidebar here which allows readers to see my feed. The block was created using the Popfly Mashup Creator by simply connecting the Twitter block to a list display block.

If you’d like to use a similar gadget on your blog, Facebook account, personalized start page or Vista Sidebar, just use the mashout control to rip the project to your own Popfly account. You can then customize the input to the twitter block and change the html link to point to your own feed (or simply use my project and enlighten yourself with my random musings!).

Performance Tips (Part 1)

Ben Anderson — Mon, 13 Oct 2008 18:54:00 GMT

While we’re constantly working to improve the performance of the Popfly Game Creator, there are a number of tweaks you can make to your games right now to improve your users’ frame rate.

Right now, there are two main bottlenecks for games created using Popfly and depending on the characteristics of your game, one or the other can probably help you.

Today we’ll talk about the biggest perf. hit for most games, which is collision detection between a large number of actors. There are a number of ways to address this.

The easiest trick is to make as many actors as possible non-solid:

This is a per state property, so if your actor has multiple states, make sure you set it for each one. When an actor is non-solid, it’s collision bounds will be drawn in blue instead of red.

When an actor is non-solid, it will no longer push or get pushed when it collides with other actors. This allows us to skip testing it for collisions except when there is a collision listener whose event includes the actor. Even then we only have to test it against other actors that are included as the other actor on the same event.

The next approach is to limit the number of actors you use on any scene. While this can lead to a less compelling game, but if your game is bottlenecked on collision checking, it is guaranteed to increase performance.

If neither of the above is desirable, you can also increase performance by limiting the motion of your actors. When an actor has not moved, it often allows us to skip testing it in parts of our collision detection. This also improves Silverlight drawing performance (which we’ll talk more about tomorrow) since we will not have to update the Silverlight plugin and Silverlight will not have to re-render the actor in its new position.

Finally, if you are spawning new actors throughout the course of your game (through shoot behaviors, Appear behaviors, effects etc) there are a couple of things you can do to keep things snappy.

First, make sure you limit the lifetime of the spawned actors. Leaving the “disappear on scene leave” behaviors intact helps with this since once the actor reaches the edge of the screen, the actor will be removed from the game keeping the total number of actors low. Second, limit the rate at which new actors are added. For example, if you allow the player to shoot, try limiting the rate of fire by setting a property to 1 on your actor when the player presses the fire button, then clear the property to 0 on a timer. Then simply add a filter to the fire behavior to only allow the player to fire when the property is 0. Alternately, you can limit the # of bullets the player can fire at once by filtering on the # of BulletName property (you may have to copy the value of this property locally to your actor from the scene using an “every frame” timer). Lastly, you can throttle down the rate at which your enemies fire when there are a lot of enemies on the screen through custom code or using a filter on # of EnemyBulletName.

Hopefully these tips will help those of you with games whose performance is bound by the total number of actors. Because naive collision detection’s performance is an O(N^2 ) problem (where N is the number of actors, adding one more actor will cause another N + 1 collision checks to take place), adding actors can quickly cause problems. Using the tips above can really improve performance. If you’re having trouble after following these tips or they aren’t helping, be sure to head to the forums where other users and members of the Popfly team can help.

Tomorrow I’ll follow up with Part 2 where I will provide some tips for creating actors that are easy for Silverlight to draw and also help keep Popfly’s game engine running fast. Stay tuned.

Popfly September Update

Ben Anderson — Wed, 01 Oct 2008 03:09:00 GMT

While I’ve been working on a super secret (ok, just regular secret and probably not exciting to anyone but me) project the last month which you won’t see for a bit, the rest of the Popfly team found time in between actually super (and secret) projects of their own to provide a couple cool updates to Popfly. One is a perennial request. You’ll now be able to track which projects are ripped from which to see whose based projects on yours and what other projects were based on. There’s also a new badge and more info on your news feed. You can read more about the updates here on the team blog or check them out yourself at http://www.popfly.com!

How To: Create Lander

Ben Anderson — Wed, 17 Sep 2008 21:37:46 GMT

At PAX, one part of my presentation/demo on Popfly was creating the game Lander from scratch. It was a hit with the crowd so I decided to do a screencast of an extended version of the demo which creates a full version of Lander (for the presentation I only implemented the up/down motions, not the swivel motions that let you travel horizontally.

So if you weren’t able to attend the presentation at PAX, or just want to check out Popfly and learn how to create a game from one of the developers, check out the video below!

Popfly Game Creator at PAX

Ben Anderson — Wed, 27 Aug 2008 00:07:54 GMT

For those of you in the Seattle area this coming weekend for PAX, be sure to stop by the Microsoft booth if you’re interested in checking out the Popfly Game Creator. I will be giving a demos of the PGC Friday at 5:00, as well as Saturday and Sunday at 11:30 AM. I’ll also hang around at the booth for a while after each talk if you want to stop by and chat.

For a schedule of other MS demos, check out the full listing at Gamerscoreblog: http://gamerscoreblog.com/team/archive/2008/08/22/560668.aspx

New Features Since Launch

Ben Anderson — Tue, 05 Aug 2008 04:59:18 GMT

We’ve been hard at work on new features for the Popfly Game Creator since first launching this May. I took some time to demo new features in the following video:

You can also check out Adam’s blog for more info here and here, find games you haven’t played here (requires sign-in so we know what games you’ve played), and of course, check out Popfly to see things for yourself!

Happy Mother's Day! (Games for Mom)

Ben Anderson — Mon, 12 May 2008 04:56:03 GMT

Look Mom, I made you something:

Happy Mother's Day!

For those of you who are not my mom, the above game is my take on Plato's Allegory of the Cave (my Mom is a Philosophy and Religious Studies professor at the University of Idaho). I made the game using Popfly Game Creator, the product I work on for the Non-Pro Developer Tools team at Microsoft. You can use the tool to make 2D web games without writing any code. If you don't believe me, check out what my very non-programmer girlfriend came up for her mom (who teaches Spanish to elementary age children). A matching game for learning the colors:

And another game to learn the animals:

It's great to be able to do something creative for Mother's Day again. Love you Mom!

(For those of you interested in how these games were made, just click the tweak button and you can see them in Popfly for yourself! Next week I'll post some tips and tricks on the special effects I did in the Allegory of the Cave so that others can incorporate them into their own games).

One week of Popfly Game Creator

Ben Anderson — Sat, 10 May 2008 03:31:00 GMT

It’s now been one week since we first released Popfly Game Creator to the public at Maker Faire and on the web on May 2nd. I thought I’d take today to point out some of the cool games that people have made.

User zbuff001 made this challenging set of minigames:

[removed...]

while Adam made a pseudo-rhythm game “Type Type Revolution:

[removed...]

Raden managed to make “Badly Built Wall” very difficult: http://www.popfly.com/users/Raden/HARD%20GAME

Moo777 had a great game – Bellyjish Adventure with multiple stages: http://www.popfly.com/users/moo777/The%20Bellyjish%20Adventure

Here’s an interesting one a bit along the lines of the old "Scorched Earth" type games that someone came up with at Maker Faire:

[removed...]

One of the great things about building PGC on the Popfly platform is the collaboration it provides. Since the games are Popfly projects, users can share their games with others, which lets everyone learn from and tweak them. It’s cool to see a variety of games coming both that make interesting tweaks on existing games and samples, and those that folks come up with all on their own. It’ll be exciting to see what folks come up with after they’ve had more time with the creator.

I’m sure there are plenty of great games that I missed. If you have something you’d like to share, feel free to link it in the comments!

5/10/08 Update: Bellyjish Adventure is back up, removed the embedded "Badly Built Wall" update since the sounds were annoying :).

5/10/08 Update: Also removed the embedded Bellyjish Adventure since its sounds also were annoying :). Both are linked instead.

9/01/09 Update: Removed embeds now that popfly.com is down, I’ve removed the embedded games. If you downloaded your games before the shutdown, you can still host them on your own.

Rainbow Duckies - Great post on creating games with grandchildren

Ben Anderson — Thu, 08 May 2008 06:18:00 GMT

Michael Leonard is another engineer on the Popfly team and just posted a great entry on the experience he had testing the Popfly Game Creator with his granddaughters. It really is a great example of the interactions you can have when you're not just playing games, but actually making them.

Capping your actor’s speed

Ben Anderson — Thu, 08 May 2008 01:23:32 GMT

If you’ve been playing around with Popfly Game Creator long enough, you’ve probably noticed that if actors get going fast enough, they can sometimes manage to fly right through a wall. There are some things you can do to get around this like making your walls extra thick, or making sure your actors go slow, but I’ll be the first to admit that this can get kind of annoying.

The issue is that with the alpha release of PGC, we only check for collisions once during each frame. If your actor is moving so fast that one frame it’s on the left side of the wall and on the next it’s on the right, we will never know that in between it should have collided. We have to actually catch the actors colliding during a frame in order to realize they collided and then resolve the collision. This was due to both time limitations and the performance limitations of running on the browser’s JavaScript engine (we could probably do it, but given our short timeframe before releasing the Alpha, we chose to go with the “good enough” method you see in the Alpha) since doing continuous collision checking is both harder to code and less performant [yes, I know this is not a word that means fast – but dude, English is a living language] due to all the math.

We’ll probably do something about this down the road sometime after Silverlight 2.0 RTMs, we begin requiring it and can begin using C# (no promises as usual). But in the meantime, I figured I’d post some quick custom code which you can help dealing with this by capping the speed of your actor.

You might think that you can just use the “Max Speed” value in the motion dialog and be done, however there are many cases where this isn’t good enough. While Max Speed does work, it only concerns itself with the current behavior. What Max Speed does under the covers is calculate the amount of acceleration to apply such that the contribution from that behavior will reach terminal velocity at the value you enter. If you have two behaviors, both with a Max Speed of 100, and they both are pushing in the same direction, your max speed will actually be 200. While that example is a little contrived, there are many times, especially in physics based games like Badly Built Wall, that over time, the contribution from various behaviors and collisions will add up to making you go really fast.

How do you overcome this? Why with a custom behavior of course! Adding a custom behavior with the following code should do the trick:

var maxSpeed = 200;
var maxSpeedSquared = maxSpeed * maxSpeed;

var velX = this.GetValue("XVelocity");
var velY = this.GetValue("YVelocity");

var velocity = {X: velX, Y: velY};
var speedSquared = Vector2.MagnitudeSquared(velocity);

if (speedSquared > maxSpeedSquared)
{
    var normalizedVelocity = Vector2.Normalize(velocity);
    this.SetValue("XVelocity", normalizedVelocity.X * maxSpeed);
    this.SetValue("YVelocity", normalizedVelocity.Y * maxSpeed);
}

Add this as a the last behavior to your actor and set its event to Timer->Every Frame. What this code does is check your speed every frame after all your motion behaviors have contributed to it and if it exceeds the value you set for maxSpeed at the top, resets your velocity to point in the same direction as before, but to go only as fast as maxSpeed. You can set maxSpeed to a whatever value you want, and as long as that value is low enough that your actor can’t pass through the thickness of your walls in a single frame, you should avoid any unexpected jumping through walls. [Note: All the *Squared values are used as a programmer’s trick to avoid the square root operation (Math.sqrt) which is fairly costly in terms of processing time.] For even simpler code, check out the following from Badly Built Wall:

var velX = this.GetValue("XVelocity");
var velY = this.GetValue("YVelocity");

if (velX > 201) this.SetValue("XVelocity", 200);
if (velY > 201) this.SetValue("YVelocity", 200);

This code doesn't actually cap the max speed, but rather the velocity in the vertical and horizontal directions. This is subtly different in that it means you could actually end up going 200 in the horizontal and 200 in the vertical directions, which, if we remember our distance formula means we end up going sqrt(200^2 + 200^2) altogether or about 283 pixels / second total. Basically, it means you can go faster in the diagonals than you can just straight up and down or left and right. As you can probably tell it’s quite a bit less complicated (and therefore faster) and even though it’s less general can actually be desirable in games like Badly Built Wall where you are colliding mostly against axis aligned rectangles (their sides are horizontal or vertical rather than at an angle).

Happy creating!