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.

Game Design Theory / Radical Game Systems Concept & Theories

Author
Message
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 12:18 Edited at: 5th Dec 2009 12:23
Link
In developing the most Radical DGDK Game Engine & MMO in the history of Computer game creation, several conceptual systems are on the drawing board to bring these creations to life.

LOL, that intro is over-the-top, but, I wanted to discuss conceptual game systems, techniques, etc that are going into your games to pull off a unique feature, optimization, effect. To start the topic off I present you with:

MODULAR ENTITY CONSTRUCTION SETS (MECS)


There is no doubt that Model Packs provide awesome artwork for an affordable price. My problem with purchasing Model Packs is knowing that the same Art Assets are being used by others. It is strongly desired that my game, has its own distinctive `look`. I've purchased packs and modified textures to provide some variation, but, thats not enough.

That is one motivation behind what I believe to be a unique approach to Model Packs and Entity construction within S3GE. A system I call, Modular Entity Construction Sets (MECs). The premise behind MECs is to provide modelled/textured Parts that can be assembled to create countless Entity variations.

Customization was the second motivator. I enjoy playing RPGs and Racers in which you can customize the appearance of your character/racer by changing parts. I realized that practically every 3D entity could be customized, although, maybe not necessary. Such a flexible Entity Creation System could prove in valuable creating large amounts of prefabricated and procedurally created 3D assets.

Inspired by Toy Construction Sets (ie Tinker Toys, Knex, etc), MECs uses a system of blocks & connectors to create classes of entities: Character Bodies/Heads, Furniture Props, FireArm Weapons, Melee Weapons, Trees/Plants, Vehicles/Crafts, and Machines; Blocks and Connectors create Parts which can be interchanged to create numerous variations within each Class of Entity.



MECs Key Features:

Standardized MECS Format. An XML-based Format that supports bone/keyframe/procedural/physics controlled animation, Level Of Detail, Shader Maps, Channelized Textures Map, and other requirements applied to 3D Entities. A standard labeling for Meshes, Bones, Animation, and Textures.

MECs 3D Plug-in that imports MECS Format into game engine/application. The Plug-in also supports parts welding & morphing, texture blending to create single piece entities when necessary.

The MECS Construct

Defines a MECS Building Block/Accessory and its Connectors.

Block: 3D Mesh in which one more Connectors are added.
- Block Skin: Textures, Maps and Shaders applied to a Block

Accessory: Audio/Visual or Virtual Object in which one more Connectors are added.
- FX Objects: Particle Emitters, LensFlares
- 3D Objects: Mesh, Lights, Camera, Sound
- Physics Objects: Cloth, Hit Objects

Connector: A connection point in which a Blocks and Accessories are connected.

- Mount: A external connector added to mesh or internal point defined within the mesh used to connect Parts & Accessories at runtime. Gender determines Parent/Child Relation between block and connector. Mounts have 3 types of Genders: Slot/Peg/Any. Slots are Parented by Blocks, Blocks are Parented by Pegs, Only Slot to Peg relationship allowed between specified Mounts of either gender. If the connection gender is any is used as standard mount

- Bone: two connecting points defined within a mesh used for bone animation. The two points maintain a Parent/Child relationship defined by the animation data. Two Bones connect to each other, at the points of the same name. Bones can be assigned a gender to connect to Mounts and Joints.

- Joint: Physics Rigid Body Joint often used in Machines: 6DOF, Clyindrical, Distance, Fixed, Point in Plane, Point on Line, Prismatic,Pully, Revolute, Sphere.

- Weld: A vertex point defined within a mesh and assigned to be used for (magnetic threshold) welding of two meshes together to create a single seamless mesh. Welds have two genders: Positive|Negative.

The MECS Entity Class

Defines a Game Entity Class, its Parts, and Assembly Hierarchy.

Class Part
- Core: Base Part in which Limb Parts connect. Mandatory for Entity Assembly.
- Limb: Extension Component that connects to Core or Limb.

Common Entity Classes:
* TerraForms (Terrain + Sky + Celetstrial Body + Fluidbody + Cloud)
* Building (Interior|Exteriors)
* Structure
* Trees & Plants
* Character Head
* Character Body
* Firearm
* Projectile
* Melee Weapon
* Prop
* Furniture
* Vehicle and Crafts
* Machines
* Items (Single Block with Connectors)

