---

Thank you for visiting the DarkGDK Open Source Project (DOSP) here on the TGC Forums. DOSP is unlike any other community project in the TGC community. Its 100% Open! Open Source, Open-to-the-public, uses Open Standards. DOSP is very ambitious. We're building the Game Engine and Editors completely from scratch drawing inspirations from some of the industries most powerful Game Engines and Editors such as: The Hero Engine, Unreal Development Kit (UE3), and many others.


- The intent of DOSP is to provide a FREE Commercial Grade GUI-Driven 3D Application/Game Development Platform capable of supporting popular game genres out-of-box without the need to program. A Super 3D Game Platform (S3GP), consisting of a:

- A 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 will include scalable Multiplayer support for Single Player up to Massive Multiplayer Games.

- A Robust Suite of Visual Editing Tools powered by the Super 3D Game Engine. Developers can build and test in real-time for WYSIWYG results in game. Using S3GE's Network capabilities, S3GEd supports Real-time Collaborative Game Creation with full project management capabilities. A centralized, Open Repository (moderated) provides a secure, user-friendly means for Contributors to get their Game Content into your games. Modular & Procedural Entity Creation to make creating unique game content a snap! Also See: Super 3D Tool Games.

- A Scalable Multiplayer Online (SMO) Amusement Park that exploits all of Super 3D Game Engine's Multi-Genre ready features and game mechanics. Essentially A real-time 3D Sandbox in the form of a 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.



Engine Core Libraries
Graphics: Object-Oriented Graphics Rendering Engine (OGRE)
Audio: Open AL
Scripting: LUA & XML
Physics: Physx (3D) & Box2D (2D)
Networking: MikeNet (DarkNet) 2.0 Modified
AI Pathfinding: Recast Navigational Mesh/Detour

Collaborative Editing Applications
Real-time Collaborative World Building and Project Management: Full-Featured Chat App, Creation, Group/User Permission, Entity Check-In/Check-Out, Version Control, Dependency Management, Multi-lingual Localization Support.
Layer-based 2D Image Manipulation Editor
Layer-based 3D Camera-driven Filtering and Visibility for 3D Editing
Tile Based Construction for Interior and Exteriors
3D Modular Entity Construction (Hierarchical) Sets Assembler
Centralized Online Asset (Media, Data, Scripts) Repository.

Built-in Content Creation Systems
Consolidated Graphical 2D/3D User Interface w/ Scriptable 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, TerraForms.
Procedural Mesh Deformation and Bone Animation Editing System utilizing Physics, BVH Motion Capture Data, Forward/Inverse Kinetics, Keyframe Interpolation/Blending.
Behavioral Rules AI Nodes System (BRAINS): AI Agents with Event Driven Behaviors, Navigational Mesh based Pathfinding & Object Avoidance.




Core Team: Community Members responsible for integrating Engine Framework, Core Libraries, and Scripting API; and contribution integration & testing.



Coordinator: Core Team Member who oversees project development, updates TGC forum Top Thread, & Administrates Web Tools.



Contributor: Community Members who authors Applications, Modules, Game Content, Games, & Documentation for Project-Trio.



Visitor: Community Members who have shown interest in DOSP.



THE TASKS

New/TBD, In Progress, Pending, Completed, Cancelled






TortoiseSVN Client
DarkGDK Source Code via SVN
LUA Scripting Engine
irrXML
Physx
Box2D
RecastNavigation
Nullsoft Scriptable Install System
Blender 3D Animation Suite (Free Open Source) Level Building

---

It sounds intersting.

Open Source Projects could be:
-FPS
-RPG
-RTS
-Puzzle?
-Adevnture

I saw a OpenFPS project for DBP, its currently being worked on.

Open Source projects, should have source control, or something, so somebody does not modify the code and mess up the whole thing.

---

Sounds like fun! I personally think we should stay away from a FPS. Because there seems to only be open source FPS projects (that I hear of anyways) and FPS Creator games would almost always be better so it's kind of a downer. I think we should do either a RTS or RPG, and a few advantages/disadvantages and things we should think about when making it:

