Some time ago, before I switched over to C#, I was an avid C++ developer (and you can bet, I still am!). I was hopping between 3D engines, looking for a well designed and dependable engine I could build my indie games on. After some proof-of-concept projects using The Nebula Device by german developer Radon Labs (Urban Assault and Project Nomads) and later Ogre, I decided to roll my own.
Thus, the Nuclex Engine was born. See, the overall design of engines like Ogre, The Nebula Device or even Crystal Space is quite neat and if you are willing to concentrate your efforts on the game alone (which you should, if you want to turn your work into money), these engines can all carry your project to the shipping stage. But I felt their design wasn't as clean as it could have been, the interfaces were not as lean and convenient as I knew they could be made.
Support Plugin Image Video Audiere Input Scene Script |\
___|_______|_______|_______|_______|_______|_______|_______|___| \
|###|#######|#######|#######|#######|#######|# | | \
|_______|_______|_______|_______|_______|_______|_______|_______ /
| | | | | | | | /
Math Storage Font Audio RStates GUI Terrain |/
Of course the work was far too great to ever reach the finish line (I had an actual finish line drawn out all right), but it taught me a great many of things about design you can not easily acquire from books. And I was obsessed with design when I wrote this engine -- anything else came second to creating a design that literally forced you to do things the right way. It boasts quite a few cool features. With its current kernel and plugins, you can stream data out of .zip and .rar archives without creating any temporary files on disk, convert any RGB-based pixel format into any other with optimized code that is generated at compile time by template magic and create themeable GUIs with anti-aliased text. You've got 100% platform abstraction, allowing games based on the engine to be ported to linux effort-free. Only plugins contain platform-dependent code, and most of them use libraries that work on several platforms.
With this post, I'm releasing my work of over 3 years to the public, free of any cost. It's not a completed engine you can just take and build your next game on, but it's not you typical abandoned pile of code either.
Anything (and I mean anything without exception!) is carefully documented using doxygen tags. It builds on cutting-edge C++ programming and makes use of Boost, Loki and libsigc++. I think this engine shows many interesting design approaches and that it can be of great value in studying new engine design approaches. It is my hope that it will be of use for someone out there to learn from it!
Full Source Code
Demo Application Binaries
Browse the source code repository online
Some numbers:
- The Nuclex Engine consists of about 40,000 lines of code. The code is highly efficient and makes full use of STL and Boost, I expect most developers would require about 120,000 lines for the same.
- Around 50% of the code is comments (not commented-out code, but actual english sentences :P)
- According to the intermediate COCOMO model, this project should have taken 10 person-years to develop, which pushes the estimated development cost way above the $500,000 line.
Demo doesn't work
Hi there.
Unfortunaly, demo doesn't work... can you fix this?
As soon as I run demo, I see the message box:
"Error executing program!"Nice
I've always enjoyed your engine architecture "ramblings" on www.zfx.info and now you release your WIP code. Pretty awesome! I'm a fan of micro-kernel like architectures myself. I've also gone through various back-and-forths with C# (when the first Managed DX came out), then back to C++, then tried XNA for a while and am now back to C++. I would assume you are now rebuilding your engine design for C# on top of the XNA framework, right? Do you plan any kind of community development (i.e. a shared repository) or is it all private stuff?
Cheers and thanks for releasing ... it'll make an interesting read once I find some time :)
-Marco
Unknown Extension
.7x is unknown to me. What decompressor knows this?
.7z is the 7-zip extension.
.7z is the 7-zip extension. You can get a program to decompress the file here: http://www.7-zip.org/
Google "7z" and hit I'm Feeling Lucky
http://www.7-zip.org/
Demo Problem
@Albert: If the error came from within my code, there should be further informations indicating the exact cause of the error. Is there anything else in that message box?
I've tried it on a fresh WinXP install with only DirectX 9.0c (June 2007) and the Visual C++ 2005 SP1 runtime on it (plus drivers for my graphics card, of course) and the demo ran fine.
Maybe your DirectX version is too old? (note that there are a dozen or so sub-releases of DirectX 9.0c, the demo requires the DirectX 9.0c June 2007 runtime, it won't even work with the April 2007 release.
Just curious...
...but the nuclex.txt bundled with the archive is written half in german and half in english. While I've always wanted to learn german, I don't think this is the best primer! :) I was just wondering if the german parts is replicated in the english parts, and if not, what I was missing.
I'm looking forward to playing around with this engine. I, too, am a stickler for proper coding practices, and an engine designed from the ground up with the stl and boost in mind sounds perfect for the side-project I have in mind.
Weeell...
Nuclex.txt has just been my personal scratchpad. The german parts don't replicate the english parts, but if there's something in german, I was just brainstorming or writing down the pros and cons of some concepts in a hurry.
So just ignore those parts ;). The entire engine codebase is 100% english in code and comments. If you're curious about something in Nuclex.txt, I'd be happy to translate that part for you!
C# Transition
@Mk42: Hi there, I didn't expect anyone from the zfx.info community would still be visiting my site. It's been quite some time since I last posted there :)
I can understand people switching back from C#, I am having second thoughts myself (see my post C# Revisited). Only the handy assembly "packaging" and CIL portability has sold me to .NET, C# as a language doesn't really impress me. All that LINQ stuff and abominations like foreach and using (compiler features which are linked to the runtime library) could have been done in C++ with templates and without bloating the language :]
My current idea is to churn out some indie games as fast as possible without sacrificing quality so I can earn a few bucks. I guess engine design is on hold for me until I can finance a studio to get a publisher and eventually some boxes on the store shelves :o).
My current work in progress stuff can be viewed at https://devel.nuclex.org/framework/. I haven't thought about community development yet, but I plan to get some more public exposure of my work!
Further developments?
I'm really pleased with what you had gotten done already, but as you said, it's not a completed engine I can just take and build my next game on. It's unfortunate because there's so much promise, and I would definitely prefer using it over OGRE or Irrlicht (or others) if it were ever finished. So, Cygon, do you know of any open-source movements built up around the Nuclex engine? I wish I had the kind of time to develop to it, myself.
Not Yet
Nope, sorry, I haven't heard of anyone actually continuing development of this engine. Some people have mailed me asking the same, but so far, I had to tell them the same.
Part of the problem is that I'm just not a community guy with connections, so the publication went off rather silently with just a tiny news item on gamedev.net. So my hope was and is that it will serve as a project to gather ideas from, or to extract example code from, like the 2D-on-3D rendering system, text drawing routines and/or GUI stuff.
toxid tanks in msvc9
I've been exploring a number of different plug-in architectures for a set of scientific applications I'm considering writing for my job. I decided to take nuclex for a spin due to the fact that it claims to be as raw c++ as can reasonably be expected making screen handling in linux / mac-osx possibly sane. Unfortunately right now I can't even get it to run right in windows (granted I'm running vista x64 but I'm compiling it as a 32bit windows app). I'm currently recompiling some of it's dependencies with debug flags enabled to hopefully track down what the problem is.
I'm especially interested in getting the storage server working with other file formats (fMRI data formats in this case) even if only through a console interface.
So first, anybody have any luck building and running the demo in vista with vs2k8, and has anyone taken a swing at developing say... a CMake file set for the framework?
replacing the /lib area with new versions of the files
I'm not entirely sure how you setup the /lib area of the nuclex engine but I can get SigC++.msvc8sp1.lib to look at the latest version of libsig which I built using vc9 when I'm doing a release build, however I can't seem to make it do the same thing for a debug build. Having no idea how you create those .lib files to begin with I'm not entirely sure how to replace them (I'd like to upgrade as many of the dependencies to the vc9 versions as possible and get the building in debug/release/final build forms).
VC9 Builds of Nuclex
Supporting Visual C++ 2008 should be trivial. I'll see if I can churn out an updated VC9 distribution of the engine!
The .lib files already existing in the source distribution are binaries of 3rd party libraries I compiled myself (eg. libsigc++, corona or Loki.
When compiling the engine, the import libraries for the engine dlls are also written into these directories so that - once the engine compiled - you can take the bin, lib and include folders and have everything you could possibly need to build your own projects.
I have VC9-compiled binaries (also including x64 builds) of most of the libraries used in the engine in my externals repository:
https://devel.nuclex.org/external/svn/
I have since dropped the Final build concept (Release meant optimized with debugging informations and Final meant ful rebuild with aggressive optimization). You can use the release binaries for the Final build configuration (all my static libs use /LTCG, so they're recompiled at link time anyway, resulting in the same performance level the original -f libraries had.
Post new comment