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 Silverlight.net that supposedly lets me in on the latest news, etc. about Silverlight.  A couple of days ago, this gem popped up: “lynda.com 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.

Inertia

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.

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 Silverlight.net site mostly.
- This build was made with Silverlight 2 Beta 2.

Some steps forward

Last night I decided that my Silverlight game wasn’t heading in the direction it should, so I went back to a previous iteration with some insights from my recent effort. I’ve had a problem getting the vision of the game solid in my head.

At first I had built a top-down, ship-centric shooter but I decided to try a map-driven, simpler game where you click on planets and then do your trading. I had the map part working nicely, but man it would have been a pretty dull game.

So mow I’m going for a model that’s much closer to Escape Velocity…top-down, player-in-the-center pew-pew game with a galactic map, commerce and weapon/ship upgrades. Last night I was able to (with the assistance of my older boy, Max) get a starfield moving under the ship, and move the ship around using velocity, etc. I still need to do the physics for thrust/velocity/turning, but for a guy that’s used to doing event-driven programming all the time, seeing this real-time action is pretty exciting.

One of the aspects of the game that I’m apprehensive about is building the AI for non-player ships (NPS? hehe). They’ll need to turn, thrust, fire weapons, target the player, etc. etc. Sometimes I think I’m getting a little too ambitious, but that’s what I need to do so I don’t get bored.

Where I am Now:

• The game universe is 30000×30000 pixels. I generate a background starfield using about 7,000 randomly-placed white circles.
• player ship in the center; a target reticle is moved by the mouse, which causes the ship to rotate to point at it.
• ship fires lasers when the left mouse button is clicked. no sound yet.
• ship increases velocity when the W key is pressed. the starfield moves in relation to the ships velocity/direction.
• Map currently represents one solar system. You can click on a planet and your ship ( a totally different ship ) appears there.

Next steps:

• Create the background more efficiently. The stars take too long to generate, IMHO, and maybe take up too much memory. I’m thinking a tiled bitmap would be better. Requires investigation.
• Get the thrust/maneuvering to be fluid. Add some graphics for thrust, sound too.
• Create a new data hierarchy to have star systems with planets/moons/stations. Each system should have a security rating, description, etc.
• Refactor the map to show star systems and enable jumping between those systems.

Silverlight/VS 2008 quirks driving you crazy?

One of the things I’ve noticed about editing XAML files in Visual Studio 2008 is that sometimes you’ll need to close the file you’re working on then re-open it in order to see certain changes take effect, in particular when you change the ImageSource attribute on an element.  That took me a while to figure out.  There are few things more frustrating than stumbling on a bug in the IDE when you’re trying to learn an entirely new way of building apps.

Another interesting thing is that you apparently need to specifically tell elements to be a certain height/width.  For instance, if you have an element inside another rectangle, don’t expect it to inherit the size of its parent…it won’t fill that space unless you tell it to!

Howdy, howdy, howdy.

Finally, a place where I can claim First Post.

I’m currently working on a Silverlight game based on the classic “Solar Wars” space commerce/cargo game (which is itself based on Dope Wars, et al). Another inspiration for this game is Ambrosia’s Escape Velocity. I spent countless hours being a galactic menace in that game. Other games in this genre are Elite, Privateer and Freelancer. I plan on eventually having a networked, persistent universe…but that’s far in the future. My dream is a low-rez, casual version of EVE Online.

My project is a top-view game with two main modes: a map of the solar system or galaxy, and a commerce mode where the player can buy/sell commodities. The player tries to buy low, sell high, and transport special cargo in order to make money to upgrade his/her ship in order to make more money, etc. ad infinitum.

The first iteration of the game will be strictly event-driven. Click on a planet/space station to travel, and then do your commerce, maybe buy some upgrades or take a mission, then it’s back to the map. The player will start with a small, unarmed shuttle capable of carrying a small amount of cargo.

I have no idea what to name the thing yet. I’m sure my 6 and 8 year old boys will come up with something catchy.

So far I’m enjoying Silverlight and XAML.  It’s like working with any other taggy paradigm (html asp.net, xslt, etc.) so I’m comfortable with the angle brackets and attributes.  Man, it’s verbose though.  And a bit odd.  The first thing that really showed me how different XAML is from HTML is the way tables (grids) are built…the grid is fully defined before any content is added.  Then when you add the content you tell it which row/column to pop into.  Pretty nifty.

I can’t wait to get into doing some styles in XAML.  I can tell it’ll be handy as hell (much like CSS), but I can’t quite wrap my head around it yet.  I’ve only had a few hours’ experience so I’m a bit clumsy when it comes to remembering all the setter property thingies and whatnot.  Fortunately I found a tool called Kaxaml which should help quite a bit.  If you’re new to XAML or just want another wicked-handy tool, I highly recommend it.  It’s free (as in beer).  May the gods bless Robby Ingebretsen.