RTS
1. Don't see many good RTS's made with TGC products
2. RTS games are suppose to be low poly so much more people could contribute (I think low poly is easiest)
3. It would be easy to expand on (just add more troop types and models so there really isn't much more coding when there is an engine in place).
4. I think a RTS shouldn't have a story mode just a simple story to give a reason for each skirmish, but there would be a lot of factions and troop types.
5. Level design really wouldn't be too hard.

RPG
1. You also don't see many good RPG's but there are more of these then RTS's.
2. Depending on the view of the RPG the modeling would have to be good or bad so more or less people could contribute.
3. It should have an exciting story.
4. Shouldn't be 3rd person like WoW (that view is done too much)
5. Level design would be harder without a good engine because there is no built in editor for Dark GDK.

Just some things to think about Good luck getting this going TechLord!

---

I think an RTS would be cool. I've only seen a few done with DB.

---

I would like to put myself forward as a volunteer for this project if you ever get it off the ground. I am currently working on a FPS with a difference, I could show you what I have done so far so you can see what level I am at.

I am willing to put that on hold as I now realise what a huge challenge it is to do everything yourself and come out with a decent playing/looking game.

I would be willing to work on any aspect of the project, I can programme, design and build levels, work on a story or put music to the project. Although programming and music are what I have done most of so far.

Good luck and keep us posted.

---

I know it sounds crazy but I always wanted to develop a Super 3D Game Engine that had all the features built in to support practically any genre/hybrids: FPS, RPG, RTS, Puzzle, Racing, etc. IMHO, developing such a 3D Engine isn't that far fetched considering the many different genres that folks have been able to squeeze out the Torque Engine, which originally began as a FPS Game Engine. Nowadays you see RTS game mechanics in RPGs, RPG game mechanics in FPSs, so on and so forth. Genre Hybrids are becoming more common and its about time for Game Engine that comes multi-genre ready to be made available.

Additionally, working in 3D space easily supports any type of camera perspective: First Person, Top-Down, Side Scrolling, Isometric, etc. Its a matter of how one orientates and control the camera and player entity. Also, switching between any of these perspectives could be achieved almost instantaneously.

My approach to designing such a Super 3D Game Engine would be to first identify the minimum game mechanics required that defines a particular genre. Second, consolidate game mechanics and systems that can be shared across genres/camera perspectives. Third, plan implementation based of these game mechanics starting from the most simplest to the most complex to get a basic game running.

Collision, Optimized Graphics Rendering Techinques, Pathfinding/Collision Avoidance, GUIs, Physics, Networking, Scripting are all types of systems that one could find in practically any genre and I be willing to wager that the implementation of these systems are practically identical in each.

I would agree and also add that unmanaged code, data, and media changes can kill such a project really fast. Even with source control things can get complicated real fast if members don't agree to a standard of some sort on how code and media is presented, documented, stored, and distributed.

When I was working on Project PLASMA, one contributor recommended black box coding. At the time, I didn't understand this concept, but, now I have an idea on how I would approach it. My approach would be similar to how DBPro plug-ins are integrated. Each contributor codes a self contained system, providing a command set to initialize/update/manipulate/terminate the system's objects, and detailed documentation on each `critical` command/construct. There will commands and constructs common to all systems, these commands will make up the Core Lib and require a Code Czar (for the lack of a better term) to oversee what goes in/out of it. I'm in favor of using a integer ID system to manage individual objects similar to DGDK/DBPro. I'm also in favor of taking advantage of OOP features for a modular design.

---

Hmm, that just gave me an idea! A open source project doesn't necessarily have to be a game so why don't we make a Level Editor that is made specifically for Dark GDK. The thing that would be different between this and something like 3DWS is that you can save the map you have and then load it up in VC++ so that everything in the editor is it's own object in VC++ so you can interact with it how ever you want (instead of one object for an entire level). If we got something like this made that would be an extremely helpful tool for all DGDK users. But it's just an idea.

---

I would even suggest dividing the development in to 4 different stages: Game Engine --> Editor Applications --> Scripting/Data/Media --> Game. My take on this is simple: The Editors design Logic/Media. The Game Engine processes I/O using the Logic/Media. The Logic/Media defines the Game.


Hmm, intriguing concept. Sort of a Visual Game Engine that outputs VC++ code? I'm not familiar with 3DWS and I'm not really sure what you mean by one object for an entire level can you elaborate on this? Visual Illustrations, etc.

IMHO, the team would have to develop an Editor of some sort anyhows. One or more editors could be powered by the Game Engine, which I believe would provide the best synergy between tools and produce the best WYSIWYG results in `The Game` whatever that may be. I wouldn't even consider any details about a particular game until the Game Engine is capable of supporting the basic game mechanics and features of one or more genre(s).

I'm a firm believer in modular design, in which one builds Higher level systems on top of others. If you take a hard look some Low Level Game Systems can be found in practically every game. Below are just a few I can see in many games:

* Sound System
* Bitmap Fonts
* UI (2D and 3D solution)
* Networking
* Collision/Physics
* AI: Finite State Machine, Pathfinding/Collision Avoidance
* Optimized Rendering Strategies: interiors, terrains, particles, animation
* Scripting Engine (go LUA!)
* Particle System

You probably see others. Higher Level systems such as Combat Systems, NPC Dialog, Inventory Systems, Etc are developed from these systems. Not to say I'm ready to start a project, but, locating these systems (Freeware Versions) would be on my First-Things-To-Do list. If we couldn't find them... find whats needed to build our own.

---

Yep, the easiest way to do this would be... lets say you have object 1 at position 10, 212, 100(x,y,z). When you go to export the map it would save Dark GDK code to a text file that includes the position, rotation and scale of an object. So for my example of object 1 it would save:
+ Code Snippet

dbLoadObject ( "object 1's filename here", 1 );
dbPositionObject ( 1, 10, 212, 100 );  

to a text file. So then all you have to do is copy that into VC++ and bam! You got a fully interactable level. We could then go and add things like ambience color, whether it's setup with Sparky Collision or not, etc.

What I mean by 1 object for an entire level created by 3DWS is that 3DWS allows you to edit solids and through in models into the editor. But when you go to export the map it saves it as one file. So lets say you have a map with tons of walls, ceilings, chairs, tables, floors, enemies, etc. It would save that to one single file so when you load it into VC++ it would be one single object for every enemy, chair, table, etc. Which because the enemies are apart of the level (literally) you can't move them unless you want to move limbs but that can be a pain. Although 3DWS is great for creating the architecture for a level. So basically my idea for a level editor (and workflow) would be as follows:
1. Create basic architecture of a level in 3DWS (anything that the stops the player from moving, or any scenery that you can't interact with)
2. Save that map and load it into an editor that we would make.
3. Go through the map adding in things like enemies, doors, breakable crates, health pickups, weapons, etc.
4. Save that map to a text file so all we have to do is copy the code from the text file to VC++ and we have a level

That's what I was thinking in a nutshell.

---

Exporting your world as one object is surly a bad idea, it means that when you draw the object(or check collisions) you have to draw the whole world, thats O.K for pacman lol.

I would think a level editor should take this into consideration and have a built in system to split the level up as you see fit, there does not seem to be an easy way to do this in 3D world studio.

But then trying to emulate such a good and easy to use program as 3D world studio would be a massive task.

Basically what I'm saying is by all means make structures or pieces of levels in 3D world studio but the actual piecing together of the level should be handled in your level editor IMO.

Then save it to file as heyufool says.

---

You could do that one object file for the whole level, then have a seprate image(similar to a heightmap) and have certain colors make that part of the level collidable? I've touched on this idea before in 2D, but not in 3D but I'm sure it's possible

---

Sure its possible, but what about buildings with more than one floor?

I suppose each building could have its own collision system.

That still does not address the issue of drawing your whole world all the time, I'm pretty sure no professional game does this.

---

Well in 3DWS when you export a map into any format every individual solid and mesh in the map is a limb. So if we want we could regulate what's being drawn by hiding certain limbs based on their position. So for example we could use the distance formula so it would be something like:
+ Code Snippet

x1 = dbObjectPositionX ( PlayerObject );
y1 = dbObjectPositionY ( PlayerObject ); 
z1 = dbObjectPositionZ ( PlayerObject ); 
x2 = dbLimbPositionX ( MainLevelObject, i );
y2 = dbLimbPositionY ( MainLevelObject, i ); 
z2 = dbLimbPositionZ ( MainLevelObject, i );
if ( sqrt ( pow ( x2 - x1, 2 ) + pow ( y2 - y1, 2 ) + pow ( z2 - z1, 2 ) ) < 500 )//500 = distance
     dbShowLimb ( MainLevelObject, i );
else
     dbHideLimb ( MainLevelObject, i );

That's just showing what the idea would look like to hide any limb not with 500 pixels of the player ("i" would be the counter in the for loop we would use to update the limbs). I know that it isn't perfect but it works. Also the collisions are simple, we would just use Sparky's Collision. We would have the main architectural object exported from 3DWS and just set it up using SC_SetupComplexObject (...) and that's that. I think some of you are making it seem more difficult then it really is.

---

I'm thinking the exact opposite, some of you are thinking its easier than it really is IMO

Although your example will kind of work, you are still drawing objects that are behind you(or on a floor above etc..). Your system would also have objects popping up in front of you so there is more work to be done there I think. Also you dont want to be using sqrt all the time, what if you have 1000 objects in your level?

What I am saying is its easy to make a slow inefficient game engine, but why would you want to do that?

---

heyufool1, I get what you are saying. I'm currently busy setting up a top down isometric rpg game like this. I haven't started with the level editor yet because i'm still trying to figure out how to define my own level format. bsp dont work that well. To find the vertexes on an X level you would have to bypass dgk and go straight to the dx sdk. I'm currently just using a heightmap with 2 colours (floor and walls). I was thinking to maybe do the level editor so that you can place plane objects as the floors and walls and then save the plane positions and rotations into a file that gets loaded as 1 object by the game. But then gdk does not have functions to find the rotations of 3d objects so that will make it abit more difficult to do. Seems like the only way to make a decent level format would be to learn some directx fuctions.

---

I would be able to help with the coding of the engine I think..
The fact that I've posted ALOT of posts on the forum is because I've got no-one except the DarkGDK community to help me
So don't let that make you think that I am a complete beginner
I can show you what I've done on a 2D space RPG that I am working on if you want to know what level I'm at.

---

How about a coding challenge to get the project up and running, something really basic.

Perhaps a "OS_Button" class (OS-Open Source), everyone try to make the most efficient button class that they can that has a small amount of public functions that would then be used by the "OS_Input" class and its sub-classes (OS_Mouse, OS_Keyboard etc..), it would also have to come with documentation.

Each one is then considered and the "Code Czar" would decide which is easiest to use and most efficient and that would go into the code base for people to build upon.

This is just an idea off the top of my head, I actually believe that no coding should start untill you have a good overview of the whole project along with UML diagrams etc...

Just seen the coding challenges on this board and thought it would be a good idea to get people involved.

The fact that alot of people may already have a button class means that all they would need to do is clean it up a bit and produce documentation for it.



What might a button class do?

It might allow you to declare different types of button:
FireWhenPressedButton()
FireOnReleaseButton()
FireAfterTimeIntervalButton(float interval)

This is just an idea, it would need to be thought out properly and established exactly how it would fit into the whole project first before any challenge is presented to the community.

There is a chance I am approaching this from completely the wrong angle.
What do you think people?

---

IMHO, the ultimate goal of any optimization is to maximize runtime speed for the smoothest Frames/Sec. My rule of thumb is only process what you have to, when you have too. Wether its minimizing the number of instructions to be processed by CPUs, minimize loading times, minimize data sent over a networks, etc. Optimization is applicable to every level and aspect of a game/app design and there is always an opportunity to squeeze more speed.

There are several well known techniques for optimizing graphics and collision processing: Binary Space Partitioning, Portals, Potential Visibility Sets, Level of Detail. I'm a Lazy Game Developer and would rather use a common technique/algotrithm/format rather then to try to invent one. I do a lot of reading on game engine design and often visit Gamasutra.com to get the latest scoops.

From my perspective there are two common loading methods. Pro and Cons for each based on the scale of the level and pace of the game. 1) Load all the media up front (lots of loading screens), 2) stream content as needed (fewer loading screens) Some forms of media are so large that its more pratical to stream them such as Video and Music. Most games have some sort of loading phase Thus, I would be interested in using a Hybrid of the two. I have been eye-balling techniques used in MMOs.

