Orchestra-Nucleus

Reviews

2007-08-02T01:45:00.000-07:00

A child Enjoing playing the Nucleus game thanks for testing it, Youssef !

MIE Winners

2007-07-31T00:02:00.000-07:00

After a whole year of work , starting from august 2006, we got our reward on 28 august 2007.
Orchestra and nucleus won the 2nd position in MIE competition. I can not describe how we all feel about this victory, because we proved to our selves and to every one that we can do it and really innovate new ideas with the ability to make it come true.
A whole year of good and bad times, with many problems. A whole year of co-operation between the team members to make the project with its status now. A whole year of learning, as we learned a lot about team work and basics of management and scheduling.
Last but not least. Thanks to every one who helped us directly or indirectly. Thanks to those who supported us by their souls. Special thanks to the MIE team and specially our university coordinator Amira Awwad for her great efforts with us to make this possible.
Hope to have another post soon about MIA winning position.

Orchestra and Nucleus, for a Better Gaming World

2007-07-26T02:00:00.000-07:00

Nucleus, a game prototype developed by our team with an innovative gaming idea, aiming to invade not only the local market, but the international one as well. While working on developing the game main structure, the team figured out that it is needed to have a special functioning game server to be able to serve it, and there came Orchestra.
Orchestra, our clustered game server, is being developed for serving massive numbers of online users, specially Massive Multiplayer Online Gamers. The entire system's design is based on collaboration between different types of team-designed servers, supporting thousands of users' connectivity.
Still under testing, Orchestra is totally designed by the team, supporting high secured and non-stop connectivity software solution to all of its users.
The integration between Orchestra and Nucleus is done in a very harmonic manner, where the Orchestra server provides the needed functionality interfaces, which are simply used by the game logic; whatever action's needed by the gamer is done through its game logic, where the game logic provides the connecting link between the gamers' interface and the game server.

Orchestra Architecture Overview

2007-07-24T09:18:00.000-07:00

Orchestra; our clustered game server, is designed to provide a stable, powerful and easy to use environment for creating and deploying massive multi-player online games. Orchestra architecture is completely designed by Kernels team.
Orchestra is a secured cluster without limit on the number of participating machines. It is a pure software application that is easily expanded without the need to shutdown or suspend the system.
Massive multi-player online games have a common architecture, where the game is split up into zones, each zone have a list of players interacting in it and any other game objects. for example a zone might contain a map on which the players' actions are taking place.
Orchestra have what is called the zone server which is a group of machines hosting game zones with the full responsibility to create, deal and even move zones from one node to another, the last takes place in case where a great number of players are interacting in a zone applying a great load on the machine hosting the zone, so that zone needs a more powerful machine to host it.
The decision of where to move a loaded zone is taken by the Zone Load Balancer(ZLB) which is implemented in distributed manner to avoid single points of failure.
Orchestra has a standard communication layer called SRMI which abstracts all the overhead of networking issues and allows the application to be easily broken and distributed on separate machines.
Orchestra provides a very comprehensive enviroment for creation of MMOGs, the game developer is totally abstracted from the details of how to deal with networking issues through a logical layer that handels all the details of what the cluster is doing.
Another abstraction logical layer, is the object store, which encapsulates all database operations using aspects.

Nucleus Major Idea

2007-07-24T04:11:00.000-07:00

Nucleus is a MMO-Game that is build to simulate teamwork, responsibility, Management & co-operation between the players through merging the two game genres Role Playing & strategy.

The Game simulates the military structure, players start as soldiers who get their orders from their leaders & complete them with their squads, by time players get promoted therefor they get their missions from a higher rank & in a different way, then they divide this objective to sub objectives and assign them to their squads that he/she is leading, & so on

so the player has a different view of the game according to his rank, the higher his rank is the more strategic the game is, & as you leader changes the game will also change as you will be playing through his vision & with a different plan

Nucleus with Torque Game Engine

2007-07-24T03:56:00.000-07:00

Nucleus is a Massive Multi-player Online Game, it is built with Torque Game Engine (TGE by Garage Games) & The engine proved to be efficient for the Job.
with some small editing in the engine code we were able to meet the requirement of a MMO-Game such as mouse controls & camera controls & other things we added.
TGE is actually built on a powerful network library (TGE is already based on a server client architecture, but unfortunately we couldn't integrate it with our Orchestra server, so the torque connects with our server & the other players that are on the Map are no more than AI players that get their orders through our server, where in return each player sends his actions to the server who broadcasts those actions to the others.
The server doesn't have a game loop, & there is no processing at all when no one is on the map or no one is doing anything (except for pinging idle players only) simply speaking the server only respond to incoming requests & nothing more.

Adaptive peer-to-peer load balancing in distributed environments

2007-07-24T03:18:00.000-07:00

As we have multiple servers that serves clients on a request-response basis, we need a robust load-balancing. And since the load can't be predicted, we need the load-balancing to be adaptive. And since robustness is an issue in a clustering system, we need not have single point of failures. So instead of a central load-balancing server, we need it must like peer-to-peer.
So we introduced our novel load-balancing algorithm that satisfies this properties. It's complexity is O(log2 N) instead of O(N). Each node is only aware of 3 other nodes, not the whole cluster. In case of failure of a node, or in case of isolation of 2 subset of nodes, each subset will be load-balanced as a single unit, which means the algorithm is also graceful degradable.
We have written a paper about the algorithm and isA it will be published soon.

Spontaneous Remote Method Invocation (SRMI)

2007-07-24T02:56:00.000-07:00

What will you do if you want some components to communicate over a network ?
Well, you can use sockets and write your own protocol. You can use some Remote Procedure Call framework, like Remote Method Invocation (RMI) or CORBA (for Java software).
Of course in order to use them you have to learn them first, which takes precious time if you have a tight deadline. The other thing is that you will modify your code to be RMI aware (if you use RMI) and
to extract some interface, and write extra logic related to RMI registry and object querying and other stuff. For that reason we invented a new remote procedure call framework based on RMI that you can spontaneously. Meaning you don't need to be aware that it exists, and the code doesn't need to change at all.
The main goal was that we will develop our clustering server as a single unit and split it up on multiple servers with minimum of fuss.
It's approach was to create wrapper classes that imitates the expected class hierarchy of the RMI in run time. They would wrap your classes and abstract all remoting-related issues from them such that the classes would be remoted as RMI remote objects without knowing or changing the code (not even changing the byte-code).
It is hosted on google code hosting http://code.google.com/p/srmi .