The MECS Entity

Defines a individual Instance of a Entity Class

Entity Part: Single Construct or Composite Construct

MECS XML Format


The Entity Class Hierarchy defines a Game Entity and the Class of Parts used to assemble it. Examples of Game Entities would be: Buildings, Trees & Plants, Character Heads & Bodies, Firearms, Melee Weapons, Props/Furniture, Vehicle & Crafts, etc. An example of Class of Parts would be like the FireArm Class illustration above. These are common entities found in games and the system is flexible enough to accomodate any others if needed. You can also create Sub Classes within the Classes for example Character Bodies: BiPed, Quadriped, Octopod, etc.

There are two types of Class Parts: Core and Limb. At minimum, one Core class part must be defined within a Class/subclass. The Core Class Part is usually the primary or central part in which limbs connect to. It can be used as the starting point. In the case of the Firearm Entity Class, I selected the Chamber as the Core class part (I named it Chamber for the lack of a better name, it was better than Core, lol). You can also optionally make limbs mandatory for assembly within a Entity class hierarchy.

The Class Hierarchy only defines what class of parts makes up a Entity, not what makes up the parts. In some cases the Entity Class is used to define a part (ie Character Head with parts for eyes, nose, mouth, ears). To create a part, we first start with a Construct. A Constuct consists of a one 3D/FX/Physics Object (Block) and one or more Connection Points (Connectors). A Part can consists of 1 or more Construct(s).

Entities -> Class -> Class Type (SubClass) -> Class Part -> Part -> {Construct(s) = Block + Connector(s)}

The connection system in MECS is the highlight of the system. Connectors tell MECS how and where parts connect. Connectors are defined within the Mesh (ie: Bones) and externally with the MECS Editor. Creating a Constuct should be as simple as 1)Loading in the Mesh; 2)Add and orientate Connectors; 3) Exporting MECS File Format. Connectors will also contain additional parameters to ensure that the foot bone connected to the lowerleg bone, and the lowerleg bone connected to the upperleg bone... All of these features will supported within the MECS File Format and MECS will know from the information how to assemble the entity.

I believe the current hierarchy is sufficient for futuristic and modern firearm assembly. I have a vague idea of what the bone and mesh def animation it will require dependent on the part and weapon states. I was drawing most of concept for firearm animation from characters. I havent put a list together for character bodies, but, I anticipate the following:

{character head} (core) -> neck <- chest
lower torso -> upper torso -> chest -> upper arm -> lower arm -> hand
lower torso -> upper leg -> lower leg -> foot

I intend to provide MECS with standard Texture, Maps, and Shaders support. In MECS textures/Shaders are treated as a interchangeable `Skin`. Ultimately, MECS just provides a means of export/import/assembly of 3D Game Entities with utilities that allow Developers to texture, animate, etc as they see fit.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 12:21 Edited at: 5th Dec 2009 12:36
Link
CHANNELIZED IMAGE MAP PROCESSOR


CHIMP was inspired by TextureMax. TextureMax is an Application & API that can be used to separate images into channels and then apply different colours to each channel adding instant variation to your media. This level of customization is often seen in RPGs but is applicable to all textures and images. Unfortunately, theres no freely available solution like TextureMax for DGDK, so I started designing Channelized Image Map Processor (CHIMP) based on how think TextureMAX works.

The TextureMax Application is basically a Drawing App that allows you 1) Load the Texture Image as a backdrop; 2) Create image map of virtual channels specified by a separate color; 3) You paint the image map pixel-by-pixel in specified channel color; 4) When painting is complete you export the image map with the information on the texture, channel and pixel data in the TMX format. 5) When Loading TMX, TextureMAX creates separate image memblocks per channel to draw texture pixels defined by the channel and pixel data within the TMX format. 6) With the texture separated into channel images you apply image filtering effects such as color/blending/brightness/possibly others? to each individually using API commands.

The above is all theory and I really don't know how TextureMax works, but, if its slightly correct, then it may be possible to use any full-powered layer-based Drawing software (Photoshop, Paint.net, GIMP) to output a `Channel` Image Map (CHIMP). The CHIMP would consist of 2 or more solid color areas to represent channels. The CHIMP Importer, would load both the texture and channel image map, than create separate image memblocks based pixel colors in the channel image map and draw the texture pixels based on corresponding pixels in the channel imagemap.



