Amazing I got this far without a thing to let me easily throw debug status displays up on the screen. At least that little oversight has finally been rectified.
I finally buckled down and reworked the camera and ship control code in the space game, and I think I have something promising at long last. There were really two major broken things, the ship control itself and the chase camera. I pulled them apart into their own classes and addressed their problems separately, which shockingly turned out to be a cleaner way to deal with them.
At a fundamental level, ship motion is Ace Combat-style. You maintain a constant velocity forward but can hold the left or right analog trigger to temporarily decelerate (all the way to a stop, in my game’s case) or accelerate using afterburners. I’ve always found that monitoring my ship’s speed is a giant hassle I can never keep up with in space sims, and the AC model means it’s simply not a problem. You know your speed at all times because you are personally holding the analog triggers that set it, just like you know whether your car is stopped or accelerating based on the pedals you’re pushing down with your feet. As far as velocity and inertia goes, right now you simply lerp to your new velocity at a constant rate. This is utterly nonsensical from a physics point of view but it sure was simple to program and it’s not hard to understand what’s going on, an important factor when you’re in interplanetary space without a lot of landmarks around.
The other nice thing about this is that all the ship behavior is based on a set of constants. Reducing the steering lerp rate, say, makes the difference between a nimble fighter and a heavy barge. This’ll make it easy to support different “flight models” for different ships, or even the same ship equipping different types of equipment.
As for the chase camera, it’s a simple affair that monitors its target and lerps (sensing a pattern here?) to the desired chase position and angle. This works nicely in that by adjusting the lerp rate I can tweak to what extent you see the ship pivoting and reeling about on the screen, and the more violently you maneuver the more the camera lags to give you a sense that you’re making tough maneuvers. I might make the lerp rate dependent on your speed, so the ship feels a little out of control at top speed. It would be easy to explore, at any rate.
Lack of decent, non-hacked in camera and ship control was a huge blocker for the game, so maybe I’ll feel better about exploring different areas of gameplay now.
Yeah yeah, blah blah blah long time since last post lame excuse etc. So while Wings 3D continues to be a delightful breath of fresh air in the 3D modeler field, one slight inconvenience is that it really doesn’t want to deal with freestanding points and lines, and doesn’t have a way to place generic Maya-style “locators.” It seems that I just need to place some fake geometry and use a naming convention in my importer. I’m not fond of naming conventions — everywhere I’ve worked that relied on them, we had constant bugs from people typoing some ludicrously complex name format — but needs must when the Devil drives, whatever that means.
Soooooo, I took that second little ship I slapped together a while back and added some test geometry to it to try this out. I’m going with a convention that cubes (like the “lights” on the end of the wing spurs) represent directionless point locators, and cones (like the “missiles”) represent directional locators — the center of the cone’s base will be the position, and then the relative position of the cone’s point determines the direction. It all seems straightforward enough, so I don’t forecast any problems plugging this into the “anchor” system I already had in my 3D engine.
Orteil (the Cookie Clicker guy) made a random generator generator. You can set up a file with some simple syntax and randomly generate all kinds of text. Lately I’ve been thinking about loot and itemization, no doubt because of playing the new Diablo 3 patch which makes substantial improvements to those things, so I made a random generator that creates space weapons.
“Quad long-range charged proton fusion blaster,” I like the sound of that.
Just busked another little spaceship I could theoretically use to test out having other ships in the game environment. I’m still annoyed that I don’t have a solid design that I’m going for, which would inform how the ships should look, but the plus side is it only took me like forty-five minutes to make this thing so if I can’t use it it’s not like I wasted a lot of time anyway.
Sorry I didn’t get anything posted the last week or two — as usual for when I confidently set aside some period ahead of time to REALLY GET THINGS DONE, I got incredibly sick instead. I swear it feels like the only times I actually make forward progress on anything is when I sneak up on work and then pounce.
Light the engines and head for the stars!
Oh, don’t mind me, just added some nice exhaust flames to the ship model. I can set their color and size as seems appropriate, and there’s an aspect of the model which amuses me — in order to make the internal flame visible surrounded by an outer shell, I simply flipped the normals on the outer shell model so you only see its back faces. For once, backface culling is more than just one of the miscellaneous OpenGL settings I turn off while desperately flailing around to see why my crap isn’t drawing this time.
While I’m here, figured I’d mention the big change to this project is that I’ve decided to think outside the cockpit and have it be a third-person view instead of first-person. The project’s been moving that way for ages as I abandoned first one than another first-person feature of the design, and eliminating the cockpit completely saves me so much hassle — like rendering it, animating it, adding in a player character model (gah), representing the HUD as a physical object instead of a purely abstract game interface, designing a ship model with decent visibility from the pilot’s seat, having an extremely close near clipping plane in the game world, and so on and so on, ever and ever, amen. Those things are simply no longer issues any more.
I’m not naive enough to think that third-person view doesn’t have its own stupid hassles — game programming is nothing but wall-to-wall stupid hassles, after all. But right now I’m hard pressed to think of anything I didn’t already have to deal with, beyond maybe having an attractive spring-damper thingy on the camera so it does more than just stay locked on the back of the ship all the time.
Also I realize I’m being a broken record here but it’s just so nice to think to myself “Self, I’d sure like to make a simple 3D model for those exhaust flames” and then just be able to do it in an application that doesn’t smart back at me. Thank you, Wings 3D.
Let’s get some COLORED models up ins! Crazy how easy this was.
It was a good idea to take a little break from the still-unnamed space thingy; I sat back and turned it over in my head and I believe I have a good concept for the whole thing that fits the art style and what I want to create, as well as a better idea of scale and gameplay. I’m going to try to get an important part of that working for Screenshot Saturday tomorrow. Wish me luck!
As part of that, here’s a simple player ship model I slapped together in Wings 3D and imported into the game. I’ve gotten rid of the remains of my last failed attempt at a lighting system and the ship is now correctly lit by the sun. Also fixed a dumb bug in my importer code which kept me from being able to import quad-based models.
I am very pleased with Wings 3D, by the way. I’m not an especially great 3D modeler and I definitely don’t enjoy the mechanics of doing 3D modeling, but Wings 3D makes the experience of just getting some simple damn models out the door as painless as one could reasonably hope for.
Yeah, decided to mess around with A. CYBORG for a bit while I rethink the story I had in mind for the space game after the weird direction it went in. Might write a bit about that sometime.
Basically, what I’ve done over the last two days is fix up the enemy system to be more production-ready. Enemy aircraft can now be “skinned” in the same way the player character is, thus the red, green, and blue aircraft, and variations with different HP and score values are organized into a list. I’ve added various animation frames for the MiG-29 and put in proper support for switching between them, so these aircraft can approach head-on and then fly up, down, or sideways. And, there’s a functioning keyframe-based flight plan for enemies so their behavior over time can be set up easily. Well, relatively easily, it’s still kind of a hassle but I’m not sure there’s much more I can do with that.
Unfortunately I’m running into the same bothersome scale issues I’ve mentioned before. See, After Burner has it relatively easy, as the player and the enemies are about the same size. This game, not so much. Here’s some pictures of people standing next to a real MiG-29. As you can see, it is much bigger than a person! Thus, once those aircraft are anywhere near the heroine they’re hugely oversized and it’s hard to see more than one at a time, and if I want her to be able to move easily between aiming at different targets she has to jerk around the sky at tremendous speed and it’s much harder to arrange for smooth camera moves. Oh, and as there’s still the issue with crashing down into the ground and how close the camera would have to be to those ultra-low-res ground sprites to see anything beyond a tiny speck…
It’s possible that if I switch to a more After Burner-like aiming scheme (the player aircraft is allowed to “turn” much more and aim the targeting cursor far to the left/right/above/below, which makes up for the player’s extremely limited range of motion) that would alleviate this situation somewhat. It’s worth considering. I should just play AB some more too… research, you see.