Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Work in Progress / The Official DarkMORG - MMORPG FPS Server/Client WIP Thread

Author
Message
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 16:28 Edited at: 18th May 2009 09:44
The MMO Game Server / Client Engine Formely Known As

Massive Multiplayer Online Role Playing First Person Shooter Game System


Introduction

What is DarkMORG? DarkMORG is a Massive Multiplayer Online Role Playing First Person Shooter Game System. Massive Multiplayer Online, Each Server supports 512 simultaneous players over the Internet, scalable from 1 x 512 Solo Party to 4 x 64 Full Party. Role Playing in a SciFi/Fantasy setting based on my Elemental DRifter RP Ruleset and Lore. First Person Shooter, featuring First Person Shooter Combat (w /Guns) for real-time, high-intensity action. Game System, providing modular entity construction tools that players use to create their own Content and Adventures.

This Thread will serve as my Interactive/Illustrated Design Document. Any and all post are subject to change without notice.

Featured Plugins:
DBPro Enhancements: DarkPhysics, DarkAI
Matrix1Util_28 20080927b by IanM
DBXML - an XML Document Parser Plugin for DBPro by Thomas Cheah, Bad Nose Entertainment. (thomascheah@badnose.com)
BarnskisLuaPlugin_1.1.1_release

Project Status
Legend: Completed Working Pending To-Do Cancelled



----Bitmap Fonts

Content Creation
Modular Entity Constrution Sets (MECS)
MEConstruct Visual Editor
----GUI Editor
----Entity Editor
----Map Editor
----Quest Editor
----FX Editor
----Audio Editor

Networking
----RPG Host Server HTTP & FTP(www.HPQuest.com)
--------MySql DB (Tables Built as needed)
--------Moderated Open Repository Directory (Built)
----Session Initiated Protocol (I2P)
--------Immediate Input Protocol (I2P)
----Server & Client Simulation Entities
--------Server & Client Prediction
----Web Application

Communication Systems
----Basic Chat
----Embedded MUD/Command System
----Q&A Dialog
----Search Engine Interface

Interactive Systems
LUA Scripting System (Integrated)
Behavioral Rules A.I. Nodes System
----PathFinding (DarkAI Integrated)
----Give||Take Registry
----Binary Decision Trees
----Hit Objects
EcoSys (RTSIO Model)
FP Combat Systems

High Performance DX9 Client Graphics Engine
----Level of Detail Manager
----Interior Octree Culling

Special Effects Systems
----Day/Night Cycle
----Weather System
----Particle System
--------LensFlare System
----Dynamic Rumble Tone Generation System/Force Feedback Headphone Support

Alucard94
13
Years of Service
User Offline
Joined: 9th Jul 2007
Location: Stockholm, Sweden.
Posted: 4th Sep 2008 17:30 Edited at: 4th Sep 2008 17:31
It sounds good I guess, do you have any ingame screens or is it too early in development for that?


TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 17:53 Edited at: 17th Jan 2009 03:30
Network Topology



DarkMORG uses a Server-Client Model based on 1-to-n Centralized 'Host' Server Network Topology. The Centralized Host Server provides Persistent Database Storage, Webpage via HTTP, and Media and Logic Files via FTP to both Game Server and Clients.

Server Map Layering

The Quest Game Server is designed to support up to 512 simultaneous players scalable from 1 x 512 Solo Party to 4 x 64 Team Party. Quests in DarkMORG are designed with a series of linked FPS Tournament Maps. Like maps traditionally found in the FPS genre, these maps place emphasis on interior design and are smaller in scale compared to large terrains found in many MMOs.

To support 512 players in Quest, Parties participate in their own Instance of a Quest using Map Layering. The idea behind Map Layering is to share geometry (static w/ sliding collision) for multiple maps between multiple Quest; and share these Quest between 512 Solo /Team Party on separate virtual `Layers`.

Map Layering is achieved by loading and aligning static level map geometry in a non-overlapping cubic partition of 3D Space. Maps are not required to be equal in dimensions. Maps are loaded into the Servers Memory during runtime and are persistent until the server reloads. Only the Maps static geometry (type: structure) at the Lowest Level of detail is used for collision.





All level maps share the same Day/Night Cycle and Season Cycle, although Weather Cycle and Environmental Conditions are independent to the map.

Dynamic Objects {Platforms, Doors, Triggers, Spawners, Props} within the Map are duplicated (Collision Geometry and Database Instance Record) and assigned to specific Layer. These objects are set by the orientation of the template map and co exist in a 3D Map with other dynamic objects assigned to other Layers. However, collisions between Dynamic objects are discriminated by Layer assignment. Object scoping is also determined by Layer Assignment.





A Layer is created when a Party (Solo or Team) accepts a Quest. Players are assigned to that layer and can Enter and Exit the Quest at will. Players may also Join Quest in progress, however there may be character level and inventory restrictions. Upon creation of a Layer the Quests Map Template is queried to generate the map’s Dynamic Objects as assign them to a layer.

The server keeps tracks of what layers have active players to manage scalability. A layer can have 1 to 4 Party Members cooperative participating in the same quest. The number of layers created will slide based on party size up to 512 total players. For example:
123 Layers x Solo Party = 123 Players
82 Layers x Duo Party = 164 Players
51 Layers x Trio Party = 153 Players
18 Layers x Full Party = 72 Players
Total = 274 Layers, 512 Players

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 18:25 Edited at: 5th Sep 2008 05:44
Maps and Quest Building

DarkMORG takes a modular approach to Player Quest Building. Quest are created by interconnecting two or more FPS Tournament Maps by Objectives (also known as Task in RPG circles). Maps are constructed from Pre-Assembled Rooms. Pre-Assembled Rooms are constructed from MEC Constructs.

The idea behind this approach is to allow Players to quickly build Quest from pre constructed maps and objective templates. Each Map is assigned a Game Mode that defines a FPS style of game play in which a Individual or Teams complete an Objective. Upon completion of the Objective, a Reward|Penalty may be a awarded to individual|team Winners/Losers. Winner Individual|Teams are allowed to advance to the next map in the quest.

Note: that in a Team based Goal-based Game Play Mode it is required that all surviving team members arrive to Point B in order to complete and advance to next map.

Tournament Game Modes:
CTF: Carry Object(s) From Point A to Point B, Item can be Dropped (Timed|Untimed) (Reward|Penalty)
Rescue: Protect Object(s) From Destruction as it travels from Point A to Point B, Object movement is automated and the object can be Destroyed|Recovered (Timed|Untimed)(Reward|Penalty)
Race: (First|Last) (Individual|Team) to Travel Point B From Point A (Timed) (Reward|Penalty)
DeathMatch|Arena: (First|Last) (Individual|Team) to (Collect|Destroy) Object x n (Timed|Untimed) (Reward|Penalty)
Stealth: (First|Last) (Individual|Team) to from/to Point B From Point A WITHOUT Triggering Event (Timed/Untimed) (Reward|Penalty)
Hunt: (First|Last) (Individual|Team) to Trigger Event (Timed|Untimed) (Reward|Penalty)
Scavenger: CTF for Point(Timed|Untimed) (Reward|Penalty)
Pub: A Pub is a Non Combative Map in which players can gather to chat, buy stuff, join parties, and select/continue Quest, Enter Tournaments, and Play Mini-games, go home. Each Quest comes with one Pub by default, however, Quest Builders can add more if desired.

Although each Map can have completely different default content and purpose, Quest Builders can provide continuity between maps by using story dialog and comparable content and assets. Each Game Mode can be modified allowing the Quest Builder to set Point Locations, Objects, Timer, Reward|Penality. Maps can also be modified allowing the Quest Builder to add/edit Spawners, Triggers, Platforms, Doors, Push/Pull Props, Warps and Dialog Menus.

