Game Mechanics

[Jochen Stier]

I I have stated working on the editor and the internals of the graphics engine again. Most importantly, I changed the way the matrices and bounding boxes are handled and at the same time improved the manipulators provided by the editor to move objects around. Changing the matrix structure had a lot of implications on different parts of the engine and while I was changing the code I made various other improvements. I found out that in some cases occlusion culling wasn’t working properly and now that it’s fixed there is a small performance improvement as well.

One of the main results is that it is now easier to build object hierarchies. A simple example is a shuttle with missiles attached under the wings. The missiles are their own physical bodies, but if you are moving the shuttle with the editor, for example, the missiles should always move with the shuttle. As you are flying away, the missiles should also remain attached and only be become active once you launch them. Then, they should move completely independent, but with the same initial velocity as the shuttle had at the time of launch. I think that most physics engines support this feature using fixed joints. I was thinking of doing it the same way, but then decided otherwise because of the problems this will cause with the network latency and the client prediction. Now, the missiles will not become their own objects until they are launched. The disadvantage is that they can’t break off should they collide with another object, but that’s probably not so important. In the tree view of the editor objects are attached to other objects by making them children in the hierarchy. This means that we can now design a shuttle by importing mesh and textures, writing a shader and then adding different weapons by making them children of the shuttle.

My first inclination was to use Lua script to launch the weapons by adding keyboard sensors, but I decided to code all the logic in C++; it is just more efficient. This means that I have to develop different classes of systems, such as shuttle, vehicle and avatar, but we can still attach different weapons. Each class responds to a set of keyboard events and then launches the appropriate weapon if it is available; of course, a shuttle can also be out of missiles. Re-arming a shuttle would then happen through a Lua script function which takes weapon and slot on the shuttle as a parameter. By re-arming via Lua script, third parties can use the editor to develop custom stores with different user interfaces from which you can acquire, fix or steal weapons.

Another aspect I improved and made more robust is the passing of objects between different physics spaces. This is a really important feature in ensuring seamless transitions between planets and large space stations or ships, and a key motivation for Geist3D to have its own physics engine. A physics space is a standalone version of an environment with bodies and geometries including a quad tree, jacobian solver and gravity. Objects in different spaces have no knowledge of each other and cannot collide. The advantage of different spaces is mainly performance, but it also creates a natural border between different servers. Physics spaces, however, will overlap and it must be possible to pass objects between spaces. This is already happening right now when a shuttle launches from the planet and flies towards the space station. Once it gets close enough, it will leave the planets’ space and enter the stations’ space. At that moment, the gravity changes and the shuttle can collide with the station. This functionality allows for some amazing effects. Imagine a battlestar galactica type of space ship flying upside down through the atmosphere of a planet. The avatars inside the spaceship will still be firmly rooted with their feet on the floor while having to look up to see the planet. Yet, if they decide to jump out they are eventually caught by the gravity of the planet and begin to fall towards the surface. Long story short, I have tested this transition again today with several nested physics spaces. As you may imagine, there is a lot of math involved in this transition. In order to make it seamless, you not only have to transform the position and orientation but also the linear and angular velocities. Long story short, today I would do much better than a ‘D’ in my linear algebra course.

I will now continue to create a shuttle with functioning weapons and a cargo bay into which an avatar can walk. As part of this, I will reuse the particle system which I made for the exhaust of the missile to create explosions. The goal is to demonstrate the ability to fly over the planet and launch missiles; upon impact with the surface there should be an explosion. I will have to tackle the problem of how to detect a collision with the surface of the planet and a missile. Stay tuned…

[Jochen Stier]

Here is a YouTube video of a missile launch

http://www.youtube.com/watch?v=bgDUp1DwoMg

[icemaster]

PoYqgN  rcrxdvkwlwkc, awymjcoqdkvh, [link=http://nkvelfhnbllp.com/]nkvelfhnbllp[/link], http://ujtedjdvploe.com/

[Jochen Stier]

I have been working on the dynamics of landing a space ship on the surface of a planet. Since the planet is generated by a noise function it becomes expensive to compute the exact shape of the terrain below the spaceship. So, I basically just sample the surface at three points around an object and then create a plane against which to perform collision detection. This works rather nice, but it causes some strange artifacts such as the shuttle penetrating the terrain or vice versa (left image). This problem becomes even more pronounced on an uneven surface, especially where the features are smaller than the size of the shuttle. So, the conclusion I came to is that space ships can only land on flat surfaces (right picture). In order to enforce this, I have come up with a sampling technique that will be used to determine how uneven the ground is. Depending on this metric, the spaceship will take damage. If the ground is too rough then it will get destroyed very quickly. I am quite happy with this approach. It will make for some interesting game play. Very large ships that may transport a lot of cargo can only land on certain spots; maybe not at all on some planets. Of course, there is always the possibility to construct a landing platform, where ships can safely land without taking damage.

[Tamarin]

That sounds like a reasonable solution. Even with a helicopter you still need a flat area to land.

[Jochen Stier]

Yeah, what's the angle that a helicopter can savely land on. what about an airplane ? How is the forward velocity related to the angle that you can land on. I don't need exact numbers here but just a general idea. I want to take the three sample points I talked about earlier to compute the slope of the terrain. Then I want to sample the terrain again in the center of the triangle and compute the distance to actual surface. This will provide a measure of the roughness. The slope and the roughness will produce a measure that determines the damage on the vehicle trying to land or move across the surface.

Building this concept into the software will be realtively easy. Determining the right parameters for each vehicle will be the hard part.

J

[Jochen Stier]

Are you talking about the faster the airplane goes, the smoother a place to land it needs?

I am not quite sure I will have more questions when I start to compute the damage for the shuttle.

Actaully, I never tried to push my limits, but I believe its around 8-12 degrees from flat either way anymore and it would have a uneven airflow and do a spin of death.

Ok, I'll keep that in mind!

[Jochen Stier]

I just added a node type and a shader for a defensive shield. It’s quite a general widget that could be used around ships, static structures or even avatars. A parameter to the shader is a force variable which is used to activate the shield in the appropriate direction and proportional to the force. When a weapon hits the shield it will only light up shortly but when the shuttle flies through the atmosphere, the force hitting the shield is basically the air resistance. Thus, the faster you go the more the shield lights up. I used some noise and colors to give a retro look. Just with most of the other stuff, there is lots of room for improvement, but I decided to give it a real development push now and add lots of features. Later on I will go back and make things look better.



Next in the pipeline is engine exhaust trails and laser cannons.  I want to get everything in place to make one complete shuttle.

[zachzab]

These look great! But I think that the slower you're going, the more the shield is concentrated at either the front or close to the front. Because if it just gets thinner it looks a little weird.