1 & 2. I'm in favor of using a 3rd Party editor for creating static geometry: building exteriors/interiors and terrains. In fact, I don't see any reason to not use such an editor for adding enemies, props, etc. Most game engines implicitly enlist 3rd party Editors in the design phase of static geometry & light mapping by supporting the import of one or more common graphics format (X, 3DS). Pricey, Full powered animation packages such as Maya, Cinema4D, 3DSMax are the primary World Building Tools for some commerical houses. We also have a competitive Free Open Source Package called Blender and it gets my vote of choice.

3. I would agree 200% with using a Built-in `Action` Editor(s) and they're usually built on top of the game engine. IMHO this editor is mandatory to achieve the most accurate WYSIWYG results and simplify testing. Such an Editor will require the development of one or more propiertary formats to store information. I've grown fond of XML and CSV, but, others are possible.

4. Are you suggesting the export of object Logic source code and merging it with engine template source code to be compiled under VC++? I wouldn't rule it out, but, its definately not a common approach. The Pros: 1) Engine Exists in pure open source state; 2) Access to full VC++ OOP features for programming logic; 3) Compiles to machine code. The Cons: 1) Rigid Hardcode; 2) Complicated synchronization of editing/debugging between visuals and logic; 3) Lengthy and numerous compile times; 4) Redundant Effort? Mission Editor, Geometry Formats already available.