Visit The Official DarkMORG - MMORPG FPS Server/Client WIP Thread
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 18:27 Edited at: 17th Sep 2008 09:08
Modular Entity Construction Sets (MECs)


Modular Entity Contruction Sets (MECs)


Inspired by the many Toy Construction Sets (Meccano, Tinker Toys, KNEX, Legos) I played with as a child, I’m implementing Modular Entity Construction Sets (MECs) to support countless variations of High Level 3D Entities by mixing/matching smaller 3D components that are assembled at runtime in the engine using Database Queries. Based on a methodology of interconnecting Blocks, Connectors, and Accessories; MECs expands on the concept by allowing users to define Blocks, Connectors and Accessories.

The ABCs of Modular Entity Construction:

Blocks

A Block is a 3D Mesh in which one more Connectors and Accessories are added. Geometry, Animation, Textures, and Shaders are pre-generated using 3rd-Party Software. The MEC Construct Editor is provided to create and edit Blocks, Connectors, and Accessories. High Level Entities are assembled from MEC Contructs with other in-game editors (ie: Character Editor).

Connector

Connectors are geometry or virtual connection point in which a Blocks and Accessories are connected or linked.
Slot/Peg: A external connection point glued to a mesh, used to connect blocks at runtime. The type of connector determines the Parent/Limb Relation between block and connector. Slot Connectors are parented by Blocks. Blocks are Parented by Peg Connectors. Only Slot to Peg connection is allowed between connectors.
Joint: A vertex point defined within a mesh geometry normally used for bone hierarchy and animation.
Linkage: A virtual Link between a Motor (Impulse Source) Accessory and one or more Blocks and Accessories
Weld Point: A vertex point defined within a mesh geometry, externally assigned to be used for (magnetic threshold) welding of two meshes together to create a single seamless mesh.

Accessory

Accessories are Audio/Visual or Virtual Object used to control or produce an effect.
Motors: A virtual object that controls another objects scale and orientation. A Motor’s method of control is by a script, a Servo is by player.
Physics Body:
Reactors: Particle Emitter
LensFlares
3DLights:
3DCamera:
3DSoundField
Mount:
HitBox:

There’s a MECs Management System specific to the following Game Entities: Character (ModEL), FireArm (Gunvertor), Melee Weapons , Props (animated & static), Trees & Plants, Vehicles & Machines, Building/Structures, and Items (Single Mesh/Textures with Connectors).

The motivation behind the implementation of MEC Sets is to 1) Support countless variations of High Level Game Entities by mixing/matching smaller components that are assembled in the engine at runtime using Database Queries; 2) Promote rapid production of user created content, placing emphasis on the creation of smaller 3D/2D assets that can be interchanged in various entities vs. creation of larger single entities such as a single mesh Character.

Although, the construction method is based off Toy Construction Sets like Legos, the art design will not be comparable to Lego PC Games.

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 18:29 Edited at: 12th Apr 2009 19:02


Gunvertor Weapon System


For many years (1995-2095), I persued the creation of a FPS game that would feature my Modular First Person Shooter Weapon System, I've effectionately dubbed GunVertor. The premise behind GunVertor is a Modular FPS Weapon & HUD System that could be assembled into virtually a countless assortment of weapon designs or used for specific set of static weapon designs.

Weapons are assembled from interconnecting weapon components. Each component effects the player, weapon, and ammo in a specific manner.

GunVertor Weapon Components:

The Chamber: The Weapon Core Component in which other components connect into. It is the mechanism loads ammunitions from the ammunition storage into the weapon, applies motivational force, directs ammunition through the barrel, and ejects ammunition byproducts. Chambers effect the amount, type and speed of loading ammunitions.

Barrel: Projects the ammunition. Barrels effect ammunition range and dispersion. Long Barrels produce long range/ narrow dispersion; Shorter Barrel produces short range/wide dispersion. Barrels also provide a ‘heat sinking’ for the weapon.

Loader: Can be attached to the barrel or magazine. Loads ammunition with Hand2.

Trigger: Control mechnism that activates Firing Unit/Mechanism. The Trigger determines how the user can fire the weapon. A weapon can posses multiple triggers.

Firing: Unit This component provides motivational force to a ammunition. High Quality Firing Units can project ammunition a great speeds long distances.

StockGrip: Absorbs Recoil. Recoil can effect weapon handling and accuracy. High Quality Stocks can absorbs greater amounts of recoil. Handgrip attaches to player.

Magazine: Magazine PowerCell Canister are storage components. These components effect Ammunition Refill/Recharge speed and Storage Quantity

AmmoMeter: A 3D HUD Display for Ammo Count associated with the magazine.

Scope: A HUD accessory component that assist in visibility of the target (ie: Zoom, Infrared, Thermovision)

Sight + Cursor: A HUD accessory component that assists in targeting object. Displays Targeting Cursor.

Distorter: This accessory attaches to the Barrel of the weapon to muffle sound of Solid Ammunitions or change the visual characteristics of Energy Ammunitions.

Bayonet: This Blade Weapon accessory attaches to the barrel of the weapon and used as melee weapon.

Firearm Entity Class


Firearm Modelled Parts (simulated)


TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 19:17 Edited at: 10th Sep 2008 16:02


Lore

Elemental Drifter is a Sci-Fi/Fantasy Themed Ruleset that is the foundation of Lore that evolves around Dimensional Rifts. Dimensional Rifts (DRifters) are tears in the fabric of Space & Time. DRifters appear in the form of illuminated mist-like vortices, varying in size and color. Their origin and reason for existence is unknown. They are unpredictable, appearing and disappearing when ever and where ever. Some act as doorways, transmutators, and forcefields. The ultimate goal of many Quest is to learn the secrets DRifters.

Mana is the residue of pure energy particles that linger after a DRifter extinguishes. Mana Particles defy all rules of physics, occupying two simultaneous states of existence that are equally opposite to one another. Mana Particles change into various forms of energy and matter which are referred to as Elementals. All Elementals have an equal opposite and are grouped in pairs based on this relationship. The Lore provides 8 basic Elementals: Fire/Ice, Earth/Wind, Water/Lightning, Light/Darkness.

Crystals are a special type of material that can store and release Mana Particles. Although Crystals do a good job at containing mana, mana will leak resulting in the shifting of Energy/Matter acutely in their presence, producing illuminous emissions of Elemental Energy. Thus, Fire Crystals appear to emit flame and Ice Crystals appear to emit frost. The quality of the Crystal determine the quantity and duration its able to store mana particles.

Mana-Tech is a field of science that employs Elemental Energy to power Devices and Machines. The Mana-Dragon is the most common of Mana-Tech Devices. It can serve as both a weapon or utility. As a weapon, the Mana-Dragon can unleash ammunitions of Mana Energy/Matter. As a utility, a Mana-Dragon can use mana energy to stimulate cell regeneration, or produce anti-gravity beams to move structures, and for many other Utility purposes.

RuleSet

The core idea of the Elemental DRifter ruleset is the application of Elemental Percentile (%) Modifiers to all Combat and Skill Test.

Combat

DarkMORG features First Person Shooter Style Combat. Both Skill and Traditional RPG Stat calcuation are taken into consideration. The RPG Stat Calculation is based on Attack VS Guard formulas to calculate damage and effects. The Game Mechanic is introduced in the collision between a weapon projectile Hitbox (Attack) and armor Hitbox (Guard). Element % Modifiers are applied to both Attack and Guard.

Weapon

DarkMORG features FireArm, Melee, vehicle and Machines style Weapons. All weapons generate a projectile of some sort during attack. For example, Melee Weapons generate 'Slash' Projectiles when swung/thrusted. A projectile has a minimum of one Attack Elemental % Modifier. Players can carry upto 3 weapons.

Armor

