OGRE

From DoomWiki.org

Revision as of 10:56, 27 August 2023 by XymphBot (talk | contribs) (Automated edit - update source ports cat)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

OGRE, an acronym for Open Gaming Resource Engine, was to be a follow-up project to Boom, DOSDoom, and several other minor source ports following their announced merger. The project opened on December 7, 1998. It was hosted by and primarily driven by TeamTNT, in particular through the work of Boom lead programmer Ty Halderman. It was a successor to and replacement for the previous defunct Joint Doom Standards group.

Initial reception[edit]

Initial reception of the project announcement was enthusiastic, with dozens of registrations on the project's forums within a few days of its opening. The stated goals of the project were to create a generic game engine framework on the base of the Doom engine, possibly progressing toward goals such as modularity similar to that found in the modern Source Engine, with swappable rendering and gameplay logic modules, and a strong hardware abstraction layer to ensure wide portability. At the height of the excitement, John Carmack himself signed up to the forums and offered some of his own thoughts on the proposal.

However, various aspects of the project were only vaguely planned or hinted at poorly in the initial documents drawn up, none of which approached an industry-standard design document. It appeared that the project would have a committee-driven design process, where addition of features and changes would need to be voted on by groups or vetted for by senior developers.

Failure[edit]

After approximately three to four months, the initial fervor had died down and left behind a largely dead forum, without any actual progress on the project having been made. The site was eventually silently taken down and all links to it from the TeamTNT homepage were redacted.

Legacy[edit]

Some of the goals of the OGRE project have slowly been realized in several different advanced source ports, such as true three-dimensional constructs, hardware-accelerated rendering capability, use of hardware abstraction layers, and the ability to load game code modules, though no one single port currently implements all of these at once.

Sources[edit]