Super 3D Game Platform

Developers

  1. The User Manual

Contributors

  1. The Design Document
  2. The Tasks
  3. The Source
  4. The APIs

Downloads

Developers

  1. The Application

Contributors

  1. The Source (Zipped)
  2. The SVN Repository (GLUCOSE) Setup Instructions
    svn co https://glucose.svn.sourceforge.net/svnroot/glucose glucose

Super 3D Game Version 1.1
A Multi-Genre Game Development System

Platform (S3GP)
Engine (S3GE)
Tools (S3GEd)
World (S3GW)
Console (S3GC)
DRifters

Copyright © 2012 by F.L. Taylor, HPQuest.com

The Super 3D Game Platform originally started as the DarkGDK Open Source Project (DOSP) within the TGC Community 08/10/2009, S3GP evolved into a separate product with the intent of providing a FREE Commercial Grade GUI-Driven 3D Application/Game Development Platform suitable for Novice and Professional Application/Game Developers.

Super 3D Game Platform is a complete, self-contained 3D Application/Game Development Platform encompassing:

  1. Engine, High Performance Server/Client Engine to power Collaborative Networked Applications.
  2. Tools, Editing Suite to Create and Edit Application Content and Logic.
  3. World, Interactive Lobby with Social Entertainment.
  4. Console, Digital Distribution and Transaction Management Suite.
  5. DRifters, Featured Multi-Genre (Client) MMO powered by S3GP.

S3GP is designed with emphasis on Content Creation. Providing a High Performance Game Engine and Editor Suite to create unique assets quickly and Logic Creation Tools to experiment with various game mechanics without the need to program.

Consolidate! Consolidate! Consolidate!

S3GP is being designed with the intent to support many game genres {FPS, RPG, RTS, Puzzle, Arcade, etc} out-of-the-box and achieving this at a commercial level. To pull this off, we have to consolidate at every level of the development process. Starting with the consolidation of the game mechanics within each Genre:

  1. Examine as many genres as possible.
  2. Identify common systems.
  3. Consolidate and Merge Systems that share similar features. (Some of these consolidated systems will be non-traditional or experimental.)

The Modular Entity Construction Hierarchical Sets (MEChS) is an example of a experimental consolidated system. MEChS is a 3D Entity Construction System originally conceived with the intention of creating various customizable static/animated 3D entities for RPGs by inter-connecting different modeled part combinations. It was realized that the system could also be employed in other genres to:

  1. Create `whole` pre-fab entities useful in other types of games.
  2. User Entity Customization
  3. Parts-based Model Packs System.

MEChS consolidates Entity Creation and Customization for RPGs, Racers, etc into one system. Entity Creation and Customization also exist for games that normally don’t require it, which in itself can be exposed to present a new twist within the Game.

Top-Down Design

A top-down approach (also known as step-wise design) is essentially the breaking down of a system to gain insight into its compositional sub-systems. S3GP takes this approach utilizing a complex feature rich system to support one or more simpler systems. The motivation behind this philosophy is to consolidate systems starting with the most complex or elaborate systems. For example, using an Advanced Physics Engine for advance physics simulation and typical 2D Bound collision.

  1. Choose what type of Application you want to create? See S3GP Requirements.
  2. Choose your Role: Developer|User, then Join!
  3. Choose S3GP Download: Application | SVN Setup | Project Setup
  4. Review the Roadmap.
  5. Choose Tasks to work on.
In order to successfully compile and run S3GP, modifications specific to your local machine will be required. To make life easier for the Compiler (and ourselves) in locating libraries we make use of Environment Variables to point to the path of these libraries.

Many of the S3GP Libraries are cross-platform and use the CMake (Cross-platform Make) Build System to create a compiler specific Build. For S3GP, we are using VC++10. I’ve attempted to organize these Libraries with a standard folder hierarchy:

  • Library SDK
    • Library Root
    • Library Build

OGRE

OGRE and many OGRE AddOns use:

Milestones:

Refactoring S3GP for Component Object Game Systems (C.O.G.s)

  1. Functional Component-based GUI Framework. Once the GUI is functional, Applications can be developed using them.
    1. Goals: Refactor Entity Components Model into Engine Framework.
      1. Tasks:
        1. Write Components Framework (work in progress)
          1. Write `PubSub` Message System Module for Components Framework.
        2. Rewrite IOU Framework (GUI) for Components.
        3. Integrate OgreBullet for Components to replace Box2D 2D Physics, add 3D Physics.

Building a Better 3D GUI

  1. Function Multi-user Support

Required Hardware (Minimum)

  • Pentium III 1GHz or equivalent
  • 1 GB of hard disk space.
  • 512 MB of Ram.
  • Fully DirectX compatible Graphics Card with 256 MB Memory or more and Hardware 3D Acceleration for Shader 2.0 (such as vertex / pixel shaders)
  • DirectX compatible Sound Card.
  • Internet Modem

Required Software

  1. Windows XP (Home/Pro) / Vista
  2. Microsoft’s Visual C++ 2010 Express
  3. DirectX SDK VC++2010 February 2010 DirectX SDK
  4. BulletPhysics SDK
  5. Web Browser with 128bit Cipher Strength
  6. S3GP Project Software

Required Services

  1. Internet (Broadband Connectivity Recommended)

GLUCOSE

The Source Code and Resources for the Super 3D Game Platform are all managed under the GLUCOSE Project on SourceForge.net.

SVN Basics

There are two parts to SVN:

SVN Server – to store and share files over the internet. It tracks updates to files and who working on them. It sends files and tracking info to Clients.

SVN Client – you install on your local computer to communicate with SVN Server, storing files in a Windows Directory and displaying the status of the files based on Tracking info.

There are two SVN Client main operations:

Update – this means download the files from the server, and replace any files you did NOT modify with the newer ones from the server.

Commit – this uploads any files you DID modify since your last commit to the server, so everyone else can download the new files. Note: Every time someone commits something new or modified, the revision number goes up. This means you can always know how up to date your files are, from what revision they are at compared to that on the server.

You can view SVN files online via SourceForge http://glucose.svn.sourceforge.net/viewvc/glucose/ To communicate with the SVN Server you will need a SVN Client. TortoiseSVN and AnkhSVN (optional) come highly recommended, but, you can also use your own.