Armor has a minimum of one Attack Elemental % Modifier. This modifier determines how much HP damage a character sustains and is calculated by Guard Strength Elemental Modifier% x Attack Damage. A GS Modifier equal to 100% provides no guard against an Attack, while a GS Modifer equal to 0% will completly nullify an attack. A GS Modifier greater than 100% results in additional HP damage (HP Drain) while a GS Modifier less than 0% restores HP (HP Boost).


Attack Strength * Elemental Modifier% = Attack Damage + Effects

Armor reduces the Total Attack Damage a weapon inflicts
Attack Strength - (Guard Strength * Elemental Modifier%) = Total Damage / Boost

Visit The Official DarkMORG - MMORPG FPS Server/Client WIP Thread
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Sep 2008 20:00 Edited at: 31st Jan 2009 17:02
Behavioral Rules A.I. Nodes System (BRAINS)

Quote: "1) How do I resolve player actions, or have a good system of restricting/allowing player action without writing hundreds of functions?

2) How can I make the avatar "smart" so that it will interact with different objects in the world in different ways.
"


Answering these questions and providing a more comprehensive AI are the motivators behind BRAINS Interactive Model. BRAINS incorporates Give||Take Registry, Binary Decision Trees, Hit Objects (Triggers), Tasks (LUA Script), Dark AI (Pathfinding), and Q & A Diaglog.



The Give||Take Registry

The Give||Take Registry is a list (queue, stack, or any other data structure) of Node Keys. A Node Key contains a: name, value, compare operator, and logical operator. Node Keys can represent any kind of property. The data in the Node Key is used to perform a simple IF condition and return a TRUE/FALSE result. I find it easier to visualize each IF Condition as a `node` in a decision tree, hince the label Node Key. All the Node results are tallied to produce a final TRUE/FALSE result.



All Interactive Entities have their own Registry and the Give||Take role is based on the entity that initiates the interaction (collision check). Entities who initiate the interaction are Giving, the receiving Entities are Taking. When Giving, each Node Key can represent something the Entity possesses. When Taking, each Node Key can represent something required by the Giving Entity for positive interaction.



From a coding perspective, we iterate through each Node Key in the Take Registry. Each Node Key is matched-by-name to a Node Key in the Give Registry. The Operators from Take Registry Node Key are used to perform the comparison. If the result is TRUE we continue to the next Node Key, otherwise we exit checking returning a FALSE result. If we’re able to iterate through all the nodes we return a TRUE. Thats it! The final result can used to execute a scripted action.



GTR is a simple and high performance solution for dealing with Interactions that require many conditional checks against a Player Character abilities, skills, accessories, items etc. GTR solves Question #1.



Hit Boxes

Triggers address Question#2. A Trigger is a type of Hit Object placed in the environment to trigger events (ie: Door Switch). A Hit Object is a 2D/3D Object that executes one or more scripted actions when a collision event occurs between itself and other Hit Objects. Hit Objects are `glued` to other objects such as Players/NPCs, Weapons, Projectiles, etc to create a means of interaction. Hit Objects are used for all 3D interactions and are what make Interactive Entities…interactive.

A Quest Map can contain hundreds of Triggers. Thus, instead of requiring a slew of actions for a Interactive Entity to `intelligently and logically` respond to a Triggered Event, the Trigger executes a action that acts upon the Interactive Entity.

The Unofficial List of Mob/Boss AI Behaviors

I will be using Dark AI for directing AI Behaviors in DarkMORG. The goal is to create distinctive and challenging behavior. Below is a list of behaviors that I will add too as they pop in my head.

Kamikaze : Relentless Pursuit and damaging Self Destruction to enemies at close range.
ScaryKat : Relentless Full-Powered Attack close or long range, immediately followed by retreat to neareast barrier.
Ninja : Silent Attack (no Audio Triggers) and usual visual distortion, uses only close range single hit melee attacks.
Sniper : Seeks Barriers only attacking from long distance.
Bowler : Attacks enemies by converting enemies into throwing projectiles upon contact.
Virus : Infects enemy mobs upon contact reproducing finite number of clones of itself and attacks with ranged weapons.
Boomer : Infects enemy mobs upon contact reproducing a finite number of clones of infected mob.
BackStabber : Relentless pursuit and attack when not facing enemy, retreats when faced.
Pawn : Only pursuits and attacks (melee) when enemy is adjacent with reduced defense, otherwise its frozen in place when directly faced with double defense.
Reverend : Heals weak friendlies.
Nemesis : Infects `corpses` upon contact reproducing finite number of clones of itself and attacks with ranged weapons.
Replicant : Consumes a finite number of weaker Enemies, Replicaticating.
Boulder : Great in Size|Speed|Both, Relentessly pursuits Enemy with Devastating Melee Attacks, Weakens in Size/Speed/Both from Critical Damage.
Fuser : Combines with finite number of its own kind to metamorph into a more power foe.
Blinker : Attacks various distances, Pauses for short time to Recharge/Reload, then Teleports.
Hydra :Great in Size|Speed|Both, Attacks from various distances, Replicates into finite number of copies with 1/2 Size/Speed/Both from Critical Damage.
Mad-Man : Relentless Attack, practically invincible with specific weak point that causes critical damage.

Oneka
16
Years of Service
User Offline
Joined: 24th Apr 2004
Location: Hampton,VA
Posted: 4th Sep 2008 21:42
Sounds pretty indepth any screenshots sofar?


Making dreams possible, one line at a time...
White Fang 12
13
Years of Service
User Offline
Joined: 28th Aug 2007
Location: In my office coding
Posted: 5th Sep 2008 00:55
So what your saying with the weapon system is that you can find weapon parts in game and make different variants of a weapon. If So awsome

I'm a noob help will be accepted
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Sep 2008 02:04 Edited at: 5th Sep 2008 06:13
Quote: "Alucard94: It sounds good I guess, do you have any ingame screens or is it too early in development for that?
Oneka: Sounds pretty indepth any screenshots sofar?"
They're coming. I'm no Artist *** Viewer Discretion is Advised ***

Quote: "White Fang 12: So what your saying with the weapon system is that you can find weapon parts in game and make different variants of a weapon."
YES!

Visit The Official DarkMORG - MMORPG FPS Server/Client WIP Thread
flickenmaste
12
Years of Service
User Offline
Joined: 2nd May 2008
Location:
Posted: 5th Sep 2008 04:42
Yay this is back!


ur putting alot of work into this


