Radar added, text back in

Well, the radar is in.  Dealing with the necessary projection matrix transformation to make it display right was a bit of a pain, really.  The actual transformation is basically only three lines of code, and they don’t even look that impressive, but it took a bit of thought to get there.
Anyway, it’s all done by modifying the projection matrix, so you can then just draw all the ships within a certain range of the player again, only with a different texture.  As far as the display function is concerned, it’s displaying the ship again at the same location as when it draws it onto the main display, it’s just the different projection matrix that makes all the magic happen and sticks it all in the radar bubble.
I don’t draw the wall in the radar because, at some point, the walls are going to go away.
So, next up: Planets, I guess.  I’ve got gravity code in there, but it’s all untested, since nothing in the game has gravity yet.

ver15

Posted in State of the Game | Comments Off on Radar added, text back in

Thoughts about the new direction

I’ve been thinking about other space-based, sandboxish games set in large universes.  Privateer, freelancer, X3.  Maybe I can have the player set up bases on planets.  Some planets are worthless, some are good for mining, and some are good for building a colony on with defences.  I guess there are two styles here: Either the universe is already inhabited and you find mostly already-settled neutral planets that are already trading with each other, like freespace, or it’s mostly empty, and it’s all about expanding your empire and claiming territory and taking resources, and the computer is doing the same thing.  Like master of magic, or most space-based RTSes.

There needs to be a story for the player, too- they have to start out somewhat weak for purely gameplay reasons, but have the ability to improve themselves drastically- and if the universe is full of others in a not dissimilar position, why isn’t everyone else doing the same thing?  It’s a question left unanswered by most RPGs, but in an open universe, it can get a little ridiculous.  Further, if you can improve yourself significantly yet still find yourself in danger, what was stopping that danger from stomping you when you were starting out?  The popular answers to this question also tend to be a little contrived.

There’s always the “self-improving nanomachine technology” card to play, which could mesh well with the “absorb powers from your enemies” concept I already have going.  Or maybe the standard “Collect resources, use them to research upgrades at your base” option.  Maybe you’d have to tow crippled enemies to your base to steal their tech, then reverse-engineer it before you could use it.  I definitely want to make it hard to steal tech, I want it to feel really special when you get a new weapon type to mix with all your others.  Like that feeling when a rare item drops in an RPG, picking it up and identifying it is like opening a christmas present.

On the more technical, immediate side, there’s the problem of the enemy getting up far too much of a head of steam and blasting past the player at ludicrous speeds.  It’s just a result of intentionally not having a maximum speed set.  Not having a max speed also makes predicting collisions a lot harder.  To counter that, I’m planning on having multiple star systems, and setting the AI a slow maximum “combat speed” for when it’s fighting you, slow enough that it can avoid planets without having to make the AI too smart, and a higher “in-system speed” for when it’s not fighting anything, and an unlimited “inter-system speed” for getting between solar systems, where it speeds up half way there, then slows down the other half, like the player would do.

Another immediate problem is the inability to find the enemy- space is large, and if you zoom out enough to see a reasonable distance around you given the speeds attainable, everything is too small to see.  Some sort of radar is definitely called for.  I’ll be working on that shortly.

Posted in Design | Comments Off on Thoughts about the new direction

A fundamental change to the direction of the game

Today’s version is a major revision.  I’ve decided not to go musical.  More strategic.  Larger in size.  With gravity and planets and bases and maybe convoys and a UNIVERSE.  I’ve got a vision, it’s partially inspired by this game I played many years ago which I just can’t remember the name of.  But maybe that’s for the best- with all the fuzzy edges of a distant memory, I’m free to reinvent details without being chained to what’s already been done, and with the rose-tinting of the past, all I remember is what I liked about it.

In any case, the music idea is out.  Partially because I was browsing through steam and found this.  It’s not exactly what I would have done, but it’s close enough that I probably don’t want to be competing with it.

Anyway, MY game is now newtonian, much larger in scale (Well, it’s more that everything has shrunk, but whatever), and has some background to give some perspective for how fast you’re moving.

Controls: WASD keys do slightly different things.  Mouse scroll wheel zooms in and out.  Everything else is the same, I think.
The enemies have a kind of weird behaviour.  They’re newtonian too, but they’re not smart enough to start slowing down until they’re REALLY close to you.  So they’ll tend to shoot by at insane speeds.  Move to the side, and you can get them to start orbiting you, which is kind of funny, but not really good enemy behaviour.
They do cheat a little- there’s a ring around the player that slows them down a lot, that was what kept them from bouncing back and forth forever back when it was non-newtonian, last version (A large damping factor in their simple harmonic motion, for the physics nerd).  But the only way it won’t look like they don’t basically teleport into you or shoot right by is a smarter AI routine, that is intelligent about when it starts slowing down, which is I guess I have to work on.  I think I need to meditate on it for a while, though.

Note that the world is indeed so large now, that it will take quite a while for the enemy to get to you.  Just wait for it.

Also worth noting: I’ve introduced a couple of .pngs.  They’re vastly smaller than the .tgas, and still support alpha, so that seems like an easy decision.

