Recent Progress

The blog may have been quiet for several weeks, but I’ve been steadily working (and tweeting). Tech research is finished, I’ve integrated sound and music (although plans for the soundtrack are still up in the air), and made a number of UI improvements. I’ve implemented the code for normal-mapped sprites which combat will use, and I’m pleased with the results. Right now I’m using a shader (via ARB_fragment_program). It occurs to me that I could get the same effect on some older cards using the dot3 bump mapping support that’s probably been around since the original Geforce, but I think I’ll stick with this approach.

One thing I’d wondered is how to deal with different player colors for the ships in combat. For UI elements, which are generally text or monochromatic vector art, I modulate by the primary color, but that doesn’t work for ship textures where you want them to be mostly metallic gray, with accents of the player’s color. My solution is to permute the color channels using a swizzle in the shader, so that grayscales are preserved but the source texture can be transformed to match the player’s color scheme. I’m happy with result, aside from having to compile a separate version of the sprite shader for each player.

I’ve been working on the artwork for ships in combat. I’m doing modelling in Wings3D, then importing the models into Blender to generate normal maps. I do exturing in Gimp, using the normal map as a guide. The workflow was rough at first, with some import problems (most notably, smoothing information being lost/ignored by Blender), but I’ve steadily refined the process. Most recently, I’ve simplified things further by painting material colors on face by face in Blender and generating an initial texture from it alongside the normal map, so that all I have to do in Gimp is add final detail and grunge. Painting colors by face is great for littering a starship hull with panels and variation. It also sucked having to trace curved geometry by hand for the first few ships.

Next on the agenda is the ship design UI. To design ships, you’ll start with a basic class/type/hull (haven’t nailed down the terminology yet) as a template, and fit equipment. This uses a blueprint-type view. Equipment choices include weapons, armor, engines, shields, and miscellaneous devices. An idea that only recently occurred to me is supporting carriers with fighters by adding a fighter bay tech that can be researched and added to ships. The idea is that you’d design fighters based on the smallest ship classes, leaving out an interstellar-capable engine and using the space saved to add better weapons and shields. Carriers add a fighter bay, and the amount of unused space in the design determines the number of fighters they can carry. This has to be abstracted somewhat, otherwise it’d always be a bigger win to load the capital ship up with extra weapons rather than carrying fighters.

The mechanics of combat in the games I’m familiar with strongly favors the largest ships. In MOO, ships in the middle of the scale are often neglected. I want to avoid that with a balanced interplay of ship maneuverability, firing ranges, and biases in the suitability of weapons toward certain ship types. I haven’t worked out specifically how yet, but I have some ideas. The brute force approach is to make larger ships less cost efficient, but that just constrains the space of useful designs without adding richness to the gameplay.

Here are screenshots of some ship designs that are finished so far:

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: