http://www.flyingguns.com

This is a 'serious gaming' platform that exists since 2003. Many ideas, but its being idle until someone wakes me up again.

http://www.flyingguns.com uses Starfires 3DS loader successfully.

If you like, I can give further hints where it is actually used in the source tree. Look for 'scene3d' project as a small-scale example.

all I can offer is http://www.flyingguns.com .... although I won't call it a 'quality game', if 'game' at all

Blogged about an example usage:

http://weblogs.java.net/blog/herkules/archive/2007/10/wyliwyt_where_y.html

TrackIR is a affordable head tracker which is quite popular esp. in the simulation games area.

I created a Java binging in context of the FlyingGuns project that can be used standalone as well.

Some more detail is here:

http://weblogs.java.net/blog/herkules/archive/2007/09/head_banging.html

I started writing a dynamics framework with flight simulation in mind. Quite different from JOODE or ODEJava for it does not resolve any collision conditions. It's more a simple framework allowing a body to react on forces/torques.

Some more detailed information can be found here:

http://weblogs.java.net/blog/herkules/archive/2007/09/a_simple_physic.html

Hi!

Maybe some people noticed the project FlyingGuns before. FlyingGuns is a distributed simulation framework with a WW1 flightsim as a demo. FlyingGuns was using Java3D from the very beginning. Meanwhile I created an abstraction layer that allows to use different high-level 3D engines (see description here).

Now I'm looking for Xith3D experts who like to implement the new interface on top of Xith3D.

This port not also should improve FlyingGuns but can also be used elsewhere, e.g. for Java3D-vs-Xith benchmarks, scripted prototypes, VR etc.

The task shouldn't be *that* complicated for FG only uses basic 3D techniques so far.

Any takers?


BTW, FlyingGuns once had a Xith3D-based prototype which worked extremely well!

I don't have a good answer. Just that creating 2D overlays with Java3D is difficult. The postRender approach is know to destroy performance. So the only way seems to be to do the 2D stuff in 3D as well.

Very cool screenshots!

Is it a commercial product? Or OpenSource? I cannot find it on the webpage ....

Hi!

Here is my jsmooth config file ... does this help already?

http://drts.cvs.sourceforge.net/drts/projects/flyingguns/etc/FlyingGunsClient.jsmooth?view=log

How do you relate your problem to PickTool?

But transforming a vector (e.g. a normal) gives a vector again, transforming a point gives a point. It just has to be kept consistent, which also is the original cause for this question.

I don't think its stupid. E.g. does Matrix4f uses different code when transforming a Vector3f and a Point3f of course. This alone is enough reasoning behind it. For a vector, only the rotational part is applied (e.g. for normals) while the full matrix is applied to a point that describes a position in space (resp. position in a reference frame).

Without that distinction, you'd have to care yourself and be very clear about what you have. As you said, there are differences, mathematically speaking.

Hm, I see ... although I cannot follow that (0,0) argument, for a Transform3D always describes a position relative to the parent. So it always counts from (0,0) of its reference frame.
Virtially, a 'true' (0,0) never exists.

Taking it another way: in my API I need to place a (game)object. I wonder wether it has to be Movable#set( Vector3f,Quat4f) or Movable#set(Point3f, Quat4f) ? IMHO the same should hold for Transform3D.
 

But it's about the meaning!?

It isn't a vector! It's a point?

Tuple3f would be completely wrong, bc. it has no meaning.

Oh, what a modest approach for a beginner. What about a spinning cube instead?

Then, for a 'simple CS', get acquaintaned with BSP or other PVS systems, animation systems, IK ... and start writing a bunch of good tools (after buying a modeler and learn how to use it).

For this is a Java3D forum, people here are supposed to propose Java3D. Anyway jME is a good choice for a game. Go for that. And take a look at Xith3D, too.

Or take another perspective: what data do you have? Model format? Scene format? Than look for a 3D engine supporting that format. That's the way I came to Java3D (although those days jME and Xith3D didn't yet exist).

Well said! Just my thought.

I'd by so lucky if anybody tried to cheat FlyingGuns!