Todays Scripting solutions are fast, flexible, simple, and FREE. Scripting adds a unsurpassed layer of programmability to your engine. Therefore, I'm in favor of Hardcoding the performance critical core systems that don't need be altered or modified; In favor of Softcoding the logic for a game entities of infinite possibilities.


Helping others code with DGDK is a noble cause. However, if a Freely available easy to use Super 3D Game Engine already existed I would rather be grueling into the actual Game Creation with Media/Scripting instead of grueling into Engine Creation with DGDK/VC++. Most of us here desire some feature in our game that will separate it from the pack. These features arent either limited or not readily available in Game Creation Software (ie FPSC) -OR- difficult to implement in a Game Engine (ie Torque). For me, DGDK puts the power of Direct X into a easy-to-work-with format and provides access to VC++ powerful features.

---

Sorry, thats a little incorrect, you can edit vertex data and index data using native GDK commands, you can even create meshes from scratch if you want to... its a given that accessing the D3DXMESH object would be faster using directX iteself, but its alot more complex than it sounds You can also use memblocks to create any kind of mesh that you like, or you could make a single plain primitive if you wanted to and recursively split the vertices till you have your terrain sitting there(I saw someone do this for an LOD terrain technique somewhere, not sure if it was DBPro or GDK though)....

Here are some of the VertexData commands :