[url=http://userbarmaker.com/][img]
Xenocythe
15
Years of Service
User Offline
Joined: 26th May 2005
Location: You Essay.
Posted: 5th Sep 2008 04:55
Wait, I thought your last couple threads out of W.I.P. were design threads too?

If you can lets see some screen shots of the server/client system in works.

3.11 We do not tolerate posts made for the purpose of putting down another forum member, group of members, religion, our company, our staff or any of our moderators, past or present.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Sep 2008 05:02
Quote: "Yay this is back!"

Never Left. Just relocated my thread from the Newcomers DBPro Corner to WIP Forum.

Visit The Official DarkMORG - MMORPG FPS Server/Client WIP Thread
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Sep 2008 06:06 Edited at: 9th Jan 2009 21:15
Quote: "Xenocythe: If you can lets see some screen shots of the server/client system in works."

Here you go.


Game Server


Honestly, screen shots aren't going to tell you much. A video or working demo would be more effective. You're gonna have to wait for those.

Osiris
16
Years of Service
User Offline
Joined: 6th Aug 2004
Location: Robbinsdale, MN
Posted: 5th Sep 2008 08:08
Ooooh, I like that dragon.

RIP Max-Tuesday, November 2 2007
You will be dearly missed.
flickenmaste
12
Years of Service
User Offline
Joined: 2nd May 2008
Location:
Posted: 5th Sep 2008 08:15
hmm....really nice background for your log in page!



and to anyone who hasn't read the other thread...you will see lots of diagrams!


[url=http://userbarmaker.com/][img]
Xenocythe
15
Years of Service
User Offline
Joined: 26th May 2005
Location: You Essay.
Posted: 5th Sep 2008 23:01
Nice! Actually, I've done a lot of multiplayer systems, I've actually got one going that has just about the same work done so far as you, made the same way as well. I'm not planning on making a game out of it, it's just for fun to make a working multiplayer system. I'll send you some screenies if you want.

3.11 We do not tolerate posts made for the purpose of putting down another forum member, group of members, religion, our company, our staff or any of our moderators, past or present.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 14th Sep 2008 20:39 Edited at: 3rd Dec 2008 11:32


Multi-App User Interace (MAUI)

Graphic User Interfaces (GUIs) are a essential component of any 3D game development. Out of all the systems of a Game, I have yet to find a GUI solution designed specifically with GAMES in mind. In using other GUI Libs, I have often found myself in a situation that requires significant modification or re-invention. As much as I dread writing a Yet Another GUI, I just could not find a solution that provided all the features I desired.

Feature 1: Operate Like a Web Browser.

For DarkMORG, I desired that the GUI operate similar to a Web Browser, in which the Menus are downloaded from a Remote Server and formatted and displayed on the client. This functionality would allow me to provide web-like applications within the Client with minimum need to patch. Thus, was born Multi-App User Interface (MAUI). MAUI is a hybrid of Markup and Scripting Languages (HTML/XML/PHP/LUA). A Custom Set of XML Tags (based on the HTML Image Map Tag) is used to format GUI Controls, define their audio/visual properties. Like Webpages, MAUI files are stored on a Host HTTP Server as .PHP (Server-Side Scripting Support) and downloaded and saved to the client as .MAUI files. Client-Side Scripting is supported with LUA. However, unlike webpages, all Source Files (images, sounds, other media) are required to be preloaded on the Client to minimize menu loading time. All Media downloading is handled by DarkMORG's FTP Manager.

Feature 2: One Pointer, Mulitple Controllers.

The Pointer, simply put is a GUI object that moves about the screen controlled by a User via Input Device (Keyboard, Mouse, Joystick, etc). It's important to me that the Pointer be decoupled from the mouse, allowing various input devices including the keyboard to be used in controlling it. The Cursor is a GUI object thats assists the Pointer in doing its job. It can be used to mark position or highlight a selection.

Feature 3: Gizmos

Gizmos are GUI objects that define hotspots on screen which can interact with the Pointer. This was a inspiration I took from the HTML Image Map. Of course, I made radical modifications in MAUI. Gizmos use Sprites for display. I chose the name Gizmo based on its definition 'A mechanical device or part whose name is unknown'. Essentially, A Gizmo is a GUI control whose behavior is unknown, as there are no pre-defined behaviors for buttons (which are commonly called gadgets in other GUIs.)

Feature 3b. 3D Gizmos

Although, not implemented at this time, I intend to add 3D Gizmos to MAUI. Their function will be very similar to 2D Gimzos using 3D Meshes in place of hotspots/sprites that can be positioned anywhere in 3D space to interact with the Pointer.

Feature 4: Event-Based Finite State Machines

MAUI is completely designed around the concept of GUI Events which are the basis for a model of behavior composed of a finite number of states, transitions between those states, and actions. An Event is a timed state change based on Pointer-vs-Gizmo Collision Detection, Key/Button Detection, and Event Flags. These `condition checks` are the basis for many different types of Events in MAUI.

For Example: Lets say the Pointer is controlled by a mouse and theres a single gizmo 64 x 16 pixels in the center of the screen. A `ENTER` Event occurs when the Pointer initially collides with a Gizmo. If the Pointer remains within the bounds of Gizmo for a specified time, the Event is changed to 'HOVER'. While 'HOVER'-ing, if a button press occurs, the event type is changed to `DOWN`. Upon release of the button during 'DOWN' changes the event to 'UP' the gizmo Action is executed.

Feature 5: Scriptable Behaviors

We are all familar with typical Buttons, Labels, Sliders, etc. These are often referred to as Gadgets in other GUI's. In MAUI these are referred to as Behaviors. In other words, a Behavior is event-driven logic that controls the `mechanical` operation of a gizmo. The example above, describes the Behavior of a typical Button. However, Games can require Gizmos with unusual Behaviors. To support any type of Behavior, I implemented a Scriptable Behavior System. The implementation allows the creation of many types of behaviors both traditional and non-traditional.

Feature 6: Image-based Styles

When I originally conceived MAUI, the goal was support lots of text and nothing but text. I thought this would be necessary for good text-heavy storytelling. A Nothing-But-Text UI was extremely ugly so I reduce the text and added some border drawing functions to improve the visual definition of a Gizmo. Additionally, I quickly discovered performance issue with using text generated with true type fonts. I found myself employing several image capturing and rendering techniques to improve performance. Shortly after, I decided to fully integrate pre-generated Images, Bitmap Fonts, Bitmap Border Sets into the event-based Style System.



Feature 7: Transition Effects

Modern Games have very active GUIs complete with sound and animation. I like games with Active GUIs. I want a Active GUI. I want a Scriptable Transitions Effect System. Transitions are animation effects executed between Event Changes. Animations are simple and programmable via scripts. MAUI implements Transitions in the same fashion Styles and Behaviors are implemented.

Feature 8: Controls Keyboard/Mouse Input

Keyboard & Pointer Device Input control is integrated into MAUI.

MAUI v2 Example






DarkBasic Pro Guy
16
Years of Service
User Offline
Joined: 4th Jun 2004
Location: Broomfield, Colorado
Posted: 14th Sep 2008 21:53
Looks like you've really got a great plan going together hear. I wish you luck and I can't wait to some progress!

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 23rd Sep 2008 05:09 Edited at: 2nd Oct 2008 13:02
MEConstruct - Modular Entity Construction Set (MECs) Visual Editor

Like most game engines, DarkMORG Client will have its own editors. There are two types of editors: Application and Game. The Application Editor used to ‘Create’ game content such as Maps. The Game Editor is used during game play to modify personal content such as The Player's Character Editor. Both editors use ATML GUI System and operate in nearly the same manner. The major difference between the two (other than role) is their appearance.

MEConstruct is all-in-one Application Visual Editor containing several editors: Construct, Entity, Map, Quest, GUI/Dialog, Character, Audio, Particle, Lens Flare, and FX.


Concept Drawing of MEConstruct in PowerPoint.




Real-world Editor (WIP)

Click to Enlarge


MEConstuct is designed with features to support: Modular Entity Construction, Moderated Open Repository, `Turned based` Multiuser Editing. Due to these requirements, MEConstruct operates slightly different than normal editors.

Modular Entity Contruction Sets (MECs) was inspired by Toy Construction Sets such as Meccano, Tinker Toys, KNEX, Legos. MECs basically creates a virtual 3D toy construction set using the methodology of interconnecting Blocks, Connectors, and Accessories.

The goal is to create a wide assortment of High Level 3D Entities such as Characters, Weapons, Buildings, etc by interconnecting smaller 3D components that are assembled at runtime in the engine using Database Queries. Additionally, support a substantial number of customization options for every type of High Level 3D Entity.

DarkMORG is designed with a heavy dependence on Player-created Media Assets and Content. To make it as easy for players to get their art into the game, and of course protect the game from damage, a Moderated Open Repository is established. Players can simply upload their Media Files to the MOR Server for review and approval. Moderators inspect files for damage, compromise, obscenities, etc. If approved the files are moved to the Closed Repository (Production) for use in game.

This leads me into describing how Assets are generated and used in DarkMORG. MEConstruct Editor doesn't generate any media files for geometry, animation data, bitmaps, audio. All Media files are produced with 3rd Party Editors. Media files stored in the Closed Repository are cataloged in the database.

MEConstruct loads Assets by performing queries on Host Database for assets and data (applicable to the entity editor mode) generating A/V previews. Assets are downloaded via FTP upon selection. All High level Entities are constructed on the fly by querying the Database. This is pretty much the same process the Client uses to load files for gameplay.

A collaborative multi-user Editor in which multiple users can build content simultaneously and in real-time was a strongly desired feature. However, implementation of a turned based Multi-user management would be less painful. I'm still working I manage entity check-out/in, User Authorization, and other details.

The Construct Editor

Most of the Editors in MEConstruct are commonly found in 3D world building in other engines, however, the Constuct Editor is the most unique. The Construct Editor allows users to create MEC Blocks to be used with High Level Entities. This feature would be the virtual equivalent to hand-crafting a unique custom block in a toy construction set.

In creating a MEC Block, users simply load in a mesh, specify the entity type, add and position connectors. The mesh can be of any shape and upto 16 connectors can be used. Once a MEC Block is created and [/i]saved[/i] it can be used by any user in assembling a Entity of specified type.


MEC Block



If you notice in the illustration above connectors labeled `Slot` and `Peg`. This denotes the role of a connector which determines Parent/Limb Relation between block and connector. Slot Connectors are Parented by Blocks. Blocks are Parented by Pegs. Only Slot-to-Peg Connections are allowed to ensure MEC Blocks connect properly.

There are also 3 special purpose Connectors: Joints, Weldpoints, Linkage. Like regular connectors, these connector use slot/peg roles to determine other factors.

A Joint is a Point defined within a mesh geometry used for bone animation, Slot/Peg role assignement is matched to Bone Parenting Hierarchy. Weld Point is point defined within mesh geometry and used for welding two meshes together to create a single seamless mesh. Weld points Slot/Peg roles are assigned merely for Slot-to-peg connection, Parenting is ignored.

A Linkage is virtual connector visually represented in MEConstruct to show a linkage between a Motor (Impulse Source) Accessory and one or more Blocks and Accessories. By default the Motor is parent to linked Blocks & Accessories.

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 4th Oct 2008 16:30 Edited at: 19th Jan 2009 02:52
Moderated Open Repository

DarkMORG is designed with a heavy emphasis on Player-Created Media and Content. To facilitate a quick and user-friendly means for Players to get their Art into the game (and of course protect the game from damage), a Moderated Open Repository is established.





Players can simply upload their Media Files to MOR for review and approval via HTTP. Moderators inspect files for damage, compromise, obscenities, etc. Upon approval the files are moved to the Closed Repository (Host Server) for use in game.

Simplified Directory Structure

DarkMORG Host Server, MOR, and Client utilize a simple and identical Directory Structure to maintain files. All files are required to have a unique name. All files retain their native format and extension without cosolidation or additional compression.

Root:
-- 2D: Stores all Image and Movie Media Files
-- 3D: Stores all 3D Geometry and Animation Media Files
-- Audio: Stores Audio Media Files
----Sound
----Music
-- Data: Stores all Logic and Aux Data Files
---- UI: Stores User Interface and Dialog Files

A Game with MORe Content / MORe Games with The Content

One of my goals for MOR is not only to supply my MMO with lots of content, but, also supply lots of other games with the content.

For example, one game concept thats on burner is the development of two distinct genres that interact together to create a MMO with complex Political Factions. 1) Kings: A Real-time Strategy Game in which Player's battle for control over Terriorities on a Slower Turn-based `Macro` Scale. 2) Knights: Multiplayer FPS in which Players select a faction and battle over Bases on a Faster Twitch-based `Micro` scale. The actions of Kings generates quest for the Knights - Knight's success/failure effect Kings ability to control a territory. Although the genres play from different perspectives and game mechanics, they can share the same Assets and Lore.

Alucard94
13
Years of Service
User Offline
Joined: 9th Jul 2007
Location: Stockholm, Sweden.
Posted: 4th Oct 2008 16:35
You're really putting a lot of planning into this, which is very good for me to hear rather than the usual "I wanna make pwn MMO plz?!" that we usually get.
This is going to be awesome.


Alucard94, the member of the future of the past.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 8th Oct 2008 09:52 Edited at: 9th Oct 2008 18:16
Rumble Tone Generation System - Force Feedback Headphones

DarkMORG Client features a Rumble Tone Generation System to produce Rumble effects using ForceFeedback Headphones and other `Bass Shakers` (Tactile Transducers) Devices.

I elected to use this system because 1) I own a eDimensions AudioFX Headset, 2)Flexibility, 3) Ease-of-use. The system is relatively simple, essentially playing a variety of low frequency samples at varyied pitch and volume to generate Rumble Tone during certain events suchs Quakes, Explosions, etc. Some tones are below hearing range, thus, generate only a vibration.

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 9th Nov 2008 22:56 Edited at: 9th Jan 2009 21:20
Rate my Login Screen Version 3 (Click to view Full Screen) Note: The URL takes you to the Production Host Server and Login Menu Image also used by the Game Client.

