Posts Tagged ‘Silverlight’

A Change in Direction

I’m really damned bored with the game as it is right now.  I’m not going to finish it just to finish it.  In its current state, it would be an exercise in programming tedium.  It’s time to bring in the creative big guns: my kids.

I was thinking about making it the same sort of game, but more action-focused, and with the boys (9 and 7 year-olds) doing the art work.  Max came up with a great name – “Space Drawn”.  We might put it on a notebook paper background (but that’s been done before…we’ll see).

I also want to come up with some unique angles on the game play.  The mechanics of the thing needs to be new and different.


Stop with the Silverlight 1.0, already!

I have an RSS feed from that supposedly lets me in on the latest news, etc. about Silverlight.  A couple of days ago, this gem popped up: “ Silverlight 1.0 Essential Training”.  (Am I going to link to it?  No.)

Why?  Oh, why do we have Silverlight 1.0 tutorials making the news?  Why are people posting new ones?  Why are people posting old 1.0 tutorials they’ve just found?  Silverlight 1.0 wasn’t even a commercially viable product!  Silverlight 1.0 skills will never be sought after!  Well, barring self-fulfilling prophecy, anyway.  I mean, if the net keeps getting cluttered with 1.0 crap, guess what everybody’s going to know?

I think in the interest of getting Silverlight (1.0, or 2.0 beta 2, or 3.7 rc2, or what the hell ever) off the ground, Microsoft should PURGE its websites of SL 1.0 material.  I realize that some of it is pertainent, namely the XAML stuff…but the rest of it is going to do nothing but confuse the hell out of people just getting into it.  It’s not to late to nip the 1.0 in the bud before it pollutes everything.

I realize that there have been oodles of tutorials, videos, blah blah made about Silverlight 1.0.  I’m sorry, but it needs to go.  Much like we let go of phrenology as barking up the wrong tree, so must we do away with SL 1.0.

Now if you’ll excuse me, I need to figure out why my SL 2b2 project has people thinking is SL 2b1…

Locations and Radar

I added the locations (planets, moons, space stations, etc.) to the screen, and I’m about half done with the radar.  The max velocity has been cut from 20 to 10 px per frame.  It’s a bit easier to control.

I’m freekin’ thrilled about the radar.  I’ve been thinking about how that’s done in video games forever.  What I’m doing is scaling down the game world by a factor of 75…and that’s adjustable, of course.  I’ll have zoom in/out buttons on there pretty soon.  I stayed up a bit late to get the radar working, and it paid off.  It was the fulfillment of a lifelong dream when I pointed the ship toward a distant planet on the radar and saw it come into view on the main screen.

I need to learn how to use clipping in Silverlight to hide the radar blips that are outside the intended visible area.  I could turn them off manually, but that’s one more if statement to slow things down.  The way I’m doing the radar probably isn’t the most efficient anyway, but I’ll refactor it later.

The locations are stored in an XML file that has their coordinates, name of the corresponding image, and a brief description.  The same file contains the commodities I’ll use later in the game.

The consensus with amongst my work buds is that the steer-by-mouse needs to go, in favor of key controls.  I’m inclined to agree.

Latest version (a3) here.

Next steps:
– come up with a name
– make some graphics
– get the radar clipping done
– add some enemies to dispatch

Inertia fixed

Check out the latest version here.

After much thought and messing around, I realized that I needed to control the total velocity of the ship instead of trying to control the X and Y amounts separately.  So now I’m checking the velocity using Pythagoras’ handy theorem (a squared x b squared = c squared) and then scaling back the vector when it goes over the limit.

i still have some polishing to do, but here’s the code real quick…

double thrust = .27;

double velX = _playerVel.X;
double velY = _playerVel.Y;

double newX;
double newY;

double curRot = GetRotation();
pnl0.Text = “rot: ” + curRot;

Utils.CalculateMovement((int)curRot, thrust, out newX, out newY);

velX += newX;
velY += newY;

_playerVel = new Vector2D(velX, velY);

double veloc = Math.Sqrt(Math.Pow(_playerVel.X, 2) + Math.Pow(_playerVel.Y, 2));
pnl3.Text = “vel: ” + veloc;

double testVel = 20;

if (veloc > testVel)
double scale = testVel / veloc;
_playerVel.X = _playerVel.X * scale;
_playerVel.Y = _playerVel.Y * scale;

