Frequently Asked Questions about Hawthorn

This page is the official source of information regarding Doomsday 2.0. If you have additional questions, feel free to append them to the end of the page.

General Topics

What is Hawthorn?

Hawthorn is the codename of the new engine and framework that is being designed and implemented by JaakkoKeranen. Once completed, it will become Doomsday 2.0. Hawthorn is written in C++ and is designed to work in Windows, Linux, and Mac OS X.

The central idea behind Hawthorn is the one that was attempted in Doomsday 1.x with varying degrees of success: a common engine capable of running multiple pseudo-3D games. Conceptually, the difference to Doomsday 1.x isn't radical. The main difference is that an object-oriented approach (and programming language) is used. The engine is designed around a client/server approach, which has been pretty common since Quake.

However, games are handled very differently than in Doomsday 1.x. When Doomsday was first written, it was born out of a rather forciful separation of the Hexen game logic and the generic engine components. As you can imagine, this kind of a move will not result in a clean separation of subsystems. The scars in the architecture still haven't healed, so to speak, and continue to subject new code to a set of rules and restrictions. Hawthorn will change all this by completing what was started, and only the pure game logic will remain in the game components. Everything else from object interaction to map data will be moved to the common engine, where it will be available to all the games.

How does Hawthorn relate to Doomsday 1.x?

The Hawthorn code base will be written almost entirely from scratch. It is intended to supersede Doomsday 1.x in every fashion.

At the level of source code, some aspects of Hawthorn will resemble the ideas present in Doomsday 1.x. However, the implementation will be object-oriented and interactions between the various subsystems will be designed carefully beforehand.