Sergey K
17
Years of Service
User Offline
Joined: 4th Jan 2004
Location:
Posted: 10th Nov 2008 09:45
lol too many projects with name DARK inside =/
DarkMORPG, DarkSDK, DarkPhysics, etc. etc. etc.

but nice scatching you did there with it, TechLord.

Get DBP stuff here! - (plugins/models/scripts and more!)
Rampage
13
Years of Service
User Offline
Joined: 4th Feb 2008
Location: New Zealand
Posted: 11th Nov 2008 05:55
Wow this looks great, really looking forward to this one

[url=
"Welcome to the forums, MasterXMP. Your game looks like garbage..." - Game Maker
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 24th Dec 2008 05:47 Edited at: 31st Jan 2009 17:03
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 25th Dec 2008 22:12
Communication Systems

I've been pondering over Communication System Features this week. IMHO, this is an area that could use some innovation.

I'm brainstorming ways to deal with `Hyper-Action` (ala FPS Style) and slower-paced activities (social chatting) in the most efficient manner based on simple rule-of-thumb: Faster Action, Less Reading & Typing / Slower Action, More Reading & Typing.

I personally find it way too difficult to type and shoot in FPS Combat. Voice Headsets solve some issues, but, I like text. To deal with this, I'm looking at Word Prediction, Menu-Driven Messaging, and other AV Messaging such as Animated Gestures and SoundFX tiggered at the press of a key.

For slower paced scenarios I desire a traditional Chat and a full command language similar to MUDs. I lot of my inspirations in this department are from MUDs. MUDs such as Achaea provide a deep richness to its world through detailed text descriptions. I believe text-based descriptions can compliment Audio Visuals in a Graphical MMORPG by describing how things smell, taste, and feel to the touch.

A dimly lit cave.
The closeness of the walls in this cavern can be more felt than seen. The musty scent of packed earth is intermingled with the woodsy, rich smell of roots. What dim light filters through this place comes from a narrow opening in one wall, grown over from the outside with a dense curtain of ivy. Pasiphae stands
here in a simple grey cloak. You see a single exit leading out.


With that said, there is time for reading and it isnt when you have Plasma Spheres crackling and whizzing over your head.

Other Thoughts...

I dislike repetative NPC dialog when the scripted dialog runs out. My solution to this is implementating a Chatbot Tech as a interactive `Dialog Filler `. I'm also considering bolting on Search Engine to NPCs so players can ask questions and get relavant answers (although I prefer and encourage players help players.)

Text-based mini-games. This is my `easter-egg` tribute to the TeleType. Back in my military days, the good ole teletype would provide hours of entertainment playing Two Player Turn-based Games such as Battleship/Chess/Tic-Tac-Toe, and Hangman. Access to these games would be available anytime by simply typing a command like `PLAY CHESS WITH <CharacterName here>`.

to be continued...

FireIndy
14
Years of Service
User Offline
Joined: 17th Jan 2007
Location: US of A
Posted: 26th Dec 2008 17:04
This is really interesting, and awesome that your putting so much planning into this. I think your doing great on this. Also the Boomer from Left 4 Dead XD. Just saying. But great work you have going man.

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 27th Dec 2008 16:15
Hi FireIndy

Interestingly, the original concept for the game to be made with DarkMORG would have been a MMO version of Left 4 Dead. But, I tossed the Human vs Zombie setting for a more diverse and opened theme dealing with Dimensional Rifts (DRifters). There will still be zombies, but, thats not focus.

Sigh
15
Years of Service
User Offline
Joined: 26th Dec 2005
Location: The Big 80s
Posted: 27th Dec 2008 19:23
Wow, good work TechLord.

A number your ideas seems quite similar to mine (or vice-versa), especially your MECs.

Fighting the War Against Misused Apostrophes since 2002! Stop by for a chat! [IXE]Nateholio on irc.maxgaming.net:6667 #GarageGames
AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 27th Dec 2008 20:14 Edited at: 27th Dec 2008 20:35
Hi,

I just take a look at your work and planing. You did a graet work until now. I myself work on an MMG game now several years. To generate a theory how to do is most of the part before writing any line of code.

I just bought DBPro and work me into it. But one thing I can tell you after short time. It is not perfect for making an MMG itself but a good base to start.

My project will splitt the clanmanagment and a stock tradesystem out of the 3D engine (not completly but up to 80%) and the clanmanagment should be accessable via HTTP too. I think the clanmanagement is about half of the code I had to write and I start with this.
I plan to split CPU Power to external tasks (written in TclTk / LUA) especialy to have the posibility to use a Linux Server for serveral tasks (it's more stable and I can generate webpages out of the game too) I plan to use the pipe/socket ability of TclTk to build up workers that do data management and precalculating parallel to the DBPro engine. So the CPU load for the 3D Game is reduced. With TclTK I can access MySql and do a lot of work (Tradesystem, Itemhandling ...) out of DBPro.

I just will do as you a portal system to split the players to servers. But what happens when more then 512 players will play in the same area? Split it to different servers means to syncronize all content on more than one server. Here also DBPro alone will not do the task that's why I decide to do with multible programming languages.

Now I look for a posibility to connect DBPro to TclTk pipes/sockets to allow a dataflow between this two languages. Maybe I use a LUA addon (Luasocket) or an TCL addon (Winlua). Best would be to have the posibility to use DBPro funktions to etabish a data transfer without using special addons or programming a DLL for that perpose.

Paralell to that I code testing programms for balancing combat and the skill system. (I will use a very complex dynamic skill system) Also I work on theory of logging several parameters like tradings, where players gamble around, chatlogs ... That are needed parts to hold a MMG alive. MMG are not just coding the game itself but to plan a lot around it's running in the future. Because I plan to have a lot of dynamic game content I plan and simulate a way of syncronizing it on all running servrs.

I always look out to learn from others doing work on an MMG and to share knowledge.

Best regards

Alfred
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 29th Dec 2008 12:01 Edited at: 29th Dec 2008 12:50
Quote: "A number your ideas seems quite similar to mine (or vice-versa), especially your MECs."
Sigh, Great minds, think alike!
I'm interested in hearing how you propose to develop your Modular Entity Construction System. Especially for Characters.

AlfJan, I'm writting both the server and client with DBPro. I strongly believe DBPro can handle a MMO with use of Plugins. There are several powerful (FREE) plugins: IanM's Matix1Utils, Barnski's LUA Plugin and many others that will instantly boost the potential of DBP. I've also purchased DarkPhysics, DarkAI and others DB plugins to ease my development.

My network lib is custom built with Matrix1Util #28. I've designed the Client to operate online ONLY, loading all media and logic (scripts and data files) from a remote server via HTTP upon demand. I use a combination of PHP, XML, and LUA languages for data formatting and scripting. Communication with the MySQL Database is also achieved via HTTP using Server-side PHP.

I hosting HTTP/FTP/Database at www.HPQuest.com. The `Host` Server job is to host all the files and DB records. The Game Server (DBPro) job is to manage interaction between Player Input (twitch) and Object AI. The topology allows for simplified re-allocation and expansion.

Quote: "I just will do as you a portal system to split the players to servers. But what happens when more then 512 players will play in the same area?"
More than 512 players will require more servers. The Map Layering system I propose is a tough one to explain. I'm not using zones, but, more so Maps akin to FPS games. Players essentially pick a Quest, and play in their own `instance (aka layer)` of Map(s) for the Quest. Players essentially teleport from map to map.

To conserve resources on the server, a single copy of the Map's Static geometry is used for collision detection between all players and dynamic objects. However, collision between dynamic objects is only calculated between objects in the same Instance, thus, Maps with moving platforms, etc, require multiple copies.

Different Quest can share 1 or more Maps and 2 to 8 players can share an instance (upto 64 in a special map/quest). The total number of players/instances is scalable upto 512 Player `Slots`. I had planned to allocate Server Player Slots on a first-come, first-serve basis. However, This does present some synchronization challenges, but, I have options: Specified Player/Server Assignments, Reallocate Players/Quest to Servers with avaliable slots (Requires Sync).

May0naise
12
Years of Service
User Offline
Joined: 16th Nov 2008
Location: Lost in Time
Posted: 29th Dec 2008 14:16
Looks like it'll turn out amazing...Good look with it!

Be patient....everything takes time.
AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 29th Dec 2008 20:05
TechLord,

I now use the Matix1Utils too. It's easy to access a TclTK Server with it. All the Inverory and Statments of the player are running via socket in Tcl scripts. I plan to do more modules via Tcl scripts, because it ist easy to use them on different maschines. I also got LUA for DBPro (I just ordered it) because it gives more advantage for the Engine. I got also the AI modul and several others because they make development more easy and productiv.

My game will use FTP, Php and HTML also. You wrote that you do MySql access via HTTP/PHP that's a great idea an I will think over it. At moment I use plain Txt files to hold date, but in future I like more the idea to use MySql. I run my own webserver now for over 7 years and I discovered that MySql is not as fast as I wish it to bee but I will see. My game should also have a pure HTTP/PHP interface for some game aspects like clan-/guildmanagemnt, trading, chatting....

In one aspect we differ. My game would be more an rpg (sifi style) with an huge ability system (should dynamicly be expandable) a comlex crafting system and a clan-/guildsystem that will allow to manage a lot of user wishes. I will give the players also the ability to "play" when they are not online. They can decide what ther character focuses in there offline time (studiing, earning mony fro semiautoqueste, produce stuff ...).

Estimating that the tradesystem, inventary, guildmanagment, abilitycontrolling etc is on a seperate server(s) I plan to host 1000 player per server. I'm not shure if the world should be a portaled or a seamless design. But just I work not on that aspect. I do work on the non graphical side of the game first.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 30th Dec 2008 12:30 Edited at: 30th Dec 2008 12:44
AlfJan,

Player-Creation is top priority in my design. Players create content and quest (essentially creating their own themes). So in my opinion the `Game World` should support a `open-lore` in which many possible themes and hybrids like Elves with Guns or Cowboys on Dragons can exist. I asked myself what person, place or thing could tie these different worlds together? What could tie these different `dimensions` together? A lil voice in back my head answered: Dimensional Rifts (DRifters). So I provide a tiny but powerful background Lore based on DRifters for Players to build their stories on top of.

I'm also planning several types of client-based and web-based `meta-games` to support the MMO world. I'm dividing the meta-games between the client/browser based on a simple rule of thumb: Real-time Activities: Questing, Combat, Chat --> Client. Turn-based, Time-Consuming, and otherwise tedious activity (such as player control shops): --> Browser. The premise is to use the same Assets and Data to create different games that affect one another.

For example, a Meta-Game concept thats on burner is the development of a separate MMORTS and MMOFPS that influence the political power between Factions within the MMORPG. 1) Kings: A MMORTS Game in which Player's battle for control over Terriorities on a Slower Turn-based `Macro` Scale. 2) Knights: MMOFPS in which Players select a Faction and battle over Bases on a Faster Twitch-based `Micro` scale. The actions of Kings generates quest for the Knights - Knight's success/failure effect Kings ability to control a territory. The affect of both influences changes in the MMORPG.

AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 30th Dec 2008 15:53
TechLord,

Quote: "Player-Creation is top priority in my design. Players create content and quest (essentially creating their own themes)."


In my game also. Specaly in clan-/guildmanager a plan a NPC to be used to finish open quests and to give a defined reward. All quets there should be designable from the clanmanagement tool. My game will also go into detail of object the players could find. They can learn out of it "new technologie" and if they have the ability design new/modified ofjects for there need and for sell in game. The object that are used will have abrasion and must be repaired themself or by NPC. The clanhall should be widthly designable by the clan managmenttool. I build a background by myself to give a base for players to generate backround for there chars.

The chars can die also but this will not end the game each char could have a child which will inhert the parents belongings and some of his abilitis (depending on time the parent spend to be with his child). The gene of the childs will be build out of the parents one. That make it posible to develop special abilitys in future generations of players.

That ist a long list of programming to do and I am far away to end. I like to build a game that have a large posibility to use dynamic objects and to make the game expandable in each way. I myself played long time rpg but always was frustrated of the static quests and concept. That's why I try to have an newer concept.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 31st Dec 2008 10:44 Edited at: 31st Dec 2008 13:28
Quote: "The chars can die also but this will not end the game each char could have a child which will inhert the parents belongings and some of his abilitis (depending on time the parent spend to be with his child). The gene of the childs will be build out of the parents one. That make it posible to develop special abilitys in future generations of players."


`Genetic Inheritance`, Interesting. So does the child follow the parent on quest? Does the parent have to protect the child from danger? Can a parent raise more than one child at a time. I'm probably going in the wrong direction with this but, I could see some interestinng game mechanics with the concept of children.

I honestly want to put 90% of the `Game Creation` into the hands of the players, relieving myself of the responsibility. With that said I'm only offering:
1) High performance network/graphics FPS engine on the client.
2) Dimensional Rifts (DRifters) Background Lore
3) RPG Game mechanics based on my own Elemental DRifter RPG Ruleset.
4) User-Friendly Creation Tools for Entity and Story Creation.

