The goal of RakEngine is to put together all the best game libraries and utilities on the net in one package. There's no engine specific code except for code to bind these libraries together or provide trivial functionality. It's mostly just a collection of libraries that you could have downloaded yourself. But it's a pain in the ass to setup the solution, the include and link paths, and get libraries compiling so I did that work for you.

Here's the libraries I chose, why, and what I had to go through to get them to work, in case you were considering alternatives:

******* INCLUDED LIBRARIES ***********

*** Graphics + GUI: Ogre 3D 1.2.2 Dagon (p1)Why:Ogre 3D has the most features and support of all the 3D libraries: The runner up was Irrlicht, which is very well written, easy to use, and easy to modify. It also compiles without dependencies so is good if you can't have or don't want dependencies. However, Irrlicht has a smaller user base and as such as far fewer tools and exporters. It also has fewer features.

Ogre 3D comes with CEGUI. It's not as easy to use as it could be. I made things a little easier by including a "GuiManager" class so at least you don't have to parse input from OIS to CEGUI.

Setup:I spent several hours trying to get Ogre 3D compiling directly into the engine as a DLL. However, I was reminded by a forum user this means the engine would have to be LGPL. So eventually I just put it as-is under Source/Engine. I built it directly there, so you can trace into the sources without having to specify the paths somewhere else. I also cleaned up all the unnecessary files created by the build process.

*** Sound: fmod 4.04.20Why:It literally took 15 minutes to add to the solution. Everything worked the first time, was easy to use, and it is very cross-platform and powerful. fmod has a downside in that it is non-free, but it is only $100 for a shareware license. The alternative was OpenAL. I spent about 8 hours trying to integrate it before I took a look at fmod. In short, OpenAL sucks and you'll save more than $100 worth of your time just going with fmod. fmod is also free for freeware games.

Setup:It's easy to use so no wrapper was necessary. There is a project with a dummy .cpp in case you want to add to the project.

*** Input: ois 0.7.2Why:It's cross platform. The alternative was DirectInput implementation, which I first wrote and later just replaced with ois.

Setup:ois took some work to get compiling. It's in its own project.

*** Networking: RakNet 3.0Why:It's the best :)RakNet includes the CrashReporter, which does a minidump for you on crash with the option to send an email to the developers.

Setup:The autopatcher PostgreSQL server files were left out of the project, since they require that you have postgre installed. If you do, just add them to the relevant folder from Source\Engine\RakNet3.0\DependentExtensions\AutopatcherPostgreRepository. I also broke out bzip2-1.0.3 (for the autopatcher) and speex-1.1.12 (RakVoice) from the DependentExtensions directory in case you wanted to use them separately, or not at all. speex was somewhat difficult to get compiling.

******* RECOMMENDED UTILTIES ***********CELayoutEditor - Used to setup your GUI and can save the designs out, which Ogre can then read.CrashRelauncher - Part of RakNet (Included). If you want to auto-restart your app on crash, you can use it.MeshViewer - An Ogre extension.ParticleEditor 1.2 - An Ogre extension.RenderMonkey - For material editing. It has tools for both programmers and artists, a plugin for Ogre. Ogre itself doesn't have a material editor although supposedly 3 are in development.

******* INCLUDED FUNCTIONALITY ***********GUIManager - Starts up CEGUI and converts input from OIS to what CEGUI uses.InputManager - Starts up OIS and passes input to CEGUI. Also provides a callback in case you want events when input occurs.InputState - Provides additional information CEGUI doesn't give you, such as the location of and time since the last mouse press.

****** ENGINE TEST ***********EngineTest is a sample application. You can delete it if you don't want it.

To run:Right click on EngineTest and select as the startup project.

IMPORTANT: Set the "Working Folder" of your game project (such as EngineTest) to $(SolutionDir)$(ProjectName) as this setting is not saved in the vcproj. Set command to $(SolutionDir)$(ProjectName)\$(TargetFileName)

******* GAME PROJECT SETUP ***********

