EvilEngine

EvilEngine is the unofficial name for the codebase developed by Heavy Iron Studios as the foundation for their games on the sixth generation consoles. It was used in the following games:

EvilEngine is named in reference to Heavy Iron's proprietary level editor, EvilEditor, which was named after their first game Evil Dead: Hail to the King. EvilEditor was used for all of Heavy Iron's sixth generation games.

EvilEngine uses .HIP and .HOP files to store all the levels in each game as well as common resources that are used globally throughout the game.

EvilEngine uses RenderWare for its 2D and 3D graphics rendering.

History

After the release of Evil Dead: Hail to the King on fifth generation consoles, Heavy Iron began development on Scooby-Doo! Night of 100 Frights. Initially, the game was on the same codebase and at least one of the same platforms as Evil Dead. An early prototype of the game on PSX can be seen here.

At some point, Heavy Iron switched to a new engine for sixth generation consoles and restarted development on Scooby-Doo. One of the earliest builds of the new engine on PS2 can be seen here. At this point, the engine uses an older level format, perhaps the Evil Dead format. However, it uses RenderWare for rendering and stores raw RenderWare files on the disk.

Eventually, Heavy Iron created a new level format to be used by the new engine: .HIP and .HOP files. A build containing the early HIP/HOP files can be seen here. Many of the new engine features can be seen implemented at this point. The .ini file format was also updated and added new settings that went on to appear throughout all EvilEngine games, such as the BOOT, AnalogMin/Max, and Speed settings.

The final release of Scooby-Doo! Night of 100 Frights was the complete first iteration of the engine. The engine was modified in various ways throughout subsequent games, but fundamentally remained the same.

When Heavy Iron began work on Ratatouille, the game was initially prototyped on EvilEngine, similarly to how Scooby-Doo was prototyped on Evil Dead's engine. An early prototype of the game on GameCube can be seen here. This prototype contains multiple build configurations: Debug, Release, Master, and Master with Debug. The debug build has a debug menu containing options to test many of the engine's features, "tweak" specific settings and save the tweaks to a file, and visualize things like collision, textures, and memory usage.

Eventually, Heavy Iron again switched to a newer engine on seventh generation consoles to finish making Ratatouille. This engine is referred to as GoodEngine. It was built on top of EvilEngine, but it is heavily upgraded and features new file formats and technologies such as the Havok physics system and Autodesk Scaleform.

EvilEditor

EvilEditor was the level editor used for all of Heavy Iron's EvilEngine games. Jason Hoerner, lead programmer on several Heavy Iron titles, shared information on EvilEditor:

The editor we used for the game was called the “EvilEditor”, and I didn’t do any work on it myself.  It was named after Evil Dead, the first game Heavy Iron worked on, which was before I started working there.  I did do a lot of work on its successor, the “GoodEditor” (which was used for all of Heavy Iron’s post RenderWare games).  I can tell you all 3D geometry was built in Maya, and the EvilEditor itself was only used for object placement, setting object parameters, and scripting.

The scripting was all event based, there was no actual scripting language.  Objects could send events to other objects, and an FNV hash of the string name of each object was used as an identifier for the object to send it to.  Maybe searching for things that look like hashes (obviously not floats or integers) will make it obvious where events are present in the code.  The game included a system where updates of distant objects were turned off for performance, including a feature where you could group objects to all update together.  The “group update together” feature was used to ensure synced objects (like moving patterns of Tikis) would stay in the same pattern, and dependent objects (like teleport box pairs) would activate together.