You’ve all seen it. The message asking you if you wanted to play a tutorial whenever you created a new pilot. Well, I’m pleased to say that message won’t be bothering you anymore, because the tutorial has a new face.
Main menu with tutorial button
So, a new tutorial. What is different? Well, first of all the tutorial isn’t based in the regular game anymore. Where the old tutorial desperately tried to give you a quick crash course on how to play right at the start of the game, this tutorial is accessed right from the main menu, taking its time in a special training environment, teaching the basic concepts without worrying about the player flying off somewhere because, well, he can’t. So, hopefully, the new tutorial will make the learning process smoother for new players.
Another thing that is different is that the new tutorial is split up into several distinct modules, each module focusing on a limited selection of concepts and ignoring all the rest. This is good, because it means that our fledgling, ignorant player-in-training can revisit specific parts of the tutorial without having to sit through the whole thing again.
At present, six tutorial modules are coded up. These are: Basic operation, Interstellar Flight, Communications, Basic Combat, The planetary screen, and Missions and events. A further two, Advanced combat and Trade, will eventually be added. I say eventually, because both combat and trade are parts of the game that are in for a serious overhaul. Writing tutorials about them now would be pointless.
Most of you will already know how to play the game, so a new tutorial won’t help you much, but hopefully this step has made Naev that much more accessible to new players.
As a good sign of what’s going on, all changes have been merged into master and development is now going to be done there. Some stats on the change:
naev: Edgar Simo master * rc7d316d / (9 files in 3 dirs): Merge branch 'balance' of git://github.com/Deiz/naev into tutorial (+1161 more commits...) - http://bit.ly/fmcrdB
As you can see it’s a pretty big change. I’d consider it a new game. Anyway, on the 0.5.0 beta we’re waiting on finishing the new tutorial and then we’ll do some quick check ups and code analysis before the release. This won’t be the official release, just a beta as it’s still buggy and such. However it does give a change to get some mass testing done to get a nice polished 0.5.0 release. So after over 1000 commits and 100k line diff we are finally nearing the awaited 0.5.0 release, albeit with like a 3 month delay of the original goals, however this release is so ambitious I believe it’s totally worth it.
It has come to my attention that numerous people become dizzy while playing Naev. As it is to my interest that no physical discomfort happen while playing Naev I’ve dealt with probably the first cause which is the zoom. While the zoom is nice to have automatic (and you can tweak it’s behaviour), it seems like it can make people dizzy. So Naev now has an option to enable manual zoom. It is controlled by mouse wheel, however I’ll probably add key bindings in the near future.
Location of the checkbox to enable manual zoom.
This is a start. If anybody experiences dizziness still with Naev 0.5.0 I’d be very interested in feedback and investigation into what exactly triggers it to try to solve the issue.
As part of our move to become more independent from Google’s services, which should allow us more flexibility and comfort, we have decided to host our own wiki. This wiki will allow us to organize proposals, todo and overall design considerations by centralizing them. This does not make either the forums or the mailing list obsolete, but complements them. It’s not fully fleshed out yet, but it is already far superior to the old one. If you are interested in Naev and would like to contribute to the wiki, feel free.
One decision we have taken on the wiki is that we do not want every planet to have it’s own article. The wiki should focus on general information for both developers and players, without recording individual details. So, while the Empire faction gets it’s own page, the planet Em 5 does not. As with all wikis, we ask that you please do not add stuff you would like to see in game directly without getting the approval of a devteam member. However, you are completely free to write a proposal and submit that for review. You are all welcome to use the Naev wiki, let the editing begin!
Today we’ll talk about the name of this game: it’s history, pronunciation and how to write it. First off a bit of history, as you probably do know, NAEV originally stood for “Neutron Accelerated Extreme Velocity” although “Not Another Escape Velocity” was also widely accepted. The original idea was to sort of create an improved clone of the original Escape Velocity game. However with the 0.5.0 release we will transcend that. Naev is no longer a clone and therefore no longer an acronym, it is now a proper noun. So from now on no more NAEV, only Naev! You may notice I have been changing that, this unification of criteria will make it easier to handle and no longer cause confusion.
Now onto pronunciation, how is it pronounced? In case someday we hold a Naev meet or the likes we should all know how to pronounce it so we don’t make a mess and fools of ourselves (we probably will anyway). The proper way to pronounce Naev is /nɑ.ɛv/ if I got right my symbols (would need confirmation). I know most of you pronounce it more like knave, but trust me, that is wrong.
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.
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.
Empire Hawking shooting a Llama showing ewarfare turret tracking.
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 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.
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:
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):
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:
So we can write the composite form as:
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 ). 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:
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, . We’ve found that a good value is .
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 .
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!
). 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?
. We’ve found that a good value is 
.
Recent Comments