The Right Moves : PGC

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 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!

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

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!

Mailbag: Even Easier Music

Ben Anderson — Wed, 07 May 2008 23:36:09 GMT

Reader Michael Sterling pointed out today (or rather late last night) a neat tool that lets you create music even more easily than with Finale:

For people who want even easier music creation so are willing to give up some of the nuance that Finale offers, they could try JamStudio.com. It's kind of like GarageBand for the mac (I'm sure there's a non-apple analogy), but even a bit simpler. You just choose the instruments you want to use and then assign chords to each measure. They want you to sign up, and there's a little tutorial video that plays when you first start, but you can skip it and don't have to sign up (although you might need to if you want to export the music, I'm not sure)."

I took a look and it indeed looks pretty cool. You can sign up for free, but to export an mp3 of your work requires a $10/month subscription. Might be worth it if you create a bunch of songs, sign up for a month, then export everything at once for your game. After playing with it a bit, it sounds like it’s using samples instead of midi for at least some of the instruments (which sounds a lot better although you lose the retro vibe) and is indeed super easy to use, even if you know little or nothing about music.

Creating Music for Popfly Game Creator

Ben Anderson — Wed, 07 May 2008 01:19:00 GMT

Sound and music is probably one of the most overlooked areas of new hobbyist game developers. Just adding a cheesy soundtrack and cute hopping and squishing noises subtly changes a boring, simple game into one that feels professional and complete. The funny thing is that usually this process is completely subliminal with most people not realizing the difference sound makes. Even great games can be vastly improved through the use of audio as anyone who has completed Portal can tell you.

PGC allows you to upload your own music and sounds as .WMA or .MP3 files to use in your games. You can find a “How To” explaining the process of uploading and playing back audio on the Popfly wiki here. There are many programs which allow you to record audio on your computer from very basic programs (Windows Sound Recorder) to very advanced interface/software packages such as Pro Tools. However, this all assumes you are in possession of musical instruments, recording equipment and are musically capable or willing to invest the time to become so. That’s a lot of commitment for most folks.

While I can’t help you with the becoming musically capable part, I recently dug up a free program called Finale Notepad which I had played around with during my freshman year of college. The full version of Finale is a professional tool for creating music scores on the computer. At least back when I first used it, it was pretty much the standard for creating music notation. The Notepad version probably isn’t full featured enough for that crowd, but it’s great for composing simple songs which can then be exported as MIDI. MIDI is an electronic format which isn’t an actual recording, but rather the instructions to synthesize a piece (what notes to play, what synth instruments to use and when to play them). As such, it’s a great tool for making retro game music, because that’s exactly the kind of music that was used back in the 8 and 16-bit days of Super Nintendo and Genesis. I usually just play around on the staff in the key of C to get what I want, but I believe you can also hook up a keyboard to record the notes. Even if you aren’t musically inclined, you can probably put together some basic tracks by trial and error. Once you’re happy with your piece, just click File->Save As… and change the file type to MIDI.

Since PGC requires files to be of type .WMA or .MP3, you’ll now have to convert the MIDI file. The easiest way I’ve found to do this is to change your recording device to “What You Hear” in the sound settings in control panel. If this option isn’t available (I think some drivers don’t support this option) like on my work machine, an easy workaround is to plug a cable into your headphone jack and back again into the microphone jack on your computer. You may have to play around with the volume settings to get it just right. Once you’ve done this, you can easily use Windows Media Player to playback the MIDI and Windows Sound Recorder to record a WMA file (Vista) or a WAV file (XP) which you can then convert to a WMA or MP3 using a tool like CDex. There might be an easier way to do this – if so, let us know in the comments.