YASS-Engine.de http://www.yass-engine.de/ Serving with news about YASS development since October 2007. (Still with missing features) en-us News: YASS @ Google+ The official ‘Yet Another Space Shooter‘ Google+ page is online!


Development: Vacation Last month we met in a vacation home for 2 weeks and spent a good amount of the time working on YASS. The original plan was to release a new version to the public at the end of the 2 weeks. Unfortunately it was simply too much work, so we didn‘t quite finish it. Nevertheless we got a lot of things done in that time, so here is what we accomplished in a nutshell:

  • Lighting: As you can see on the latest nightly the lighting improved A LOT!
  • Vehicle physics: A complete rewrite of the vehicle physics concludes the update to PhysX 3.0. Driving the car feels really good now and is not comparable to the previous physics model.
  • The freighter in orbit has been completely furnished, with sanitary fittings, captains quarters, engine room and so on...
  • A lot of bug fixings: Things that were broken or did never actually work are now working, like landing on the freighter, jump the freighter into Saturn orbit, take the elevator to the hanger deck and leave the freighter with your fighter and many more...

These are just some of the improvements we implemented. Hopefully we will pack everything together into a new release in the not to distant future for you to check it out for yourself.

News: YASS @ YouTube There is a brandnew YASS gameplay video available on YouTube, you can watch it here:


Further videos will follow to give you an overview of the current state of development. Soon you‘ll also be able to watch them directly from this site.

Development: Elevator We now have a working elevator on board of the freighter. So it is possible to land with your spacecraft on the freighter hangar deck and take the elevator up to either the machine room or upper deck where the bridge is located.
No need anymore to switch to spectator view and ‘teleport‘ to access other areas of the ship.

Development: Water and Sky Thanks to the Hydrax and SkyX Plugins for the Ogre engine we have now appealing visualization of water and sky in YASS.

Water is rendered with 3 dimensional waves, reflection and refraction shaders, godrays, caustics and other nice visual effects. You can swim and dive in it, but if you‘ll stay underwater for to long you‘re gonna drown.

The SkyX Plugin comes with complete day and night change, moving sun and moon, volumetric clouds and a starlit sky during night.

Integration is not finished completely yet, but you find a first impression on the latest nightly screenshot...

Development: Testing another Z-Buffer Happy new Year!

With the recent addition of the HMS Fearless, the huge, galactic order ensuring military command platform (prominently shown in the right picture), one not yet solved issue became more apparent. With the very long visible range there is the problem of rendering intersecting geometry. This is usually solved by using a Z-Buffer. Simplified speaking, when a pixel is rendered it‘s distance is stored alongside in a bitmap (the Z-Buffer). When another pixel is about to be rendered at the same position the decision to keep the first or take the second computed pixel can be decided by e.g. taking the nearer pixel.

As always, things are not that simple. I don‘t want to go into too much detail here, but the precision of the Z-Buffer is limited and the usual implementation has very high precision with near objects and loosens more or less quickly with further objects. This can result in visual artifacts, known as Z-Fighting: objects, which should be solid, flicker and possibly overlap each others. Usually these errors are not noticeable when there is a decent view range. However, we need to push it to the max. Especially for the Fearless, which is approximately 3km in length, as it is visible from far away. When you look very closely on the first image, you can already see some Z-Fighting with the "fins" at the center top. The intersection with the main body is not well defined, but is grainy and flickers when in motion.

To solve this, the formula which maps a depth value of a pixel to a certain value of the Z-Buffer (a 24 bit integer in this case) can be adopted. As discussed by cameni on his gamedev journal a so called logarithmic Z-Buffer can easily be used by using shaders. This implementation sacrifices a bit (though: not noticeable) precision with near objects and gives it to the objects further away. With the image on the left you see the results, which are visibly free of z-fighting artifacts. The still occurring artifacts, indicated within the image, is a two seat table placed intersecting the rocket launchers.

This is a prototype, however. To fully use this, the whole engine needs to discard the fixed function pipeline, so that all objects share the same Z-Buffer implementation.

Development: Artificial Gravity It is now possible to walk up to the bridge of the freighter and take over the control of the EECOM console on the left side of the bridge. There you can justify the artificial gravity on the ship to any level in a range between one and zero g. It is a lot of fun to switch to zero g and float to the next room where the snooker tables and lots of other stuff are located. You can mess around with ‘em and push ‘em around and such. As you can see on the latest nightly shot as well...

And of course a merry christmas to all of you!

Development: AI Enemies There are now several enemies spread over the island. The moment they see you they stop moving around and move directly towards you. When you shoot at them they get angry and move even faster. You should neutralize them before they reach you or else they will attack you with their tazer weapon...
That might not be the cleverest enemy AI, I grant, but it is a good start all the same. ;-)

Development: The epic quest of Ogre The last few days were like a blast. Coding nine-to-five and five-to-three, we made a lot of progress and ate too much fast food ;-)

