Middleware

Middleware is not as low-level as OpenGL or DX, but it's not an entire finished game engine either (like the Unreal engine). Renderware, for example, have a product called "Renderware Graphics" which provides (I assume, since I have never used it) spatial subdivision routines, lighting routines, stuff that you'd build your engine on top of. So you don't have to write everything yourself from scratch.

cheers
sam.

A good example of middleware is the Fmod sound library. In my game engine, I could write my own sound libary, or use Fmod. It's just a way to fill out your engine with features you don't have time to write.

Middleware is exactly what it says on the tin, but there's a lot of variation in how much 'middle' the 'ware' actually does for you.

Something like Renderware Graphics will give you a C library of functions that let you avoir writing your own graphics engine; you just throw models at the library, tell it where to put the lights and what type they are, then have it go render it. It saves all that tedious messing about with OpenGL or DirectX and -- a useful feature for pros -- you can use the same code for PC, PS2, GameCube, XBox and more.

Renderware is one of the more flexible types of middleware: there's a graphics engine, a physics engine -- sublicensed from Havok, I think -- an AI framework (which was produced after I'd left), an audio engine -- co-designed by Mr. FMOD himself, surprisingly enough, and you just pick and choose the bits you want.

More recently, they've produced something called "Renderware Studio" which, ultimately, is intended to become a sort of "Click Here To Make Game"-type thing. It comes with pre-optimised "packs" for specific game genres, such as FPS, racing games, etc. (I think only the FPS pack is available so far.)

Other companies offer similar software. Some is closer to Renderware in usage: you write your code and just link the middleware library into it, much as you would, say, DirectX or FMOD. NDL's "Gamebryo" is like this, as is Auran's "Jet" series and the venerable RAD Game Tools pioneered the whole middleware concept, having been around since 1991.

Depending on whom you choose, you'll find libraries that cover most of the bases: audio, video, 3D, physics, etc. Some companies specialise in only one particular field -- Havok only does physics, for instance.

Other companies produce genre-specific middleware. ID and Valve, for instance, make plenty of cash from licensing their own FPS engines to other companies. (Valve's HalfLife 2 engine includes the 3D graphics stuff, audio support and the Havok physics engine. As well as a scripting system.) A prime example of these is the Torque engine, which is basically an FPS game with a glorified editor and scripting system. (You _can_ talk to it as a standard library, but it's not really intended for this. It's really an extremely 'moddable' FPS game.)

The middleware philosophy -- that you try and avoid reinventing the wheel as much as possible and focus your resources on actually creating a game -- has expanded somewhat to include the whole development process and improved toolchains. Renderware Studio is (if memory serves) the furthest down this path, as it even includes integration with versioning software and close links with major 3D modeling packages.

Anyway, that's about the size of it. It really boils down to saving time: I remember being able to get an animated 3D model, with textures and lights, up on the screen in less than four hours using the original 3.0 release of Renderware Graphics. And I didn't know shit about 3D graphics programming at the time.

Regards,

--
Sean Timarco Baggaley

[DISCLAIMER: I wrote the first User Guide for Renderware, which appeared in v3.1 or 3.2, leaving Criterion in August 2001. My info is probably outdated by now.]

Quote:

Original post by stimarco you can use the same code for PC, PS2, GameCube, XBox and more.

Unless you want to get the back buffer as a texture, it seems :o) I had that problem recently.

RW Physics is what used to be the Karma physics engine, which Criterion inherited when they bought MathEngine.

Quote:

Original post by HarryW Quote: Original post by stimarco you can use the same code for PC, PS2, GameCube, XBox and more. Unless you want to get the back buffer as a texture, it seems :o) I had that problem recently.

That's a good point. Renderware isn't actually cross-platform as such; more of a multi-platform solution. About 90% of your codebase can be the same, but the idea was to expose platform-specific features in a way that avoided the 'lowest common denominator' problem that affects many cross-platform libraries.

It's a bit of a weird architecture, is RW3. I've no idea what their new RW4 is like though. Hopefully they've junked their ancient Renderware v1/v2 terminology for something a bit more meaningful than "RpClump" and "RpAtomic".

Quote:

RW Physics is what used to be the Karma physics engine, which Criterion inherited when they bought MathEngine.

Ah, that's right. I knew they were buying-in something for that, rather than writing one of their own, but I'd left before they actually forked over the cash. My memory is seriously crap

, so I should state now that my earlier post should be viewed with that handicap in mind.

--
Sean Timarco Baggaley

I ain't kidding either. I don't know if there's a term for the opposite of an eidetic memory, but that's a good description of what I have. I worship at the altar of Post-It Notes.

wow , no wonder some companies are shelling out a lot to get hold of these babies :D

none of my buisness (and you will probably reply with "Yeah!!" )
but what went wrong at Criterion

Nothing went wrong at Criterion. Why would something have gone wrong?

Edit: oh, you're probably talking to stimarco, wondering why he left.