dbLockVertexDataForLimb(int Obj, int Limb);
dbLockVertexDataForMesh(int iMesh);
dbUnlockVertexData();
dbGetVertexDataPositionX(int iVertex);
dbSetVertexDataPosition(int iVertex, float xPos, float yPos, float zPos);
dbSetVertexDataUV(int iVertex, float fU, float fV);
dbSetVertexDataDiffuse(int iVertex, DWORD diffuse);
dbSetIndexData(int iIndex, int iValue);

If you do want to access the object using directX, you can get a pointer to any GDK 3D object using the command " sObject* dbGetObject(int ObjID); " and use that pointer to get at the mesh, frame, material, shader etc.

---

Ahh it's good to see someone knows what I'm talking about . About the source code in the text file thing... the only reason I really suggested that is because I don't know how to use other file formats like the ones you suggested. Although I am using a mini editor I made for my game with loading code and it works pretty well. What I do is in my editor when I save it to a text file it only saves the value of the objects. For example if object 1 is at position 101,102,103(x,y,z) it would save:
+ Code Snippet

1
101
102
103

to a text file. Then in my source code I have a while loop that just goes to the end of the file and loads each line and interprets it there. It's just as easy and more flexible then copying hard code from a text file, but it doesn't take long to compile.
I'm not saying we make a game engine, but we make the level editor because 1. There isn't any like it for Dark GDK and 2. It would help a ton for game creation.

So I think we should make this level editor just as a simple 1 week project, then make a game.

---

@heyufool1, take a look at this level loader.

http://forum.thegamecreators.com/?m=forum_view&t=125713&b=13

