Building Torque As Static Library

#1 Just in my humble opinion, compiling a full game engine as a static library seems counter-productive and has no redeeming value. On top of that, attempting such a procedure would be insanely difficult. I couldn't even think of where to start.

Can you provide an example of how this would be useful for you?

What kind of application could possibly use this feature?

#2

Quote:compiling a full game engine as a static library seems counter-productive and has no redeeming value.

How so? Other than how difficult it is, I know...I tried, what's the disadvantage to creating the core of Torque as a static library for consumption by the executable project's linker.

Quote:Can you provide an example of how this would be useful for you?

Granted my opinion has changed on this based on a post I received it would be useful in the respect that it would treat TGEA as a 3rd party library not first party. Think of it when you integrate LUA, TCL, Python, FreeType, DirectX into your application. So other than API changes dropping in the latest torque static library in the right spots allows for a pseduo seamless update, assuming you "rebuild" your executable. There are tons of engines out there that have adopted this approach. Just a style rather than a religion.

Quote:What kind of application could possibly use this feature?

Not sure what you are getting at...but I'll try to assume a bit...I imagine that it'd make all the demos compile a helluva lot faster due to not having to compile TGEA each time.

The long and the short of it is...the engine, client, and server, currently, are not decoupled...they are pretty intimate in fact. So..there's zero advantage today to try and do this other than to waste your time. So as the saying goes...When in Rome do as the Romans do...

My 2 cents...

#3 I understood a few of your points William, but I still can't quite wrap my head around the overall concept.

Quote:
...that it would treat TGEA as a 3rd party library not first party

...along with...

Quote:
Think of it when you integrate LUA, TCL, Python, FreeType, DirectX into your application.

Well, that's the point. TGEA *should* be treated as 1st party app. That's because it is a full 3D game engine.

LUA/Python - Scripting API
DirectX - Rendering API
PhysX - Physics SDK

TGEA - Rendering, networking, collision, entity management, memory management, yada yada.

Because of the dependencies within the system, it doesn't make sense to wrap up the "core" parts of the engine.

Wrap up the renderer? What if you need to add another rendering pass or change the material system?

Wrap up the networking? What if you have to open up a new UDP connection internally?

Wrap up the player? Of the thousands of changes you can make to the player, why would you even think of wrapping this up?

Those are just examples.

From your list, the only advantage of wrapping anything up into a lib would be decreased compile time. Unless you have to change something in the .dll, then you have increased compilation times and dev time. Plus the months of dev time it would take to isolate the systems to wrap up into individual libs.

(Max) Time it takes to do a full recompile of the SDK = 5 minutes

Compile time for a few modified files: less than 2 min.

Also, just my 2 cents =)

#4

Quote:
Granted my opinion has changed on this based on a post I received it would be useful in the respect that it would treat TGEA as a 3rd party library not first party.

And why exactly is it useful to have TGEA as a 3rd party library? You haven't mentioned that yet, just that it would be.

Quote:
There are tons of engines out there that have adopted this approach. Just a style rather than a religion.

Interesting. Care to mention their names? Even one will do. :)

#5 Since you asked nicely Stefan, with a :) ...I'm going to preface this by saying that this is my opinion. I'm not an all knowing guru and definitely can get things wrong. I'm also very willing to learn from others. I do not think I'm any better than anyone else here. So...I'm not advocating for one design methodology one way or the other as these discussion tend to devolve into design holy wars...Less filling...tastes great...less filling...tastes great.... ;) I'm also probably not taking into account all possibilities/scenarios/assumptions one can make of this argument as I'm "trying" to get work done too...speaking of which...my gf just dropped off some chocolate chip cookies for me at the office...woot! I was just giving a possible answer Michael's initial question as to why a static library has value.

Considering I'm working at a company that has several projects well over 1,000,000 lines of C++ alone we'd be in deep water if our front end, back end, and utility libraries weren't decoupled from one another. Not only does it reduce compile times, it also reduces overall design complexity, IMO. I know when I work with the that I only need to worry about either deriving from a base class or overloading a function in order to get my work done. I've just made it real easy for me to port from one update to the next. All at the cost of a relink or a specific project rebuild. So rather than make all the devs build the products we only "link" against the static libraries and dlls that were published with that previous days build. Especially when nightly builds are on the order of an entire day (All the products). I've also kept myself at an arms length from their implementation...I trust that they know what they are doing.

So in terms of TGEA. For example, the GG devs are not responsible for changes I make to player.cpp or any other facet of the engine I may have had to "modify" to meet my needs. So when they release a version that fixes some bugs or does some new thing that fits a demo they wrote then I'm already in trouble. Where as If I were able to treat TGEA as a 3rd party library that I derived objects from, overloaded functions, etc...I'd isolate my changes at the interface level rather than at the implementation level. I think this is ultimately a good thing. There's really no one right way to design this stuff...cause if there was...everyone and their grandma would be doing it.

Quote:And why exactly is it useful to have TGEA as a 3rd party library? You haven't mentioned that yet, just that it would be.

I see value in a library I can drop in. What's the difference between fmod...other than TGEA is a wrapper for FMOD to make it do something...TGEA doesn't need to know about how FMOD works...it just needs to know what API has been exposed. I personally don't see it any difference with a "game engine" vs. another library of code. At the end of the day it's just a library that has wrapped up a whole bunch of other things and ultimately provides an API through which I can make pretty pictures explode. :)

