Naev Development Blarg (Page 19)

• 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 :(

  ---

• NAEV 0.4.2 is now available in openSUSE

  BY DEIZ, ON NOVEMBER 12TH, 2010

  While development continues towards 0.5.0, increased availability of the current stable release is always a good thing. NAEV can now be found in the openSUSE Games repository.

  See here (this link is dead :() for downloadable packages for openSUSE 11.3. There are also packages built for a number of other RPM-based distributions, including Mandriva and Fedora listed by the build servicehere (this link is dead :(), downloadable from here (this link is dead :(). It appears that you’ll need the naev and naev-data packages; after installing both, NAEV should be ready to play.

  ---

• Big Big Systems

  BY BOBBENS, ON NOVEMBER 10TH, 2010

  So what happens when you take big systems and inject them with pure essence of big? You get Big Big Systems. How big are we talking? If an old system maybe had an effective radius of 3.75 kpx or so, now we have radius of 25 kpx. That’s a pretty big increase. How long does it take to fly across it? It’s likely faster than before thanks to dynamic time compression.

  A brief overview of how this is handled; There are currently two ways to trigger dynamic time compression:

  1. Activate autonav
  2. Right click on the overlay map

  What it does, essentially, is increase the time compression until your ship reaches an “effective” speed of 2500 m/s. That means all ships behave nearly identically, be it capital ship or light fighter. This means that capital ships are much more playable now.

  Can’t leave you without a pretty screenshot, so this is what a big big system looks like. As you can see there’s a YOU and GOTO on the map and dynamic time compression is at 27.1x. My Empire Hawking is flying from YOU to the GOTO. On the map overlay you can also see friendlies flying nearby.

  So what’s next? Balance. Balance? Balance! It’s going to still take a while, but it’ll be damn well worth it. For those following Git, big big systems are still in the balance branch and haven’t been merged into bigsys yet.

  NOTE The screenshot has been lost to time :(

  ---

• Mouse Targeting

  BY BOBBENS, ON OCTOBER 24TH, 2010

  Possibly what could be considered the last of the large planned features has been implemented. This is mouse targeting. Well what does mouse targeting mean. It has two implications, the first is that in the regular game screen while flying around you can now target ships. However you can also target jump points, planets and ships with the overlay map. This means that you do not necessarily have to go through long boring cycles to try to select a ship to board, or a ship on the map.

  Hopefully the feature will be cool and enjoyable for all. If someone doesn’t exactly like the implementation or think it could be better (or more natural) don’t hesitate to get in touch with us.

  Finally, what is next? Well now we have the long complicated task of balancing and implementing new outfits. This daunting task will be done in the “balance” branch as it will most likely mess up everything. We’ve already integrate some of the ideas from the forums like the damage rejection. It seems like we may be ahead of schedule for 0.5.0, but I make no promises.

  ---