Now, fly around the galaxy yelling “Git some!  Git some!”  I’ll have something for you to shoot at pretty soon.


More futzing with the “drift” on my game.  I believe the correct term is “inertia”.  I really need to read that “pysics for game developers” book.

i simply took the ship’s current rotation and generated a vector from it based on an arbitrary thrust value, then added that to the ship’s current velocity vector.

like so:

CalculateMovement((int)curRot, .3, out newX, out newY); // this function ripped off from Silverlight Rocks

velocityX += newX;
velocityY += newY;

_playerVel = new Vector2D(velocityX, velocityY);     // i then use this vector to move my background layers, as well as the player’s position in the game universe.

And I have a check in there to make sure the ship doesn’t go too fast in any direction.   Before I had the check in there, the thing could go to warp speed in a few seconds.  It was a good test of my starfield generating algorithm, anyway.

So now I’m slipping and sliding all over the place.  It looks really good.   I’ve found a bug with my min/max check that I knew would happen, though.  More thinking and tweaking before I upload a new version.

Solving the velocity problem

Last night I fiddled with my game’s physics a bit and I came close to a method of providing “drift” to the player’s ship when you change direction and add thrust.  The previous version instantly changed direction but maintained the same speed – not realistic, not elegant, and highly dangerous.  (Instant 180 degree turns would probably turn your crew and cargo into a nice thick paste coating the rear wall of your ship.)

Here’s the solution I came up with after playing Three Card Monty with the variables (I am not a math person by any means)…

currentHeading – ((directionShipIsPointing – currentHeading) * arbitraryThrustValue) = newHeading

This works great for the most part…but a problem arises when you turn the ship from, say, 5 degrees to 350 degrees…my algorithm interprets that as a change of 355 degrees, and thus the ship bounces backward for a second before coming to its correct course.  I won’t bother posting the actual code here since it’s WRONG!

Oy!  What to do?  Fortunately, Avi Pilosof just posted a thorough, illustrated and wonderful set of blog entries about this very thing.  I cought it via Silverlight Cream.  So I’m going through that and I’ll rework my physics using vectors instead of basing everything on rotations.  This will help me out with Second Life programming, too, I’m sure.

Moving backgrounds

I was using a pretty lame technique to move the background starfield under the player’s ship and the more I struggled with it, the more I saw its flaws.  I had 4 panels, each was the same size as the game screen and a pretty nice starfield pattern.  I would move the panels according to the ship’s velocity and direction.  When one panel went offscreen, I would move it to the opposite side so it could be re-used.

My primary flaw in logic was that I had a cyclic error when testing to see if the panels’ x,y coordinates were less/greater/equal to the boundaries of the game.  I’d detect that panel 1 was off-screen, then place it in a position where it would then get picked up by another off-screen check and guess what?  You’d never see that panel again.  The equal-to part of the check was the main problem.

Anyway, I decided to use two overlapping randomly-generated starfields instead.  My offscreen checks are now nice and tight, and I can get funky with what happens in those checks (like change the star’s color or whatever).  The double-starfield looks sweet, too.  The top layer has 3-pixel stars and the bottom has 1-pixel stars.  The bottom layer moves a bit slower.  The effect pleases me.  I am pleased.  Yes.

Your first taste of Splodge Pre-Alpha .0001

The ship is ripped off from Lost Garden’s free game graphics collection.  I highly recommend Lost Garden for anybody noodling about in the indy game cosmos.  I’m probably going to use some of my kids’ art as soon as I get it digitized, or they’ll make some for me on their ‘puters.

Anywhooo, this is your first chance to test out Splodge Pre-Alpha v0.00001!  Some notes before you check it out:

– Click yer left mouse button to fire, use your mouse to aim/steer.
– Press W to accelerate, S to decelerate.  I don’t have fancy physics worked out so that your velocity/direction is dampened correctly when you turn and burn.
– I don’t have thrust sound or graphics yet.
– The laser shot sounds get clipped occasionally.  Still working on that.
– The stars are really cool.  Just keep that in mind.
– Be careful using Silverlight in Firefox (especially FF3, apparently).  I’ve seen it crash several times, and not on my stuff, but on the official site mostly.
– This build was made with Silverlight 2 Beta 2.