Hey everyone, it’s time for that weekly update! Once again this week’s engineering effort has been primarily focused on missiles. The locking system is nearly complete, though it will need a lot of balancing later, and the HUD integration is being wrapped up. Missiles have proximity detonation if they’re within a close enough radius of their target but their velocity prevents a direct impact. They can also be shot down by bullets or any other projectile, including missile on missile collisions, if you somehow manage to shoot one. Finally, we had an internal playtest to try out the new weapon code. Obviously, as an initial implementation, it’s still quite rough but getting all of the major weapon types mocked up in the game is a major milestone.
On the art side we’ve got many different things in motion. Kristian is working on the final geometry pass for the cruiser which is beginning to come together nicely. Jan has been tinkering with weapon and shield effects. These are primarily placeholders but they give a good idea of the general direction we’re thinking of moving in and should be integrated in our next patch. Dan has been working on some stuff for our website, which we need to update soon, as well as the final geometry pass for the space whale bobblehead.
That’s pretty much it for this week. We can see the light at the end of the tunnel for our next patch and once it becomes available there will be a lot more to talk about.
A direct hit with the target does 100% damage. However missiles are very small, so hitting a target directly might not be easy ( players can dodge incoming missiles ). At 75% of the missile life time ( WIP number ), they switch to detonation on proximity, to get near-guaranteed damage ( if the target didn’t use counter-measures ). It will most likely do less damage though - right now, about 50%.
Kindda; there’s no fuel, but a missile life time ( which in some ways could be explained through hidden fuel ) to prevent missiles from wasting too much network resources or polluting the servers. Once the target’s lock is acquired, the missile tracks the target independently of the parent ship sensors.
Could the missile also explode when it reaches the end of its fuel and hasn’t hit the target (at an even lower percentage of damage)? Not for the purpose of hitting anything, but as an explanation of what happens when it dies! Also it would look pretty, rather than just vanishing!
Plus, in a big battle, there’s always a (tiny) chance it might damage someone who happens to be too close when it dies!
How differently will missiles behave in an atmosphere vs out in space? Do you think they’ll be easier or harder to dodge, or stay about the same in terms of evasion difficulty there?
Based on that image, it looks like you are doing position based homing (pure-pursuit), aka. the missile just tries to fly toward the target. Is that right?
This is what most games do, but it makes for pretty weird trajectories and boring kind of combat. To make missiles a real threat you have to up their acceleration and range way above what regular ships are capable, which makes them kinda binary. They are either really strong (e.g. you explicitly need some sort of countermeasures to evade them, dodging is pretty much impossible), or they are useless. Would you consider implementing more advanced missiles with lead-pursuit homing? The code is not much more complicated, except that you use velocity (and/or acceleration) as the basis of the homing instead of position. Smarter homing would let you nerf missile properties (turning speeds/acceleration, flight times) to be more in the realm of small aircraft and still stay a real threat. This way players could utilize a larger arsenal of manoeuvres to defeat missiles as opposed to “flare and run away”. Reducing missile mobility also means that they become more situational, and players firing them have to think more about when and how to use them.
The image is from a test app I wrote, which includes many algorithms and possibilities to vary parameters.
The basic algorithm, as you guessed, simply aims at the target position.
There are more advanced algorithms, which try to anticipate movements of the target. One of those estimate the time it takes ( at the current missile speed ) to reach the target, and adds to the target position its velocity multiplied by this time. For example, if it takes 4 seconds to reach the target, the missile will aim at (pos + vel * t) with pos = target position and vel = target velocity and t = 4s.
There’s an even more advanced algorithm which solves a quintic equation to better anticipate the target’s future position, but so far I’m unconvinced by that one ( it’s pretty cpu heavy and does not always seem to work better than simply using the target velocity ).
So the short answer is that: yes, I’m experimenting with various algorithms and parameters, that’s the whole point of writing a separate application for that.
At the moment the missiles roughly have the same thrust acceleration properties than an interceptor, around 5g. The goal is that it is possible to dodge them if you strafe at the right time when a missile is about to hit, however avoiding proximity detonation ( which does half damage atm ) is impossible, guaranteeing a minimum amount of damage, unless you use countermeasures to avoid any damage.
@cornflakes_91 brought up the algorithm that I was going to mention. As I recall, it was the one used on the heat-seeking Sidewinder. It adds an element of skill to firing a missile because the seeker head of the missile records where the target is at time of launch, and then it just tries to keep flying while keeping the target at that spot.
So if a pilot points right at a target, the missile will point straight at the target as it flies. If the pilot points ahead of the target, the missile will point ahead of the target as it flies. And it’s all variable, so the pilot can lead as much as he wants (within the limits of the seeker’s field of view).
It’s a wonderful mechanic because player skill stays in the loop, even for a guided missile. The pilot has to decide how he wants to employ that missile’s primitive guidance. Other guidance systems should have similar weaknesses to them so that players can use their own skill to make up for their deficiencies.
The mechanism could even have an acquisition/lock time, where the player must keep the target steady so that the missile can decide that THIS is the target the pilot wants to hit.
Making missiles autonomously sniper-lethal would be an marvelous accomplishment of engineering, but it would detract from gameplay.
Except that a sidewinder doesnt use the bearing of the target (which would lead to chaser behaviour) but the change in bearing to control its own course.
It doesnt try to keep the bearing the same as at launch but the angular velocity of the bearing 0.
Which leads to the missile always following the same couse when launched from the same position (assuming a missile with infinite course correction capabilities).
There is no pilot factor in the missile course over distances much larger than the launch/aquisition/initital course correction phase.
This is just two ways of expressing the same thing. If I have target at a certain bearing and I keep moving forward while approaching that target at the same bearing, I’m going to hit it - constant bearing decreasing range. I can also say that if the target changes bearing at 10 degrees per second then I should turn at 10 degrees per second, but the net result is that I keep my bearing to the target constant.
The Sidewinder implementation may choose an ideal approach bearing on its own, which means that the pilot’s initial approach angle really doesn’t matter much at longer distances, but in terms of gameplay, I’d recommend not giving the missile that much brains and just let the player’s initial configuration determine how the missile tracks. Just keep the bearing constant and go.
