Yet Another Coding Blog : games

Silverlight RPG: Steel Saga

Avi Pilosof — Tue, 24 Mar 2009 07:34:14 GMT

My friend Darren who wrote the hilarious Buddy Knavery game has released a preview of his new project called Steel Saga.

http://www.steelsaga.com

It’s an old-style RPG written in Silverlight, and seems quite deep. At the moment there are only two “zones” (one outdoor and one dungeon), but Darren hates having a life, and is going to spend the coming weeks writing plenty more content.

Check it out; I still can’t believe one guy is doing all this work (programming, art, music).

Avi

Silverlight Game Contest: $5000 prize

Avi Pilosof — Mon, 16 Feb 2009 02:51:34 GMT

The site is a little low on details/rules, but the prize seems pretty sweet:

http://www.serverquestcontest.com

[The Global] War On Terrier

Avi Pilosof — Thu, 17 Jul 2008 04:46:09 GMT

I mentioned in the last series of posts that I'd written a small Silverlight game for an internal competition. Well, I'm finally able to put it online, here it is:

http://silverlight.net/samples/2b2/waronterrier/waronterriertestpage.html

It's very similar to the old Worms games (which I love!), but much simpler. The reason I used puppies? Because my colleague suggested "War On Terrier" as a name, and while "Wombat Combat" was better, it's really tough to draw a cute cartoon wombat.

I think that programmers in general find it difficult to share their code with others because they rarely feel it's good enough, and we're a judgmental lot. I am no exception :) But here's the code anyway:

Download the code

I know it's not great code, so here come the excuses: Zero up front planning went into it; it was written in 2-3 hour bursts over the course of a few weeks; it was my first Silverlight program.

Now that those are out of the way, let me point out what I found difficult in writing this game:

XAML! My god, the amount of time I spent trying to figure out why my polyline didn't fit in the grid and how to scale it to fit and scale many polylines together and why the boundaries of the canvas were so big and why the transform origin was wonky and why things move when they shouldn't and why this won't wrap, and, and... Suffice to say, my XAML-fu is very weak.
The game is turn based, but within a given turn it will also switch to being physics based and also Silverlight animation based. This forced me to write a big state machine for the game which complicated the code alot. Basically, I had to do things like this in many places: "If we're waiting for an animation to complete, then do nothing this frame."
Learning how to use Silverlight user controls as my game objects, and how to structure the project around that. Do I load the XAML at runtime from a resource? Do I create actual user controls for each "image" in the game?
XAML - did I mention that?

That having been said, it was alot of fun getting it to work. Here's what really needs to be added to the game:

Network play. This would be way more fun if playing against other humans.
Allowing the characters to be moved along the screen.
More crazy weapons, different types.
Bonuses, hazards, etc.
Music.
Different scenes.

I hope the code is useful to someone, and that it doesn't lead you too far astray. Feel free to do whatever you want with it; if you have any doubts or questions as to why I did something, post a comment. I'll likely answer: "Because I wasn't thinking straight at the time" :)

Avi

Trivial Physics Simulations (...in Silverlight) - Part 5

Avi Pilosof — Tue, 24 Jun 2008 02:09:00 GMT

The finished product:

