FlyingGuns needs YOU!

So much things changed … e.g. Java3D has shader support now and FlyingGuns has particles … anybody?

Also like to discuss things like distributed dynamics, GUI, engine abstraction, …

Need you to do what exactly? To participate on the full game dev including all levels etc.?

There is a wide field of possibilities. But setting up shader usage for the FG particle system would be one.

The Java3D guys asked me to do so. In this case, they’d shown FG at JavaOne. But I’m afraid, it’s too late now for that.

Generally caring for the 3D stuff can be a nice field for someone interested in that topic. FG looks a bit old-style and could need some polish.

Another current topic is 3D engine abstraction, which would allow to replace Java3D e.g. by Xith or jME.

How much engine abstraction do you want ?

Switching an entire engine would be hard and i don’t really know why you would want to do that. The java game engines i know currently in activity, xith, jme and agency9 all have a renderer class sort of that allows those engines to switch between one of the opengl bindings or just use a software rendering api (correct me if im wrong). This is a sort of abstraction.

Another type of abstraction is scene-graph abstraction. In this case i don’t know of any Java engine thst does this except perhaps xj3d (through x3d) that isn’t really a game engine. If you really want the maximum of abstraction possible build a game engine that reads x3d (with the extensions for suporting shaders) and let your game be truly data-driven.

You don’t need to do this the way xj3d does (interpreting a set of x3d files). A more flexible way would be to create a x3d to java source translator then compile the generated java source. You could have different translator variants to translate to different engines.

Thats my sugestion.

NOTE: Blender has a nice x3d exporter, something also made opengl and jogl exporters for blender. If you know something about Blender and python you could consider making a blender exporter to your choice of engine source code.

OpenGL abastraction or such are far too low level. FG doesn’t even has interfaces to that level.

Scenegraph abstraction would be extremely difficult due to the rich set of functionality and classes. This would be a lot of work just leading to the least common denominator. And FG doesn’t really rely on the engine to be a scenegraph. It fits well, but a SG isn’t mandatory at all.

What I have in mind is application level abstraction. Thus the interfaces will be ‘Terrain’, ‘Airplane’, ‘Tank’ and such. The abstraction should cover the complete 3D world including collision detection or picking.
I think that is approximately the abstraction level seen when going from CounterStrike to CS source.

The reasons to do so are manifold. First, I’d like to stick with Java3D (a) its already there, (b) I wanted to stay as Sun-friendly as possible relying on industrie standards and © keeping the way open towards cave rendering and such. The idea behind that is that FG isn’t too much of a game but also reaches out for areas like simulation. OTOH, jME or Xith3D seem to be much more suitable for a game. We had a rough port to xith once and all of the sudden had a smooth and highly performant game. But even a native OGL-engine would fit easily under that hood without influencing the rest.
Maybe more important: this level of abstraction also allows for an ‘engine’ that can run on the server (FG is a network thing!).

My personal problem today is that there is not much time for myself to work on the project. I have a job (that sucks) and a sparetime job to buy my family a nice vacation trip. If I had time, I’d like to focus on networking, architecture and physics. So at least the complete 3D part is vacant …

I hope you find someone to help you. I’m not skilled enough yet at that programming level. Also consider data-abstraction. This is usually side to side with the kind of architecture you are thinking.

Sure.

There will be a engine-level database specific to the formats of the engine (e.g. with 3DS-files for Java3D).

Then there is a game-level database describing the scene, roles, behaviors, …

The two are connected by the means of the HeadQuarter identity system.

Update: help still needed and warmly welcome!

The abstraction layer mentioned above made good progress. People interested in pushing that forward or those finding their challenge in pluggin in other renderers (Xith3D, jME, JOGL) are welcome.

Other options like creating cool effects with GenesisFX arised lately.

And theres still alot to do in all areas of programming art: network, architecture, gameplay, graphics, sound, web, database, …

Currently I’m working on the integration of the TrackIR headtracker.

Sounds good to anybody?

  • J

A xith3d frontend would be interesting… Are you really wanting it ?

Yes, definitely!

If you like to evangelize Xith3D this also would be a great opportunity for the new abstraction layer is ideal for benchmarking :slight_smile: