Theory of a framework

I was away from jME for about 1.5 years and worked with an MMO kit i.e. a framework which gets you started quite fast. Beside some advantages of that framework there were some showstoppers and that's the main reason why I'm back to jME.

The last weeks I spent with finding out what's new and restarted my MMORPG project with jME.



I really appreciate what I see but there is one problem I face now: That's how to add all those bits into a big picture and keep the code maintainable and the performance at a reasonable level.



The pieces I want to use are: jME2, StandardGame and GameStates, JGN, FengGUI, texture splatting and some features: dynamic terrain tile loading, first-person perspective and mouse look, switching between relative and absolute mouse with custom cursor shapes so that the GUI can be used.



This works more or less but the code is not really easy to maintain and the performance could be better. Currently I have a problem with the custom cursor shapes and I think it's time to review the overall approach and design.

Darkfrog pointed me to GameControls which could further simplify the code but I wonder how it fits in so that the GUI and the mouse switching are still working. That means I'm back to question one: How should a game be designed so that all the pieces work together?



At this time I wish there would be a kind of framework ( without the disadvantages of course :wink: ) but I can understand that jME is much more general so that the reusability of such a framework is questionable.

A theoretical framework i.e. the design and the connectors of above mentioned pieces would help. I don't expect ready to use code - I know you're all busy with your own projects. But I'd appreciate some design ideas and I could put the result to the wiki. I think there are more out there having a similar problem like mine.



The current state of the project in question is on googlecode (http://code.google.com/p/worldofmystery) and you will see why I call it messy when you take a look.


Welcome back galun



As a sketch, I visualise the application of layers or Facades, being 3d world ( jme ), gui ( Fenggui ), client application and data. between these are adapters to facilitate state change.



I just use mock singletons or concurrent queues with tasks to bridge these facades. It means that the gelling of the layers are dependant on interfaces and not on implementaton.



For instance, some fenggui components however may be state related to game entities ( eg a players health bar ), and it is how the appliaction

a. knows when to update the health bar and

b. how to update the health bar



There are some java design patterns I use for this, namely reactor, observers and singletons. It could even be done as an MVC.



Designing a framework is straightforward when you know exactly what you want it to do and the requirements are fixed, but this isnt real world as we often find features that we wish to add as we realise them throughout the development lifecycle. Therefore the most important thing imho is just to get it working then to spend time refactoring and cleaning up.



It was either Hevee or Hamsterofdeath that posted about everything being an entity in the 3d world which is identifiable and interactable. I go along with this approach and define all client server state objects as Products, all parent jme components are Nodes and an Entity is an interface that bridges the client server data world to the jme world.



as a guide here is the class Entity



public interface Entity {

   public EntityKey getEntityData();
   
   public Node getNode();
      
   public boolean isAnimatedEntity();
   
   public Product getProduct();
   
}




public class EntityKey implements Serializable{

   // ? should this also hold reference to map and block??
   
   private int uniqueId;
   
   private int x;
   private int y;
   private int z;
   
   private int xRot;
   private int yRot;
   private int zRot;
   
   public String name;
   public ProductKey productKey;
      
   public EntityKey(ProductKey productKey, int uniqueId) {
      this.productKey = productKey;
      this.uniqueId = uniqueId;
   }

   public int getProductId() {
      return productKey.getProductId();
   }

   
   public int getProductTypeId() {
      return productKey.getProductTypeId();
   }

   public int getX() {
      return x;
   }

   public void setX(int x) {
      this.x = x;
   }

   public int getXRot() {
      return xRot;
   }

   public void setXRot(int rot) {
      xRot = rot;
   }

   public int getY() {
      return y;
   }

   public void setY(int y) {
      this.y = y;
   }

   public int getYRot() {
      return yRot;
   }

   public void setYRot(int rot) {
      yRot = rot;
   }

   public int getZ() {
      return z;
   }

   public void setZ(int z) {
      this.z = z;
   }

   public int getZRot() {
      return zRot;
   }

   public void setZRot(int rot) {
      zRot = rot;
   }

   public int getUniqueId() {
      return uniqueId;
   }

   public void setUniqueId(int uniqueId) {
      this.uniqueId = uniqueId;
   }

   
   
   
}



Product is a class that is obtained from factories by speciyfing the productType ( eg Weapon = 1 ) and the productId ( eg SmallShortTitaniumSword = 45645 )

Hi galun, you might be interested to check out the Data Driven Game Architecture from perick: http://www.jmonkeyengine.com/jmeforum/index.php?topic=6980.0



It combines injection framework with component based design. Perick created various Components to achieve a composition approach (car owns physics) instead of inheritance (car extends physics).



I had a deeper look at the code and find that the same composition approach can be achieved by simply using GameStateNode trees rather than custom Component classes. And since GameStates don't necessary have to contain any rendering logic, there won't be any unnecessary overheads.



A injection framework would be quite useful though, ideally the ultimate gaming framework should allow plug and play components such as GameStates, GUI, Networking etc all injected without hard coding. But i think would be quite a challenge to have something as generic as that.

I am using AspectJ very heavily recently for another project, but intend fully to use it on my next game project…I never really understood how powerful programming in aspects and using pointcuts could be in your application.  It also helps that AspectJ lets you do things that Java by itself absolutely cannot do.

darkfrog said:

I am using AspectJ very heavily recently for another project, but intend fully to use it on my next game project....I never really understood how powerful programming in aspects and using pointcuts could be in your application.  It also helps that AspectJ lets you do things that Java by itself absolutely cannot do.

I checked out AspectJ briefly but it seemed to me as a more beneficial addition to business software writers than to game-developers. Could you perhaps describe some situations where you could make use of AspectJ when developing a game?

Well, I just recently created a new API with it called "Magic Bean" that allows you to listen for changes at the field-level or method-level on standard beans:


                Person p = new Person("Test", 10);
                MagicBean.addChangeListener(p, "age", ChangeType.FIELD, myChangeListener);
                p.setAge(20);



What you see there is all you have to do to add change support to the Person bean.  Even if you have a method like:

                public void makeThirty() {
                                this.age = 30;
                }



That modifies the field directly and will still throw an event.

Further, I've added bean-binding support as it should be (not like the crappy JSR that is out there).  To bind two fields on a bean:

                Person p1 = new Person("Test", 10);
                Person p2 = new Person("Test", 10);
                Bind.bindBeans(p1, p2, "name");



No any time the "name" field is changed on Person in either bean it will update the "name" field on the other bean. This does not use polling so you're not dragging down performance when nothing is going on and requires no change to your beans at all.  In fact, you can listen for changes to fields on built-in JVM classes.

There's a reason it's called Magic. ;)