I use a inheritance and modular contruction for every aspect of the game engine/game. I'm hoping to promote rapid content production by doing so. Most of my inspirations for my project have come from every other type of game, except MMORPGs (only played two: Tantra, ShadowBane). So, I'm not going conventional.

Characters

There are no predefined Player races. Players create a humanoid character from a extensive set of appearance and functional (Perks & Quirks) customization options. Options can be selectively packaged and saved as a Template made available to the public for use.

Classes

There are no predefined Player Classes. Players learn and develop the skills they desire from a catalog of skills/subskills. Skills/Subskills can be selectively arranged in Skill Trees and saved as Templates made available to the public for use.

Quests

Quest Masters define all aspects of their quest to inlcude Storytelling (NPC, Dialog), Challenges (Mobs, Puzzles) and Rewards (Gear and Points). Players apply Gear and Points where they see fit. There is no automatic leveling. Quest can be saved as Templates made available to the public for use.

Guilds

There are no predefined factions or guilds. Players can design their own `Insignia`, define their own ByLaws, and establish their own Leaders. Players are allowed to regulate themselves by setting up permissions and banning Members, etc. Players can only join one Guild at a time, however, they are allowed to change Guilds at any time. Insignia and Bylaws can be saved as Templates made avaliable to the public for use.

Crafting

