[subheading]Yet Another New Project[/subheading] Time for yet another new project: a 3D space shooter using the Unity engine, tentatively titled Star Blaster. (A quick google indicates at least 2 other games with the same title exist, so I'll probably change the name when I've thought of a different one).
Since Gamedev are awesome enough to allow hosting working Unity apps with the GDNet webspace (big thumbs up for that), I shall try to upload the latest build as frequently as possible, and keep a log of changes made here. It's not going to be anywhere near a decent game for quite some time (and the graphics will likely suck for just as long), but feel free to provide any feedback here.
The latest build can be found here.
[subheading]Current Features[/subheading] What's implemented so far is very basic: You can fly the ship around, and it's followed by the camera. \o/
The camera is attached via a configured 6DOF PhysX joint, with springs to return it to the defined anchor rotation behind the ship. I'm pretty happy with how this has turned out, though it might need a bit of adjustment when there's more than one ship type in game.
The ship control scheme is WASD for forwards, backwards and strafing, and mouse for pitch / roll. The space bar provides an additional booster, and left shift cuts the engine and turns off drag ([size="2"][font="Arial"]a[/font] la Freelancer's tab / z keys). I'm not really sure I like the pitch / roll model, and will probably implement a rotate towards type thing for comparison (the real test probably will come when turrets / shooting exist).
[subheading]What's Next?[/subheading] First up is fiddling with the Unity WebPlayer Template to show a keyboard layout below the WebPlayer. Then I probably need to think up some sort of hardpoint system, for simple creation of different engine types / effects and weapons turrets etc.
See the next page for ongoing progress this week.
[page] [subheading]Progress Log[/subheading]
Keyboard layout image created and placed below WebPlayer (a bit ugly, but it'll do for now).
Thruster fitting logic and placeholder particle effect added (thruster drains linearly over time and recharges non-linearly).
Changed the engine particle effect (figuring out the best general settings to base future engine effects on and enabled multiple particle systems per effect).
Changed the skybox (now one of the Spacescape presets). It's amazing how much better it looks just with this. I'll play with Spacescape some more later - seems like a pretty nice tool.
Changed the thruster effect to be the base engine effect (scaling particle velocity with current ship acceleration force). Added rather rubbish looking smoky effect as a thruster effect.
Experimented with engine trails, but they don't work very well. Mainly because the thruster / engine effects are done in local space, rather than world space, so they stick out in a different direction. Changing the engine effects to worldspace just doesn't look very good, so I'm leaving engine trails out for now.
Wing-tip vortex trails, however, look quite shiny, so they stay in.
Fixed bugs in thruster logic (ship can now go backwards, thruster turns off properly when out of energy).
Ship is now twice the size it was, and goes much faster and accelerates quicker (adjusted particle effects to match).
Added a couple of numeric readouts to the HUD (the top one is ship speed (velocity magnitude) and the bottom one thruster energy remaining)).
Toolitps now work (kinda fiddly working out the offset / text alignment so that they show on screen no matter where the item being hovered over is located, but it's done now).
"Parking brake" turns off mouse input and decelerates to a stop (enter key). Turned off by using one of the normal movement keys.
Parking brake added to keyboard map and player starts parked (currently called "All Stop" - might need a better name later).
GUISkin created for HUD (no visible difference, but will be useful later).
Simple muzzle flash exists as place-holder, triggered when firing.
First attempt at turrets is in. Turrets have a base, stem (yaws left / right) and barrel (pitches up / down) and aim at where the mouse is. Still needs some tweaking.
Eliminated barrel jittering (up vector now properly recalculated).
Added tracking speed to turrets (probably leave this high enough to be nearly instant for most turrets, but lower for torpedo type things). [subheading]To Do Soonish[/subheading] Proper weapon slots / groupings.
Last summer I started on a project that stalled largely due to my apparent compulsion to write engines, not games, excessively ambitious scope, lack of a realistic project plan and a masochistic hardware target (OpenGL 4.x). However, since ATI seem to have fixed a couple of driver bugs that were plaguing development (for loops with uniform conditionals, and a hideous driver crash), I spent the weekend fiddling with lighting and bump mapping. Even with just two rather amateur test textures I don't think it looks too bad:
The bump mapping was a bit painful, due to using tri-planar texturing for the terrain. While the relevant GPU Gems article touches on the subject of bump mapping, it doesn't really go into detail. Still, I seem to have ended up using a hacky method similar to the code in the article.
The scribbles below show my thinking out the tri-planar texturing method, and the coordinates needed. I'm using the same texture on multiple "sides" of the projection for the moment, and seem to have a slightly different mapping from the article (notice that on all the sides of the cube UP is upwards, not on its side). Splitting out the 6 cases I wanted, the correct texture coordinates can be figured out from the world (/object) space position (they can be combined into 3 by using the sign of the relevant normal).
So far I've not managed to properly generate tangents to perturb the normal, so I'm just swapping the x / y displacement to the relevant world-space axis each for the tri-planar projection, adding it to the normal and normalizing. This is what the bump vector is on the right of the scribbles.
And here's a test image of the terrain using the tri-planar projection:
The snippet of glsl below shows the end result of the scribbles in code. I'm currently using a default texture, and an array of alpha maps / other textures - I might simplify this to include the default in the array at some point. I'm using noise to sharpen and randomise the transition between different textures - this could also be improved, perhaps taking into account the bump map.
// get terrain normal (already normalized) vec3 normal = texture(NormalsTexture, TexCoords).rgb;
// hacky normal mapping normal = normalize(normal + detail_normal * BumpScale);
I'm still not 100% satisfied with this, and will probably try out the method of generating a tangent basis touched upon in the GPU Gems article and see if it looks better. In the mean time I'd love to hear if anyone else has done any bump mapping with tri-planar texturing, and how you got it to work.