Planning a GDK

A group of us are getting together. To make games. We have elected to use Axiom.

Since Axiom is only the renderer we have to find/make/compile a GDK

Took a quick look at RealmForge and downloaded the source code.
Also sent the maintainer of the project as listed about taking over the project. Got no response, soon after found the homepage reference fixed. But now it points to the propriety product that sprung from the realmforge project. So I guess that I got my answer after all.

Since all of us are married and cannot afford licenses (hence the open source tools like Axiom) we have to start from scratch it seems

Anyway...
We plan to build a GDK that is open source and will stay open source.
Give back something.

Anyway we would like to Build a GDK based on Axiom.
100% C#
Run with Dot Net Framework or Mono
Cross platform

Axiom comes with a awesome set of tools/binding for other things like
physics, gui etc but nearly all seem to be bound to C++ dll, libe etc.
Anyone have a list of replacements?

For example the CEGUI had/has a similar project #CEGUI that appears to be dead or ?? I cannot really find much current about it.

Anyway we are extremely serious about this. And if anyone has any advice assistance etc. A bigger community for an open source project usually means survival.

thanks a bunch,
theMouse

[Borrillis]

A group of us are getting together. To make games. We have elected to use Axiom.

Great!

Axiom comes with a awesome set of tools/binding for other things like
physics, gui etc but nearly all seem to be bound to C++ dll, libe etc.
Anyone have a list of replacements?

GUI - Cegui#
Physics - XNADev.Ru ( Managed Bullet Physic Engine ) http://www.codeplex.com/xnadevru
Input - SharpInputSystem ( just started )

For example the CEGUI had/has a similar project #CEGUI that appears to be dead or ?? I cannot really find much current about it.

It's not dead, just does not have a very active community surrounding it at the moment. It's used in several projects besides Axiom, like MOGRE and OgreDotNet.

thanks a bunch,
theMouse

No Problem, and good luck!

Hey thanks,

Good to know about #CEGUI. The guys and I were talking. (After seeing some stuff about KDE 4, and SVG.) were were thinking that might be really nice. Not sure about how CEGUI works. Does it load bitmaps etc? Just a 50000 ft overview will do!

How about AI any C# ones?

Also were were planing on using C# as the scripting language as well as the programming language.
http://www.members.optusnet.com.au/~ole ... index.html

Thinking it would be nice to leverage skillsets, and functionality.
(The CS Script Lib also almost compiles with Mono, there are warnings but those can be resolved, errors debugged)

theMouse

Hi,

The idea is very good, i would like to help.

Is SharpInputSystem in progress?

_r00t_

[Borrillis]

Is SharpInputSystem in progress?

_r00t_

Yes, it is in progress, I have spent several weeks building the interfaces and getting the basics working, I have the DX keyboard functioning properly now and and going to start working on the mouse. If anyone is interested in asisting, I will commission a project for it on SourceForge,

Hi,

I would like to know what you think about use a discountinued Realmforge as base to a new LGPL C# game engine?

[_r00t_]

I have been looking at RealmForge.
I think it would be good as a reference but starting with it or using it as a base is probably a bad idea.

1) Its someone else's project. And that someone is no longer answering questions.

2) I think that the maintainer went to Visual3D.net or is at least part of the team. Conflict of interests?

3) (personal) I don't like the in-game editor approach. I'm a coder and I like my ide's

4) its not flexable enough. I have been thinking that a "wrapper" path may be better. I know that "wrapper" has a bad tone but hear me out...
I think that all the libs should be plug-in-play. You can allow different rendering engines (AXIOM or OGRE), GUI (CECGUI), Physics etc. This would generate more interest in the project itself. And allow the C# versions to be done separatly. This way the GDK would be more stable. Code stays the same etc.

I am still putting together the "design" using DIA. I'll post more later.



Adam

Well, I would be a customer of your GDK - I am leading the development of a game which we hope to turn into an MMOG.

We have extensive hardware infrastructure (over 6 servers, db clusters) and are professionals in our fields (network admin, software design, etc). So its not a bunch of kids, as is the case with most indie MMO titles.

If you guys can make a decent GDK which will be able to be used with a MMO - then I'll happily see about using it. Of course, the whole art/dev team will need to agree to it, but I am sure they won't be hard pressed if you do a good job.

For more info, we're at http://www.projectparagon.info

Check us out
Meldarion

[Borrillis]

I have been looking at RealmForge.
I think it would be good as a reference but starting with it or using it as a base is probably a bad idea.

1) Its someone else's project. And that someone is no longer answering questions.

He is quite busy with ither things ATM.

2) I think that the maintainer went to Visual3D.net or is at least part of the team. Conflict of interests?

Yes, he and few others in this community are now part of that organization.

3) (personal) I don't like the in-game editor approach. I'm a coder and I like my ide's

I agree with you here. I have been tossing around the idea of using SharpDevelop for an IDE. The only problem with using SharpDevelop is that it is Windows only. There is MonoDevelop, but that would mean writing 2 sets of plugins, not the worst scenario in the world, but a little more difficult.

4) its not flexable enough. I have been thinking that a "wrapper" path may be better. I know that "wrapper" has a bad tone but hear me out...
I think that all the libs should be plug-in-play. You can allow different rendering engines (AXIOM or OGRE), GUI (CECGUI), Physics etc. This would generate more interest in the project itself. And allow the C# versions to be done separatly. This way the GDK would be more stable. Code stays the same etc.