TortoiseSVN Setup

1. Download TortoiseSVN. 2. Install it. 3. Create DOSP Directory and [Right Click]. (DOSP SVN Directory Structure is aligned to that of the Dark GDK Directory) 4. You should now see an option “SVN Checkout” 5a. In “URL of repository”, paste this: https://glucose.svn.sourceforge.net/svnroot/glucose 5b. In “Checkout directory”, paste the path of the Dark GDK directory. Example: C:\Program Files\The Game Creators\DOSP 6. You are done!

For anyone who wants to use your own client, here is what you need:

svn co https://glucose.svn.sourceforge.net/svnroot/glucose

How to use TortoiseSVN:

Warning: It is highly recommended that Contributors, [Right Click] and choose SVN Update in the root SVN Directory before starting any work.

SVN will add and update matching files. The “Projects” Directory contains the VC++ Project Trio: S3GE (Engine), S3GEd (Editor), & S3GW (Super 3D Game World: The Game). All associated Libs, Includes, Media etc for the project, etc are filed in the applicable directories.

Project Directories

In a effort to 1) Reorganize the project in a more intuitive fashion; 2) Stablize Open Source distribution via SVN for all contributors; 3) Minimize Version conflicts. For self-containment, the DOSP contains its own version of 3rd Party Core Libraries. The Project File structure is based on the Directory Structure recommendations from the Core Team Members.

  1. DOSP – Root Directory
  2. Documentation – 3rd Party Libraries, Plugins, and Tool Documentation.
  3. Include – 3rd Party C++ Header and Source Files. All #include directives use relative paths to locate header files.
  4. Lib – 3rd Party Static Library Files. All Libs are stored in a single directory. VC++ IDE requires you specify the absolute path for libs on your local PC in order to properly locate the Lib Directories for DOSP. To achieve this, you may need to add a entry with VC++ IDE: Tools → Options… → Project and Solutions → VC++ Directories → Show directories for: Library files → [Absolute Path of DOSP]\DOSP\Lib\vs9 Note: Due to this requirement, Contributors will have to manually add this entry. This may appear simple enough, but, it can cause conflicts if other Entries use same root directory because VC++ will search these directories based on order.
  5. Dll – 3rd Party Dynamic Link Libraries.
  6. Projects – DOSP Projects. In this stage of development, the project is compiled in debug mode and should generate object and executable files in Projects\S3GE\S3GE\Debug\ Note: The Debug/Release Directories represents the Root Directory for S3GE.exe and associated files. To ensure DOSP compiles and run from VC++ with Debugging make the following entry: S3GE Properties → Configuration Properties → Debugging → Working Directory → $(TargetDir)
  7. Tools – External S3GP Utility Executable(s).
  8. Content – S3GE Application/Game Media, Data, and Logic Files.The Content Directory (currently located in the Debug Folder) represents an Application/Game’s cached content {media, auxiliary data, markup & script} files for use by S3GE. This directory contains the cached Content Files for Application / Game. Note: S3GE Host Server will provide a centralized repository for all Content Files downloaded S3GE upon requirement.

You can create Directories and Files like you normally do. A question mark ? overlays their icons. A Directory with this ? means that the Directory itself or some files within it have not been Added for commitment to SVN Server. Files with the ? have not been added. You will need to Add these directories & files in order to commit them to the SVN Server for everyone else to see. In some cases, you may not want to commit the directory/file to this SVN Server, leaving it in this state is harmless but its recommended that it be added to the ignore list (see details below).

To Add Directories and Files, [Right Click] and select TortoiseSVN → Add. You can select one more directories and files to add at once. Warning: Tortoise will only display file extensions without names, thus its tricky to know what files are being added. I’m not sure if this is bug or a setting I failed to turned on.

Once files have been Added, a plus sign + overlays the icon. If you modify files a exclamation mark ! overlays the icon. Both icons mean the directory/file are ready to be committed. To commit, [Right Click] anywhere in the view and select SVN Commit to update the SVN server. When you commit changes please a short log message so people know what has been committed. This is in the top box when you commit. You will also be prompted for a username and password, this is you sourceforge username and password.

There will be local and Directories/Files that you don’t desire to commit to SVN server. To omit these Directories/Files highlight them and [Right Click], select TortoiseSVN → Add to Ignore List.

OGRE Addons

$(BULLET_ROOT)

$(OGRE_Home)/AddOns/ogrebullet

https://ogreaddons.svn.sourceforge.net/svnroot/ogreaddons/trunk/ogrebullet

Start

DOSP Tasks are organized and managed within the DOSP Coordinator. Tasks are created and posted by Core Team members in which Contributors can work on voluntary assignment. Core Members assist in integrating Contributions into the S3GP. DOSP Coordinator is powered by MantisBT which is popular web-based bugtracking system. It has been adopted for DOSP with a Task-Oriented theme (english only) to track what needs to be done and who’s working on it.

We’ve extended the purpose for Tasks in DOSP. Task are being used to:

  1. Track Jobs created and posted by the Core Team for themselves and other Contributors to work.
  2. Track Issues (bugs).
  3. Share Ideas.

There are 4 read/write access levels: Coordinator, Core Team, Contributor, and Viewer. Coordinators can create/edit Projects & Task. Core Team Members can create/edit Task. Contributors can create Task and handle they’ve created.

Login

To get started Log in or Join. When you intially join, you’re added to the project as a Contributor. If you wish to be part of the Core Team please advise the Coordinator.

Viewing Tasks

