Blog | Games | About | Contact | Links

Mon, Jun 29th 2009, 12:24
Shore Leave  

A bit more art is now in place and some general tinkering this week. I spent a good four hours just tweaking the player's shield flicker. It relays the shields' state much more clearly now. Having a HUD free combat experience has presented some interesting challenges; there are still a few rough spots (most notably: shield regeneration), but the presentation is clean. With so much stuff going on at once, having a bunch of meters and values cluttering up the screen space would just make it that much harder to play.

I'm figuring on the next wave of testing being two weeks from now. This should be confirmed next week provided nothing blows up in my face between now and then.

808 comments

Sun, Jun 21st 2009, 10:55
Art Grind  

As the final battle art is rolling it, I started putting in the time to more carefully place the ship "muzzles" and came to an unfortunate realization: the player can adjust his bullet size, but the size of his ship's cannon is static.

So I adopted an approach that moves the muzzle based on the the size of the bullet. This fixed the "giant bullet of doom overlapping the hull" problem, but, depending on the muzzle size, starts looking funny when the bullet gets too big or too small. So it got scrapped.

Instead, bullets now fire at a muzzle-appropriate size and then then quickly expand once they're in the playfield. This keeps the action looking smooth at the player's ship without compromising the variable size. In some cases, it can look a little unusual, but it's rare and a sane player would probably never build his ship that way. Short of making a whole bunch of different gun art (or software scaling it, which would be worse, really), I think this is as good as it can be with the way the game works.

338 comments

Sun, Jun 14th 2009, 13:11
Vista's Siren Song  

It's no secret that Spacegame does not get along with Windows Vista right now. I have been told that the latest (repository) build of VERGE will make this all go away, so I'll just drop in the new.. Oh wait! It's not that simple.

I wish it was. The reality is that I've been running on a semi-unofficial, long-deprecated engine build. So, since I've started, the lua binding has been changed a bit and, worse yet, the class system has been replaced with one that is not fully compatible with some of my slapdash code. This is all actually quite good for the engine. It is, however, bad for me. To get my game up to snuff would require a fair amount of clean-up and rewriting. This of course puts me at the awkward spot of choosing either no Vista support, or pouring even more time into this game.

I can't really afford to not upgrade the engine, so it's not much of a choice at all. After this is done I'll have Vista support, cleaner code, and support for new engine features as they come. I do slightly regret diving headfirst into the lua side before it was cemented, but ultimately it was fun and this is only a minor setback.

385 comments

Sat, Jun 6th 2009, 19:56
Nomenclature Madness  

Well, I finally sat down and worked through the only real remaining hurdle: reworking the defensive attributes. Each "ship" had three different adjustable attributes (the names of which where never really finalized, but were: "offense", "defense", "quantity").

Each of these attributes then influenced one or more specific qualities of the unit, with many even overlapping to create "compound" properties.

e.g. The Streamer's movement rate was affected by both its Offense and Defense. By moving faster:

* It is harder for the player to spot it and get out of the way in time.(Offense)
* It is more likely to make it off the screen without being shot and destroyed, yielding a "successful" deployment. (Defense) It's worth mentioning, for those that haven't already played (and quite probably most that have), that this ship doesn't maximize its damage potential until after it exits the screen.

So, in order to max out its speed, you'd actually have to max out both its offense and defense attributes. I think this is a pretty neat way to handle things, and, in a perfect world, it would make a great game, but it.. doesn't.

The reality is that not only is this pretty complicated (especially for a game that's largely just pick up and play shooting), but it's all happening in the background under vague labels too! Best case: dedicated players reverse engineer the numbers and learn how to work the system, while casual players are uninformed and fail miserably. Worst (and most probable) case: players are quickly frustrated and annoyed, prompting them to give up on the game.

Obviously that's bad, so that plan has been scrapped. Or at least severely amended.

It's not exhaustive, but here are some quick bullets about the "new" system:

* Each unit type still has three attributes, but each set of three has been tailored to the specific unit type, instead of trying to shoehorn the unit types into a generic attribute set.
* Each attribute is linked to a single property. Gone are the days of complex, intertwining relationships.
* When setting up your defenses, the UI clearly displays what an attribute adjusts for that specific unit when mousing over its slider. The numbers are all still tucked away in the background, but at least the relationships are clear; semi-transparency should be sufficient.

As big as I'm making it sound, in implementation these are tiny adjustments, but I spent a lot of thinky-juice deciding that this is the best course to take. Now that this is done, I'm feeling good about the project again and really can't wait to wrap up the rest of the non-balancing work so I can get this out to everyone.

426 comments