So in summary, a static library has value to me because:
It reduces build times
It decouples me from TGEA implementation as I'm working at the interface level. Through extension and overloading. I extend player rather than modify player.
It allows for easier porting from one version to the next. Just like DX, FMOD, etc...same principle applies...just because it is a game engine doesn't make it any more/less special.

At the end of the day...TGEA was not architected in such a way that would enable you to take advantage of it as a "static library of code" without a significant amount of work...I've already conceded that point and am not dwelling on it. Again, I was just trying to give a possibility to Micheal's initial question.

Quote:Interesting. Care to mention their names? Even one will do

As I don't have the money to access the big name engines I'll name a few non-250000 dollar ones.
Ogre
Power Render
Irrlicht
Nebula 2

However, I'd even be willing to bet a six pack of Oregon's finest beer that the 800lb gorilla engines (Crytek, Unreal, Id Tech, Gamebryo) are also very decoupled from a game developers client code. Now I'm not saying that there aren't cases that a game dev might not have to go in and make a modification in order to realize their vision...I'm just of the opinion that is the exception rather than the rule. But, then again...I have no AAA games under my belt so maybe a GG veteran could chime in. I'd be very curious.

#6 It really is a design methodology question more than anything.

So you want a component architecture rather than an engine application? Ogre is an excellent renderer which is one component. There are tons of excellent components that developers have added to it to implement more of an application or "engine" mentality to it as well. Some of the projects are extremely intricately coupled and others are nicely compartmentalized. Irrlicht and Power Render (and TrueVision3D) are set up similarly in their design methodology. However, most commercial engines whether it be id tech's or Unreal are not usually decoupled in the way you are explaining because of the fine-grain control needed between what are considered core mechanisms for the games that they are currently developing. Whether this is good or bad comes down to a judgement call and the project. Torque comes from this same mentality, and you can see it in the GPL'd sources of the Quake engines as well.

Now, we do want to componentize Torque because that is an *excellent* direction in terms of adding functionality with third-party libraries. But right now it was built with a different methodology in mind, and one which the current game industry utilizes for the most part since they are building applications with specific featuresets in mind, and while licensing that tech can definitely be beneficial, they want a stellar example of that tech in use for their products. So the code often gets more and more tightly coupled for those projects. If you look at the Source engine's leaked code, you can see some major coupling going on there as well.

#7

Quote:
Since you asked nicely Stefan, with a :) ...

I don't think my questions were offensive, with or without the smiley.
Out of the engines you mentioned, only Nebula 2 is a game engine (just like the Torque products).
Comparing game engines to standalone API's isn't valid.

Ogre and PR are both rendering API's, more or less, and it's suitable to distribute them as libraries. Same thing with FMOD.

Quote:
[...]I extend player rather than modify player.[...]

That's not valid, IMO. You use the tools available to you, and Torque is written in C/C++ which gives you the ability to derive from other classes and make subclasses, childclasses or whatever they are called in English.

Other than that, I agree. But the benefits are minor.

#8 I drool every time someone says "componentize" =)

I'm going to second David's mention of the AAA engines out there being coupled. I'm pretty sure (based on a convo I had at GDC with a dev) that Crysis is tightly coupled, and I know id's Doom 3 engine and Valve's Source engine are both as tight as Torque.

Now, though I'm not brave enough, I could see an interest in wrapping a clean module to port form one Torque engine to another, but I don't have a good example : /

But:

if(nothing())
{
	
}
else
{
	remember([b]this[/b]);
}

this: There is no set standard for how game engine technology works, but once you are in a game engine it's a good idea to uphold the flow of the technology you are working with instead of trying to tear it apart or turn it into another engine =)

#9 Sorry Stefan, forum posts are a bad way at expressing sarcasm/care fee comments which more often that not can be mistakingly taken as I'm attacking you or I found something you said offensive. Your questions were not offensive and quite appreciated! If you were sitting next to me in my cubicle you would have seen that I appreciated your post, respected your opinion/questions, and was only trying to be care free...about saying...hey thanks for responding with some dialog. It did not come across that way to you so again I apologize.

Thanks to everyone else that responded. I've learned quite a bit. And I understand more now than ever what Torque is bringing to the table. Thanks again.

#10 I usually take what a person says in a forum thread, create my own interpretation, and draft a back story of anguish and drama. Then I sit on the fabricated message for months, letting the rage stew.

Quote:
I'm also very willing to learn from others.

Ya see that?!? The sarcasm and condescending tone?!? I'm taking this out on the person in the nearest cubicle...
Target Acquired...arming nerf gun.

Success!!!!

In all seriousness, though. This was a pretty good thread. Great information all around =)

#11 "Pretty sneaky sis."

You stop refreshing the forums for five minutes to get some work done and this is what happens.



I'll get you next time Gadget. Next time!

#12 Sorry Stefan, forum posts are a bad way at expressing sarcasm/care fee comments which more often that not can be mistakingly taken as I'm attacking you or I found something you said offensive. Your questions were not offensive and quite appreciated! If you were sitting next to me in my cubicle you would have seen that I appreciated your post, respected your opinion/questions, and was only trying to be care free...about saying...hey thanks for responding with some dialog. It did not come across that way to you so again I apologize.

Thanks to everyone else that responded. I've learned quite a bit. And I understand more now than ever what Torque is bringing to the table. Thanks again.

#13 Dang it...double posted...