Add your game project to the solution. Copy the settings from the EngineTest project. It will output your exe to the same directory as the name of your project. All the header include paths should be setup so you can use the libraries directly.

The first time you run, or if you delete the output directory, run CopyDLLssTo<ProjectName><Debug | Release>, in order to copy the necessary DLLs to the same directory as your executable. You will have to modify the batch file to match the name of your project.

Run Clean.bat to delete all unnecessary output files.

Run Build<ProjectName> to clean the project and to copy necessary output files. You can modify this batch file to do other processing as well.

Under Configuration Properties / Debugging / Working Directory set $(SolutionDir)$(ProjectName)

IMPORTANT: Set the "Working Folder" of your game project (such as EngineTest) to $(SolutionDir)$(ProjectName) as this setting is not saved in the vcproj. Set command to $(SolutionDir)$(ProjectName)\$(TargetFileName)

There was a configuration problem with the additional libraries directory for the ogrenew project. Change it fromC:\RakEngine\3rdParty\Libs\$(ConfigurationName)to$(SolutionDir)3rdParty\Libs\$(ConfigurationName)

I would hope either Lua or Python -- <plug>we have our very own Overmind if Rakkar goes the Python route</plug>, but Lua is rapidly becoming the defacto gaming industry scripting language of choice. Then again, the same can be said of Python in the open source community. Evil white space driven language. <g>

For scripting I can recommend Lua with LuaBind for interfacing with C and C++. Unlike Python, Lua is specifically designed to be embedded which is probably why it's so popular. Python has its advantages like OOP and extensive libraries, but it's a lot more bloated than Lua which is about 100K when used by itself, and a bit more with libraries (Python runtime last I checked was around 1.5 megs). Also I believe that Python has a debugger, while Lua itself doesn't although there are some third party debuggers. Some of these are for modified distributions of Lua which makes them not-so-useful (such as Lua for .NET). I still haven't found a working debugger for Lua that I can use, and although there are hooks provided in Lua for making your own debugger I personally don't have the time to make one. So both Lua and Python have their advantages.

There're various ways to get C to Lua communication, but one of the more popular ones is LuaBind. It has a bit of a learning curve but it's very powerful, and lets you bind whole C++ classes to Lua, not just C-style functions. It also adds some OOP functionality to Lua where you can even derive Lua classes from your C++ classes.

For the record, I've been using Lua for about two years now. Primarily for setting up windows and widgets, and handling widget events. It has its annoyances like Basic style syntax, variables created at access time so you'll never get an "undefined variable" error when you make a spelling mistake, and of course using 1 instead of 0 as starting value (what is this, Visual Basic??). But overall I'm happy with it, and there are some really crazy (in a good way) things you can do because of how flexible the language is.

LuaBind is a modified version of boost::python (which I *LOVE* mind you) and definitally makes binding easier, but that does not negate the fact that LUA is really far better suited to initial configuration and setup, not run-time data calculations.