ver14

Posted in Design, State of the Game | Comments Off on A fundamental change to the direction of the game

AI and better looking enemies

Well, three basic AI modes are in.  I feel stupid even calling it “AI”.  It’s… behaviour.  The ships follow the player around, it’s not like it’s a thinking robot.
Anyway.  Mode one: It chases the player.  There is acceleration in all the modes (they start slow and speed up, and if they’re going fast and you get behind them, they have to slow down to turn around), but it’s hard to notice unless you set it very, very low.  I’m thinking about making it only apply to turning.
Mode two: It runs away from the player.  Not really sure what that’s good for, because they just immediately get stuck in a corner, but it took five seconds to add in, so that doesn’t really matter.
Mode three: It attempts to maintain a specific distance from the player.  The distance is hardcoded for now.  I think this mode is probably my favorite, which is why I’ve set shipdata.txt to use it for the default enemy.  Switching that value in shipdata.txt will activate the other modes.
Also, ship explosions are back in (They got lost during the conversion from pixel coords to game coords a couple updates ago, I forgot to resize the explosion size, so they were still happening, they were just much, much smaller than a pixel).  I’ve slowed down the rotation, so now they look slightly less dumb.
Retextured the enemy ships, and added orientation.

ver13

Posted in State of the Game | Comments Off on AI and better looking enemies

Weapondata.txt

I’ve worked a bit on AI recently.  It’s not in there, but almost!  (Of course, I’m talking about very basic ship movement AI here).  The data structures are in place and initialized, the ship update function is being called, I just need to drop in the computations to actually figure out what direction the player’s ship is facing and change the speed, then change the position according to the new speed.  Should be pretty straightforward.  I already do most of that for projectiles anyway.
But, what’s new:
Projectile properties are now read from weapondata.txt at runtime, as are enemy ship properties from shipdata.txt.
So, modders could open up weapondata.txt and change, say, the main gun’s firing cooldown time down to 5 and damage down to 0.1 and have a machinegun stream of bullets.  Or change the velocity on the shockwave weapon to something super high and lower the firing cooldown and have shockwaves bouncing around all over the place.  I actually did that by accidentally reading it in the data sideways, and it was a fun effect.  Firing weapons insanely fast seems like more fun somehow.
Now that I’ve got the function in place for reading stuff from a file into a data structure I’m comfortable with, I could conceivably do this with most of the magic numbers, like how big and fast the explosions are, how big the enemies are, how big the player’s ship is, how fast it is, that sort of thing.
Also: Enemies now do damage when they collide with you.  Well, they don’t move, so you have to run into them yourself, but the point remains.  Player HP is tracked on the screen.
The other big thing is now there’s an actual damage model for the enemy too.  I’ve intentionally made them pretty strong and the weapons pretty weak, just to make it easy to make sure it’s working.  One downside: The shockwave weapon now works in a kind of weirdish way, which is now obvious that everything doesn’t die immediately.  It does damage every ms to anything inside it.  So things near it’s center will take more damage, but just because they’re in it longer, so they won’t die immediately.  It looks weird to have stuff die after the “shockwave” has already passed them.  If I changed the graphics to look like an “energy field” or something instead of an obvious shockwave, I imagine it would seem less out of place.

Now that I’ve got a basic weapon system in-game, I’ve been contemplating some sort of power pickup system.  I know I want the player to steal powers, or eat powers, or something, from the enemies, but how?  Enemies drop powerups occasionally?  If so, how does the player decide which one of his two weapons he wants it to replace?  I’d like to have a solution that doesn’t involve pressing a key, to keep stuff simple.  I’d like to keep it kind of kirby style- have some short range, low damage weapon, maybe, that you have to kill an enemy with to steal their weapon, to make it more risky, like how it’s more risky to swallow a guy as kirby than use your power to kill him.  Keeping a risk/reward balance is important, and the payoff for having a new weapon to play with is large, getting it should be difficult.

ver12

Posted in Design, State of the Game | Comments Off on Weapondata.txt

Text- more difficult than you’d think

Rendering text in OpenGL ends up being much harder than I thought it was.  It seems like such a fundamental thing, but it took me a while to really believe that there isn’t native functionality to do it.  I tried a few libraries which claimed to be a sort of “Drop it in and it will work” solution, but they either relied on deprecated OpenGL methods or they seemed they’d lack flexibility.  So I went with the plain freetype 2 library, which is far from a ready-made solution to the problem, but does handle reading font data.  Then a few hours more figuring out that opengl displays bitmaps incorrectly when the bitmap doesn’t have even dimensions (Like, a 50×30 would display right, but a 49×29 wouldn’t).  (Ends up there actually is a good reason, I had just never needed to know before now).

That was day one, I went to bed rendering a single letter to the screen as a texture, thinking I was pretty much done.

Day two I spent figuring out how to get the large amount of data required to put text on the screen as a string rather than a single letter.  Let me put it this way: you end up using every arrow labeled on this chart before you can know where to put it and how big to make it in every direction.  The nice thing, though, is that now I can effortlessly drop in new fonts just by feeding the font class the path to the .ttf file, and write to the screen with them.