I'm having trouble finding a way to embed the SL app inside this page, so let's see if this works (c'mon, skydrive!):

CLICK HERE TO SEE THE APP IN ACTION.

And download the solution from here:

Taking it Further

Particle systems are the basis for lots of very high tech graphics effects such as fire, smoke, water, and explosions. Perhaps that's no longer the state of the art - but it used to be :) Anyway, with extra work, you can simulate the above to some degree of realism.

Aside from that, the physics we've created here aren't just for particles - you can use them in games for any simple physics-based motion (space ships, cars, projectiles). I say "simple" because things start to change if you want realistic physics that take into account the shape of the object and how it reacts to its environment.

Here are some ideas:

Direction: Currently, our particles are drawn as simple circles. Let's say we wanted to upgrade them to space ships. In that case, we'd get a terrible effect where the spaceship changes direction without actually rotating - nowhere in our code do we rotate the visual based on the direction (which is a function of its velocity). This could be fixed by adding a RenderTransform at the FireworksRenderingHelper level.

If you do that, you'll be 80% of the way there, but you'll notice that as the direction of the ship changes, the rotation can "flip" suddenly, which is unnatural. The reason for this is because the code we've written simulates a body being acted upon by simple outside forces; but a spaceship actually introduces its own forces (thrust). See more below...

Forces: We haven't talked about the concept of "force", but it's at the heart of real physics. We've hard-coded the acceleration to simulate gravity; but in reality, gravity applies a force, which causes acceleration. If you wanted to simulate a spaceship, you'd be better off altering the acceleration based on the force created by its thrusters, rather than having a fixed acceleration.

Introducing forces to the animation can make the realism really jump to the next level, because you start "feeling" inertia. But keep in mind that there's no force without mass, so bust out this equation:

F = ma

Or for our purposes:

a = F/m

Where "a" is the acceleration, "F" is the force being applied, and "m" is the mass of the object being pushed. The heavier the object, the slower the acceleration.

Obviously, this would add to the inner loop for the particle - but the basics are the same: modify the acceleration based on the force, the velocity based on the acceleration, and the position based on the velocity.

Friction: The current simulation has no mention of friction. The most obvious one is air resistance, but depending on what you're simulating, there could be others. I won't go into detail here because friction can be complex depending on the scenario; but it's essentially another force acting on the object. It can be a matter of reducing the acceleration, it could be tied to velocity, it could be tied to mass, materials, etc.

Angular Momentum: Getting fancier, you might want to give particles an angular velocity (or acceleration) - rotation. Let's say you smack a cube on the corner; it's going to both move and rotate. If your particles are being rendered as anything but tiny dots, it makes sense to add a component for that. In 2D, it would probably be of type double, units "degrees per second", or something like that.

Visuals: This is where you can really go nuts. In my youth (on my beloved Amiga, RIP) I wrote a program which rendered animations of explosions, smoke and lightning. All used a particle system like this, but altered the way that individual particles were rendered. All used a particle whose transparency fell off near the edges - you can probably do this in SL with a RadialGradientBrush - and whose colour changed over age. For example, an explosion particle went from bright orange to gray (as it turned into smoke). It actually turned out very beautiful and quite realistic (well, the 2nd version, anyway).

As you can see, there's lots of room for improvement and creativity. If you want to get into a more detailed physics simulation, I recommend this book:

http://www.amazon.com/Physics-Game-Developers-David-Bourg/dp/0596000065

Once you get into collisions between oddly shaped bodies and working out how they come to rest; that's when things start getting really complex.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 4

Avi Pilosof — Tue, 24 Jun 2008 01:52:33 GMT

Tying it all together has zip to do with the physics simulation, but there are a couple of interesting bits which I'll paste into here. The rest you can grab from the solution that I'll post up; feel free to ask questions.

The Game Loop

The heart of the app is a method call which renders one frame only. The trick is calling that method for each frame, and having that method do a very simple fixed set of operations that updates the particles for that frame only.

For the "call-each-frame" part, I use a very nice method stolen from Bill Reiss:

http://silverlightrocks.com/community/blogs/silverlight_games_101/archive/2008/03/28/the-start-of-a-game-helper-class-library.aspx

Each frame, that loop calls my method:

   1: void _GameLoop_Update(TimeSpan elapsed)

   2: {

   3:     AddNewParticles();

   4:     UpdatePhysics(elapsed);

   5:     _Renderer.Render();

   6:     RemoveDeadParticles();

   7: }

This method does the following:

Checks to see if we've got as many particles as the user wants us to have, and if not, adds a few more. I only add a small [random] number each frame, to avoid creating large spurts.
Updates the physics for all particles by calling each particle's RunFrame method. Because this uses the elapsed time since the last frame, the particles maintain a correct speed on-screen, even if the frame rate drops/increases.
Renders the particles to the canvas. More on that soon.
Removes any particles that have died, to prevent the particle list from growing indefinitely.

Generating Particles

The AddNewParticles method is where you need some creativity, and is the method you would alter if you wanted to change the nature of the fireworks (say, to create an explosion effect instead of a fountain). This method relies on simple heuristics to generate initial velocities. Here's the relevant bit:

   1: // Generate some random starting conditions for this particle

   2: Vector2D vel = Vector2D.FromSpeedAndAngle(200 + this.MaxSpeed,

   3:     ((180 - this.SpreadAngle) / 2) + rnd.Next(this.SpreadAngle));

   4: double milliseconds = 200 + rnd.Next(3000);

   5: double radius = 2 + rnd.Next(10);

   6: Color color = FireworksColours[ rnd.Next(FireworksColours.Length) ];

It's really all in lines 2 & 3: The initial velocity of the particle. We use the user's UI selections as limiters to random values. The more randomness, the more "natural" things look.

Rendering Particles

In making some effort to separate the logic of the physics from the UI rendering part, I created a FireworksRenderingHelper class that is given a list of FireworksParticle and a Canvas, and knows how to render one to the other.

Pre-Silverlight, I'd reset each frame, clear the background, render all particles, and show the frame. But with Silverlight, it already has internal methods for drawing objects to the screen, buffering, etc. So what I do is add my shapes as the Canvas's children and let it draw.

The catch is that I don't want to remove/add all the children each frame - it seems wasteful. This is why I added the Custom field within FireworksParticle - I use it to track a reference to the child of the canvas. At render time, if the field is null, I create a new Ellipse as a child and add it to the canvas. If it's not null, then I retrieve it and modify its position. Here are the loop internals ("p" is the current particle):

   1: UIElement canvasChild;

   2: if (p.Custom != null)

   3: {

   4:     canvasChild = (UIElement)p.Custom;

   5: }

   6: else

   7: {

   8:     canvasChild = new Ellipse()

   9:     {

  10:         Width = p.Radius,

  11:         Height = p.Radius,

  12:         Fill = new SolidColorBrush(p.GlowColor)

  13:     };

  14:     p.Custom = canvasChild;

  15:     _Canvas.Children.Add(canvasChild);

  16: }

17:

  18: canvasChild.Opacity = 1-p.Opacity;

  19: canvasChild.SetValue(Canvas.LeftProperty, p.Position.X);

  20: canvasChild.SetValue(Canvas.TopProperty, p.Position.Y);

Removing Dead Particles

The one non-trivial thing about this is that you can't use a simple foreach loop and remove any particles where Alive==false. Doing so would be modifying the collection while enumerating it, and you'd get slapped by the runtime. Normally, you'd get around this by separating things into two steps (get the list of dead particles, then remove them individually).

It seems that LINQ allows you to do this in one line, and I think it's due to the ToList() in there:

   1: private void RemoveDeadParticles()

   2: {

   3:     _Particles.Where(p => !p.Alive).ToList().ForEach(p => _Particles.Remove(p));

   4: }

In the final installment, I'll post the zipped up solution (and if I can work out how, the actual Silverlight app), and I'll explain how you can take this further.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 3

Avi Pilosof — Mon, 23 Jun 2008 23:55:38 GMT

So now that we have vectors, we need to do something with them. We're going to use the concept of a Particle. This is supposed to represent a tiny object in our world that is affected by physics. For this reason, it has a position, velocity, acceleration, etc.

For starters, let's define the basic particle:

   1: public abstract class Particle

   2: {

   3:     protected TimeSpan _Age;  // How old is the particle right now?

4:

   5:     public Vector2D Position { get; set; }

   6:     public Vector2D Velocity { get; set; }

   7:     public Vector2D Acceleration { get; set; }

   8:     public TimeSpan MaxAge { get; set; }

   9:     public bool Alive { get { return (_Age < MaxAge); } }

  10:     public double Radius { get; set; }

11:

  12:     public Particle(Vector2D pos, Vector2D vel, Vector2D acc, TimeSpan maxage, double radius)

  13:     {

  14:         Position = pos;

  15:         Velocity = vel;

  16:         Acceleration = acc;

  17:         MaxAge = maxage;

  18:         Radius = radius;

  19:         _Age = TimeSpan.FromMilliseconds(0);

  20:     }

21:

  22:     /// <summary>

  23:     /// Iterate one frame of animation for this particle.

  24:     /// </summary>

  25:     /// <param name="timeSinceLastFrame">How much time has passed since the last frame?</param>

  26:     public void RunFrame( TimeSpan timeSinceLastFrame )

  27:     {

  28:         double secondsPassed = (timeSinceLastFrame.TotalMilliseconds / 1000.0);

  29:         Velocity += Acceleration * secondsPassed;

  30:         Position += Velocity * secondsPassed;

  31:         _Age += timeSinceLastFrame;

  32:     }

  33: }

A few things to note:

It's an abstract class. Depending on your use of it, it doesn't have to be. This is actually a ready-to-go particle; it just doesn't have anything in terms of visuals attached to it.
Note the concept of "Age" in there (lines 3, 8 and 9). A particle lives for a while, then dies. It doesn't have to - but for most particle based simulations, you do want that.
The "Radius" property is supposed to indicate the size of the particle. It could be argued that this belongs in a subclass.

The only real point of interest is the RunFrame method on line 26. This is the key to the whole physics simulation. Remember I said that it's down to two lines of code? Those are 29 & 30 - the rest is fluff. We call this method every frame, telling it how long since the last call, and it will move the given particle in the right direction by the right amount.

So now that we have this abstract particle, let's use it to make something a little more specific to our fireworks demo:

   1: public class FireworksParticle : Particle

   2: {

   3:     public object Custom { get; set; }

   4:     public Color GlowColor { get; set; }

5:

   6:     public FireworksParticle(Vector2D pos, Vector2D vel, Vector2D acc, TimeSpan maxage, double radius, Color color)

   7:         : base(pos, vel, acc, maxage, radius)

   8:     {

   9:         GlowColor = color;

  10:     }

11:

  12:     /// <summary>

  13:     /// Fade the opacity of a particle as it gets older

  14:     /// </summary>

  15:     public double Opacity

  16:     {

  17:         get

  18:         {

  19:             double pctOfLifetime = ((double)_Age.TotalMilliseconds) / ((double)MaxAge.TotalMilliseconds);

20:

  21:             if (pctOfLifetime > 1)  pctOfLifetime = 1;

  22:             if (pctOfLifetime < 0)  pctOfLifetime = 0;

23:

  24:             return pctOfLifetime;

  25:         }

  26:     }

  27: }

You'll see we're only adding two things, both tangential to the core of this topic, but we need a little bling: The particle's color and opacity - the latter being a function of its age; it dims as it grows older.

Oh, and the Custom property. I'll get to that later; it's totally an implementation detail and not necessarily a pretty one.

So, what are we missing at this point?

We need a page to put all this on, with some UI controls for playing with variables.
We need some way of rendering the particles to the page (there's no drawing code above - I prefer not to put it in these classes).
We need to actually create particles with positions and velocities that will suggest some kind of fireworks.
We need code to tie it all together; the rendering, the UI, the particle generation.

Here's a screenshot of what the end result will look like:

(Yeah, no beauty contest winner - but it's effective :))

Next up: Putting it all together.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 2

Avi Pilosof — Mon, 23 Jun 2008 04:26:20 GMT

If you know how vectors work, this isn't going to be interesting. If you've never seen one before, I'll try to keep it simple. Keep in mind that throughout this post I'm talking in 2 dimensions. The same stuff applies for 3D work; you'd just add another variable (the Z component) to the vectors.

A 2D vector stores two numbers which can be used to describe the position of an object (X, Y), or the velocity (X = the speed along the X axis, Y = the speed along the Y axis).

So take for example an object that's traveling at a speed of 10 pixels per second directly northeast:

The red line (marked "v") is the actual velocity (10 pixels per second), while the dotted blue lines indicate the speed along the x-axis (vx) and the y-axis (vy). Essentially, we've "decomposed" the one diagonal line into one horizontal and one vertical. For now, we're going to leave the details at that.

At the very least, here's what a Vector2D needs to know how to do:

Store the X/Y components
Add two Vectors to each other (eg; add acceleration to velocity)

So here's the code:

   1: public class Vector2D

   2: {

   3:     public double X { get; set; }

   4:     public double Y { get; set; }

5:

   6:     public Vector2D(double x, double y)

   7:     {

   8:         X = x;

   9:         Y = y;

  10:     }

11:

  12:     /// <summary>

  13:     /// Add two vectors and return the resultant vector

  14:     /// </summary>

  15:     public static Vector2D operator +(Vector2D v1, Vector2D v2)

  16:     {

  17:         return new Vector2D(v1.X + v2.X, v1.Y + v2.Y);

  18:     }

19:

  20: }

At this point, we can do stuff like this:

   1: Vector2D acceleration = new Vector2D(0, 10);

   2: Vector2D velocity = new Vector2D(50, -50);

   3: velocity += acceleration;

That's probably sufficient to write the engine, but there are a few other features we'll want which will make the eventual code cleaner. Specifically:

Scale the vector by a fixed amount.
Generate a vector given an angle and a speed.

Why do we want that second one? Well, let's say you want to write code to generate the vector in the hand-drawn scribble above. What values do you give for vx and vy in order to generate the speed of 10 pixels per second in the northeast direction? You'd actually need to calculate them using some trigonometry, and that's some ugly code to have to read at a high level; so we bury it in the Vector class.

Eventually, we want to be able to do this:

   1: // Init from a speed (10 pixels per second) and an angle (45 degrees)

   2: Vector2D velocity = Vector2D.FromSpeedAndAngle( 10, 45 );

And here are the methods we want to add to the above class:

   1: /// <summary>

   2: /// Scale the vector by the given amount (ie; multiply by a scalar)

   3: /// </summary>

   4: public static Vector2D operator *(Vector2D v1, double scale)

   5: {

   6:     return new Vector2D(v1.X * scale, v1.Y * scale);

   7: }

8:

   9: /// <summary>

  10: /// Convert the given angle (in degrees) to a vector with origin

  11: /// (0,0) and length == speed, breaking down into the X/Y components.

  12: /// </summary>

  13: public static Vector2D FromSpeedAndAngle(double speed, double degrees)

  14: {

  15:     double radians = Vector2D.DegreesToRadians(degrees);

  16:     return new Vector2D(Math.Cos(radians), -Math.Sin(radians)) * speed;

  17: }

18:

  19: protected static double DegreesToRadians(double angle)

  20: {

  21:     return angle * (Math.PI / 180);

  22: }

For now, we're done with the Vector2D class. As I promised, it's quite trivial. We might add a couple of helpers here and there if we need them, but they will be obvious.

The key thing to remember about Vector2D is that it inherently stores both the magnitude and direction of the motion. So not only will it tell us the direction something is going in, but how fast it's doing it. This allows us to use it interchangeably for velocity/acceleration/position, and have everything "Just Work".

Next up: The Particle class.

Avi

Trivial Physics Simulations (...in Silverlight) - Part 1

Avi Pilosof — Mon, 23 Jun 2008 03:34:39 GMT

Table of Contents:

Introduction

I recently wrote a small Silverlight game for an internal competition and a friend asked me how I did the projectile trajectories. Turns out that something which looks cool in practice is one of the simplest algorithms of all time (two lines of code!), and which I guarantee you learned in highschool science class; although they didn't call it an "algorithm", they called it a "formula". The cool thing is that it can be used to generate fairly complex visuals, by adding just a little extra spice.

I'm going to write up a short series demonstrating how to simulate fireworks in Silverlight using a very basic physics engine. At the end, we should have a nice interactive simulation to play with.

To start off, let me get back to the basic physics equation which underlies this whole thing:

v = u + at

To paraphrase this: "The velocity (v) a after some time (t) will equal the initial velocity (u), plus the acceleration (a) multiplied by the time (t)." Alternatively, to really get to the heart of the matter:

"Acceleration makes things go faster [or slower!] over time."

Now let's look at the units of measurement:

Time: seconds
Acceleration: pixels per second per second
Velocity: pixels per second
Distance: pixels

I think Newton may have been using the outmoded "meters" rather than pixels when he came up with this stuff; but it won't matter as long as the unit is consistent throughout.

Now, when you think about those units of measurement above, you notice that acceleration is just a measure of how velocity changes, and velocity is just a measure of how distance changes. So the whole physics simulation, at its core, is this set of two lines:

   1: while ( true )

   2: {

   3:     position += velocity;

   4:     velocity += acceleration;

   5: }

In other words:

"Every frame, the position of the object changes based on its velocity, and the velocity changes based on the acceleration."

Run the contents of that loop for each frame, and you have yourself a simple physics simulation.

One big thing that seems to be missing above is the direction of motion. It actually isn't missing - It's hidden in the type of those variables:

   1: Vector2D acceleration = new Vector2D( 0, 10 );

   2: Vector2D velocity = new Vector2D( 50, -50 );

   3: Vector2D position = new Vector2D( 0, 0 );

What's a Vector2D? It's a custom class that stores both a X component [of motion] and a Y component, and knows how to add/subtract them. Turns out that the WPF Vector class was taken out of Silverlight, so we need to write our own. Also turns out that this is trivial.

With this simple algorithm, by merely changing the initial velocity, you can simulate lots of simple phenomena:

A ballistic trajectory, by giving a high initial velocity in the direction the gun is pointed.
An explosion, by creating lots of fragments that have large initial velocities radiating in a rough circle from an origin.
A fountain, by continuously creating particles that radiate roughly upwards from a single point.

Stay tuned... Next up; the Vector2D class.

Avi

Buddy Knavery - The Killer Riffs

Avi Pilosof — Fri, 13 Jun 2008 00:21:03 GMT

Some Silverlight goodness. My friend Darren wrote this amazing game that has strong ties to those 90's adventure games that I miss; Kings|Space|Police Quest, Leisure Suit Larry, etc. Writing a game engine is one thing, but doing all the artwork & scripting while holding down a full time job (at MS, no less) is quite impressive.

Check it out:

http://www.buddyknavery.com/