Yes, the Python community may utterly recommend extending rather then embedding, but that is only because they don't like their dear precious language relegated to the status of a scripting language, which is actually something it was designed for. I have completely embedded it successfully, although due to its design it is still easier to keep it as a seperate DLL/so, but it is still completely usable (and I find even far better to use then LUA) as a scripting engine. I've thrown examples all over the forums I frequent (not many here) about just what you can do with Python as a scripting language. What sucks is that because of the community's thought patterns, the documentation on using it as a scripting language (aka. embedding it) is *really* thin. It has been over a year since I initially figured out how to first embed it and since then I've figured out so many of its nice internals that usually remain so hidden that you just cannot do anything with them. The very fact is that Python was designed to be used as a scripting engine as well. I have complete code for loading modules when they do not exist on disk, for serializing function calls across the network when a function is called (I've demonstrated that on this board somewhere I think), etc... etc... And yes, I love the IDE's available for Python. Python also has some of the best traceback's I've ever seen. If you have a problem with your syntax, it tells you where. If your code crashes because you pass a float into a function expecting a class pointer, it tells you what it expected, what you passed, etc... etc... Wonderful for debugging. In my current setup I dump all traceback's to a log file and to the in-game console.

I used LUA for about a year before I really discovered Python and yes, as stated, it has its strong points, but real-data flow is not one of them. And if you use Python as your scripting language, it can be your configuration files as well. My app currently has a number of 'engines' inside it that control the flow of its data, one is for a dedicated server, one for a listen server (which doubles as single player), and heck, one could be a webserver that controls a little web-based game. The engine just controls the overall data flow and communication between the user, other engines, and the internal world. Guess how this is configured, something akin to this:

This is just a standard configuration script (parsed through Python instead though), and the Engine is a string that specifies the name of the engine to use, which I then dynamically load. Currently all of my engines exist in C++, but they could easilly be derived inside Python to do something unique if need-be. The whole hierarchy, the base class exists in C++, it is subclassed either by C++ or Python, which in turn can then be subclassed in C++ or Python, and so on. My hierarchy near duplicated UT2k4's Scripting setup for any that are familier with it. That is another thing, LUA has no concept of classes, they can be emulated, but there is no true class handling, not multi-subclassing, no nothing beyond being able to redefine a few things in a table that you pretend is a class. You cannot even instance them properly.

Not to mention the Python license allows you to do just about anything with Python, you don't even have to say you use it. And it has been used successfully as game scripting engines, Civ4 comes to mind first off, as well as a host of open-source games.

And no, I don't use Python's standard libraries either.

If all you need is a basic setup scripting engine that just sets up the game world with no heavy lifting, and you know LUA, then use LUA. I *really* learned the hate the LUA syntax while I worked with it, even with going above I'd say the BASIC syntax feels better then the LUA syntax, and I really hate the BASIC syntax. LUA's ability to do things in a multitude of different ways that each do the same thing is a huge source of problems, at least when I was working with it. Whenever I started to have scripts that become even moderatly long, I just could not get them to run. Compare that to Python which enforces ways of doing things, I can create a multi-page long Python script for my little game engine and it works correctly the first time. The only thing I'd say bugs me with Python is that you have to put "self." in front of class members (which is still better then LUA since it does not even have real class instances at all) which I still forget on occasion, but then a nice traceback causing my console to suddenly open reminds me by pointing out the line it needs to go on.

Non-programmers that I know also picked up Python vastly quicker then LUA. Python "just makes sense" to them in how it works and flows, unlike all the wierd little symbols and odd things you have to do in LUA which took stupidly long to learn what does what for them. LUA is by far more geared toward existing programmers whereas Python is geared toward everyone, programmers and not. Also, I have yet to see a LUA script of any decent size that you can actually follow and is easy on the eyes, and if you follow Python's conventions (which it tries to force you into, you know, the whitespace and such), it is so much easier to follow through and read.

But yea, if you need any help binding either LUA or Python to C++, I have a great deal of experience with both.

LuaBind is a modified version of boost::python (which I *LOVE* mind you) and definitally makes binding easier, but that does not negate the fact that LUA is really far better suited to initial configuration and setup, not run-time data calculations.

You really shouldn't be using scripting languages for "heavy lifting" because they're not meant for that. Though as you have said Python was designed more in mind with it being used as the primary language with speed critical parts being written in C/C++ (thus the "extending" rather than embedding). That's totally unacceptable for me though.

If you have a problem with your syntax, it tells you where. If your code crashes because you pass a float into a function expecting a class pointer, it tells you what it expected, what you passed, etc... etc... Wonderful for debugging. In my current setup I dump all traceback's to a log file and to the in-game console.

LuaBind does this too by the way. Any errors generated by Lua and any exceptions thrown by your code are caught by Lua bind and re-thrown as exceptions that you can handle. Just as you have done, I have these spit out onto the console and log file. Without this debugging the Lua scripts would be (and, in fact, was) impossible.

I used LUA for about a year before I really discovered Python and yes, as stated, it has its strong points, but real-data flow is not one of them. And if you use Python as your scripting language, it can be your configuration files as well. My app currently has a number of 'engines' inside it that control the flow of its data, one is for a dedicated server, one for a listen server (which doubles as single player), and heck, one could be a webserver that controls a little web-based game. The engine just controls the overall data flow and communication between the user, other engines, and the internal world.

Are you doing all this in Python? If you mean that Lua isn't suited for this kind of stuff then I completely agree. I wouldn't write any advanced components in Lua. Although LuaBind provides OOP support in Lua, it doesn't feel solid enough to me. However, I wouldn't write such heavy components in any scripting language. C++ is quite well suited for this kind of stuff. It's fast, and powerful and I've never felt the need to write engine components in a script. I just use them for setup/configuration, event handling, and other light duty. I wouldn't use a procedural for anything more though in any case.

And by the way I've been using jEdit for writing the Lua scripts since the beginning. No IDE, no debugger, just syntax highlighting. It was an awful experience until I finally figured out how to get the error info from LuaBind. Now any syntax errors are instantly thrown out with the name of the script file, and the line where the error is. Same thing for LuaBind specific errors (such as type mismatch) and for any exceptions my code throws. You don't seem to like the flexibility of Lua, and it's true that it can cause a lot of trouble but if you learn all its intricacies you can do some really powerful things. For instance functions are treated the same way as variables so you can create new functions whenever you want and assign them to table entries -- these functions effectively have no name and only exist in the table. I used this for quick 'n easy event handling. Here's an example:

So I create an event handler function only if I intend to handle events for the particular widget. The Gui_Event() function checks if an event handler exists for the particular widget, and if it does it calls the dynamically created function that handles the event. There's a whole bag of tricks like this that I've learned over time.

This engine is intentionally lightweight - similar to ReplicaManager - where I only provide flexible functionality everyone needs where there isn't any significantly better way to implement that functionality.

Features I will add are:Text inputA keymapping interfaceRakVoice integration with fmod plugin (which you just don't use if yiou don't want)

I might add a state manager of some sort but that's really on the border, because there are different ways to do that and not all games might need it.

I won't add scripting. Scripting is a controversial feature. Some people like it, some people don't. One example of this gone bad is how the Reality Engine used C# for their scripting and then went on to write all game code in C#. So if you don't want to or can't use C# then that engine is useless to you. This is bad design and something I want to avoid.

Again, this engine isn't something you run, change a few assets, and get a shooter. It's a framework to start from, designed to save you a week or however long it would take to find those libraries and get them working toegether.

If you have ideas about what can go in it and it fullfills the criteria (no better way to do it, everyone needs it) then let me know and I can do it.

You really shouldn't be using scripting languages for "heavy lifting" because they're not meant for that. Though as you have said Python was designed more in mind with it being used as the primary language with speed critical parts being written in C/C++ (thus the "extending" rather than embedding). That's totally unacceptable for me though.

But then you lose the capabilities that my system is built around. You can create new Actors/Entities inside my application, entire classes, anything, as it is running, and see the resuilts in real-time. You can change things, alter any running class, anything, that is the kind of heavy-lifting I use Python for that you just could not do otherwise. If I need any speed boost in anything I create, I can just rewrite any specific method, function, entire class, or what-not in C++ either in my base application or through a normal Python extension module (I do not lose that capability by embedding Python).

LuaBind does this too by the way. Any errors generated by Lua and any exceptions thrown by your code are caught by Lua bind and re-thrown as exceptions that you can handle. Just as you have done, I have these spit out onto the console and log file. Without this debugging the Lua scripts would be (and, in fact, was) impossible.

As stated, Luabind is a modified boost::python, so yes it includes those exception things which are quite nice, but Python also has built in tracebacks, I could even execute line-by-line after that if I wanted, and it would not hold up the app in doing so.

Are you doing all this in Python? If you mean that Lua isn't suited for this kind of stuff then I completely agree. I wouldn't write any advanced components in Lua. Although LuaBind provides OOP support in Lua, it doesn't feel solid enough to me. However, I wouldn't write such heavy components in any scripting language. C++ is quite well suited for this kind of stuff. It's fast, and powerful and I've never felt the need to write engine components in a script. I just use them for setup/configuration, event handling, and other light duty. I wouldn't use a procedural for anything more though in any case.

I didn't say it was all in Python, actually almost none of it is in Python currently, I am a C++ coder, not a Python/Lua coder. The scripting system just allows other people who do not have access to the internals to extend it however they wish, to create their own packages (I created a package format to encapsulate things too), which can even be placed on the server and uploads to clients the parts of the packages they require to run, which may be nothing if it is a server package only. I could make everything, and I mean *everything* in C++ if I wanted, the scripting side my be a bit integrated into the engine, but the only time it is required is for the class registration system, python just does it far better then what I created before (which was nice mind you, just no where near as complete).

And by the way I've been using jEdit for writing the Lua scripts since the beginning. No IDE, no debugger, just syntax highlighting. It was an awful experience until I finally figured out how to get the error info from LuaBind. Now any syntax errors are instantly thrown out with the name of the script file, and the line where the error is. Same thing for LuaBind specific errors (such as type mismatch) and for any exceptions my code throws. You don't seem to like the flexibility of Lua, and it's true that it can cause a lot of trouble but if you learn all its intricacies you can do some really powerful things. For instance functions are treated the same way as variables so you can create new functions whenever you want and assign them to table entries -- these functions effectively have no name and only exist in the table. I used this for quick 'n easy event handling. Here's an example:

# can do this in a function, global scope, where-ever:bind(MY_BUTTON, "code_here_semicolon_delimited_if_multiple_commands_but_usually_just_calling_a_function")# or just register an object directly, but it has to be callable, so an object that has operator() overloaded (__call__ in Python) or a function or anything that is callablebind(MY_BUTTON, someFunction)# if you were inside a function that relied on some input data for example, it could build the function and pass it directly, as such:def someFunc(anInt): def tempFunc(anInt=anInt): # doing it this way instead of just setting it directly still allows an external event caller to override it print "hey, event was called with a value of %i" % anInt bind(MY_BUTTON, tempFunc)# to unbind and release the memory used, just pass an empty string or None or anything else that evaluates to a boolean Falsebind(MY_BUTTON), None)# to get the description of the bound event, just bind with the event name, it returns the actionprint bind(MY_BUTTON)

I already have a full action mapping system, and all my keyboard keys are registered in two ways, when a key is pressed, for example, 'u', then the action "U_Press" is called, and when released, "U_Release" is called. Keys that don't have a good single representation are returned by the input system's name representation of the key, like the Stop key and so forth would become "Stop_Press" and "Stop_Release". It also passes event data to it depending on the message, for example my "Walk" message has a power from 0.0 to 1.0 (thinking of changing it to -1.0 to 1.0 and removing "BackWalk").

I don't have to do these bag of tricks with Python is the thing, the code for the binding system is near non-existent as it just exposes some basic Python things to C++ in a different namespace (equivilent to a different LUA interpreter) to make sure the user in the console cannot do something stupid to the main system, mostly access control to make sure they can't do anything normally server related when not a server and what-not, quite simple.

« Last Edit: August 10, 2006, 11:55:31 PM by OvermindDL1 »

Logged

Gilad

Regarding scripting, I use AngelScript (http://www.angelcode.com/angelscript), which has tight integration with C++. It still doesn't have a big community, but I think the engine is mature enough for real products.

Thanks for posting that Gilad. It looks like a sensible scripting language because it provides the functionality that is needed without trying to rewrite a language. Does it have debugging capabilities, so I would be able to debug my scripts?

Logged

Gilad

Yes, it has debug interface. I also wrote some code for easy debugging it (a full editor, including syntax highlight, breakpoints and so on). You are welcome to contact me if you would need some help with it (I used it a lot so I have a lot of experience with it)

Currently AngelScript cannot handle class methods where virtual inheritance is involved. If you want to be able to call such a method from within AngelScript you'll have to wrap the call in another function or method.