MMORPG kit - draft document in progress, for discussion purposes only
I want to create something like Everquest, only anyone can extend it, and possibly modify it.
This is extremely similar to DarkLife and there may well be collaboration/exchange/complete fusion for various parts or the whole.
Here is a high-level strategic view of the project. This post will be edited as time goes on making it the Reference.
Goal of the project:
Create an MMORPG toolkit and context for creating an MMORPG-style environment
Philosophy of the project
Anyone can create a zone and add it to the MMORPG. Ideally anyone can add content and the system will integrate this seamlessly into the game. Ideally I can create a single avatar, with corresponding health, money, XP, and use him/her across all integrated zones.
How this would work - High level view
Each player will have an attachment that represents everything about them.
A set of API modules facilitate development of monsters, weapons and so on.
Between zones, a floating exchange-rate could be implemented for money and XP.
By using modular scripts that communicate using a well-defined Linked Messages interface we will move any secret-secret stuff into what will hopefully be a tiny tiny script/module, leaving anyone free to generate their own monsters, weapons and avatar types!
Deliverables
Documentation
- The project design (this post, will evolve iteratively)
Example implementations:
- Example monster (open except core)
- Example avatar token (open except core)
- Example weapon (open except core)
- Example spell implementation (open except core)
Core script modules:
These modules could be freely available (open) but would be closed prior to actual instantiation in the game world in order to lock them, eg with channel number.
- Zone exchange rate implementation modules: enforces XP and Money exchange-rates (locked module)
- Generic monster module(s): integrates a monster into the MMORPG (locked module)
- Generic weapon module(s): integrates a weapon into the MMORPG (locked module)
- Generic avatar module(s): integrates an avatar into the MMORPG (locked module)
Helper modules/systems:
- Zone exchange rate caculator system: calculates XP and Money exchange-rates (open modules)
MMORPG Library:
A set of modules that could be incorporated into monsters, weapons and avatars that provide functional abstraction and facilitate the rapid generation of these objects.
- Weapon API module: placeholder
- Monster API module: eg provides code for moving, pathing, basic AI and behavior
- Avatar API module: placeholder
How this would be used
Joe decides he wants to make a dungeon. He gets hold of copies of copies of the core, live modules and adds them to his weapons, monsters, and avatar token. He adds in the MMORPG Library API modules, and writes surrounding wrapper code to customize how his zone behaves.
People come and visit the zone. Hopefully. They play for a while and accumulate experience and money in this zone.
As time goes on, the system learns how easy it is to get xp and money in this zone and can compare this to other zones, in order to generate exchange rates.
The exchange rates set the equivalent xp and level as one moves between zones.
Now the MMORPG just got bigger! People can choose where they are going to level. Zones that are a posteriorae hard to level in get assigned a favorable exchange rate, and visa versa.
Priorities
Stuff to create a dungeon zone is priority 1.
Stuff to provide zone inter-compatibility is priority 2.
Risks
Risks outstanding for creating dungeon zone:
- Risk that unable to create convincing and fun monsters -> risk outstanding, prototype in progress
- Risk that convincing and fun monsters will be too resource intensive -> risk outstanding, awaiting results of prototyping
- Risk that demise of project owner would kill off existing implemented dungeons -> very low because all modules open in their non-instantiated form.
Risks outstanding for inter-zone compatibility:
- Risk that unable to implement xp equivalence detection
- Risk that unable to implement financial equivalence detection
- Risk that unable to implement object equivalence dection
- Risk that unable to implement xp interchange mechanism
- Ditto for finance
- Ditto for objects
-> risks for inter-zone compatibility will be looked at in more detail once technology for creating dungeon zones in place
Risks with Status=Closed
Make a sword to hit people -> prototyped, works ok
Make a sword to hit objects -> prototyped, works ok
Store life points and stuff, kill avatar as required -> prototyped, works ok
Details and Discussion
This section will provide implementation details.
Zone addition/modification
In order for the exchange rate system to work, we need to implement systems to handle zone modification. Worst case, we lock zones against modification and have all modifications as adds followed by deletes.
Use of objects between zones
To be decided.
Security
There is the possibility that a channel number, or other secure protocol parameter, will become widely-known at some point, compromising the stability of the game world.
To mitigate this we need to consider methods to:
- modify the channel number, or equivalent, throughout the effected gameworld
- segment the gameworld to limit the damage caused by any single breach.
As far as channel numbers, we might consider using a different channel per zone. The zone designer designates the appropriate channel number.
If the zone designer owns all objects in his/her zone, we can have the objects respond to a change_channel request, as long as it comes from his/her id.
In an initial project implementation, each avatar is local to the zone. In future updates, we might choose to conserve this, and to provide gateway systems to seamlessly move between zones. That allows us to shut down a compromised zone by removing it from the gateways systems.
Detailed Design - modules
Note: draft, for discussion purposes only
Introduction
We can split the required functionalities as follows:
- secure comms (in-channel shouts)
- receive damage
- receive effects
- send damage
- send effects
- stats (life, money...)
- AI (for monsters)
- movement (for monsters and possibly for avatars)
- control interface (for avatars)
We need to consider for each module the extent to which:
- it must be easily updatable
- it should be stable wrt changes
- it should be secure/locked wrt players and wrt zone designers
For the effects/damage modules, we basically need that we can flexibly add new weapons and effects into the game, whilst all objects already in the game will respond appropriately to them.
To this effect, we will split the damage/effect modules into receive and send. The send modules will be fairly flexible and can change with time. The receive modules must be very stable wrt new attacks.
Dynamically loaded scripts were considered but not retained for now because of the load they would impose on the sim motors.
Module design
Damage/effect receive modules will respond to six primitive attack types:
- directdamage(amount)
- damageovertime(amount, duration)
- movespeed(percent, duration) (can be more or less than 100%)
- attackspeed(percent, duration)
- attackpower(percent, duration)
- sensorpower(percent, duration)
Damage/effect send modules will use these primitives to create a range of attack types.
Projectiles can be implemented within this framework because the receive modules dont need to know with what they are being attacked, just the amount of damage inflicted.
The receive modules will be using Listens to sense attacks. Since scripts/modules are not threaded the listen must exit immediately, without undue delay, ie no llSleeps, and delegation to other events/scripts as necessary.
A stats module will store current avatar state, ie Life, Money, Movespeed, AttackSpeed, AttackPower, SensorPower.
Other points
Sourceforge
Now possible. Just need to do it.