There is no explicit `crafting` system other then the Player-Creation tools. I'm considering using `crafting` in the RTS Meta-Game. Currently no solid plan for crafting.

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 31st Dec 2008 13:35 Edited at: 1st Jan 2009 13:25
I'm seriously considering a Age Restriction (18+). This may be required to include skill-based tournament gaming features, mature content, and unconventional marketing stategies.

AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 1st Jan 2009 14:22
Quote: "`Genetic Inheritance`, Interesting. So does the child follow the parent on quest? Does the parent have to protect the child from danger?"


The children dont follow the quest and the are only playable after death of the Parents. One child per player. The have not to protect her child but to invest time (education) and monye for education and live. I simplify the gen system in a few parts as stregth, inteligence, willpower etc. There are dominant parts that will succeed in transfering genes.

An example: D = Dominant N = Nondominat
Father Inteligence 12N; Strenth 10D
Mother Inteligence 14D; Strenth 8N

Intelligence of Child: iteger(12+(14*2))/3 = 13
Strength of Child: ((10*2)+8)/3 = 9

There will be two childs one for Player A and one for Player B

The abilitys of the Parents could be transvered to the children be education, depending of the ablity to teach them (an charakterability) and the time that ist invested in the time they are together with the child(s).

I'd like to allow player creations too. But until now I have no idea how to handle ist. Especialy the crafting system should allow to medel new objects. Like a better gun, a handheld, a robot for exploring areas ...

The player can explore large areas for new technologie and learn out of it to build new and better equipment. Or just sell information or teach other some concepts for Monye. It is a bit oriented on shadowrun.

Player characters are only humans. But there is a posibility to modify to a cyborg to get better reflex or strength but that reduce the ability to use psyonic (magic).

There are no classes defined. You can learn a lot of abilitys. Your class is selfmade by the abilitys you learn. You can go to a width range or specialise. Fightng, electronic, chemistry, biologie all the abilitys for real live will be learnable and can be used to secceed in quests.

Quests are both given by an admin team (recruit out of players is possible and a goal) and by players. Look for an information, a new tool, a person wich can teach with an certan level of knolledge of maybe electronic. Then there will be random quests that are only for the time player are of. With them there is an income possible to finance the char. It's like a timeplan you have to do for offlineplaying. You tell the system what kind of quests you like to do, how many time you spend for you child, your education, training ... that all will run when you are offline. All quests that are made by stuff are dynamic and can generate new quests, depending on succeed or failure of players (or playergroups). All the player behavior will inflict all the game for all other players too.