Also, I’ve detatched the “view” from the rendering, so I can now change resolutions and keep the same parts of the game visible in the correct aspect ratio, or zoom in and out, or otherwise manipulate the view.  As long as it is done it right (which I almost achieved when I first wrote it), it’s super easy to move the view around with a single function call.  I haven’t actually done anything with it, but it’s definitely something that needed to be done.

ver11

Posted in State of the Game | Comments Off on Text- more difficult than you’d think

Shockwave weapons

I didn’t do what I planned on doing, but I did do a shockwave weapon.  When I first saw the shockwave in action, it suddenly felt a lot more like a game.
The keys, updated:
1 for normal projectile (I’ve turned bounce on for both it and the
shockwave weapon)
2 for the laser
3 for the shockwave
q to quit.
= and – no longer change mouse sensitivity, they now control how fast enemies spawn.  Crank it up really high and wait for a while, then use the laser, it does an amusing digging effect.  Or drop it low and use the normal projectile and fill the screen with bouncing bullets, see how many you can get on screen before the game slows down.  The number is surprisingly high.

ver10

Posted in State of the Game | Comments Off on Shockwave weapons

Timer scheduling, dangerous lasers and some low-end animation

Updates with this edition: Lasers now destroy ships as they should, and if they hit multiple ships, they only destroy the closer one, not whichever was spawned first.  Of course, I haven’t plugged in any damage values yet, so everything is a one-hit-kill weapon, so the laser will just destroy the second ship in line one millisecond later, but whatever.  It’s in there.
More importantly: The timer scheduling code is done and functional.  That was some pretty tricky code.  Ships now “explode” when destroyed, though the explosion animation is pretty terrible due to my lack of artistic skills.
Also: Projectile code generalized a little bit more.  Now supports projectiles bouncing off the walls and/or having a set lifetime before they expire, all set by flags on each individual projectile.  Also added a “fake” projectile type, to handle purely visual fragments from explosives (which are not in yet).
Added a texture to bullets
So I’ve got the event queue programmed in, which allows me to have animations (or, at least spinning, shrinking, expanding, changing transparency over time, stretching, that sort of thing), so now the problem is making the animations not look stupid.  I’m working on explosions right now, and it’s… kind of difficult.  I can pretty much do everything that the UDK can do in textures (except I have to hard code it instead of dragging boxes around and drawing lines between them like you can in the UDK), so I’m planning on analyzing a lot of their techniques, though obviously not using their actual textures.  One interesting thing about this whole experience is I’m learning a lot of what’s behind those magic boxes you can drag around in the UDK- I’m realizing now that a _lot_ of them are basically directly translated into one-line function calls (assuming DirectX is like openGL), plugging in the values you type into the box for the arguments to the function.  At least, that’s true for the texture stuff.  To a large degree, a lot of the UDK is a pretty, graphical, drag-and-drop UI for writing code, especially graphics code.  Which makes sense given my theory that it’s intended for artists so they don’t have to constantly wait for programmers to progam in their art.

For next time: Add in an always-on call to a LUA function to the event queue, to act like a “heartbeat” hook for LUA.  Want to write some LUA that will execute once per frame?  Stick it in that function.
Add projectile fragments to the explosion, and maybe change it to expand rather than shrink and spin.  Change the explosion to flip through a bunch of textures, maybe. Change the ship image from a placeholder to what I actually want it to look like.  This will proably take a while to get right. And, I guess now that the timer queue is in, the next big missing chunk is AI.  So I should start thinking about that.

ver9

Posted in State of the Game | Comments Off on Timer scheduling, dangerous lasers and some low-end animation

Laser textures

You may have noticed previous versions did a weird ugly thing when you overlapped something transparent with something semi-transparent.  I was using a slightly incorrect alpha blend function (there are about 15 to choose from), I have fixed that.  I’ve also textured the beam.

Texturing is turning out to be a problem, though.  Photoshop doesn’t really display alpha in the same way OpenGL does (to the best of my knowledge), so after taking about 20 minutes to make what I thought was going to be a really nice, firey-looking laser, I stick it into the game and it looks terrible.  Just a really simple gradient from red to orange looks slightly better, which is what is in there now, but it’s still not very good.  Maybe once it’s animated.

I believe I’ve solved the problem standing in my way with the timer code, though, so I should finish that tomorrow.

ver8

Posted in State of the Game | Comments Off on Laser textures

Laser beams

To do explosions, I need to have a way of having a list of things to do in the future.  I knew I was going to have to do this eventually, but it seems tricky to do in a really general way.  I want to have a sorted linked list of a really simple class, just holding a time (the time at which to start executing an action), with a pointer to the function to call.  Maybe.  I will contemplate the issue further.

In the mean time, I’ve implemented beams, which in turn required me to update a lot of the placeholder projectile stuff.  It’s somewhat more general now, and there’s a basic framework in place to handle implementing additional weapon types.

New keys: press 1 to use normal projectiles, 2 to use the beam (which
doesn’t have collision detection on it yet, and is also untextured).

ver7

Posted in State of the Game | Comments Off on Laser beams