http://magic-bean.googlecode.com

Read more up on AspectJ and you will be amazed at what it can do.  Specifically for game development I would expect Magic Bean on its own would be extremely useful, but AspectJ as a whole has many benefits to simplify and modularize your code.

This sounds very intresting and userful.

I must have a look at this.

Magic Bean sounds awesome! One question though: does it rely on beans having PropertyChangeListener support built in manually, or is that also done "by magic"? I guess this is what you actually need AspectJ for? Or is that even a requirement?

(OK, that wasn't really one question, and I know it!)

hevee said:

Magic Bean sounds awesome! One question though: does it rely on beans having PropertyChangeListener support built in manually, or is that also done "by magic"? I guess this is what you actually need AspectJ for? Or is that even a requirement?
(OK, that wasn't really one question, and I know it!)


It comes with its own compiler - so the actual classes created may not be as a developer would naturally expect. try decompiling one of the generated classes and take a peek..

They must be compiled with the AspectJ compiler, but you can pretty much think of it like your normal JDK with some extra awesomeness attached.



The beans require NOTHING special at all, which is the way it should be.  You'd think the stupid JSR 295 would have come up with a less crappy solution than they did…it was that which drove me to write an alternative.  No, it's not perfect because you are stuck having to compile with AspectJ (or you can use the runtime JARs, but that seems like a lot more hassle to me), but unfortunately I think that's the best we're going to get until Java provides language-level aspect support or at least listeners at the method/field level.