Naev - Naev Development Blarg (Page 19)

0.5.0 Alpha Gameplay

BY BOBBENS, ON JANUARY 8TH, 2011

Recently the new x.org brought me frustration. My open source driver broke down and I was left without being able to run Naev. After realizing I needed a kernel upgrade I found out the biggest benefit of gallium3d: I can make videos! So kudos to the open source ati driver team. Here’s a video showing off preliminary 0.5.0 alpha gameplay in the balance branch.

Things to note:

I’m using forward cannons, swivel for the win!
Using HatlessAtlas’ new AI, it’s harder to follow and track them
Pretty backgrounds (for those who haven’t seen 0.5.0 in action)
Smooth camera and dynamic zoom (zoom will be revised a bit more probably)
New rumble (it’s preliminary, but much smoother)
Penetration model (I barely get hurt – maybe more balancing needed)
New weapons

This is not meant to be a really serious video, just me fooling off and showing my awesome ship build and mad skills.

Naev 0.5.0 Skirmish

0.5.0 Status Update

BY BOBBENS, ON DECEMBER 31ST, 2010

Lots of you have complained about accuracy in Naev and hitting stuff with forward mounts. As part of the increased range and weapon rants it was unbearable in the sense you never hit anything unless you went point blank. I am proud to announce the implementation of swivel forward mounts. That means all weapons have a tendency to correct minor errors in accuracy. The longer the range generally the more they compensate. This also works similar to turrets with electronic warfare, but generally the accuracy is much higher with forward mounts than with turrets. Hopefully this will make forward mounted weapons actually usable.

You can check out the changes in the every unstable balance branch on github.

NOTE This screenshot has been lost to time :(

0.5.0 Status Update

BY BOBBENS, ON DECEMBER 21ST, 2010

We haven’t posted in a while, so I decided to update even though we don’t have anything spectacular done (depending on your definition of spectacular). So what is going on? As you may know the current development and broken branch is the balance branch (This branch is now long dead, unsure of the commit sha). This branch is active and will mangle your saves if you load it. Why? It’s caused by the implementation of the weapon rant, which makes it so all the weapon are changed. Some retain their name, but most get lost in the transition. This is unavoidable and will happen to everyone once it’s merged back, but it shouldn’t happen again then.

Other things, ewarfare has more or less been balanced. We’ve introduced another parameter for heat. So the more your ship heats up, the more visible it is. The equations are also tweaked in such a way they make more sense and are cooler overall. Also turrets finally use it, so you can’t track a fighter with a long range anti-capship turret. This all may still need fine tuning but it is working quite well.

Another major change which has broken a lot of missions is the fact we’ve changed the time model. Previously time only changed when you landed or jumped. Now time will change while flying too. That means that slower ships will waste more time in system while jump times will be very similar. This sort of makes everything more interesting and realistic which is quite cool. However it means we have to revamp all our cargo missions which we want to rethink anyway when we do economics. For now we’ll probably keep them similar to how they’ve always been, but in the future we’ll change it.

Finally mentioning some changes we want to do. With google being more and more evil, we’ve been thinking of completely foregoing both google code and google groups. We’re working on having our own wiki which shouldn’t take too long to be available. If someone is really interested in helping out we can sort of speed it up and spread the half-finishedness. It still needs lots of love. Secondly we’re considering the possibility of also hosting our own mailing list, but we’ll see about that. That hasn’t even been started.

Closing words on the release. The original intention was to release end of 2010, however we believe it is much more important to have a good solid release than a half-finished rushed release that will need a dozen bugfixes to be playable. We would like to still release at the end of 2010, but chances are we’ll just do a beta at the start of 2011. There’s still much to do, need to finish some stuff and then fix everything we broke. To speed up the release we are trying to delay changes that aren’t fundamental, however we also want this release to sort of establish the maturity of Naev, but chances are 0.6.0 will be the true maturity once we get there.

tl;dr We’ll release when it’s ready :)

