Sorry your browser is not supported!

I'm trying to decide which Dark GDK version to get (GDK.C++ or GDK.NET).

There are some things that I have concerns about regarding each product, some of which probably only the developers for TheGameCreators can answer, because they concern the future direction of their product development, and I'm not sure of their plans.

Concern #1: The Update Food-chain.
It appears in the product upgrade food chain that DB Pro is always updated first, then GDK.C++, followed by updates to GDK.NET. In addition, it seems that the number of features present in each product decreases as you go further down the food chain, so that DB Pro always has the most features available first (e.g. all those add-on packs), while (as of the writing of this thread) GDK.C++ can use DarkShader, but GDK.NET cannot. Is this the way things will continue for the near term?

Concern #2: Elegance vs. Performance vs. the Long-term Future.
At present, it appears C++ rules the Windows game development world with its unsurpassed speed of execution and huge quantity of development libraries. But it is a relatively kludgy and complex language, a simpler core language retrofitted with OO programming scaffolding. However, the future of Windows game development languages I feel lies with .NET, CLR compatibility, and managed code, especially once Vista is widely adopted and .NET functionality can be counted on as built-in Windows functionality. In the .NET managed code arena, there are definitely choices out there for using some elegant programming languages. Will GDK.NET eventually replace the need for GDK.C++ altogether, where instead of just an interop wrapper, GDK.NET becomes the flagship product, written from scratch to be a .NET app? (Perhaps someday even a GDK.X10 or GDK.XNA?) By the way, has anyone run any benchmarks showing how close (or far) the performance between GDK.C++ vs. GDK.NET is?

Concern #3: Having the rug pulled out from under me.
Although there are a lot of things to like about GDK.NET, from earlier posts in the forum I got the impression that it started off as a personal project of one of TheGameCreators' developers. Recently, in another post, TheGameCreators said that GDK.NET has a "bright" future. (I hope "bright" doesn't mean it will soon flame-out, now that the initial development phase has ended.) Does this mean that from now on you are committed to updating this product? Do you plan on eventually rolling out updates to DB Pro, GDK.C++, GDK.NET simultaneously?

Conclusion (yes, finally)...
If I was only considering development for the immediate here-and-now, GDK.C++ appears to be a little more favorable because it seems to get updated more quickly and contains more game development features (e.g. DarkShader) than GDK.NET. But I definitely feel the future lies with GDK.NET. If you develop games for the Windows platform, you may at the present time be working with .COM-based technology. (Or as GDK.NET now stands (?), a wrapper over .COM-based technology). But eventually I think you will be forced to develop under pure .NET, because it will not only become the standard underlying core Windows technology, but its advantages in ease-of-development cannot be ignored either. So, which to choose? It all depends on what TheGameCreators plan on doing, I suppose.

Here are my thoughts:

#1 The Update Food-chain.
Clearly the greatest lag in feature migration is going from DBPro to the GDK. Paul APEXNow is pretty nimble in passing those down to the .Net. But there's more to DBP than just the "basic set" as you pointed out: there's the plugins. Now getting those into the GDK's from DBPro is a lot trickier as sources and willingness to port needs to be available from the original authors.

Concern #2: Elegance vs. Performance vs. the Long-term Future.
I also think that once you get used to C#, C++ can be quite clunky at doing certain things. However the long term future does tie with #1, and the fact that people involved in maintaining DBP->GDK->GDK.Net does diminish as you progress along that list. In the case of the .Net version the truck factor is enormous: if anything were to happen to Paul (perish the thought!), the .Net version is toast.

Concern #3: Having the rug pulled out from under me.
This one, again, really is an extension of the other two. I really don't know how many people have bought the GDK or the GDK.Net. But it has to be several degrees of magnitude less that DBPro. Should maintaining the GDK become more of a pain than it already is, with the limited return TGC probably are getting from it, I wouldn't be surprised if they would chop it altogether in a time of dire need, unlike DBPro which, short of TGC closing for business altogether, is not going anywhere.

FYI I own DBPro, which I nearly don't use, and the C++ GDK, which I also haven't used much but in this case due to general lack of time in life (I would/will use if life slows down a bit). I don't have the GDK.Net, although I will buy it someday because Paul deserves it.

For those who want to know about the "truck factor" look here
http://www.agileadvice.com/archives/2005/05/truck_factor.html

As of this moment, addition packs for both DGDK and DGDK.NET are being dealt with. I will not detail any further regarding this situation, but it is effectively an on going process in order to ensure continuity for both products. Also, as of v1.0.8.0 for DGDK.NET, this should provide DarkShader compatability as is been stated for the library updates to DGDK(C++). Any releases of DGDK, are immediately placed into the .NET version as soon as I obtain them.



As far as language support goes, there will always be the various flavours of language, and in reality, C++ will most likely remain the primary language of choice for all professional game development teams. I try to refrain from judging the various languages because it's a matter of using the tools that are best for the job at hand, so the potential to mix languages and the respective game platforms, isn't an impossibility. I'm somewhat sceptical as to the overall performance issue if DGDK.NET was ported from scratch into a true managed code library, and really, the performance hits are most likely to be the interop layer anyway. In general, .NET itself is a pretty efficient and fast development platform which may even exceed certain functionality bottlenecks that are found in C++. I've not performed any rigorous benchmarking tests between DGDK and DGDK.NET, since they both use the same engine code internally, and DGDK.NET would as a matter principle, run slower than the C++ veraion anyway. How much slower is totally dependent on how much interop activity is used.



