TIGSource Forums

Hi all!

Sorry, I've been reading TIGsource daily for a while now, but I never thought on going on the forums before a couple of days and I feel a bit ashamed that one of my first post is a kind of advertisement. Sorry also for my lame English that is probably far from being half as good as half of you would like it to be.

This said, let's move on...

So I'd like to speak a bit of orx, an open source (LGPL) game engine I and some other people have been working on for a couple of years now. This game engine may differ a bit from the usual ones, hopefully.

To give a small background I began working in the video game industry 7 years ago (ouch, I feel suddenly old...) and orx roots go back then. It wasn't called like this nor was structured as it is nowadays, but I was trying to put some work to make a small engine whose goal was to avoid all the flaws I could see in "professional" engines in everyday work. Well, it probably has a lot of others, but we liked the idea. Orx was meant to come with a user friendly editor (called editorx) which is still no more than a few lines of draft on papers as of today. All the people willing to work on it got "distracted" before even beginning to work on it. Only the engine went through. The engine was written first to support an indie adventure game development (long dead by now), and I'm working pretty hard on it on evening as I'd like to go back to the light side of the game industry and work again on games I'd play myself and would be proud of to show to my grand kids in an hopefully far future. That's for the history.

Actually orx is more of a meta-engine as it's not trying to reinvent the wheel and try to be a better engine as others but more to take advantage of what already exist and try to combine all the good parts.
It was designed to be as portable as possible through the use of plugins for all OS/platform dependent features, having in its core only what is considered as almost-fully portable. So it aims to allow people developing easily on platform as different as PC, Mac, DS or PSP.

I'd love to give you a link to a well presented page with all the features and demo, but there's none existing. You can find the project page on sourceforge, an old outdated wiki, a long time dead developer's blog and a never-been-updated doxygen doc page. I'll give all the links at the end of the post.
There has been some little demo/tutorial written a couple of month ago, but at this time I was the only one working on it and didn't have time to make new ones nor to update the old ones as orx evolved. I did a game prototype as a proof of concept that I can't unfortunately show because it was for my current employer for a non-announced yet game.
I know that all of this isn't very appealing at all but I still hope some curious people here would like to learn more.

