I'm considering giving a shot on connecting a Gamestudio app with a JVM through JNI. I'm looking for someone here, who has some experience with JNI in general to discuss this topic.

Best regards,
-Chris

If your goal is to use Java on the Webserver as GameServer,
you can use either http, TCP/IP or UDP commands for the communication.

I had a basic Java-Gamestudio multiplayer system running using a UDP plugin
from nfs42.

Other plugins also offer HTTP support.

No, I want to mirror the current state of all engine objects and global variables into a pure, thoughtful object orientated approach in JAVA. This way you can take the benefits of JAVA on a very high abstraction level and all game engine synchronization is done in the background.

Basically, with JNI you can 1.) invoke a JVM from inside a native application (C, C++, etc.) or 2.) run a JVM and invoke from there native code. I think it is possible with a Lite-C stub, a DLL and careful designed packages along with multi-threaded concurrent active classes.

so basically you want to do an engine wrapper like i did for python?

i would look into a wrapper generator like SWIG.

Yes and no. I want to take the C style engine interface and put it into a class hierarchy. Like an abstract entity class with concrete classes Model, Sprite, Terrain, Level, etc. with their type specific attributes and methods. E.g. each Entity has a filename with is then an attribute like e.g. private String filename; which is accessible via public String getFilename(); or else. So need for ent_for_file for instance. Or I want to abandon ticks. Also, all types are primitives and automatically converted to var when synchronizing the virtual OO-engine state in the JVM with the real C-engine state. A lot of stuff can be simplified then, especially arithmetics (vectors!), behaviour, event driven interaction, software patterns, real data and method encapsulation, containers, etc.

My basic idea (which is the reason why I am thinking about it) is to create an Actor class which is an active class (an agent) which inherits therefore from java.lang.Thread and can use a collection of Entity objects as represenatives -- I really don't like the (fundamental) idea (of Gamestudio) to connect code directly to a resource like a model. An actor can be build from a model, from several models, or a map entity with some particles or whatelse but these are only the visualizaion of the actor. So, in my opinion, you have to use ideally some sort of the MVC pattern where you seperate the model (the logic and semantics of your code), the visualization (entities, textures, particles, etc.) and the controller (AI or human input through keyboard, mouse, etc. and also visualization control, like animation, effect invocation, etc.).

So, ideally you start your Java app and from THERE the engine gets invoked and communicates with the acknex package through polling and/or some sort of memory pipes. If that doesn't work, I suspect to provide a small C++ template for compiling an exe that invokes the JVM and initialized everything needed for the sync. So, the C++ stub work as some sort of a mediator.

I don't get the principle of SWIG - I don't want to --port-- code from Jave to Lite-C (or C++ and used in Gamestudio), I want to mirror the game engine state so that I can alter it in my own custom Java app and the it gets reflected back into the A8 engine.

Ideally in the end the developer just does a package import like

import AckJava.*;

compiles -once- his JVM invoking personalized EXE (so that it matches his/her licensed acknex.dll) by loading a VS project file and pressing compile and then you can write your whole game in JAVA with the public static void main () as entry point.

So basically a wrapper?

SWIG is just a tool that saves you from manually writing all the cumbersome JNI stuff. SWIG is the only one i know for java but maybe there are other similar tools.

you need an engine wrapper (no polling or something like that). above a SWIG generated wrapper you could do another layer in pure java with your wanted oo design.



my python wrapper is oo too but much simpler. i often find oo like java programmers tend to do very overengineered.

A Wrapper library consist of a thin layer of code which translates a library's existing interface into a compatible interface. So, no, I dont want a wrapper. Or simple delegates. I want some sort of an active mediator.

Example:

When I create a new Entity object in JVM, the "wrapper" needs to create that entity in the engine by ent_create. But if the entity is modified inside the engine (e.g. through physics, because the lifetime of a particles expired or a level is loaded with sub entities), this has to be reflected in the JVM hierarchy (creating or deleting representative classes).

So it is a wrapper for both sides of the medal, because both sides are active. This mediator passes actively instructions from JVM to the engine (called by the user code) and from the engine to the JVM (invoked or reasoned by the engine). It passes, mhhhh, more like some sort of messages. JVM says: move that entity! Engine says: moved it, but it stuck at XYZ. Mediator says to JVM: adjust that entitiy coordinate to XYZ.

So, this is not just about wrapping the engine function interface. So this is not a wrapper.

@Vent: I think the opposite: most C++/C programmers tend to spoil code ;-) but let us not discuss on the C++/JAVA thing. These are two totally different languages with very different aims and language design choices, so it is everyones right to like one only or both ^^

hm... that's exactly what a wrapper does. that's how my python wrapper works and that's how the c# wrapper by stromausfall works.

how thin your wrapper is, is up to you.

Convinced. I owe you now another beer. They are now 2.

OK, I want a wrapper ^^ for the sake of precise terms!