parentNode.org

Preface

During 2006 I had the pleasure to work on a fair amount of interesting flash projects, of tease the most advanced by any measure was Barda. Barda is a fully functional Isometric MORPG (Multi-player Online Role Playing Game). Currently players can create instances of two basic levels, in which they can hunt NPC’s for items and loot. To to progress from one basic level to the next, the player has to face a and defeat two boss-mobs (A minion and the master). Each game instance can support up to 8 players.

Go try the game

Sadly the game currently only exist in Danish. This is however not a large problem as the game is pretty self-explanatory as soon as you created a user. Therefore I have devised the following translated screen-shots of the process.

Signup and Login

Join game and Create game

Game UI

Click here or one of the above screenshots to go try the game

Current state

The current game has been running since mid January, and has been a rather large success. However the project beaning produced in a hurry on a very limited budget, still leaves allot to be desired. I am sure some of you will find the lag of a merchant system or a way to trade items rather irritating, but we had to prioritize. Related to this please notice that the lag of a classic text chat was requirement, as the client feared for the problems that arise when having children on a chat.

Development

The entire game in its totality was made by 3 people; Oliver Kofoed Pedersen writing the server, Niels Loew drawing all the graphics and me writing the Flash client.

The project from signing to delivery was done in 3 months, but in truth such a small time-frame was only possible as we started development before the signing as we really wanted to make it anyway.

Future

Level 3 which is a part of the original delivery will go online next week. But we are currently also negotiating with the client for version 1.5 which should solve most of the current problems. An interesting thing to note here that the current client only owns a license for the game in Denmark, Sweden, Norway and Finland. Therefor if you want something like this in another territory be sure to .

Server

For the back-end Oliver write a costume server in C#. Instead of trying to duplicate the RPC system that the flash media server uses, we choose to just to base the entire thing on XMLSockets.

As games are seperate instances there is no technical limit to how many players can be online at the same time, as users will just be distributed out over several servers. Currently we have no idea how many users can be online at the same time on a single server but we have observed over 500 with no problems.

Basic levels are randomly generated when the first user joins a game.

Sadly I cannot comment much on the server, as Oliver write the entire thing, and I don’t feel like reading through so much source-code just for this article.

Client

Engine layers (click to view large)
The client is written in flash 8 using AS2.0. At the base the engine is subdivided into several layers. Each layer is essentially just a movieclip at a separate depth with added functionality.

Most complex of these layers are the 3D layer which keeps tracks of every element on the stage and make sure they are rendered in the correct order. To do this each static element has a fixed depth, and all moving elements depth are dynamically updated using a costume depth-manager.

For the engine I also wrote the following subsystems, the list is not excessive, but contains the more interesting parts.

Pane system

While this system is not very fun to look it its likely the most important in the entire client. Basically it allows the client to load and unload parts of a level at runtime, such that even though the levels are around 15.000×15.000 pixels large flash only has to handle and render the immediate area around the player.

Actually the server uses an almost identical system to ensure that the client only receives relevant data.

Pane system demo - Rather unimpressive but never the less important.

UI System

To allow the users to utilize their entire screen-area — for the game and related windows — the game fills out the entire browser window. As a result of this the users can resize the game area while the game is running. Of course this should not change the game view so a small UI engine allows different elements to be linked relative to points on the screen.

Windows in this case are just UI elements that allows the user to change this linkage.

Attached elements demo - Simple example showing how elements move and resize when the window does so.
Demo UI - Simple user interface created with the system.

Particle system

Any good engine need a particle system! The only special thing about this is that it adjust the amount of total particles dynamically such that it does not kill the users computer totally.

Particle system demo 1 - Look its pretty
Particle system demo 2 - Shows how the particle system can change on runtime.

Path finding

One thing I really dislike about similar flash projects is that there is never any path-finding, continuously making my character walk in to walls and such. Making a path finding algorithm that is fast in flash was however a bit of a challenge, so allot of work went into this. At the end I opted for a slightly modified A* algorithm.

A* femo - Simple implementation of A* that runs onEnterFrame and verbose so you can see how the algorithm work.
Final algorithm demo - Demo showing the final algorithm in action.

Shadow system

To offload our graphic artist, and to decrease the total size of the game, I wrote a system that generate shadows for the “3d” objects on runtime. The system works by projecting objects distorted onto a transparent bitmap canvas.

Shadows demo - Shadow system in action.

Final words

I really hope you like it :)