The guilds are a great tool in game. They offer working places (buyable) that raise you abilitys. For example a elecronic laboratory will raise you ability in electronic in a range between 5 and 25%. It depands on the stuff they put inside. Thre are players residence, puplic rooms, a bank, clan storeage(s) (items are tagable and goes back to the guild when a menber leaves that guild, free guilsstructure (exept guild founder) with an aditional title system. A rigth system in with you can define if the rank can post in certain cannels, manage the guild finances, allow others to lent object out of the gulíldstorages and a lot of more ideas. The guild system is about 30% of the game content. Guild insigna not only for clothes but also for objects. A training area that ist selfdesignable and to modify. (The guilds have to buy t´some stuff and it can be placed in the trainings area. A stock trade system for individual traids and for guild traids. A guild forum and hopmepage. With individual opages for members whith will show there growing and succeed in game (if the player alow it) directly out of the game. A good member management with guildfee, warnings, statistics and so on.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 2nd Jan 2009 15:17 Edited at: 2nd Jan 2009 15:33
Quote: "You wrote that you do MySql access via HTTP/PHP that's a great idea an I will think over it."


MMO_DatabaseConnection.php


MMO_DatabaseQuery.php


HTTP Submission String with URL Encoding


I wrote a special http function to parse the return data (using Chr 12 as the delimiter) and stores into a Array (Table), but that is the jest of it.

AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 8th Jan 2009 18:40
I will work on a more direct mysql connection. I will post here all samples when I'm ready. I hope I can do it this weekend.
AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 10th Jan 2009 14:25
Hi,

I have done some code but it is to much to post it here. I make an FTP directry on my server. Just connect to ftp://ntse.de there is a DarkBasic folder and inside a Archiv.zip. All files that I describe here are in that file.

I put in that zip an USB webserver with it you can run an Apache Webserver with php and mysql on your local PC to test and develop your webtools and mine. There is also a build in SMTP server and I plan to do a tool to send and receive mails directly in game.

Just unzip the file in a blank folder and start the USB webserver (http://www.usbwebserver.com/ here the original link but the site is danish.). The Web Server itself is english. Start the mysql-server.exe and after this the darkbasic mysql.exe (both tools are using port 9999 on localhost. It's a simple call of a select statement via TCL. In the string you get back are all results of the sql statment. Each row in { } and each string that contains blanks is enclosed by { } too.

There are several advantage about using that TCL socket. It runs under windows and (with an other library for mysql access) under unix without changes. The mysql-server.exe is encoded to avoid cheating by users. You can run that socket on a server or on client side to reduce pervormance problems on server.

There is a tool inside named FreeWrap you can dowload from http://freewrap.sourceforge.net/. It's free and well documented. It's a standalone TCL Wraper to generate all extensions in TCL.

If you do via PHP you have an aditional layer (http -> php -> mysql). Using the TCL script you just have (TCL -> mysql).

You can also do all mailing and FTP via TCL. I plan to work on an FTP tool to download updates and changed datas in backround. To split the work in several modules will grant the posibility to focus on the 3D part in DarkBasic. You can also put some logic into the mysql interface to prepare or calculate date after doing the sql statement. That spares the coding inside DarkBasic and the modules can easy placed on another server/client to increase the performance.

I think over it and I find that our ideas are not so different. Why not sharing parts of your development? I start on the other end of developing the application. My fist work will be the Guild/Clan management that is stand alone from the other data. Just the player ID must be syncronized. That means you can use (but must not) a different mysql server to increase performance. Some parts of the management are planed to be done form inside the game but most are via http and php. Some data must be shared into the other sql-server like 3D trainingground that I plan to let the clan build by need. (using prefabs) that will be placed by the clan and loaded into the game.

Maybe you are interested in sharing the work. In that case I can open my ftp server for you to give you the posibility to upload and manage data. That will also give you the posibility to test the FTP parts you plan to use.

Here some of the code:

First the TCL Mysql Server.



Here the darkbasic part.



The errorhandling in the TCL part can be improved to give back the mysql error massage and a logging posibility should be worked in. Until now it's still a working example.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 12th Jan 2009 11:27
Hi AlfJan,

TCL looks pretty slick, but, I'm sticking with what I'm familar with. In the beginning I was concerned about extra layers (HTTP -> PHP -> MYSQL), surprizingly, the performance has been acceptable. I'm also using XML for formatting data such as GUIs, so using PHP to output XML works well too. I have also elected to exclusively upload/download data via HTTP.

Quote: "I think over it and I find that our ideas are not so different. Why not sharing parts of your development? ...Maybe you are interested in sharing the work. In that case I can open my ftp server for you to give you the posibility to upload and manage data. That will also give you the possibility to test the FTP parts you plan to use."


Thanks for the offer, I already have a Hosted FTP/HTTP/Database Server @ www.HPQuest.com. I agree there are some similarities in our Project concepts, but unfortunately, I cannot commit to any particular `sharing work` arrangements at this time. I will continue to share any ideas, etc as time permits.

I'm curious as to why the Guild/Clan Mgmt Data is `stand alone`. I understand the Clan Mgmt Feature is a highlight, but, I fail to see any obvious priority for it to be stand alone. Keep in mind I'm not versed in clan management, so I could be overlooking key factors for your decision. Can you elaborate on your reason behind this, maybe i need to consider this.

AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 13th Jan 2009 15:53 Edited at: 13th Jan 2009 17:37
Hi TechLord,

you find your way do do, that's best. I'm a software engineer and in my job I have to deal a lot with databases. Specialy Oracle and MySql. I write interfaces between that databases and application for our intranet to visualate results from the tabels and give the opportiunity to let people do some adminitration of them via PHP.

It's ok not to share work at the moment. It was just an offer to spare some worktime on both sides. But it's great to discuss several aspects of our working process.

Ok then to the Clan/Guild management. Why (nearly standalone). For the tables you need in the 3D enviroment about 10% the rest is just for Guild perpose and need no data or code in DarkBasic. An example: you need access to the player-id and password for logging in. (Form outside of the 3D enviroment). The player datas need only an entry to what guild he belongs. Fees and stuff for the guild must be taken out of the sponsoring player, why keep in game until someone need. I write a "transferbox" form player to guild and reverse. Most in the guild tool are lists, equipment rooms where players can rent tools, info boards, guild messaging, forum, managment of members and of course a charakter managment. It's more easy to manage the charakter more clearly outside of game then to write a huge GUI for ingame managing. A lot of people whant to look and manage a guild from there workingplace or an journey. Some had to travel for ther job and dont want to be completly out of the game.

I will write a stock trade system also as seperate module. If an Object is offered it must go out of players hands to solve cheating others. A "transferbox" will manage putting objects in the stock system and get objects out.

I thought long time about it and there are just only pro's:

1. Better errorhandling and development because of seperate modules. (The code is not so hugh also) An error will not hang up the hole engine.
2. Better update posibilitys be using more independet modules.
3. Reducing code inside DarkBasic. Concentrate on the real meaning of a 3D engine, to do 3D work. All other things can be done outside with better (more readable) interfaces.
4. Playersecurity. Prevent cheating etc.
5. The posibility to run a few MySql servers on diferent PC's to increase performance and playercounts per layer by reducing non 3D code in DarkBasic.
6. It's easier to implement new functionality per modulprogramming.

Thats a short description of reasons I found to go that way in development.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 19th Jan 2009 03:01 Edited at: 23rd Jan 2009 08:46
Moderated Open Repository Part II




Moderated Open Repository is coming together along with Editor. I've setteled on using HTTP to upload Media Assets (2D,3D,Audio) created with 3rd Party Tools (ie:Blender, Gimp) to the Host Server FileSystem via The Asset Uploader.

Below is an screenshot of an uploaded test model to MOR and from MOR into the Client MEC Editor.




AlfJan
12
Years of Service
User Offline
Joined: 5th Dec 2008
Location: Germany
Posted: 22nd Jan 2009 16:44 Edited at: 22nd Jan 2009 16:44
How will you manage a correct scaling? If player a makes 1 meter with 64 length and an other with 128. In the end the player had a to big or to small object in hand or equiped.

I will excuse myself for my bad english. It's not my native language and even if I read my textes three times I found spelling errors when I read it once again.
TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 23rd Jan 2009 08:52
Quote: "How will you manage a correct scaling? If player a makes 1 meter with 64 length and an other with 128. In the end the player had a to big or to small object in hand or equiped."

1. Example models will be provided.
2. Quality Assurance - manual inspection and correction by Devs prior to moving asset into production.

TechLord
18
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 23rd Jan 2009 20:59 Edited at: 23rd Jan 2009 21:12
For the past week, I've been working out the Economics for META-Lore. After some serious consideration, I've decided to totally remove all coin (ie gold, plats, etc) from my MMO in favor of the crafting/exchange of Raw Materials and Items. Essentially EVERYTHING is crafted from Raw Materials or built from smaller items: Elementals --> Raw Materials --> Items --> Ultras/Structures/Machines.



I've decided to start with 6 Elementals: Water, Air, Earth, Fire, Light, Dark which form N number of Raw Materials. N Number of Raw Mats are manually combined to craft Items. N Number of Items are manually combined to create Ultras.

Login to post a reply

Server time is: 2021-03-05 10:26:51
Your offset time is: 2021-03-05 10:26:51