So let's throw some features randomly (sorry, communication is definitely not one of my skills) :
- Everything used by orx is interfaced and it has its own types and interface for every outside calls
- It has some memory management (allocation using zone flags, banks of contiguous chunks, hashtable) and sorting facilities (linked list, trees, queues, ...)
- It has module management and dependencies, meaning that if you want to init X module that depends on Y and Z, you don't have to init all the dependences manually. If one of this module will become unavailable for a while, all modules depending on this one will freeze till it's been reactivated.
- It has a debug module including logging facilities (timestamp, file, console, filtering, breaking, etc...). It will soon have call stack unwinding for better debugging contexts.
- Every update is made through clocks. Each clock has its own settings (frequency, list of callbacks, type of DT modifier, ...) and can be modified / frozen / time stretched at will and independently of others. It'll also soon support multi-threading by assigning clocks to threads. So it's easy to set different frequencies for rendering and logic for example or slow down a given group of NPCs or let' s say the sound. Time consistency is enforced at every level.
- It uses a system of plugins for every OS/platform dependent call. This way you can write your own display code for the platform X, or base it on Y or Z library. For example I wrote 3 different 2D graphic display for win/linux using Allegro, SDL & SFML. You specify which one you want to use at runtime (command line or config file), and soon it'll have static "plugin" support for platforms like DS or PSP. You can also add any function to extend orx (like sending mail or heating coffee if you want) which will be accessible by script. (Currently we're working on script integration so that no pre-processing utility will be needed to make the links between C and your scripting language)
- It manages resources with an object oriented design (even though orx is written in C for a few reasons we can discuss later). All resources are linkable via orxOBJECTs and are accessible by the engine. Textures resources are also meant to be unique in RAM whatever the programmer behavior is.
- All objects are placed in a 3D spaces, but as of today, orx only has 2D rendering (easy to have a 3D one, it's just that it wasn't one of my priority, we just need, on the core side, to add a matrix module in its math section, which won't be too hard given the already existing 3D vector module)
- It has abstraction layers for all resources (physics, graphics, animations, ...)
- It has an animation graph allowing to easily define what the animation chaining possibility are and easily go from anim A to anim E giving criterias and without having to poll to chain animations by hand
- It has events communication
- It has a config system and an automated command line "parser". Multiple config files can be loaded, modified in memory and saved in place or under another file. You can register an argument on command line and a callback will be called if present, if not it'll try to map it automatically to the corresponding section in config files, if present
- It has world / camera concept where you can create many camera and map them to viewports on screen or on textures for immediate reuse in the world.
- It has 2D rendering with built-in differential scrolling capacity
- It currently has 2D display plugins based on Allegro (probably out of date), SDL and SFML. You can add your own easily for any platform/OS you'd like
- It handles IO (files, mouse, keyboard, joystick, text, ...) and has a package module to pack your data (this last one isn't functionnal yet)
- It has minimal partitioning (as for now) including object's neighbour list
- Positioning is done through hierarchical frames (concept similar to positioning in Open Scene Graph or RenderWare) making it easy to pack objects in group or to position them relatively to other objects
- It has collision and dynamics support (the only plugin written so far is based on Box2D)
- It's about to have scripting support (we're currently working on this plugin interface with a first plugin based on LUA)
- It has sound support (through a FMod plugin for now and a soon to come SFML based one)
- and probably lot of stuff I'm forgetting (like being able to create fully functionnal objects with graphic, animations, collisions, ... in a single line of code) because it's already 4:20 am here!  ;D

Soooo if there are still people reading, I'm posting here hoping to find some curious indie developper eager to see what's inside and what it can do, and give me some feedback or advices so I can improve it, or even more daring ones willing to use it to develop their next game (yes, it's good to have dreams =) ).

If some want to contribute, there's a lot of plugins to write given the fact there are many platforms that I'd like to support, beginning with DS and PSP, and the core was already compiling for them, just need the plugins. If you're really motivated and can follow strict rules of coding, working on the core is also an option. =)

PS : I'm sorry, there are probably a lot of English non-senses but I feel far too tired to be able to correct myself right now. Hopefully it's still in a readable state. Thanks for your attention!  ;D

PPS: Thanks, too tired that i forgot the links here they are:

Project page (http://arcallians.sourceforge.net) (the package to download is out of date, get the svn version rather. I'll update it in a couple of days if everything's fine)
wiki (http://wiki.arcallians.org)
doxygen (http://doc.arcallians.org/)(completely out of date, need to re-run doxygen)
dev's blog (http://blog.arcallians.org) Last post is very old, and apparently the blog is broken...
Googling orx will probably give you the name of a French swamp, but if you try with orx game engine keywords, it should be the first link.

You 'll need to update your post with the links.
The name "orx" isn't readily googleable (it's not in the first 5). Change the name accordingly.

What are the advantages of using this over just SDL for cross-platform I/O, graphics, timers, sound, etc.?  It looks like your engine does everything SDL or Allegro does, and then you just use SDL anyway, for the real drawing.  All of the stuff about objects and events and graphs could be done by slapping Lua and a few lines of C on top of SDL.

Are there any games that can showcase the engine's features?

There are many advantages. Almost all the advantages you could get from any engine without an editor (yet). I think lot of them are listed above, but I'll give a few examples. Mostly you just need to focus on your game logic and don't bother with all the resource management.

And as I was saying... the only showcase I have can't be shown, because I did it for my current employer.  It was both good and bad; it showed me that the engine works, and I made a lot of changes to make it more user friendly. The drawback is I can't show it to you unless we're working at the same company, and inside the walls of this company... Not very helpful, I know. :( That's why I post here, trying to find people willing to test it and even contribute to it. I'm not the "owner" of the project, it just happens I'm one of the 2 guys still working on it and one of the main contributors.
Currently there are 2 small indie games that will be made with it, but at the pace it is going I'd rather find other testers to know what to change and make it even more user friendly/efficient.

One of the many advantages is that you can try different renderers without having to change your code a single comma, but rather changing the plugins that are loaded at runtime. It also means when the plugins will be available for platforms like DS, PSP and GP2X (I just ordered one today to make plugins for it) you can easily port your games (Provided you respect the hardware limitations.) Same goes for sounds, physics, graphics, interactors (mouse, joystick, keyboard, ...), file system, scripting...

If you prefer scripting using Python rather than LUA, it's simple.  Use the corresponding plugin. The bindings don't have to be done again, only the interpreter interface has to be coded for a scripting plugin - which isn't a lot of work. And you'll have access to all orx features (including the ones you can add with user plugins).

Now, for example, if you want to make a split-screen multiplayer game, all you have to do is create 2 cameras, 2 viewports and you're done. That takes 4 lines of code, and all your displays will prune and clip accordingly to the camera's and objects' positions.
When you create an object, it'll link graphical resources, physics ones, etc... You don't have to manage all those separately. No need to worry, all the displays will be handled.

Here's an example of the player creation for a small game I'm working on when I have the time :


This creates my player.  There's a graphic resource, a dynamic collision shape (actually I use a template to specify all the physics properties, I just removed the lines to avoid too much confusion. Without the template it creates it with default properties and creates a box the same size as the bitmap).


This creates an animation set with 4 basic animations given a file pattern (based on a 0.1 s regular frame duration, but frames can have any duration, it doesn't have to be regular). This animation set can be used by all my chuckys (it won't be duplicated in memory, just the "cursors" will be unique per Chuckys).


This creates all the chainings possible, some with the immediate cut property (we don't wait till the end of the current animation). And the last line links it to my player, creating all the cursors needed.

And now, in my update callback, here's a very basic order :


This tells the animation controller to target for the walk left, and given the current animation, whatever it is, it'll do all the chaining according to the potential set criteria. If there's no link, orxSTATUS_FAILURE is returned (the code should check it, but in my sample I know there's always a link given the basic chaining I made, sooo... :)).


If you try the little Scroll demo (the code is out of date given there are now a lot of wrappers to make it more compact), the whole waves update is just this part:


It updates 4 positions along a vertical sine. As the waves are tagged to behave with a differential scrolling computed from their Z component and are grouped in 4 groups, I just need to update the vertical position of these 4 groups.

Maybe you can give me a code example for doing something directly in code, without any engine (a small game or an experiment maybe?), and I can try to show you something equivalent done with orx, this way you'll be able to have a better assessment.

I'm not really in the market for this sort of thing at the moment, but if you're looking at improving your pitch, try organizing your features into categories.

Also, play up the features which are interesting and unique as opposed to features which may be redundant. For example, you list supported data structures as one of the first features, but if I were to adopt a new API for a project, I would probably just use STL for these, as it's extremely familiar and does all the same things.

Try to come up with a quick description of your API, in a nutshell, which fits into a few brief sentences at most. Is it made to be as quick and easy as possible? Is it feature driven? What kind of game is it intended to be used for? What are the central components or emphases?

Graphics are typically one of the central foci of any games API, since they are often the most time-consuming to implement, but I notice you don't mention until almost the entire way through your post whether your engine is focused on 2D or 3D development. If 3D has not been fully implemented yet, mention upfront that the engine focuses on 2D games. Try to list your strengths as opposed to your weaknesses. You could probably list things your engine can't do all day (For example, I doubt it can clean my house for free), but I'm more interested in reading the things it can do.

Finally, put together a very short and tight demo showing off your API with good graphics, not programmer art. I've evaluated a lot of different APIs for various products and if I see something that looks like crap, I switch it off right away. If I'm looking at a page of engines which promise to do this or that, the most I put into looking at a demo is about five minutes. If I'm impressed, and pulling up a source file gives me fifty to a hundred lines of code to make something awesome, then that's great, otherwise I'm not interested. If you aren't artsy, get a friend to draw stuff for you. Pay him or her in beer or sexual favours.

I'm not trying to be a jerk about this or anything, I'm just trying to give you a feel for the kinds of things I look for when I evaluate an API. I understand you aren't charging for this, but you've obviously put a lot of work into it, and I think it would be more rewarding for you if you got a bunch of people on board using it. It looks like the work is done -- now you just have to sell it to jerks!

Actually, just as an addendum, any time you're trying to explain anything to anyone, the first sentence should tell them the main point right away.

I suffer from this problem all the time -- I think it comes with working with a lot of procedural code -- you want to start a story at the beginning, but to get someone's attention you really have to start it right in the middle.

"There are many advantages"

I don't doubt it, but as opening sentences go, you would do better with:

"My API will make you rich and covered in naked men/women (circle one or both according to preference)."

I mean, ideally you would be more honest than that, but my point is that people always want to know the central point first. What will this do for me? Where should we go for dinner? Why are you covered in blood? Etc.

Thanks for your reply and you're totally right.
I'll try, in the future, to focus on presentation and to organize my writings before posting.
But I have three major issues there:
- I'm a programmer, which implies that I have very poor communication skills,
- Secondly English isn't my mother language and it doesn't help at all (and I'm not sure there are a lot of French readers around here)
- Third I'm a programmer, double handicap on this one! =)

So yes, to sum it up, right now this engine focuses on 2D games (no 3d rendering plugins yet, probably in a distant future) and portability with a very open architecture.

Concerning the feature list, I really should re-organize it, I was listing them from ground to top as they were crossing my mind which is a poor presentation model, you're right.

As for the demo part, I'm all for it but I don't know anyone around me either with good art skills (I'm surrounded by coders) or willing to spend time to do this instead of playing WoW, for example. If some people reading this are willing to make art for showcases, I'd love to hear from them. :)

Thanks for the advices, I'll try to keep them in mind in my future posts.

I totally understand the communication difficulties as a fellow programmer.  I can't describe something to save my life!

Anyway, I feel like this engine is a bit complicated for noobs.  You may be misjudging your audience.  Don't get me wrong, your code is good and it looks very well done, but those who can appreciate this will probably want to just write it themselves.  On the other hand, if you can drastically simplify the code that a user of your engine must write, you will be on to something.  For example:


becomes:


And this:


becomes:


At that point, amateur game devs with little programming experience can be impressed by your engine.

(The above examples are valid Lua code and work in my little engine built on top of SDL...)

Yes, the C-level API is aimed for advanced users only (ie. coders with good knowledge of C). That's why I posted in the technical section and not in the project one. I'm sorry if this was unclear, I really need to work on my comm skills! :)

For end users the interface will be scripting only, but I can't showcase it right now as it's being implemented by someone else. As far as I'm concerned my next tasks are network integration and handheld support.


becomes:


The script call will definitely look a lot like this, even if it'll probably be loadObject instead of loadimage because it does a way lot more stuff than just loading an image:
- It creates a generic object container
- It creates a frame containing local & world coordinates, placing it in the hierarchy under the tree root, then links it to the object (all linkings use reference counter)
- It creates a graphic object containing a texture (2D flag, in 3D it'll be more mesh/skeleton), which is an abstraction layer for whatever display plugin is behind. It makes sure texture is unique in memory, and finally links all this to the object
- It creates a physics body and a body part (abstraction layer for Box2D shapes for example) based on the object bounding box (which is constructed from the graphic object). It then links everything to the object.

That's why you have flags to control all of this in the low level call, it allowed me to write a single object creation wrapper. And before this wrapper everything was done manually (as you can see in the demo I wrote beforehand).

But anyway, this won't appear in the script at the end.


Same here, the script will look a lot like this with a loadAnimation function. Again, animation are more than images, 2D ones are sequences of abstract textures with time stamps as 3D will be bones transformations.


Thanks for your reply and advices.
I may not have mentioned it before, but if some people are willing to dig inside orx and see what it can do, they'll have a full support from myself, being my highest priority tasks. If some people (designers/artists) would like to make a small prototype or game I'd even love to code it for them.

Showcasing orx is more important for me now than adding features (which will then become a background task). The thing is that I'm a poor designer and an even more poor artist. I miss the old demo scene days where I hadn't to care about all this... :(

One year later, the first candidate has finally been released! :)

A lot changed in the engine since then. For example, now the engine's almost completely data-driven. Very few lines of code are necessary for some complex operations.

The latest changes have been to add a generic input system that abstract keyboard, mouse & joystick inputs, a Mac OS X version and fragment (pixel) shader support.

You can find more info at http://orx-project.org.

Also, if you want to have a quick glimpse of the engine current features, I wrote a quick particle test that you can find here (source + win32 binaries) (http://orx-project.org/orx/particle-test.zip).

You can change presets using mouse clicks or up/down arrows. You can change the presets or even add new ones via the config files on the fly (no need to restart the executable to test them).

If you want to try the linux or Mac OS X versions, you can either compile it yourself with the latest version of orx, or you can download the tutorial packages at sourceforge (https://sourceforge.net/project/showfiles.php?group_id=234700&package_id=284950&release_id=683418), as the 11th tutorial is very similar to this test.

Any feedbacks/comments are more than welcomed!

Thanks in advance!