Most critical component of an engine?

[Baker]

What do you feel is the most critical component of an engine?

My opinion is that it is the texture manager --- managing the textures uploaded --- because if you don't have this one in place, it places severe limitations on the flexibility of things you can do.

[And it the focus on my current battle. The FitzQuake texture manager requires data be validated prior to passing data over and then, upon passing data over, indicates where the data came from and the manner of which it can be reloaded.]

Still, my perception is likely altered by my current challenges and maybe my next answer to this question might be something like the network code, as I might have said video mode switching back in 2007, for instance, as an answer to this question.

[mh]

The filesystem.

Closely followed by memory management.

Or perhaps it's the other way around?

Without those nothing works.

[Spike]

there is no single most important component.

the single most important aspect of an engine is imho either its look and feel, or how capable it is of accepting new gamecode that do cool things.

the second is only important if you have mods willing to target only your engine, thus the first must be appealing before the second is even relevant.

pk3 vs pak is unimportant, pak is fine. you get better compression from using the right data formats instead, which also provides better in-memory cache performance (skeletal models beats vertex animations).

memory management is important in any application. but there's no need for anything other than malloc/free if they're used properly, as they should be more than capable of managing your engine's memory. valgrind greatly helps with that. the only time you actually need memory management is when your libc is from the dos days.

a texture manager is no different from, say, a model manager, a sound manager, a shader manager, an entity manager, a cvar manager, a command manager, etc. In FTE, everything is drawn via a shader (supposedly), so the texture manager code itself doesn't really need to be that complex. To be honest, just some code to call glGenTextures and glTexImage would probably be enough. The shader code does the rest. Again, if the memory is released individually, then the code doing that releasing will have no problems at all calling glDeleteTextures too.

imho, look and feel is the most important *aspect*. An example is the console particles in ezquake that make me want to vomit any time I see them. I don't know if they're still enabled by default, I dare not try it just in case.
what are engines most known for? generally its the graphics. directq is known for getting good framerates on intel cards, fitzquake is known for being faithful to the look of software, proquake is known for, urm, not changing looks from glquake, tenebrae/darkplaces is known for its realtime lighting, telejano/qmb are probably most known for their particles. sure, they have mapper features, or modder features, etc etc, but the easier it is to make it look how the respective targetted audience want it, the more likely it is to be popular within that audience, be it faithful, glitzy, or visually apealing.
In QuakeWorld, the overriding factor of the popular engines has generally been 'the engine with the most visible enemy players, the highest framerate, or the lowest latency/smoothest is the most popular engine'. Again, all look and feel.

[andrewj]

I mostly agree with Spike, though I would say the most critical part of an engine is that part(s) which you yourself have no idea how they work and couldn't fix or enhance them if you needed to. So you'd want those components to be as rock solid as possible.

For me that would be the networking code, everything else I could do something with but I can never get my head around networking stuff like client-side prediction, dealing with lost packets etc etc....

[mankrip]

For the users, what Spike said.

For me, the in-memory data types and structures.

[Baker]

I mostly agree with Spike, though I would say the most critical part of an engine is that part(s) which you yourself have no idea how they work and couldn't fix or enhance them if you needed to. So you'd want those components to be as rock solid as possible.

For me that would be the networking code, everything else I could do something with but I can never get my head around networking stuff like client-side prediction, dealing with lost packets etc etc....

Curiosity is killing me. Are you the guy that made the Shambler model for DarkPlaces last year?

Yeah, the most important component is the one you don't understand yourself ... by that measurement, it would be everything that Spike does QCC and the tools and such. I love and understand pointers, but once the syntax gets too complex, I no longer am able to mentally connect the dots.

I suck at 3D math ... I am kind of upset they never really explained what it was good for back when taking all of those courses. Yeah, Identity matrix and basic matrix manipulation ... I get all of that. But the stuff that Spike, MH, LordHavoc, Sajt and R00k understand in that context is source of ... I'd use the word "envy" but it isn't like that ... it is more like the feeling of lost opportunity.

Network code ... I feel I have an above average ability to "get that" ... but I am skeptical I'll be acting on it this year. Not because I can't but rather because I believe if you touch the network protocol you should probably think it through deeply and make a well-documented spec and I don't have the experience and have not done enough hands-on experimentation. Don't pull a pizza out of the oven until the crust is brown and crispy. And I'm not quite at the level of being able to make a great network pizza protocol yet. I have important experiments that I would have to do as a prerequisite.

From my perspective, even if components I cannot make or fully understand are more "important", the concept of a quality texture manager offers me personally more freedom. I've always liked writing 2D interfaces and 2D drawing in general.

Although I am certain of far lesser engine experience and talent than MH, Spike or LordHavoc ... I'd like to believe that my more pedestrian way of thinking has interesting concepts to contribute to the Quake gene pool from a mere mortal perspective. Diversity is one of those things where you get to look at how x, y, z and w think. In a perfect world, I'd have time to play with Vengeance R2 and Quake 2K4's scripting stuff --- I think both of those engines have interesting ideas, but I have yet to really use their distinctive features.

/End rambling ... note to self: download all of Entar's stuff in the next couple of days since it was hosted at QuakeDev. Already downloaded Justin Thyme's QCide stuff, but make sure you download the Tremor engine stuff too, at least to preserve it. That engine doesn't really have anything unique in it, but in the hall of echos it is nicer when things don't die a silent death. And grab Arq-Lite or whatever, maybe the last remnant of Tomaz's CleanQuake.

[dreadlorde]

Obviously, the most critical part is main().

[andrewj]

Curiosity is killing me. Are you the guy that made the Shambler model for DarkPlaces last year?

No, I've never made any Quake mods or models.

[Irritant]

I think it's hard to define what would be the most important part.

You can however, discount game code, since that isn't really part of the engine. You can probably also put netcode pretty far down on the list since not all games are going to be played over a network.

GUI, again, not very high on the list, though nitpickers will judge it.

So really we are mostly talking about rendering aspects. Speed is important, so use of VBO when possible is nice, or at least code that is effiecient. If there is one visual area that I think can be singled out more than any, it's lighting and shadowing.

However none of that is of any importance unless it renders fast.

So, I'd say the most important aspect of a game engine is going to be performance.

[revelator]

id say the most important part is the guy (or gal) behind the engine .

[mh]

I'm thinking a bit more on this one, and it seems to me that how it presents itself to the player is quite critical. Quake is almost a poster child for "how to do it wrong" here: a mess of command-line options, needing to restart the engine if you want to change certain things, unfriendly error message that don't actually describe the root cause of the problem (failed to load gfx.wad anyone?), important settings that are hidden and not easily discoverable (mouse look), unimportant settings that are there in your face (lookspring and lookstrafe), multiple different ways of doing what should be the same thing but which exhibit subtle differences (-hipnotic vs -game hipnotic), I could go on - have we got all day?