I knew it was around here somewhere, I have not used it but it deserves a look if you are thinking about using 3DWS as the main level creater.

I think it includes frustrum culling which is the kind of stuff I was talking about earlier.

Here is a good site that explains the principles

http://www.flipcode.com/archives/Frustum_Culling.shtml


Edit: just tried the demo and its pretty amazing, this is surly a must for any Open Source project.

---

Thanks for the link Matty Halewood! It's very cool except for some reason it gets a run-time error when loading direct-x files exported using panda x exporter in 3ds max...

---

I would like to participate in developing a full powered open source Super 3D Engine -> Editor -> Game Content respectively. IMO, its more effecient to build an Editor on top of your Game Engine, especially if you desire speed and accuracy in testing your levels. Sure, you can build a separate Editor, but, thats the old way of doing things (ie: Quark Editor for the Quake Engine). New engines like Hero Engine come with impressive Editors built on top of its Engine. So what came first the chicken or the egg? Answer: The Engine!

However, heyufool1, I've been thinking over your proposal. Being a Poor & Lazy Game Developer I'd rather have the option to use a freely available matured 3D Editor. Any decent 3rd Party 3D Editor such as Blender could handle the task of creating static geometry (Building Exterior/Interiors, Terrain) and adding dynamic geometry (enemies, doors, breakable crates, health pickups, weapons, etc) using special label identifiers and generic geometry for placeholders. I wont even mention the support for keyframe and bone animation.

Draw up the Scene, label stuff, and export it to DGDK in an acceptable format, preferrably DirectX Format (.x). The Direct X format is suitable for storing geometry in a hierarachy (for limbs) with labels and additional info for materials, etc. Like other pro 3D packages, Blender has a scripting language (Python) that could be used to write additional UIs and Export `engine` related data not suitable for X. Once exported to x, then all one needs is a Scene Importer Module for DGDK.

The trick to making this all work is in the label identifiers. You name both static and dynamic entities with a special label identifier (ie: `terr_01`, `bldg_06`, `prop_001`, `door_07`, `npc_03`, `trig_23`) and export the scene to .X. The identifiers serve as a key for associating the geometry to any data you desire. So the basic job the Scene Importer module will be to load the X file, parse the identifiers and create keys: <identifier, objectID>, storing this info a data structure of some sort. The keys can then be used to associate the geometry to engine objects, complimentary data, scripts, whatever.

Although, its old school, this method would provide a `Black Box` approach to level building using any full powered 3D Editing tool that allows you to label and export geometry in X format. If the X format is not suitable, one may be able to script a proprietary exporter for the Editor and write DGDK scene importer for that format. In fact, you can write several Scene Importers for several formats.

---

@TechLord

Have you tried the free version of 3DWS?
Have you looked at the open source loader that pixelperfect created for DarkGDK(link above)?

If so, then cool, someone has to make a decision on what tools should be used and how they should integrate and as long as you have cosidered everything then I would be happy with whatever you decide.

If you have not then you should take a look as you are talking about a scene importer and if you see what pixelperfect has created I think you would be pretty impressed as well as seeing how much work would be saved by using it. The other benefit is that 3DWS is unbelievably easy to use (opposed to blender, but then that is free).

I think everyone has their own idea in their head of how it should be done and everyone is probably favouring the tools they are used to using, including me lol.

---

Hi Matty. You got my vote for it. However, before we begin a coding challenge, perhaps we should figure out what the project will be (which appears to be a challenge in itself - lol). I would suggest a series of polls to select a Project, its Features, available code Libs & Tools to use, Project Member Assignments/Roles. Poll Participants advocate for their nomination in a writting. We'll ask for a non-participant (TGC Staff or Mod) to select a winner based on a the most convincing nomination. Once these selections have been made we can devise Coding Challenges directed at solving task that effect the project.

One of the greatest challenges will be keeping the project Open Source on TGC Forum. One thing I've learned from the past is to not `out site` the project until its functional. Once you remove the project from the original meeting grounds, interests slowly dies off as contributors navigate back to it.

We're gonna have to get clever in operating polls, version control, and other collaborative task. I have a web host where I can set up a http, ftp, and databases for the project, however, I desire retaining this forum thread as the primary portal. I've been pondering a means to communicate dynamic changes in this forum. Since applets, iframes, etc are not allowed the next best thing are Images. I've seen folks use dynamically generate images for signatures on other websites, so it should. Now all I have to do is find Dynamic Image Generation with PHP and I'm in business.

