In this section we describe some technical aspects of our project. For more details take a look at our CVS repository ( code comments are in english ).

Network Engine. ( )

It exchanges messages on top of TCP/IP sockets. The messages are made of two separated parts : data and behaviour. The behaviour is the message's associated code on the remote side. The data part is composed of raw java primitives only. The message sender possesses only the data part of the message, the message receiver posseses the data and behaviour parts.

Main Features :

- client - server architecture.

- different network personalities providing asynchronous message handling, packet aggregation, ping information, etc ...

- dynamic message class loading.


A-star pathfinding algorithm. ( wotlas.libs.pathfinding )

We have an implementation of the A-star algorithm for path-finding. Given a 2 color bitmap mask this algorithm finds the path between two points. The only needed class is wotlas.utils.List which is an adapted implementation of the java.util.Vector class ( adapted for the A-star algorithm for better performance ).We also have developed a simple smoothing algoritm for our Astar.

There is an example of implementation of this library in our CVS repository :  /wotlas/src/test/petrus.


Persistence Engine. ( wotlas.libs.persistence )

Our client accounts and game worlds need to be made persistent. This library allows us to save and restore objects in dot-properties files ( human readable text files ). It is mainly composed of one class, PropertiesConverter, that offers various save and load methods.

To be saved/loaded, a property should only have a public getter and setter and should not be transient ( i.e. if the field is xxx, setXxx() and getXxx() should be public ).

Arrays are supported either with indexed setter/getter or with a global setter/getter (taking an array as an argument), but only one-dimension arrays are supported.


Generic 2D graphics Engine ( wotlas.libs.graphics2D ).

      A flexible 2D Graphics engine you can use in applications that need 2D side-scrolling display. It mainly works around a GraphicsDirector that displays Drawable objects and uses a WindowPolicy to scroll the game screen in an appropriate manner.

      Drawable is the mother class of all the graphical objects. We provide a full set of graphical objects for our 2D engine : TextDrawable (for text display with any font you want), MotionlessSprite (to handle motionless images), Sprite (to handle images that can have motion), MultiRegionImage (to handle huge images), AuraEffect (to display a selection aura on sprites), and much more... Of course you can develop your own Drawable objects very easily.

      To load/unload images efficiently and reduce memory costs we use an ImageLibrary which is a simple image database. Our ImageLibrary can load images from disk when the application starts and/or just in time when the images are needed. The structure of the library is a tree composed of directories and images. Each directory can contain images and/or sub-directories. You can indicate directories that must have mutually exclusive sub-directories (especially useful for huge images you don't want to be in memory at the same time).

      Finally, our 2D graphics engine works with Java Swing as its GraphicsDirector extends the JPanel class. But of course, because Wotlas is a GNU open-source project, you can change that easily.

You can download our 2D engine ( source + doc + demo ) from our SourceForge homepage.


World Organization ( wotlas.common.universe ).

Our game universe is made of distinct worlds, towns and buildings. Players can only see their character when they wander in buildings, moving from one room to another. To limit the awareness of players in buildings and have a modest scalable system we chose a simple approach : locales with a 1-step policy.

Building floors are made of different rooms ( locales ) that are linked by gateways ( open space with or without doors ). Players can only see what's in the current room of their character and what's in the rooms linked to their current room ( 1-step policy ). This is a simple way to perform some interest management. For a far more complete approach on the subject refer to the MASSIVE-III and RING virtual environments.