I am still putting together the "design" using DIA. I'll post more later.



Adam

Yep, couldn't agree with you more.

Working on the design.

Architecture / Plug-In Design
Have any ideas on this? I am not sure where/how etc would be the best way to do this.

I would like for it to work.
GDK.CodeLibrary -> Provider DLL -> Functionality.DLL

i.e
GDK.ScriptLib.DLL -> CSharpProvider.DLL -> CSharpScript.DLL
GDK.ScriptLib.DLL -> LUAProvider.DLL -> LUA.DLL
GDK.ScriptLib.DLL -> PythonProvider.DLL -> Python.DLL

GDK.GUI.DLL -> CEGUIProvider.DLL -> CEGUI.DLL
GDK.GUI.DLL -> CEGUI#Provider.DLL -> CEGUI#.DLL

GDK.RenderEngine.DLL -> AxiomProvider.DLL -> Axiom.DLL
GDK.RenderEngine.DLL -> OgreProvider.DLL -> OGRE.DLL
GDK.RenderEngine.DLL -> OgreDotNetProvider.DLL -> OGREDotNet.DLL
("I of course prefer Axiom. But to build a full and strong community for the GDK I'll have to support all of them. And if someone wants to add a provider for another engine i.e Irrlicht or something they can.")

Basically the GDK.CodeLibrary will (or should)
provide the objects that will be used in the GDK
and the translation specific code in the provider which calls the actual functionality in the Functionality.DLL.

And I think the "provider" should also expose all the raw functionality
of the Functionality.DLL. In case a developer wants use all the power of the given library.

Normally when I have coded for work either the provider (i.e SQL Server/ ODBC, yeah I know old but this is an example ) was written for me or if I wrote it, it was directly referenced.

What is the best way to do this and keep within the coding style of axiom/ogre. Any idea's, know of any examples? I have a few things I tried, but the so far they seem a little cobbled. Need a more professional/standard approach.

Also the name of the GDK? RealmForge is taken, and the only one I like . Everything I come up with sounds like crap, LOL. Best I have is
OSGSK "Open Source Game Development Kit". Basically trying to determine the root namespace. You have any ideas?

[Borrillis]

Working on the design.

Architecture / Plug-In Design
Have any ideas on this? I am not sure where/how etc would be the best way to do this.

This can depend on how you want the behavior for each of these subsystems to behave. Is there going to be only one ScriptLib possible or many? Are you going to allow multiple GUI providers or only one?

You can look at the Plugin System of Axiom for some examples of both. Only One RenderSystem and SceneManager is allowed, but Other SubSystems could allow Many ( Media Codecs )

You might want to check out Pluto, it's a Plugin toolkit that might suit your needs.

Also the name of the GDK? RealmForge is taken, and the only one I like . Everything I come up with sounds like crap, LOL. Best I have is
OSGSK "Open Source Game Development Kit". Basically trying to determine the root namespace. You have any ideas?

Not yet.

Well I plan to make this as open as possible.
I have seen a lot of GDK/Editors out there. But like I have said before they all seem to die.

I don't want that to happen.

I'll take what ever advice you have

theMouse

Some advice?

Start small. Really small.

The only way to fuel growth is through successes - and its better to have lots of little successes often, than one large success all at once.

Keep the ball rolling with new features getting added all the time.

Basically - get a basic GDK running for Axiom/ODN which loads up the graphics engine with GUI support. Then tout that around while adding Scripting, then Networking, then Sound.

You may want to know about Lidgren - its a UDP network library written in C#. We are using it for our project.

Alternatively, you could come to our project (and my indie game dev company) and we will manage the GDK project for you and make sure you have all the needed resources to get it done.

Thank you for your advice.
Start small is the game plan.
Sort of.

Full design first. I want to make sure that I think as much as possible
and build the framework to be as solid and flexable as possible.
Then modular design. Do the design so it can be built 1 piece at a time.
Hence I am looking at all of the parts I will need. Some of it I will figure out later.

Its basically the design I need to make the games I want anyway.
Just isolating the parts that will be truely different.
I'll just sharing the common code.

Plan to release it is going to be like this:

Initial Release
Core (everything you need to load/run a basic game. No AI, Networking etc)
Basic IDE (I may just release SharpDevelop/VS "starter" projects and create designers/plug-ins for the various editors etc. No point in re-inventing the wheel. But I am not at that point in the design yet.)

Then release the different parts. Add the functionality to the game and its "designer/plugins" that are needed with it.
Probably
Networking
AI
etc.

Also thank you for your offer, in joining your project. Which looks great.
But I am not ready to do that yet.
One I don't know all of what I need yet. (13 years programming will only take you so far. I need a basic understanding of the parts before others can rely on me. I am getting there but I am not there yet. Doing this design is part of that process.)
Two time I can commit and stick to is sporadic at the moment. Between work, school (going back for a gaming degree. gotta learn 3ds max from someone LOL), family.

Wonderful - I think you have gotten a good plan together.

If you have any more questions, I'd be more than happy to answer them - feel free to email me about them. My email is on my profile.