---

What is the project?
What is a game engine?

This is how I see it in my head, although my knowledge is pretty limited so you might have to correct me where I am wrong.

We want to create a library of classes and functions which take care of everything which most games have in common. Sometimes I think a good way of working out what you want is to start at the end lol. What I mean is this, what code are the engine users going to have to write, here is a small example with comments describing what the engine might do.
+ Code Snippet

OS_Character player1("elf.x");  // this constructor may load the model and animation data from file and assigns it an object number which we dont need to know.

OS_TPCam camera1(player1);  // creates and sets up a third person camera and tells it to follow player1(elf).

OS_ControlPad controller1(); // creates a standard dual analog controller.

player1.OS_SetActionJump(contoller1.LeftShoulderButton1); // sets a button on the controller to player1 action JUMP.


while LoopGDK()
{
   controller1.OS_Update();
   player1.OS_Update();
   camera1.OS_Update();
}

This may not look like much but that is the point, what you would have with this small piece of code is a character which you can move around and look around with a controller and he is completely animated, he would start with his idle animation(which you dont need to set) and automatically interpolate to walking, running, jumping etc depending on what you are doing on the controller. The camera would automatically follow him around with a third person perspective.

I think this would be a good start and it keeps in with your(TechLord) idea of an engine for any type of game, e.g OS_TPCam could easily have been OS_BirdsViewCam and you have a completely different game.

It also gives you a good idea of how the classes should relate to each other for instance, I have just realised that the controller needs to know what type of camera we are using so that would have to be addressed.

Am I on the right tracks? Maybe I'm being a bit too simplistic or maybe I'm complicating things, you guys will have to let me know.

I know we don't know what the project is yet but I'm voting for Engine-->Editor-->Game(s) in that order.



Edit: Added a very rough class diagram to make it a bit clearer.
Full lines indicate inheritance, dotted lines mean that class makes use of.

---

I would vote for a library.

Graphics and sounds are the only thing that really changes with games.

A chess game is a chess game. A pawn is always going to move 1 or 2 spaces forward at the start and 1 space at a time after that. It is always going to attack diagonally.

The only questions is what does it look like? Does it make a sound when it is moved? Is it a static picture or animated? If it's a car, does it morph into a monster truck and flatten the opposing car?

Chess, checkers, connect4 and tic-tac-toe all have a few things in common. They all use pieces and boards. A CBoard class can be developed to work with all 4 of em.

---

Cool Flowchart Matty. I like illustrations as you can see in here:

http://forum.thegamecreators.com/?m=forum_view&t=147426&b=3
http://forum.thegamecreators.com/?m=forum_view&t=136420&b=8

I can easily see the relation and inheritance of objects within it and its giving me some ideas. I'll draw up some illustrations and post'em tonight.

So far what you have written down coincides with developing a Super 3D Game Engine and its almost enough to start piecing together a main file for the engine. Have you coded anything yet. I would like to take a lil more time get more input, but, if you have code ready lets check it out.

I'm writting out my nominations and will post them within a day or two.

Vote a library for a project? I would think open source implies a library or collection of libs. Can you elaborate please. thnx.

---

I have not coded anything specific for this project, my most recent project is a FPS(TPS), at the start I promised myself that I would take my time and not get too far ahead of myself. So the idea was to create a small set of classes that will load any model along with an animation data file which you could easily create in notepad as long as you stick to the correct layout and then you could use simple commands like:

player1.move(170, 5); // (angle, speed)

This would move and animate the model as specified.
I made alot of progress and it works to an extent, but as usual I started up another project and started making my game with the incomplete classes, I made quite good progress with this as well but realised that I was getting ahead of myself and I should go back and finish my classes with documentation so I could use them in all my future projects, then I saw this thread and thought what a good oppertunity to start again and do it properly and actually finish what I'm doing before I move on as other people will be relying on me, plus they will be making progress in other areas so I could concentrate on doing one small part properly.

I can send you the classes with a small example of what they can do so far, but they have no documentation.