Left: Texture. Right: Channel Image Map. The Channel Image Map was drawn with GIMP using 2 layers: 1)image map (top layer), 2)texture backdrop (bottom layer). By simply adjusting the opacity on layer 1, I was able to use the toolbox to draw several different colored channels within a few minutes. When complete, hide the texture backdrop, set layer 1 opacity to 100%, and save the image map layer in desired DB compatible image format.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 12:25 Edited at: 5th Dec 2009 12:27
Link
GUNVERTOR MODULAR FPS WEAPON SYSTEM


I have long desired to develop a RPG with a FPS Combat/Weapon System. For many years, I persued the creation of a such a game that would feature my Modular FPS Weapon System, I've affectionately dubbed GunVertor. The orignal premise behind GunVertor is a Modular FPS Weapon & HUD System that could be assembled into virtually a countless assortment of weapon designs.

When developing the system for an RPG, I realized that the weapon could become the embodiment of the character building. Weapons are assembled from interconnecting weapon components. Each component possess statistic variables that impacts the player's control, weapon performance, ammunition visual effect and damage.

So instead of the Player just customizing a Character, equipping weapons with no ownership value; the player is the Character and customizes their FPS Weapon to fit their style of game play and individuality. After all, The BFG is the hallmark of the FPS.



Gunvertor Weapon System


Quote: "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.

Deflector (not shown): This accessory attaches to the Chamber or Barrel providing defense shield capability."

Firearm Entity Class


Firearm Modelled Parts (simulated)


As a RPG, GunVertor would implement character progression with component upgrades for customizing/enhancing your weapon, instead of upgraded weapon prefabs. My goal with GunVertor would be to put an enormous amounts of detail into the appearance, animation, function, and stats of the components. IMO, in a FPS the weapons should be eyecandy. Thats what I've always appreciated about Unreal, their FPS weapons appearance and animations are top notch.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 12:44 Edited at: 6th Dec 2009 09:51
Link
MODERATED OPEN REPOSITORY


The Game Engine is designed with a heavy emphasis on Shared and 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

The Game Engine Host Server, MOR, and Client utilize a simple and identical Directory Structure to maintain files. All files are required to have a unique name.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 13:00 Edited at: 6th Dec 2009 10:04
Link
MULTI-APP USER INTERFACE (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.

I desire 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 the Engines 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.



Behaviors can also be scripted to use two or more Gizmos to operate as a Composite Gizmo such as a Dropdown Box. These types of Behaviors rely on MAUI's Gizmo Family Linking System in which Parent|Child|Sibling relationships are automatically established between Gizmos during creation. In the Parent-Child relationship, the Parent usually influences the Child. Gizmos that share the same Parent are Siblings. MAUI uses Family-Linking for both operational and performance purposes.

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






Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 13:06 Edited at: 5th Dec 2009 13:07
Link
BEHAVIORAL RULES A.I. NODES SYSTEM (BRAINS)


BRAINS is a Finite State Machine Based AI that attempts to solve two questions:

Quote: "1) How to resolve player actions without writing hundreds of functions?

2) How to make the Bot (AI Agent) "smart" so that it will interact with different objects in the world in different ways.
"


BRAINS incorporates Give||Take Registry, Binary Decision Trees, Hit Objects (aka Triggers), Scripted Tasks, Pathfinding, and Q & A GUI 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 Collision 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.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 5th Dec 2009 13:11 Edited at: 5th Dec 2009 13:12
Link
THE DSCRIBE SYSTEM - SLASH/BLAST/CAST/PATHS


Want to do something different with the First Person perspective other than the weapon-glued-to-camera technique? Try the good ole Cursor-only on the screen technique.

The dScribe System is a First Person Weapons/Action Control System that uses the Mouse and Cursor(s) to draw Sword Slashes, Gun Blasts, Cast Magic, Movement Paths, and various other actions. The system provides a unique Point & Click interface suitable for fast past action within a First Person `Shooter` view and allows hand/weapons to be removed from view area. Another feature of the system detachment of cursor from the camera allow free movement of the cursor along XY axis. A variety of Animation and Movement techniques can be applied to the cursor. Animation, Special Effects, and Sound FX are applied to the `Scribe` (drawn line) coupled with traditional particle/lensflare/decal/shader effects.