DarkGDK.NET's idea began with a chap named CattleRustler, a good friend of mine. We both banged heads together to see if the concept was viable as an alternative toolkit for .NET users. I then began work on prototyping the library and got heavily involved in security, documentation, testing etc. It took a number of months, but TGC were very positive by what I had shown them before we took it to the next phase. As of now, the product definately holds true as an option for .NET only users. Plus, having compatability with VB and C#, easy installation and setup, I'd be mad to not continue full support for the product. And, incase you are worried, this is what I've always intended. Which does raise the issue of "Truck factor". If anything does happen this end that constitutes a catastrophey, it will be handled by a third party.

I will refrain from reply to the conclusion as this will put me between a rock and a hard place. So I'll leave this decision to you anyway.

Hope this answers some of your questions.

Paul.

Thanks for your input, guys.

@Miguel: I haven't come across the term "truck factor" before, heh heh. Thanks for that tidbit and your feedback.

@Paul: I am glad to hear that you are determined to keep DGDK.NET current with DGDK.C++. I'm not crazy about the wrapper/interop layering of the product, but I suppose as long as it must remain identical to DGDK.C++, it is probably the only reasonable way to go. Did I understand your post correctly, in that as of the latest release of DGDK.NET (version 1.0.8.0) it now supports Dark Shader? If so, this is good news indeed!

The ideal situation would be for TheGameCreators to develop a native .NET product, or perhaps an XNA-based product (unless as has been demonstrated in FPS Creator X10, you might have an even better Framework to build from ). A number of XNA-based game creation systems are starting to appear (e.g. XNA Magic, Visual3D.NET, Torque X Engine, etc.) and it seems C++ libraries are being converted over to .NET or XNA more and more. I think I spot a trend. I guess inside I'm hoping you would base future products on .NET, XNA, (or perhaps your superior FPS Creator X10 Engine) because I would like to see TheGameCreators remain the leading source in the realm of easy but very functional game development software that could be used to develop commercial products. Since you guys announced that there will be a DB Pro X10, will there be a corresponding DGDK.X10?

Incidentally, on the topic of programming language usage, TIOBE Software maintains a programming language popularity index chart, updated monthly, based on a number of factors. Just go to their website and click on the link in the right-hand panel that says TIOBE Index for February 2007. A quick glance at the chart (scroll down the page to the second chart to see the long range trends of the top 10 programming languages in use) shows that C++ usage is starting to decline overall, while Visual Basic is most likely winning the battle of .NET languages (the index combines the use of all versions of VB though), and C# usage shows a very gradual but steady growth overall in its usage.

As i understand, DGDK.Net is 99.9% identical to DGDK.C++ in functionallity as the .NET is only a wrapper for the C++ library.
So anything that is natively supported in DGDK.C++ should be supported in .NET as soon as Paul has an updated version ready.

Before I can decide which version of DGDK to purchase, I need to know one last thing:

Lee mentioned on one of his videos that entirely new libraries are being developed for the new DirectX 10 engine that FPS Creator X10 and DB Pro X10 will use. Furthermore, he mentioned that Windows Vista would be one of the requirements for using FPS Creator X10 (and presumably DB Pro X10).

Since Windows Vista is a requirement, are these libraries being written based on technology from .NET, XNA, both, or neither?

If the new DirectX10 Engine is going to be based on .NET or XNA, I think I'll purchase DGDK.NET, since any future DGDK would have to also be based on .NET or XNA technology. If not, then perhaps sticking to DGDK.C++ and avoiding another layer of possible performance/compatibility issues may be the better course of action.

I made the decision to go with DGDK.Net vs the C++ version for simplicity. Frankly I hate C++, I know it, but I hate it. It is way overkill for anything I want to do, ultimately people need to understand something about .Net All of the core languges in .Net decompile into the intermediate language compiler.

This then means that all base result is the same wether you wrote it in C#, VB.Net, or even C++. However, the difference to C++ is that Microsoft opened alot more core framework to it first, so there is the real food chain.

C++ will always have more than C# and VB, where as C# and VB share the same framework calls.

As for XNA, thats a different animal. It is written to be used by VB.Net and C# (mainly C#, there are instructions out there on how to use it with VB.Net). So, if you are thinking XNA, then go with DGDK.NET.

Thats my 2cents worth as it is. I own DBPRO and DGDK.Net and as far as I am concerned, they have done a BANG UP JOB with the documentation and conversion, just lacking on samples that I desire at the moment.

While deciding which version to purchase, there is something that could help. There's actually a OOP Wrapper for DKDG.NET, it is called DarkEngine. Some people say it is better to program in DGDK.NET using it (as it handles all the objects ID, and also I think the classes names are better: DarkCamera vs. oDBCamera).

Here are some examples:

Using DGDK.NET


With DarkEngine Plugin for DGDK.NET


I know I shouldn't be the one to tell this (as I am one of the developers of DarkEngine), but maybe that's a good point if you're like me, someone that do not live WITHOUT OOP.

Hope that's something that will help.
Best Regards

Thiago

I am not expert, but I read and experiment a lot. I love C++, but I have decided to go for C#. Philosophically, I don't believe in intuition, but because of lack of expertise, my vote, for myself, went to C# and I think it is because C++ requires lots of non-game programming "activities"!! Also, I have DB pro for many years, but I just discovered it recently. Now, I switch between DarkDGK.net and DB Pro.