As far as using them for this project, I dont think it would work but I could certainly use some of the methods and ideas from that project. For instance, a standard text file to hold animation data worked well, I have included it with this post(colX animations), I never put all the animations in so it does not look like much, but you can see how easy it would be for the modellers to put their animation data together and then their models could be dropped straight into the game and be automatically animated when they move etc..

O.K I'm going on a bit now, one last point I would make is that I believe we should have a good overview of the project and how the objects are going to relate to each other before we code anything.

---

I have no idea what is causing this, but as we have the source for this loader, fixing any small incompatability problems would surly be easier than starting from scratch.

We could always create our own editor that places objects in the world we create in 3DWS, it might also deal with collision, triggers etc..

---

Agreed, which is why I writing my recommendations for A Project, its Features, available code Libs & Tools to use, Project Member Assignments/Roles and encourage anyone seriously interested in participating to do so as well. Lets set a deadline for posting nominations by 08/20th. In the meantime lets continue discussion.

---

Do you know of anyone else who is doing this?

It may only be you that is making the effort, I hope not though, the more people interested the better.

If it is only you then that might not be too bad either as your recommendations will give us a good overview of the project. I also think that since this is your whole idea anyway you should pretty much tell us what the project is lol. But kudos to you for giving everyone the chance to have a say right from the off.

I will try to put something together before that date as even if just a small part of it is picked up then it will be worth it.

---

BECOME A CONTRIBUTOR IN THE DGDK OPEN SOURCE PROJECT-TRIO TODAY!!!

---

Cool diagrams TechLord, I may have lots of questions for you once a project is decided, hope you dont mind.

---

Thanks Matty. I sent you an email. Please feel free to ask any questions you desire.

---

My nomination for a DGDK Open Source Project.


THE PROJECT

To start the creation of an open source 3D super engine.

To develop it in such a way that once each unit(plug-in) is complete it will be useful to the community in its own right and at the same time fill a vital piece in the jigsaw that is the DGDK Open Source Super Engine.

The project will be split into stages, each composed of units that will seamlessly integrate to complete that stage. The units themselves will be developed with an object-oriented approach to allow multiple people to work on self contained classes that will make up the OS (open source) library.


THE FEATURES

Library – A collection of existing and new plug-ins brought together to give the clients of the engine a simple interface to create games of any genre.
FPS, RPG, RTS, Puzzle etc...

Level editor – A real-time editor which will allow the set-up and manipulation of all in game objects, this will make full use of the library's versatility and will allow a simpler UI for the engines clients to create their game.

Games – A series of simple demonstrations that show off the capabilities and ease of use of the engine.


THE TOOLS + PLUG-INS

Tools:

Blender – free 3D animation suite.

3D World Studio - level building tool that is popular with the TGC community.

MAUI – user interface system which will fulfil every requirement for the development of all the GUI's whether they be for external applications or in game menus, dialogue boxes etc... currently being developed by TechLord.

Plug-ins:

Sparkys Collision

Multisync

3D World Studio loader - by Pixel Perfect

............and many more to be confirmed.......


THE JOBS

Software engineer(s) – To complete the planning of every aspect of the project with full documentation, to also do integration tests to make sure all the components will relate to each other in the desired manor before coding begins. Their role will also be to make sure the core team is coordinated and each member is clear in their role.

Core team – group of people to oversee the project and coordinate what goes into the project, perhaps to help modify contributors source code to integrate it into the core engine.

Programmers and artists – People from the community who feel they can contribute to any aspect of the project, they would work closely with the core team to make sure the interface to their source code(programmers) is completely compatible with the project.

---

I have to agree with Matty's idea.

---

Count me in as well

Cheers,
-Try

---

How were we thinking of deciding who is going to be in the dev team?
Or is anyone who wants to be in going to be in?

---

Well, IMHO we could let anyone who has any kind of interest to cooperate in making any part of the project (at the beggining of course! and to motivate everybody )

So, first we need to assume what is needed for the game (engine, editor, etc.) and what kind of skills or people we need to accomplish what we want through out the project.

I'm thinking about TechLord him self to watch over the process and maybe Mista Wilson is he has got the time (these guys are cool and have good manners, I like 'em )

So, any ideas? (Can't wait till we're actually on the horse riding wildly )

Cheers,
-Try