Pathing: Draw Paths for movement using freeform, splines, etc. The MB is used to drop waypoints/spline points along the path.


Slashing: Draw Lines (straight & curve) that represent slash/wield strikes. The MB is held down during the `slash` and released upon completion.


Blasting: Mouse moves Cursor along X/Y. The MB is used to generate a Burst (instant Line Of Sight Damage) or Projectile when pressed/released.


Casting: Draw Symbols (Runes) that activate Spells. The MB is held/release to draw symbols. When the symbol is completed (via Digital Character Recognition) then the spell is activated.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 6th Dec 2009 10:28
Link
MANA++: A RPG SPELL SCRIPTure SYSTEM


I've pondered over the concept of using a Scripting Language in which players can create their own spells with various visual and damage effect. The Script may use Symbols & Images. Unlike a typical `language`, access to constructs, keywords, etc are driven by items and skills the player acquires. There could be point cost associated with writing/editing the spell, using certain keywords, the number of variables used, etc.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
BearCDP
14
Years of Service
User Offline
Joined: 7th Sep 2009
Location: NYC
Posted: 6th Dec 2009 23:00
Link
Why make it a script?

Anyway, this is a great presentation of ideas. MAUI looks great, and I always like FPS games in which you can get mouse-independence as in DSCRIBE. However, BRAINS is still throwing me for a loop, I'm going to have to sit down next weekend with your diagrams figure out some use cases to see how the concept works.

For MANA++, why make it a scripting language? Neverwinter Nights' authoring tools allowed you to create custom spells and custom effects in a GUI editor. Granted, they were probably not as complex as you were hoping to achieve, but I think its only flaw was how closely tied to type-damage the effects were. My friend made a special type of arrow that would do poison, fire, electric, ice, puncture, dark/evil or something, and some other type of damage and when the arrows hit it was like you got smacked with a rainbow.

Game Design, Audio, and Music Blog
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 8th Dec 2009 09:20 Edited at: 8th Dec 2009 09:26
Link
Quote: "For MANA++, why make it a scripting language?"

I honestly havent worked out details of Mana++ but, it wouldn't be a script in the conventional sense, and unlike NN authoring tools the `Spell Scripture` is part of the game.

Currently what I visualize is the Mage/Wizards `learning` words & constructs they use to write spells. What you can use in the spell would be limited to what words/constructs you have learned and level authorization.

There would also be a Mana point cost associated with writing the spell dependent on the words/constructs and effects used. Some spells may even have a drain cost to the caster dependent on the damage effect.

The Mage can store their spells in their Grimore, but, that can have upgradable restrictions such as how many spells it can hold, if spells can be stolen from it etc.

The idea behind Mana++ is to let magic casters be more involve with how their magic works and provide more creative freedom. I was also considering a different way to execute spells. In my concept RPG `TypeCasters`, players type out spells and actions to execute. Typing accuracy effects failure/success and damage multiplyiers.

PS: If you're interested, I wrote a DBPro version of MAUI here. I will be rewriting a more improved version with DGDK/C++ for Super 3D Game Engine.

Super 3D Game Engine (S3GE) - The Ultimate All-in-1 3D Game Engine in development with Dark GDK.
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 12th Dec 2009 14:11 Edited at: 9th Mar 2011 22:04
Link
RNG Arcade Game: A modern-day Action/Arcade Style Games of Chance that use RNG Scoring/Prize/Payout (Token/Cash based) Systems akin to Video Slot Machines. A RNG Arcade Game is designed to appeal the next Generation Gamble Gamer.

DGDK Open Source Project-Trio: Super 3D Game Engine/Editor/World - Multi-Genre 3D Game Production Platform {Online}
Back to top
Profile PM Email Website
TechLord
21
Years of Service
User Offline
Joined: 19th Dec 2002
Location: TheGameDevStore.com
Posted: 27th Jul 2019 21:06
Link
Never give up on your Dreams. This concept lives.
TheGameDevStore.com
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-04-26 03:19:35
Your offset time is: 2024-04-26 03:19:35