Once you’ve logged in, you will see a screen similar to the one below. The Main Menu Bar and Project Selector are presented on every page. The Project Selector (#2) will select the scope of Tasks viewable/editable.

  1. User – This tells you your log in.
  2. Project – This Drop-down menu will allow you to select the scope of Tasks viewable/editable. The options available are dependent on your access level.
  3. View Tasks – This link will display a list of task (based on Project scope) similar to the list above.
  4. Summary – This is a short description of the Task often used as a title.
  5. ID – Task ID is unique for every task. Click to view Task details. Mantis provides several features that use the Task ID. If you need to update the Task, Click the [mantis/images/update.png ].This option is dependent on your access level.

 

Your View

This view will quickly sort Tasks divided into groups by:

  1. Unassigned
  2. Resolved
  3. Monitored by you
  4. Created by you
  5. Recently Modified

Contributors can create, assign and work task. Task states are color coded to instantly convey what state the task is in.

  1. New – Newly created and unassigned Task.
  2. Pending – Task requiring feedback from contributors or validation for use in the project by Core Team.
  3. InProgress – Task undergoing work by Contributor.
  4. Validated – Core Team has reviewed and approved.
  5. Assigned – Task is reserved or on hold by assigned contribuor.
  6. Completed – Task completed and ready for use or integration.
  7. Closed – Cancelled Task.

When you select a task you’ll be presented with a page similar to the one below.

Creating A Task

When you select a task you’ll be presented with a page similar to the one below. Menu selections are dependent on Project Scope.

  1. Category – Task Category.
  2. Bug Reprodcucibility – If the Task is used to report Bugs this selection can be used to describe how often the bug occurs.
  3. Component – DOSP Component Types.
  4. Product Version – Version #.
  5. Summary – Short description of the Task often used as a title.
  6. Description – HTML allowed with the exception of anchors and images.
  7. Addtional Information – HTML allowed with the exception of anchors and images.

Super 3D Game Engine is a High Performance Game Engine capable of producing unique 3D Computer Games based on one or more basic game mechanics that define popular computer game genres/sub-genres: FPS, RPG, RTS, Puzzle, Arcade, and many others. The Engine designed with a scalable Multiplayer support for Single Player up to Massive Multiplayer Games.

Interactive-centric Framework

Super 3D Game Platform Architecture (Full View)

The Engine Framework is a set of inter-working sub-systems that integrate Core Libraries. The User Interactivity System (IOU) is the Engine Framework’s Central sub-system, with all other Framework sub-systems built to support it. IOU integrates practically all Core Libraries: Scripting, Networking, Physics, Graphics, Audio, and Input. IOU consolidates all User and CPU Interactivity such as 2D/3D GUI Widgets, 3D Event Triggers, Player Controller, Actors into one system. For more details see GUI Design.

Entity Components and Modules

S3GE uses a Component-based model for Engine System Objects (Modules) and High-Level Interactive Objects (Entities).

http://cowboyprogramming.com/images/eyh/Fig-2.gif

The main advantages to component based systems are:

  1. No programmer required for designers to modify game logic
  2. Circumvents the “impossible” problem of hard-coding all entity relationships at start of project
  3. Allows for easy implementation of game-design ideas that cross-cut traditional OOP objects
  4. Much faster compile/test/debug cycles
  5. Much more agile way to develop code

http://wiki.hpquest.com/images/1/12/IOU_Design.png

S3GP Entities are derived from Game User Interactivity System Components. Interested in getting started with Component-based Entities? Take a gander at Cistron: an open source component-based object framework: Forum|SVN|Example.

References: 1,2,3,4,5

Programming Publish/Subscribe Observer Pattern

In using many Design Patterns, S3GE adopts the publish/subscribe message system implemented in similar fashion to Observer Pattern to handle events system wide. Note: OGRE and other Core libraries make heavily use of the observer pattern. The Messaging System is a special component added to every component to handle both component inter-communications and other messaging requirements.

Creation & Customization

S3GE powers a suite of Visual Editor Applications (S3GEd) for every aspect of Asset Creation. A Majority of the S3GE Framework classes are designed to facilitate these applications and are also available to the engine on demand.

BLending Interpolation Procedures (BLIPs)

The concept of using various Blending & Interpolation Algorithms in the form of Task-Bots to Transition from one value to another allowing Computer Automation to be applied at various Application levels.

3D Net Browser

A Server-Client Communications methodology inspired by the Web Browser/Server utilizing ‘Pages’: Server-side Scripting (PHP) & Markup (S3GXL), output to Client-Side Markup/Scripting (XML/LUA) to generate the presentation. Additionally, S3GP network topology includes a communication with a dedicated WWW Host Server to synchronization between S3GP Products and Web Application. Design goals include the implementation of HTTP Server within S3GP to provide 3D Net Server functionality. The Host Server will provide DNS Service for both Game Server Location S3GP HTTP Server Redirects. Ahead of the game…

Open Systems Networking

Open Game Protocol Specification v1.01
LESS Protocol
High Level Architecture
Base Object Models (HLA)

Gaming Standards Association – The Gaming Standards Association (GSA) is an international trade association that creates benefits for gaming manufacturers, suppliers, operators and regulators. We facilitate the identification, definition, development, promotion, and implementation of open standards to enable innovation, education, and communication for the benefit of the entire industry.

G2S v1.1 G2S is a communication protocol that unlocks the power of networked gaming and revolutionizes the way information is exchanged between Electronic Gaming Machines (EGMs) and back-of-house systems. It provides a common interface between devices and systems, as well as supports essential networked gaming functions, such as software download, remote configuration, and advanced features. With G2S certified systems, operators have the ability to control and extract information from their gaming floors.

Moderated Open Repository

S3GP is designed with sharing/collaborating Developer & Player-created Content in mind. To make it as easy for Developers/Players to get their content into the game, and of protect the game productions from damage, a Moderated Open Repository is established. Developers/Players upload their Media Files to the MOR Host Server for review and approval. Moderators inspect files for damage, compromise, obscenities, etc. Approved files are moved to the Closed Repository (Production) for use in game.

I2P Immediate Input Protocol

S3GE utilizes Input Transmission as its primary `Twitch` update and and Position Transmission as secondary to client sync. I call this protocol the Immediate Input Protocol. Each player’s inputs are sent to their Client of the game without having to wait for their opponent’s input to arrive over the network.

If the simulations diverge, S3GE rolls back to the most recent accurate state, corrects the mistake, and jumps back to the current frame, all before the player can notice. This provides the illusion of lag-free gameplay. Ref GGPO.

Input is better suited the Game User Interface Controller Component which translates inputs into positional and physics influence data. Input Transmission is the desired choice for Fighters, and other games that need to communicate player state changes quickly.

Space Time Continuum

S3GE takes in consideration of

  1. Undo Redo Change History
  2. Bullet/Elapse Time Control over Independent Entities
  3. Record, Replay, Reverse, Fast Forward Scene

Replay Feature Memento pattern,C++ Mememto implementation

Super 3D Text Game Engine

S3GP Command Line Interface is a collaborative IRC-powered interface. S3GP CLI can execute S3GXL and LUA script.

S3GP’s CLI also embeds multiple Text-based Game engines that can be used within 3D Games.

  1. The MUD engine
  2. The Interactive Fiction Engine
  3. Grid-Game Engine: Chess, Checkers, Battleship, etc
  4. Action-Text: 2D Arcade-style game mechanics using Text in place of Images.

IOU, A Game-User Interactivity System (GUI)

Graphical User Interfaces (GUI) are mandatory in today’s utility and entertainment application productions. Games in particular feature GUIs with heavily animated Widgets and unique input device control. When using the term GUI, most of us visualize two dimensional rectangular windows, buttons, menus. However I come to realize that the entire 3D Game-world is a Graphical User Interface and in most cases games incorporate a custom GUI system to support this interactivity.

What I describe herein is a design for Physics-powered Graphical User Interface that consolidates all User and CPU Interactivity: 2D/3D GUI Widgets, 3D Event Triggers, Player Controller, AI Agent Controller into one system. A Game-User Interactivity System, Input/Output & You (IOU). IOU’s Design draws upon inspirations from several 2D/3D Drawing & Animation Applications such as Scaleform(Flash), Cinema4D, GIMP, PowerPoint, Movie Maker.

IOU is designed to support:

  • 2D / 3D Animated Widgets
  • 3D Cameras & Viewports
  • Various Input Devices

Interactive Primitives: Input, Output, & User Devices

IOU has 3 Interactive Primitives (C++ Classes): InputDevice, OutputDevice, and UserDevice.

  1. InputDevice manages User Input from peripherals such as Keyboard, Joystick, Joypad, Mouse, other. (Key, Button, Axis).
  2. OutputDevice manages presentation of Visual Objects and Audio to the user.
  3. UserDeviceis an aggregate object that couples:
    • InputDevice for contact collision detection (button presses, etc).
    • Body, a Collision Component powered by Physics Engine for high performance bound collision detection/filtering and physics simulation.
    • Sprite, a Visual Component powered by High Performance Graphics Engine. Visual Components: 2D Image & Video, 3D Sprite/Mesh & Light, High Level 3D Entity.

In IOU, contact collision detection from input devices and bounds collision detection powered by Physics are the key mechanism of User-Application interaction and the driving principle behind IOU’s design. IOU adopts the Entity Component Model in Engine Framework C++ Classes and Model-Viewer-Controller design pattern in the Script API (S3GXL) implementation, decoupling visual components from the collision component. Collision Detection generate Events, which are used select and execute scripts.

GUI Entities: Canvas, Widget, Pointer

IOU provides 3 GUI Entities (Script API) common to graphical user interfaces: Pointer, Widgets, Canvas . All other Interactive Entities inherit from these GUI Entities in a Interactive-centric Gameworld.

  1. Canvas provides a single presentation point consolidates 3D Cameras, 2D Viewports, and Listener.
  2. Widget provides a single interaction point for the direct manipulation of a given kind of data (1). A Widget has no specific mechanical operation (Behavior) until assigned, and a Widget can be assigned any Behavior.
  3. Pointer, a Widget controlled by a User via InputDevice. Its used to interact with other Widgets. IOU decouples control of the Pointer directly from the mouse allowing it to be controlled other devices to include the keyboard.

Event State Machine (ESM) Model

IOU implements a Finite State Machine model composed of a finite number of states, transitions between those states, and actions. States are determined by Events. An Event is a state change based on Pointer/Widget collision detection, Control Input Detection, and Event Flags. These interactions are the basis for many types of Events in IOU. Hence, the Event State Machine. A Widget can execute a Script (Action) with each Event State. IOUs design revolves around Widget and Control Events.

Event-Driven Scripting

Event-driven Scripting Behaviors, Transitions, Styles, Themes, Schemes & Actions.

In most GUI’s the mechanical operation of a Gadget (ie: Button, Slider, etc) is hardcoded. In IOU, this functionality is scripted and referred to as Behaviors. Behaviors define the logic for handling interactions, event states for Widgets and Controls. Games can require Widgets with unusual Behaviors. Scriptable Behaviors allows for many types of traditional and non-traditional Widgets to be created.

Games have very active GUIs complete with sound and animation. It was desired that IOU support sound and animation during events and in between. Transitions define logic for effects executed in between Event Changes. They were originally intended to be used for audio/visual effects during the transition of one event to another, but, can be used other actions.

Styles define Font properties based on Widget Event States and Themes define Border Images and Lines based on Widget Event States. Both Styles and Themes can use Script for visual effect fonts and borders are drawn.

Composite Widgets

Behaviors can also be scripted to use two or more Widgets to operate as a Composite Widget such as a Dropdown Box. These types of Behaviors rely on IOU’s Widget Family Tree Data structure in which Parent|Child|Sibling relationships are established between Widgets during creation. In the Parent-Child relationship, the Parent usually influences the Child. Widgets that share the same Parent are Siblings. IOU uses a Link List for both operational and performance purposes.

Image-based Border Themes, Fonts, and SoundFX

IOU supports 2D Image-based Border Themes, 2D Animation Frames, and Fonts using Texture Atlases. The .PNG format is the recommended file format for Images.

IOUs Image-based Border Theme uses built-in drawing functions and image sets and IOU XML Theme Tag provides attributes for all edges and corners.

IOU BgSound Tag and Scripting makes it easy to apply sound effects to Widgets based on Events and Transitions.

XML-based file format for import/export.

Inspired by HTML. A XML/LUA S3GXL Implementation was adopted for the S3GP which includes IOU Widget/Canvas/Input configuration.

Messaging

References

Introduction

Purpose of this document

This is a technical document describing the Super 3D Game XML/LUA (S3GXL) Scripting for the Super 3D Game Engine (S3GE). It’s not a tutorial, nor does it provide detailed examples of useful S3GXL code. For examples of S3GXL, the reader is referred to the source code to the S3GXL Scripts, which provides thousands of lines of working S3GXL code which solves many problems such as the User Interface, AI, and Inventory. A good way to get started is by copying, modifying, and testing existing scripts to see the results.

This document assumes that the reader has a working knowledge of XML and LUA. Information presented here are excerpts from existing documentation for these languages. Please visit http://www.w3.org/XML and http://www.lua.org for more detail.

Design goals of S3GXL

S3GXL was designed to provide Game Developers with a powerful and easy-to-use Markup and Scripting language to customize all Game Object properties, behavior, and logic within the Super 3D Game Engine Application. The major design goals of S3GXL are:

  1. To provide external programming capabilities to specific internal Game Object properties, behaviors, timing, networking; maximizing S3GE performance and S3GXL ease-of-use.
  2. To provide a uniform set of procedural commands.
  3. To provide a Markup Language (XML) to describe S3GE Game Objects and Scripting Language (LUA) to program S3GE Game Object Logic. With this combination, S3GXL provides the following benefits:
    1. XML
      • Simplicity – presents information in easy to read form which can easily be processed by computers.
      • Openness – XML is a W3C standard, endorsed by software industry market leaders.
      • Extensibility -There is no fixed set of Markup Tags. New tags can be created as they are needed.
      • Self-description – XML documents can be stored without such schema definitions, because they contain meta data in the form of tags and attributes.
      • XML provides a basis for author identification and versioning at the element level. Any XML tag can possess an unlimited number of attributes such as author or version.
      • Contains machine-readable context information – Tags, attributes and element structure provide context information that can be used to interpret the meaning of content, opening up new possibilities for highly efficient search engines, intelligent data mining, agents, etc.
      • Supports multilingual documents and Unicode -This is important for the internationalization of applications.
      • Can contain any possible data type – from multimedia data (image, sound, video) to Script.
      • Can consist of nested elements that are distributed over multiple remote Servers. XML is currently the most sophisticated format for distributed data – the World Wide Web can be seen as one huge XML database.
    2. LUA
      • Easy-to-use with BASIC-like Syntax.
      • Dynamic Types: variables do not have types; only values do.
      • Supports functional programming with first class functions and closures.
      • TABLES! – One of the most elegant data structures I have seen in any language
      • Easier and faster to express behaviour of game entities in Lua than in C++
      • Lua is interpreted, so you can simply change the script while the game is running and see if the new changes work.
      • Lua allows level designers to work on creating new levels / missions etc without being able to wreak havok to the with the core game engine.

S3GXL Example Script

This example illustrates a typical, simple S3GXL, and it highlights the syntax and features of S3GXL. Note that this code may differ from that which appears in the current S3GE source, as this documentation is not synced with the code.

<widget name="TopBarMaster" description="Show/Hide Top Bar" collision="1" operate="1" transit="1" active="1" audio="1" visible="1">
    <attribute name="spritex" value="0"/>
    <attribute name="spritey" value="0"/>
    <attribute name="toggle" value="0"/>
    <orientate ref="worldboundright" width="28" height="48" xalign="left">
        <physics noresponse="true"/>
    </orientate>
    <event state="IDLE" behavior="pushbox" transition="yshift" theme="graybox" style="standard" scheme="pointingFX" caption="" xalign="center" yalign="middle"/>
    <event state="ENTER"/>
    <event state="HOVER" scheme="pointingFX"/>
    <event state="DOWN"/>
    <event state="HOLD"/>
    <event state="DRAG"/>
    <event state="UP">
        <action language="darklua" type="1">
            <![CDATA[
                sgeWidgetToggle = 1 - sgeWidgetAttributeGet(this, 'toggle')
                sgeWidgetAttributeSet(this, 'toggle', sgeWidgetToggle)
                msg = sgeWidgetMessageCreate()
                sgeWidgetMessageInsert(msg, MAUI_MSG_TYPE_VALUE, MAUI_MSG_WIDGET_CLOSE + sgeWidgetToggle, 0)
                sgeWidgetMessageInsert(msg, MAUI_MSG_TYPE_ATTRIBUTE, 'toggle', '0')
                sgeWidgetMessageSend(msg, 'TopBarMaster', MAUI_MSG_TO_CHILDREN, 1 - sgeWidgetToggle)
                sgeWidgetMessageDestroy(msg)
            ]]>
            </action>
        </event>
    <event state="EXIT"/>
</widget>

The key elements to look at in this script are:

  • The Game Object declaration Tag.
  • The Variable declarations Tag.
  • The functions. Functions can take a list of parameters, and they optionally return a value. Functions can have local variables. Some functions are called by the S3GE engine itself (such as BeginPlay), and some functions are called from other script code elsewhere (such as Trigger). More Details
  • The code. All of the standard C and Java keywords are supported, like for, while, break, switch, if, and so on. Braces and semicolons are used in S3GXL as in C, C++, and Java.
  • Actor and object references. Here you see several cases where a function is called within another object, using an object reference. More Details
  • The “state” keyword. This script defines several “states”, which are groupings of functions, variables, and code that are executed only when the actor is in that state. More Details

Note that all keywords, variable names, functions, and object names in S3GXL are case-insensitive. To S3GXL, Demon, demON, and demon are the same thing.

A 3D Net Browser Markup Language

S3GE’s Client Networking and A/V Interface is inspired by the Web Browser utilizing ‘Pages’ from the Host Server & S3GE Server that contain S3GXL to generate the presentation. A 3D Net Browser. Web Browser’s use HTML/Javascript as a Client-Side Language to present Web Content, S3GXL uses XML/LUA as a Client-Side Language to present Application/Game Content. Server-Side Scripting Languages such as PHP can also be used to generate S3GXL dynamically from the WWW Host Server. S3GE’s Network Topology consists of the following Network Entities: WWW Host Server, S3GE Server, and S3GE Client.

The S3GE Server also uses S3GXL to set up the game-world and its interactive entities on the Server Side.

LUA Task-based Execution

The S3GE Server controls all gameplay and interaction between players and actors (cpu controlled interactive entities). In a single-player game, both the S3GE Server/Client run on the same machine; in an network game, there are one or more dedicated S3GE Servers running on independent machines; All players connect to this machine using S3GE Clients.

All gameplay takes place inside a “level”, a self-contained environment containing interactives. Though S3GE Server may be capable of running more than one level simultaneously, each level operates independently, and are shielded from each other: actors cannot travel between levels, and actors on one level cannot communicate with actors on another level.

Each actor in a map can either be under player control (there can be many players in a network game) or under script control. When an actor is under script control, its script completely defines how the actor moves and interacts with other actors.

With all of those actors running around, scripts executing, and events occuring in the world, you’re probably asking how one can understand the flow of execution in an S3GXL. The answer is as follows:

To manage time, S3GE divides each second of gameplay into “Ticks”. A tick is the smallest unit of time in which all actors in a level are updated. A tick typically takes between 1/100th to 1/10th of a second. The tick time is limited only by CPU power; the faster machine, the lower the tick duration is.

Some commands in S3GXL take zero ticks to execute (i.e. they execute without any game-time passing), and others take many ticks. Functions that require game-time to pass are called “latent functions”. Some examples of latent functions include Sleep, FinishAnim, and MoveTo. Latent functions in S3GXL may only be called from code within a state (the so called “state code”), not from code within a function (that includes functions define within a state).

While an actor is executing a latent function, that actor’s state execution doesn’t continue until the latent function completes. However, other actors, or the VM, may call functions within the actor. The net result is that all S3GXL functions can be called at any time, even while latent functions are pending.

In traditional programming terms, S3GXL acts as if each actor in a level has its own “thread” of execution. Internally, S3GE does not use Windows threads, because that would be very inefficient (Windows 95 and Windows NT do not handle thousands of simultaneous threads efficiently). Instead, S3GXL simulates threads. This fact is transparent to S3GXL code, but becomes very apparent when you write C++ code that interacts with S3GXL.

All S3GXLs execute in parallel. If there are 100 monsters walking around in a level, all 100 of those monsters’ scripts are executing simultaneously and independently.

The S3GE Game Object Overview

Before beginning work with S3GXL, it’s important to understand the high-level relationships of Game Objects within S3GE. In S3GE, all Game Objects that physically interact with the User in some form or fashion are based on the User Interactivity System’s Widget Object. The widget was originally intended to be used for only creating GUI Gadgets, however, I expanded on its purpose and functionality after I realized that all interactive Game Objects could take advantage of the UI’s Interactive Mechanisms, State-based Behavior, and Messaging. With S3GXL, most Game Objects are defined with Tags using an alias for widget to improve readability such as: Doodad, Jigger, Actor, Terrain.

About TournamentBlitz

TournamentBlitz is a Online ‘Coin-Op’ Computer Entertainment Complex featuring Interactive Applications & Games that communicate with TBEMS to provide a variety of ‘Coin-Op’ Micro-Transaction Services that can generate profits for both App/Game Developers and their Users.

Products and Services include:

  • Item Malls & Auctions
  • Skill-based Tournaments
  • Contests
  • Pay-Per-Play
  • Paid-To-Play
  • Award Achievement System
  • RNG Scoring System
  • Online Scoreboards/Rankings
  • In-App Advertisements
  • Crowd Funding Donations
  • Server Locator
  • Anti-Pirate Sentry

Note: A majority of these services can be applied to any type of Application, not only Games.

TournamentBlitz’ began as the Blitz Online Scoreboard System (BOSS) in 2003. BOSS, evolved into a Tournament System designed to manage Online Cash-driven Game Tournaments in which Players paid-to-enter, competing for best score to win a Cash Jackpot. Since that time, the TournamentBlitz Event Management System (TBEMS) has been expanded to support a variety of features not supported in other Micro-Transaction API.


Click to Download the INSECTOIDZ Demo (Requires DX7).
U/P: guest/guest

DarkTokens

DarkTokens (TBEMS API) enables Developers to quickly and easily money-tize their Applications and Games, selling a variety of real-world and virtual products and services via Web-browser or in-App. Sell upgrades such as level unlocks, equipment, special weapons, cheats, and much more. Transform Single Player Games into highly competitive cash-driven Tournaments. Host Prize-based Treasure Hunts and much more.

Developer’s monetize their Application’s Online in 3 Steps:

    1. Register your App/Game with TBEMS .
    2. Add Events & Items to your TBEMS Application Profile.
    3. Setup Event & Item Point, Purchase, Award Values and Delivery Method.

Player’s can purchase and use DarkTokens Online in 3 Steps:

    1. Purchase a TournamentBlitz (Online) Bankcard with Credit Card via PayPal.
    2. Using Web-browser or In-App Store, select/add Items to their Shopping Cart for purchase.
    3. Checkout to complete order.

TBEMS takes care of all transaction processing using sophisticated methods of authentication to insure secure and rapid order fulfillment. There is no expensive equipment to purchase or install, no merchant account necessary, and no customer service desk to staff or technology to maintain.

DarkTokens API is designed to be easy, flexible, and secure. DarkTokens only relies on HTTP Request/Response Messaging and integrates into any Application, on any Platform with a means of HTTP communications. Using HTTP, a request string of specified variable-value pairs are sent to the TBEMS Processor, TBEMS responds with data in two possible formats: Plain Text (Carriage Return delimited) or XML.

Request Example:

http://tbcms.hpquest.com/tbems.php?command=buy&item=CVD30314932&authkey=13340AADGFX2034556DLG

Response Example #1 (Plain Text):

AuthKey
13340AADGFX2034556DLG
TokenBalance
95

Response Example #2 (XML):

<authkey>13340AADGFX2034556DLG</authkey>
<tokenbalance>95</tokenbalance>

The DarkTokens API Manual and Demo Applications provides detailed instructions on how to assemble the TBEMS Request, and parse the TBEMS Response, providing Developers complete flexibility to customize TBEMS Micro-Transactions within their Applications.

GunVertor

A Modular Weapon Customization System designed for Modern, Futuristic and Exotic FPS Firearm Weaponry.

The Chamber The Weapon Core Component in which other components connect into. It is the mechanism loads ammunition 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 ammunition.

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 mechanism 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.

Stock-grip Absorbs Recoil. Recoil can effect weapon handling and accuracy. High Quality Stocks can absorbs greater amounts of recoil. Hand-grip attaches to player.

Magazine Magazine Power-cell Canister are storage components. These components effect Ammunition Refill/Recharge speed and Storage Quantity

Ammo-meter 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 Ammunition or change the visual characteristics of Energy Ammunition.

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

There is no doubt that Model Packs provide awesome artwork for an affordable price. My personal issue 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 Hierarchical Sets (MEChS). The premise behind MEChS is to provide modelled/textured Components that can be assembled to create countless Entity variations. Several Model Construction Sets for Buildings and Structures are already available, MEChS takes the concept further providing Components for Character Bodies/Heads, Furniture Props, FireArm Weapons, Melee Weapons, Trees/Plants, Vehicles/Crafts, and Machines.

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.

Open Standard: The MEChS Data Format should support bone and key frame animation and simplify assembly of parts using a Open Standard for Labeling Meshes, Bones, Animation, and Textures. Model Components should be made available in multiple common formats such as .X, .3DS.

MEChS 3D Plug-in: Components could be imported into a 3rd party editor and assembled manually OR imported into game engine/application and assembled using a 3D Plug-in that handles parts welding and texture blending.

Licensing: Less-restrictive Licensing Agreement would allow Purchasers the ability to create Mods from parts meshes and textures without paying additional fees. Of course credit would have to be given to the original author and some restriction reselling Mods would have to be provided.

The MEChS Component

Defines a MEChS Building Block/Accessory and its Connectors.

  1. Block: 3D Mesh in which one more Connectors are added.
    1. Block Skin: Textures, Maps and Shaders applied to a Block
  2. Accessory: Audio/Visual or Virtual Object in which one more Connectors are added.
    1. FX Objects: Particle Emitters, Lens Flares
    2. 3D Objects: Mesh, Lights, Camera, Sound
    3. Physics Objects: Cloth, Hit Objects
  3. Connector: A connection point in which a Blocks and Accessories are connected.
    1. Mount: A external connector added to mesh or internal point defined within the mesh used to connect Components & Accessories at run-time. 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
    2. 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.
    3. Joint: Dark Physics Rigid Body Joint often used in Machines: 6DOF, Cylindrical, Distance, Fixed, Point in Plane, Point on Line, Prismatic, Pully, Revolute, Sphere.
    4. 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 MEChS Entity Class

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

Class Component
– Core: Base Component in which Limb Components connect. Mandatory for Entity Assembly.
– Limb: Extension Component that connects to Core or Limb.

Common Entity Classes:

  • Terra-Forms (Terrain + Sky + Celestial Body + Fluid body + Cloud)
  • Building (Interior|Exteriors)
  • Structure
  • Trees & Plants
  • Character Head
  • Character Body
  • Firearm
  • Projectile
  • Melee Weapon
  • Prop
  • Furniture
  • Vehicle & Crafts
  • Machines
  • Items (Single Block with Connectors)

The MEChS Entity

Defines a individual Instance of a Entity Class

Entity Component Composite Components

MEChS Format

<MEChS version = "1.0">
	<!-- Entity Classes -->
	<class name="Character" type="BiPed">
		<!--
		Class Hierarchy defines parts and connectivity.
		-->
		<part name="Chest" type="core"/>
			<part name="Neck" type="limb">
				<part name="Head" type="limb"/>
			</part>
			<part name="UpperTorso" type="limb">
				<part name="LowerTorso" type="limb">
					<part name="UpperLeg" type="limb">
						<part name="LowerLeg" type="limb">
							<part name="Foot" type="limb"/>
						</part>
					</part>
				</part>
			</part>
			<part name="UpperArm" type="limb">
				<part name="LowerArm" type="limb">
					<part name="Hand" type="limb"/>
				</part>
			</part>
		</part>
	</class>

	<class name="Firearm" type="Standard">
		<part name="StockGrip" type="limb">
			<part name="Chamber" type="core">
				<part name="FiringMechanism" type="limb"/>
				<part name="Trigger" type="limb"/>
				<part name="Barrel" type="limb">
					<part name="Bayonet" type="limb"/>
					<part name="Distorter" type="limb"/>
				</part>
				<part name="Scope" type="limb">
				<part name="Loader" type="limb">
					<part name="Magazine" type="limb"/>
				</part>
			</part>
		</part>
	</class>

	<class name="melee" type="standard">
		<part name="handle">
			<part name="guard">
				<part name="midsection">
					<part name="bluntblade">
				</part>
			</part>
		</part>
	</class>

</MEChS>

<MEChS version="1.0">
	<!-- Constructs -->
	<block name="ironman" src="3DCharactersUpperchest.x" scale="sx,sy,sz">
		<!-- acceptable skins -->
		<skin src="IronManCore_C1_1"/>
		<skin src="IronManCore_C1_2"/>
		<!-- connectors -->
		<!-- #1 --><connector name="neck" type="mount" gender="slot" coords="x,y,z,ax,ay,az"/>
		<!-- #2 --><connector name="spine1" parent="neck" type="bone" name="UC1.1" map="Bip01_Spine_1"/>
		<!-- #3 --><connector name="spine2" parent="spine1" type="bone" name="UC1.2" map="Bip01_Spine_2"/>
	</block>

	<block name="broad" src="3DCharactersUppershoulder.x" scale="sx,sy,sz">
		<connector type="mount" gender="peg" coords="x,y,z,ax,ay,az"/>
		<connector type="bone" name="UL1.1" map="Bip01_L_UpperArm">
			<connector type="bone" name="UL1.2" map="Bip01_L_ForeArm"/>
		</connector>
		<connector type="joint:6dof">
			<script></script>
		</connector>
	</block>

	<block name="popeye" src="3DCharactersUpperforearm.x" scale="sx,sy,sz">
		<connector type="mount" gender="slot" coords="x,y,z,ax,ay,az"/>
		<connector type="bone" name="UL1.2" map="Bip01_L_ForeArm">
			<connector type="bone" name="UL1.3" map="Bip01_L_Hand"/>
		</connector>
		<connector type="joint">
	</block>

	<block name="thing" src="3DCharactersUpperhand.x" skin="Machine_U1.2" scale="sx,sy,sz">
		<connector type="mount" gender="slot" coords="x,y,z,ax,ay,az"/>
		<connector type="bone" name="UL1.3" map="Bip01_L_Hand"/>
		<connector type="mount" gender="any">
	</block>

</MEChS>

<MEChS version = "1.0">
	<!-- Entity -->
	<entity type="BiPed" name="Sir_Peppy">

		<part name="Chest" align="center">
			<block name="ironman"/>
		</part>

		<part name="UpperArm" align="left">
			<block name="Broad" connector="1" state="connected"/>
		</part>

		<part name="LowerArm" align="left">
			<block name="popeye" connector="1" state="connected"/>
		</part>

		<part name="Hand" align="left">
			<block name="thing" connector="1" state="connected"/>

			<accessory type="hitobject" ID="" connector="1" state="connected">
				<connector type="mount" gender="peg" coords="x,y,z,ax,ay,az">
					<option value="Hand" connect="true"/>
				</connector>
			</accessory>

		</part>

	</entity>
</MEChS>

Editor Applications

S3GEd Editor Applications are designed with Real-time Collaborative World Building and Project Management in mind. Full-Featured Chat App, Creation, Group/User Permission, Entity Check-In/Check-Out, Version Control, Dependency Management, Multilingual Localization Support.

  • Layer-based 2D Image Manipulation Editor
  • Layer-based 3D Camera-driven Filtering and Visibility for 3D World Editing
  • Tile Based Construction for Interior and Exteriors
  • 3D Modular Entity Construction (Hierarchical) Sets Assembler
  • Centralized Online Asset (Media, Data, Scripts) Repository.

Content Creation Systems

S3GEd Editor Suite is designed with the intention of providing developers with powerful Content Creation Tools to create unique assets quickly and Logic Creation Tools to experiment with various game mechanics without the need to program.

  • Consolidated Graphical 2D/3D User Interface w/ Scripted Styles, Themes, Behaviors, Transitions, and Actions.
  • Modular Entity Construction (Hierarchical) Sets for constructing Pre-Fabricated Entity Catalogs and In-Game Customizable Entity *Categories: Character Head & Body, Weapons, Props, Vehicles, Machines, Trees & Plants, Buildings & Structures, Terra-formations.
  • Procedural Mesh Deformation and Bone Animation Editing System utilizing Physics, BVH Motion Capture Data, Forward/Inverse Kinetics, Key-frame Interpolation/Blending.
  • Behavioral Rules AI Nodes System (BRAINS): AI Agents with Event Driven Behaviors, Navigational Mesh based Path-finding & Object Avoidance.

Super 3D Game World is a Massive Multiplayer Online (MMO) Amusement Park that exploits all of Super 3D Game Engine’s Multi-Genre ready features and game mechanics. A Massive Virtual Amusement Park in which multiple Players can explore, socialize, and participate in rides, arcade mini-games, contest, events, and attractions to win prizes and upgrade their Avatar. The game world is designed in a modular fashion, allowing Game Designers to develop sub-games independently as Coming Attractions and plug them into S3GW when ready to Open to the Public.

World Feature #1

This section is not supposed to be called world feature #1 but is supposed to be titled with some major thing about the world. This is where you break down what is so great about the game world into component pieces and describe each one.

World Feature #2

Same thing here. Don’t sell too hard. These features should be awesome and be selling the game on its own.

The Physical World

Overview

Describe an overview of the physical world. Then start talking about the components of the physical world below in each paragraph.

The following describes the key components of the physical world.

Key Locations

Describe the key locations in the world here.

Travel

Describe how the player moves characters around in the world.

Scale

Describe the scale that you will use to represent the world. Scale is important!

Objects

Describe the different objects that can be found in the world.

See the “Objects Appendix” for a list of all the objects found in the world.

Weather

Describe what sort of weather will be found in the world, if any. Otherwise omit this section. Add sections that apply to your game design.

Day and Night

Does your game have a day and night mode? If so, describe it here.

Time

Describe the way time will work in your game or whatever will be used.

Rendering System

Overview

Give an overview of how your game will be rendered and then go into detail in the following paragraphs.

2D/3D Rendering

Describe what sort of 2D/3D rendering engine will be used.

Camera

Overview

Describe the way the camera will work and then go into details if the camera is very complicated in sub sections.

Camera Detail #1

The camera will move around like this and that.

Camera Detail #2

The camera will sometimes move like this in this special circumstance.

Game Engine

Overview

Describe the game engine in general.

Game Engine Detail #1

The game engine will keep track of everything in the world like such and such.

Water

There will be water in the world that looks awesome and our game engine will handle it beautifully.

Collision Detection

Our game engine handles collision detection really well. It uses the such and such technique and will be quite excellent. Can you see I am having a hard time making up stupid placeholder text here?

Lighting Models

Overview

Describe the lighting model you are going to use and then go into the different aspects of it below.

Lighting Model Detail #1

We are using the xyz technique to light our world.

Lighting Model Detail #2

We won’t be lighting the eggplants in the game because they are purple.

 

Frequently
Asked
Questions:

  1. What is a Contributor?
    1. Any Individual that contributes Source Code/Script, Media Assets, Documentation to development of the Super 3D Game Platform.
  2. What is a Developer?
    1. Any Individual that uses Super 3D Game Engine and Editor Suite to Develop Games and Tools.
  3. ?

C.O.G.S – Component Object Game Systems.
S3GP – Super 3D Game Platform (S3GP).
S3GE – Super 3D Game Engine.
S3GEd – Super 3D Game Editor Suite
S3GW – Super 3D Game World
S3GC – Super 3D Game Console (Virtual)
S3TOGs – Super 33D Tool Games

Developers

  • See Contributors.

Contributors

Chat with Techlord via Mibbit.com on the #S3GP Channel. Open 24 hours a day, 7 days a week.

Mibbit Link: http://mibbit.com/?channel=%23S3GP&server=irc.mibbit.net
IRC Link: irc://irc.mibbit.net/S3GP

Leave a Reply

Your email address will not be published. Required fields are marked *