Is pyrogenesis a 3D-engine or a RTS-game-engine ?

[ProvencalLeGaullois]

actualy I'm learning (by myself) opengl since this autumn, I learned a lot, and I also learned that making a 3D engine would be to reinvent a very complex wheel... There is several 3D engines using opengl, I considered these ones :

• Irrlicht
• Ogre3D
• Horde3D
• OpenSceneGraph

most game-people-dev-hobbyist speak about Ogre3D as the top notch of the open source 3D engine.

But I read that Ogre3D is the best in this category if you consider using DirectX, for Opengl it seems some dev-guys aren't satisfy how OpenGL is implemented.

Irrlich is always view as less good that Ogre3D... well I don't have use Irrlicht enough to say that, (I don't judge only with screenshots) but it's easier to use than Ogre3D. Like Ogre there is a DirectX and an Opengl implementations.

Since I'm using only linux, I think that it would be better to use a 3D engine fully written in opengl. Why ? because all dev-guys are working full time for the opengl implementation.

That lead me to Horde3D and OpenSceneGraph. The first one is interesting, but the team seem small and very busy in their lifes...

OpenSceneGraph, is my first final choice. A lot of developpers, saddly most documentations around the web are outdated... BUT there is some very nice features like their scene graph... is

I asked myself if 0AD could be used as an OpenGL 3D engine. Of course it does, but I would like to know if pyrogenesis is a 3D engine or a RTS-game-engine. Because I'm not interested by making a RTS-game. Also I would like to know if the GUI used in 0AD is released as a standalone library or if it's a part of pyrogenesis. I have some others questions... but the most important of them for me now, it to know what kind of scene graph(s) is used in pyrogenesis (or maybe the one(s) you planed to add)?

[sanderd17]

0 A.D. is split in two parts, Pyrogenesis is the RTS engine, and then you have the scripted data. Our aim is that pyrogenesis is a general RTS engine, and that all non-general parts are implemented in the scripted data.

So the scripted data are things like

• GUI: scripted in XML and JS files
• Simulation code: any code that isn't needed in all RTS games, or might differ over different RTS games, like unit behaviour, trading, resource gathering ...
• Artwork: art for the game and the GUI
• ...

The general RTS engine can be subdivided in two main parts: graphics and simulation. Here, the simulation part is what all RTS games should need (a pathfinder, a position for entities, range queries ...). This part of the simulation also communicates with the graphics (starting an animation, finding the height of a unit based on the position ...). The graphics part contains everything about rendering. Some things are very general (like rendering objects), but some things might also be too restricted for general games (like our terrain is a grid of square tiles, our water is a single plane...). It's possible to use the graphics part without simulation, and thus only as a rendering engine. But it will require some work (some graphics need simulation code (like the position code) to know where or how to render objects), and it might have serious limitations for certain types of games.

I hope the above post helped a bit.

[ProvencalLeGaullois]

0 A.D. is split in two parts, Pyrogenesis is the RTS engine,

.../...

It's possible to use the graphics part without simulation, and thus only as a rendering engine. But it will require some work

../..

I hope the above post helped a bit.

yes it give to me some good informations

on http://wildfiregames.com/ it says it's a 3D engine. I don't want to have to remove some game,sound,network,...-modules ... so I won't use pyrogenesis, but I will study and maybe reuse your shaders.

Edited December 8, 2013 by ProvencalLeGaullois

[feneur]

yes it give to me some good informations

on http://wildfiregames.com/ it says it's a 3D engine. I don't want to have to remove some game,sound,network,...-modules ... so I won't use pyrogenesis, but I will study and maybe reuse your shaders.

Well, strictly speaking the engine is 3D (though parts of it is more like 2.5D, i.e. the terrain), but it probably wouldn't hurt to add RTS to the description to make it clearer that it's not a more general purpose 3D engine, but rather an RTS engine that is 3D

[sanderd17]

If you're still interested, you can join the #0ad-dev irc channel on quakenet. Philip and historicbruno will be able to give more help than I can.

[ProvencalLeGaullois]

If you're still interested, you can join the #0ad-dev irc channel on quakenet. Philip and historicbruno will be able to give more help than I can.

last week I was on IRC but always when nobody was here... today and until next sunnday I can't take too much time to speak on IRC. Speaking about the engine would take some time I guess... I will surely speak with your dev-team, because you manage 0AD with so much success that I can learn from you.

[sanderd17]

I think the "you" is fairly changable. The team quite often gets new members, while old members leave. I'm one of the more recent members.

The best times to ask stuff on IRC is during the European evening/night, and a bit more in weekends. We don't have paid team members, so most of them are only available during the evening.

[ProvencalLeGaullois]

when I said "You" I meant everone of you guys

[Ykkrosh]

I asked myself if 0AD could be used as an OpenGL 3D engine. Of course it does, but I would like to know if pyrogenesis is a 3D engine or a RTS-game-engine.

It's an RTS game engine. Some of the graphics code is designed to be fairly generic (the low-level texture loading, higher-level compressed texture manager, shader system, etc) and could be reused in different types of game, but a lot of the graphics code is designed specifically for the requirements of an RTS (and specifically our RTS design) and would be inappropriate for most other games. (E.g. in an FPS you have a lot of static high-polygon-count geometry and complex static lighting, and probably need to spend a lot of effort on occlusion culling etc; whereas an RTS usually has a large number of low-poly-count objects with simple lighting and simple culling from the top-down view, so a lot of the design decisions are based on fundamentally different goals.)

Reusing the generic bits would probably be a lot easier than starting totally from scratch, but you'd still have to write a load of custom OpenGL code to do pretty much all the rendering of your scene, so it'd still be a lot of effort. An existing general-purpose 3D engine would save a lot more of that effort (assuming that engine is well implemented, well documented, matches your game's requirements, etc).

Also I would like to know if the GUI used in 0AD is released as a standalone library or if it's a part of pyrogenesis.

It's integrated with the rest of the game engine. In principle it's reasonably modular and could be split out into a separate library (plus a few extra libraries that it depends on) without a huge amount of work. But it's not a very well designed GUI engine (the original design was too limited for what we need, so we've had to hack lots of extra features onto it and it's got a bit messy) - if you're starting from scratch and don't have to worry about compatibility with already-written GUI XMLs/scripts (like we do) and aren't fussy about what scripting language it uses (like we are), there are probably better GUI libraries available nowadays.

but the most important of them for me now, it to know what kind of scene graph(s) is used in pyrogenesis (or maybe the one(s) you planed to add)?

There isn't an explicit scene graph. It's implicit in a variety of different modules that represent parts of the world - e.g. the simulation system has a list of units, which each own a CModel (which is a tree of meshes, decals, etc, with transform matrices being computed based on the tree structure, and the nodes get submitted to the renderer each frame as a flat list) and sometimes own extra graphics objects (like health-bar sprites); then terrain and water and particles etc are controlled by completely independent bits of code. Once everything has been submitted to the renderer's lists of objects, there are just some C++ functions that decide what order to render everything in, based on hard-coded knowledge of all the different types of renderable object.

[ProvencalLeGaullois]

thx for these informations. I will stay with my first choice OpenSceneGraph. I don't want to rewrite everything...