OTOH == on the other hand

Think of a HUD that you have in jet sims, current horizon, angle-of-attack and so on. These displays have to me smooth.

I'd not call console text to be a HUD, thats just a GUI. HUD is a defined term in avionics.

makes sense

OTOH this would not make a smooth HUD (e.g. for a flightsim) possible, which needs to be updated each frame?

At first I'm asking whether it is correct. If it is not, I'd ask for a change of API.
Clarification is also important for the design of my ingame API, maybe my thinking is wrong.

My point, when you e.g. transform a Vector3f by a Matrix4f, the translational part is not applied. This is useful when the Vector3f e.g. describes a normal. This is bc. a Vector3f describes just a direction and not a point in space.

Applying the Matrix4f to a Point3f, translation is applied.

So:

Vector3f == direction
Point3f == location in space

IMHO Transform3D#set( Quat4f, Vector3f, float ) needs a position in space as second argument, so it should be a Point3f.

And how do you fill your Quads? I found that painting with Java2D and creating a new texture each frame can be a performance drain as well.

Hi all!

Shouldn't it be Transform3D#set( Quat4f, Point3f, float ) ??

The second parameter describes a point in space and not a direction (like a normal or so).

Opinions??

- J

I'm really a big fan of NetBeans and use it every day, but the UML module just is not finished. Pretty powerful, but too many bugs.

FlyingGuns has a simple clock synchronization. Around here:

http://drts.cvs.sourceforge.net/drts/projects/headquarter/core/java/de/hardcode/hq/time/

db4o is GPL, or ask them for sponsorship.

Or try any other like http://odb.neodatis.org/   http://speedo.objectweb.org/

In any case I'd avoid O/R mapping, this sucks so much. Last fallback: Hibernate

RDBMS suck

If you want it easy: http://www.db4o.net

I also don't thinks it's a matter of game size or complexity.

Military simulations e.g. are highly complex and don't do everything on 'the server', which doesn't have to exist at all. Interesting enough that mil. simulations don't care for cheating .

In contrast I think the more complex and the more exact things have to be, the more you have to rely on the client.

Imagine sitting in a fighter plane giving a single shot at an opponents plane aileron from close distance, being sure that is *must* hit the target. You also need visual/audio feedback much sooner than a network roundtrip would allow. In this case, only your client can determine the hit. The server cannot do that for it only has a vague impression of what you see on the screen and maybe doesn't have the detailed mesh of the target for the exact collision bullet/aileron.

All the server can do is saying: 'well, ok, the player still had ammo and their (estimated) relative positions/orientations make a hit feasable'.

Letting the server decide leads to situations where you hit a target over and over w/o giving any harm to it. Depending on the gameplay this can be very annoying. (note: I said 'depending on the gameplay'!)

Hm, after kicking the ball, its trajectory is completely determined until something else happens. So why do you send 20 messages/sec with information everybody could know anyway?

With your approach you are really begging for latency issues and thats what you get.

If you are going like that, you have to improve your smoothing. Never realize a position received from the network. Use timestamps (and a synchronized clock) and treat incoming information as a hint to correct the current path. Remember that all messages from the network come out of the past!

I don't agree 100% with bla. I'd formulate more like that:

'If you have to avoid cheating, never trust the client.'

If cheating is not an issue, trusting the client opens a wide range of options to simplify logic and protocols and save a lot of bandwidth. It often allows for better feedback.

In FlyingGuns, the shooting client analyzes wether there is a hit and calculates the damage. Then it transmits the damage to the targets client. On the targets client, the damage is evaluated and e.g.  makes the target smoke or explode.

This way, no networking handshake is necessary, just a store-forward. Second, the experience is believable, bc. a perceived hit on the shooters side in any case *is* a hit. So no network artifacts show up.

Of course, a cheating client will always win. 

Saying that, concerning your specific questions, I wouldn't transmit the officers state with every bullet bc. that is completely redundant and a waste of bandwidth. I'd share the officers state separately or calculate the damage on the shooting side (if thats possible).

That is an error in the jnlp file, asking for a historic JRE.
I really refuse to install a JDK5.