Pyrogenesis vs. Glest/Megaglest (as an engine)

[Tiel]

Because according to tomreyn this kind of thread is really necessary.

Both are open source, and are thusly really easy to mod, though Pyro takes the lead here since you can export directly into opensource COLLADA format as opposed to g3d. Both engines use the really easy xml standard to define characteristics, which is tops. I haven't compared any of the xmls I've worked on with this engine with those of Pyro's; by the looks of things the only difference is there's a bit more subdivision regarding folder structure.

As far as content goes, it's really a matter of taste between Megaglest's default techtree and the ten or so available in Pyrogenesis's own flagship game, 0AD. The assets in the latter are indubitably higher quality, but there's also a bit less of them and balance is a mess at the moment. Additionally, more of an engine fault if anything is the fact that Pyro seems to be choppy on machines that should meet its system requirements, which are a bit higher than its opponent here, but should you meet them it just kicks Glest's requisite low-poly style out of the water.

So that said, is there really any reason to consider Glest as a platform for development when Pyrogenesis offers a lot more graphical flexibility? I'd like to hear thoughts on this; while a ton of people are going to obviously be very biased on this subject matter given the forum's mission, anyone's experience with Pyro compared to Glest would greatly contribute to the topic of this thread.

[GunChleoc]

From a translator's view, they are working on using gettext as a translation system which is a major plus.

As for gameplay, they still have serious problems with lag at the moment. It's going to rock once they manage to solve that problem though.

I have never modelled anything nor have I ever created any game content, so I can't comment on that side of things. I do have a soft spot for Megaglest though, because it was my first official l10n release

[softcoder]

For a fair comparison you'd need someone who actually spent good time in both (not sure i know anyone who really has). Beyond opinions, 0ad is much better than megaglest in many ways. They have FAR MORE resources and help than we do, so thats an obvious item right there, they also started on their code over 10 years ago!

Having said that, theres a difference between something looking nice and actually working and being fun to play. This was what differentiated GAE and Megaglest (GAE ws another fork of Glest). In the end our goal is fun, stable game play. Beyond that we have expanded many feature requests since 2010 when we forked the inactive Glest project. The bottom line is try try each engine and see what your prefer. FIRST and FOREMOST ask which game you like to play. Then decide on modding.

[titi]

MegagGlest already has some fun to play mods where nearly everything is changed and those are fun to play.  But I cannot tell you anything about the pyrogenesis engine necause I don't know it really good.

[John.d.h]

I've looked into the process of modding 0 A.D. and it does seem to be a little more complex.  That could just be because I'm more used to Glest's style, but that was my subjective experience.  There seems to be much more customizability within the engine, and that comes with a cost.  Glest is pretty straight-forward since there are a limited number of things your units can do.

Pyro's animation system is a huge plus when it comes to modding, though.  If you have two units who have some similar movements, you needn't double your animation workload or export each of them individually.  As it's been mentioned, performance is the biggest detriment for Pyro when compared to (Mega)Glest, as it slows down considerably with large armies.

If you want to see a really good-looking MegaGlest mod, look around the forum for "Annex".  I don't think any of us knew how good this engine could look before that came out.

[Ishmaru]

From what I see with 0Ad is it's use of sharers give it a huge advantage. However, I do know MG is quite capable of pretty impressive things if someone is able to work around the faults. I'be decided my next big game will be made on MG, and while it's still in very early development It's allready surpassed what I've done with Annex in terms of Graphics.

MG is really not intended for huge armies and If you focus on developing a game around that you can get away with higher poly/texture res models and it looks great.

[MoLAoS]

0AD is running into a lot of problems. I can't give specifics due to not wanting to appear to focus on anyone individually, because that tends to be dangerous with insular gaming communities. Basically 0AD has a lot of problems with their overall engine design. Granted Glest games have far less graphical options, graphics is where 0AD really excels. I would not expect 0AD to solve their current major problems any time soon. And if I ever get a break from creating my literally multimillion dollar space empire in EVE Online I would probably try to add superior graphics to a Glest engine rather than redo the whole 0AD engine to fix its performance and design issues.

Some of their issues are probably unavoidable, because they believe that using a Javascript layer will allow less experienced people to work on stuff, but personally I would consider something professionally made like Unity if that was super important or map XML to C++ on game start rather than actually RUN any part of a game in Javascript.

Compared to MegaGlest I would probably say that 0AD has ups and downs as I also have some issues with the MegaGlest engine's design strategy. Between those two engines you really need to decide what you want your game to be like and make a decision from there rather than compare the two engines generally.

For instance games with relatively traditional gameplay and small map and battle sizes would tend to favor 0AD because you can then make really incredible game assets. The same goes for single player games. Whereas MegaGlest has far superior cross platform network code for making multiplayer games. Note here that superior mostly means stable.

This whole debate basically falls along the lines of the classical best programming language debate. You pick the specific tool for the specific job you are trying to do.