With a fresh and new SVN branch we removed all Irrlicht 3D rendering from our engine. The first steps, as you can see on the right picture, where pretty much Ogre infested. So, two programmer hero‘s and one artist hero stepped bravely against the overwhelming army. There were some casualties and several injuries along the way.

As time passed, more and more heads rolled and the peaceful lands known as "Surface Earth" were cleaned of the infestation. The losses included some texture assignments and rotations. But the (imho) meanest enemy, converting of somewhat-right-handed-coordinate-system (yass engine) to a left-handed-coordinate-system (Ogre), was conquered today.

The planetary rendering system and the particle system are currently dead, as well as the trees and animated characters and other stuff I repress currently. Now it‘s time to move on. So much still to do :)

News: Forum registration disabled Today we encountered the most serious spam attack so far. Over 100 spam users posted nearly 1000 spam posts in a very short period of time. I hope there hasn‘t been any collateral damage during the cleanup process. We will enable forum registration again as soon as we update our security measurements.

Development: The quest of Ogre As some of your might get the idea, that this project is a bit slowish, I can assure you that some heavy modifications might be around the next corner. We are currently thinking about a switch of the graphics engine we use.

Some of you possibly know that we are using the Irrlicht Engine for rendering. This is a very fine engine with a clear, straight forward and easy to understand API (imho). This is just perfect if you want to start coding some 3D (or 2D) stuff and are not too experienced, but also for some serious applications. Several games and other applications have been published using this engine and the results are awesome [you will also find some prehistorical pictures of YASS on one of these pages :-) ].

The drawbacks are, that some more advanced techniques of 3D rendering are not included in that engine. As one of the skilled shader guys from the Irrlicht forum (omaremad) put it: "If you want modern rendering techniques learn how to make them or go to the engine next door".

Seriously, we are considering the latter. Which is, for example, Ogre. We hope to get these nice modern rendering techniques (e.g. shadows) with (more) ease by switching to Ogre. Also, we do expect a better performance by using this engine, which could be considered even more matured than Irrlicht. Several games, which are published internationally, where shipped using this engine. Some of the studios, which used Ogre, where gracious (read: knew their debt) and donated money to the project (please correct me if I‘m wrong, I have this only on loose memory). With this, the engine matured faster than Irrlicht.

We are still in the process of analyzing if this switch of the graphics engines is a good idea. If you want to follow that discussion, you can watch this forum thread.

If you have some experience of a (successful or unsuccessful) switch from Irrlicht to Ogre, please, let us know!

Development: Aircraft Control I implemented an aircraft control to make it easier to fly around in the earth level. When you are flying a spacecraft suitable for atmosphere flight, you no longer have to struggle with 6 axis to fight against gravity. The airfoil produces lift to keep you at altitude. Even though the lift and drag calculations are based on physically correct formulaes the flight experience is somewhat arcadeish and lots of fun. :)

News: Revision 11 The first update of the development release includes several bugfixes as well as some completely new features. The highlights are: You can now talk to the AI characters which are running around in the earth surface level and you can also shoot them whereupon they will react appropiately. In addition to that there are some speed improvements in this release due to compiler optimization and the usage of multiple threads for level loading.

In detail the changes are:

  1. new AI (built from scratch)
  2. speed improvements due to compiler optimizations
  3. added multi-core support for texture and mesh loading
  4. grass added on earth surface
  5. fixed a bug that prevented the AI from being shot
  6. fixed character transformation when a control is released
  7. fixed shooting range issue (shooting from inside the building)
  8. removed crosshair in game menu

Development: new AI built from scratch I implemeted the new AI library I am working on for quite some time now. Now the AI isn‘t just walking around randomly, but you can also talk to it. You can also shoot at the AI and it will respond properly, for now it is just running away from you as fast as possible... ;)
You can change the behaviour of any AI by just altering the scripts that define its behaviour or give it a complete new set of scripts to create an unique AI of your own.

Development: Gentlemen, start your engines! The next update, which will probably make it in the next month, will include some new features, like a completely new artificial intelligence and possibly grass (if I get the lighting right). But this post is not about this. It is about some performance improvements.

Due to a nasty and quite well hidden bug, we where not able to release an "optimized" version of the game. So, to all compiler nerds, before: without /Ox, now: with. To the others, which probably think we torture castrated male cattle even more by forcing them to optimize our game: the compiler can do some pretty tricky stuff so that the CPU does the same as before but with less instructions. However, due to that mentioned bug, some of the collision models where not created with the optimized version and therefore the game was faster, but unplayable. Interestingly, this same error, which was in our code, was in the code of several other people, which use the PhysX engine. This leads to the conclusion that this is also an error in the PhysX example code...

So, optimizations: ON.

But, that‘s not all. With an idea from the Irrlicht forum, I managed to load most of the needed textures for a given level in a separate thread, which I thought was nearly impossible without modifying this 3D engine and making it thread safe. In addition, only the nearest and needed textures are loaded*, thus decreasing the level loading time significantly. (*: textures are not unloaded, though).

So, threading: ON (at least for loading and planet and grass rendering).