What is the motivation behind Hawthorn? (Isn't rewriting everything pretty dumb?)

This is a good question, considering the features of Doomsday 1.8 and the amount of work put into it. First I would like to stress that the old Doomsday 1.x series will be here to stay for a long time to come. I like to think of it as a pretty polished engine. At no point I intend to completely discontinue its development (although it will significantly slow down, as has been witnessed during 2004). It is quite likely that Doomsday 1 and Hawthorn (Doomsday 2) will live on as separate entities in the future.

As to the motivation, I have many ideas that are simply not feasible to implement in the current code base. The baggage really starts to show: the heavy influence of the original Doom source code and the C programming language make the code difficult to understand, maintain, and extend.

In Doomsday 1.x, many features were developed gradually over a long timespan without a central plan. Consequently, several similar components were implemented, but their functionality was never properly integrated into the grand scheme of things (consider console commands and InFine).

Also, the development of the definition system in Doomsday 1.x got a bit out of hand. Initially the definitions were supposed to be used only as a replacement for the hardcoded data arrays that contained information about objects and thing states, and other such information. However, once the need to implement additional definitions was realized, it was much easier to add them to the existing system rather than to rewrite it. The end result was that the definition system gradually expanded into the behemoth that it is in 1.8. It's still quite easy to maintain (which is always a plus), but the arcane and inflexible implementation of the parser puts hard limits on how the definition language can be expanded.

An alternative approach would be to start replacing 1.8 subsystems one by one using new C++ code, but that still forces one to live with the old assumptions made elsewhere in the code. The resulting new subsystems would be negatively influenced by the old code, and it would result in more work to iteratively revise components until an acceptable standard is reached. I do not entirely rule out this approach, though, and it may be that a 1.9 series is begun with the goal of revising some of 1.8's subsystems. This will not have much effect on Hawthorn, though.

When it comes to rewrites, it is always worthwhile to spend a few moments considering the Second System Syndrome. The obvious danger with Hawthorn is that the implementation starts sliding towards too generic ideals (have support for everything!). Thus I plan to work on Hawthorn in a number of phases. In the first phase I'm going to be targeting functionality that is present in Doomsday 1.x. Naturally all the subsystems can now be properly integrated based on the experience gathered while working on the 1.x series. But any overly ambitious features such as support for all known pseudo-3D games (including Doom variants!) will be ruled out of the process. Thanks to the object-oriented approach and the possibility to design everything from scratch, the architecture can be set up to accommodate future changes -- even major ones -- gracefully. So, the first phase will be all about building a framework that can later be expanded to support anything that is deemed necessary.

Once the first phase is completed, the source code will be made publicly available.

What is the status of Hawthorn?

Currently the new framework is in early stages of implementation. Nothing that can be run interactively exists yet.

• Stubs of the server and the client exist, and basic services of the network communications subsystem have been implemented. The server and the client can send messages to each other.
• Basic services of the data object hierarchy subsystem have been implemented, for example searching for objects using a path.
• The internal components of the scripting core have been implemented, but not tested to any great depth. Script syntax and parsing have been designed, but not implemented.
• A new rendering subsystem has been designed.
• Anything related to games has not been implemented.

When will Hawthorn be available to the public?

The reality of the situation is that my university studies (I'm going to do my Master's Thesis this year!) and part-time job consume a sizable portion of time and energy. As always with hobby projects, it's very difficult to set hard deadlines as sometimes there just isn't enough time to get things done. I could say that a very very early alpha might be available during 2005, but then again in the past my release date estimates have been a bit too optimistic. Also, once the implementation has progressed a bit further, I may make the source code repository public so that other people may chip in.

Q: You mention the possibility of others being able to chip in with the development, say for example someone wanted to help by implementing a script parser will you be making available the design docs for that component?

Once the source code goes public, I will be making available/writing more formal design documentation for other developers. However, the primary documentation system will be Doxygen. This means you get the most detailed documentation available with the source code itself.

Will Hawthorn support (my favorite game/port/feature)?

A generic answer would be: initially no, but quite likely yes later on. The primary goal of Hawthorn is to be a flexible framework for pseudo-3D games, and thus it will be at least theoretically possible to support all the (open sourced) old games out there.

But as ever, since I am doing this on my spare time, my preferences dictate that the Doom Trio (Hexen, Heretic, Doom) are first on the list of priorities.

Is the source code available?

For the time being, no. It is still too early, and many of the design plans aren't yet solid enough to be executed. Once the source code will be made available, it will be distributed under the GNU General Public License.

Architecture

In Hawthorn how deep will the implementation of plugins go?

Q: For instance will the models be setup, controlled etc. in a plugin (including format reading) and then use a general API to instruct the Doomsday renderer how/when/what to render? For instance the model plugin is informed when an object is visible (the plugin keeps track of its own rendering lists?).

Plugins will play a much larger role in Hawthorn than in version 1.x. Basic object-oriented design lends itself easily to extension via pluggable components.

When it comes to models, the idea is that there is a "model manager" class that knows how to load and render models of a certain type. There is a separate manager for each supported model format. The engine itself doesn't care what format a certain object representation is in; it just asks a model manager to render the object with the given parameters. The sprites are also rendered using a "model" manager, but instead of using data read from 3D files it uses billboard polygons.

Hawthorn Environment

What is the Hawthorn Environment?

Unfortunately no one can be told what the Environment is... Well, the basic idea is that the main partner of the scripting core is the Data Object Hierarchy (DOH). All the resources and game data that the engine handles (everything including definitions, scripts, running processes, game objects, the filesystem, clients, etc.) is represented by an object in the DOH. The objects are organized into a hierarchy of directories, much like a regular Unix filesystem. By manipulating the objects in the DOH, scripts can access pretty much all the functionality of the engine.

The scripting core and the DOH are the most central components of Hawthorn.

How are scripts handled?

Q: Will there be a built-in system for reading/writing/parsing files (probably only text files like definitions?) made available to plugins in Hawthorn (not directly reading/writing streams in a plugin)? Other more specialised code (model format reading) would be done directly by the model plugin I presume.

The scripting core plays a very central role in everything that is related to scripts and definitions. All plugins can access the services provided by the engine, either via the programmatical API or via executing scripts ("console commands" in the parlance of 1.x). Thus the plugins have full access to Hawthorn runtime environment.

Graphics and Rendering

Resources

Can Doomsday 1.x resources be used with Hawthorn?

To a large extent, yes. It is definitely a worthwhile task to implement "import filters" that can read old-style resource packs and use them in the Hawthorn environment. However, full compatibility with all the features of a resource pack may not be possible (depends on how the various graphics/model/game subsystems will be implemented).

User Interface

Will there be an improved Control Panel?

Q: Will the new control panel become the central area for changing game specific options and if so will this be done by the "game plugin" registering these into the engine dynamically?

The engine provides access to the UI subsystem via the scripting core and the DOH. Everything (plugins, games, etc.) can use the engine API or scripts to implement their own additions to the UI. In fact, there is very little hardcoded UI functionality.

The UI subsystem only exists on the client. The server is just a daemon process and can only communicate via TCP ports.

There will be a central control panel into which plugins can add their own pages.

Unanswered Questions

Append any extra questions here and inform JaakkoKeranen so that he may answer them.

-- JaakkoKeranen - 08 Jan 2005
to top