NOTE This screenshot has been lost to time :(

Correct Physics

BY BOBBENS, ON NOVEMBER 23RD, 2010

WARNING: TECHNICAL POST

After much insistence on Deiz that something was wrong since we needed a hack to get ships to properly display 100% speed, we’ve finally found the culprit. Some old code of mine that what it did was:

c void limit_speed( Vector2d* vel, const double speed, const double dt ) { double vmod; vmod = VMOD(*vel); if (vmod > speed) /* shouldn't go faster */ vect_pset( vel, (vmod-speed)*(1. - dt*3.) + speed, VANGLE(*vel) ); }

What does this mean? It may seem like a good idea to limit the speed by modulating the velocity directly. There is also a dt in there to try to make it not frame dependent. However let’s analyze the consequences.

The important question is: what is the maximum velocity? The way stuff is done we’re cascading the limit_speed with the physics model. We can simplify it to an euler integration (it’s actually runge-kutta but I’ll talk about that a bit latter):

v_1 = v_0 + a dt

Everyone should be familiar with that. I won’t go into details from where that comes from. Basically it means that the current velocity is the last velocity plus the acceleration times the time that passed from the last instant. This is then chained to the limit_speed which does:

v = (v_1 - v_{max})(1 - 3dt)

So we can write the composite form as:

v = (v_0 + a dt - v_{max})(1 - 3dt) = v_0 + a dt - v_{max} - 3 dt v_0 - 3 a dt^2 + 3 dt v_{max}

Now we can see the problem. What should be linearly dependent on the dt to cancel out the dependency on the frame rate is now quadratically dependent (notice 3 a dt^2). This means that the velocity now does indeed depend on the frame rate. That’s bad. The physics model shouldn’t depend on the frame rate. How can we fix that?

The most logical and simple solution would be instead of hardcoding a limit_speed function outside of the physics engine to integrate it. What does the physics engine work with? Forces. What should we do? Create a virtual force dependent on velocity.

A bit on our physics engine. The physics in NAEV is modelled as differential equations and is solved generally with Runge-Kutta. It all sounds really complicated but it isn’t too much. If you want to go into detail take a look at src/physics.c.

First the philosophical meaning of this force. What does it represent? Why do ships have speed limits? This limit represents the ship’s stabilization systems. To allow the ships to have artificial gravity (the ones that do) and fly around so well with turning, they need complex stabilization systems. So what we’re modelling is some sort of drag force.

Now onto the force itself. After much discussion ranting and throwing of equations we finally managed to model it. The current model is:

f_{stabilization} = k (v - v_{max})

It’s much more simple, behaves really well and allows really simple max speed calculations. Your max speed is when the forces acting on your ship are 0. When does this happen? Easy, v_{realmax} = speed + \frac{thrust}{k}. We’ve found that a good value is k = 3 .

Other notes, while doing this revamp I improved the current engine. Thrust is relative to the ship, that means that rotations are smoothed out really nicely by the Runge-Kutta algorithm. Same happens with the new stabilization force. This means the physics are smoother than ever. The system was also improved to handle fast ships and jump ins without instability. What we saw originally was that when your ship was moving really fast, the stabilization force caused instability in the physics engine. This meant your ship would end up at infinity about a second after jumping in. However the new improved engine can handle any speed by chopping up the simulation more finely when the ship is going fast.

Other notes we also have a hybrid physics engine now, in the sense it can do both Runge-Kutta and Euler for different objects at the same time. I’m quite proud of it. The player may be asking what to make of all this? Well you probably won’t feel a thing, but let me assure you it’s much more awesome.

EDIT: It’s been pointed out that if you go back to the equation originally you could have looked at how the units did mismatch. We all learn from our mistakes, how stupid they may be :) .

Fancy new menu

BY BOBBENS, ON NOVEMBER 16TH, 2010

After lots of nagging and harassing of developers we finally have it! The great epic new fancy main menu background, and what could be fancier than naev itself? Yes the background is a system (specifically it’s the start system for now). It’ll be a bit fancier in the future but you can now enjoy the awesomeness. No more boring backgrounds! Check it out!

NOTE The screenshot has been lost to time :(