So, why write a new editor?

Back in 2013, Valve dropped the content pipeline update for Team Fortress 2, completely changing the way in which the game's assets were stored and loaded and predictably breaking compatibility with the development tools. Although much of the community was braced for this change, some making alternative configurations within the Source SDK in order to continue creating content, the period of waiting for Valve to update the tools was not made any less frustrating in the meantime.

This dependency on publishers to fix or improve tools, which may or may not be high up on their priority lists, became the original driving force behind the mission of the Crowbar editor. Alongside it, flaws with the Hammer editor - whose core interface and methodology has remained largely unchanged since Valve acquired its original developer for work on the Half-Life series - motivated changes to the way users interacted with and manipulated objects within their maps. Valve's iterative create-test-refine methodology implied that abstracting away from low-level details into more conceptual tasks (like "move this arena" or "widen this corridor") might help improve development timeframes considerably, and the plethora of user-made tools that supplemented the development pipeline - content packers, game asset browsers, prefabricated object group libraries and more - suggested that a modular, extensible editor that could cater to all of these requirements and more would be a valuable tool that would encompass and streamline the process of creating a map, from inception through to release.

The goals of the Crowbar editor

Considering all of the above issues, the over-arching goals of Crowbar are:

• To remain free and open-source for its entire life cycle. For community-centred activities like custom game content creation, it is important that the game community itself has as much control over the process as possible. Keeping Crowbar free will allow it to be as accessible as possible for end-users, and keeping it open source will give content makers complete control over all of the editor's functionality.

  It's important to note that open-source, specifically, eliminates the commitment of a given game's original developers to maintain their editor's compatibility with their game. If compatibility breaks, inquisitive or dedicated users (and game enthusiasts are frequently both) can set about fixing the problem, rather than being reliant on the official developers for a patch.

• To be multi-game. To be truly extensible, the editor should not centre its compatibility around one particular game; rather, it should be able to create content for as wide an array of games as possible. At the current time Crowbar will focus on games whose levels have a BSP-style architecture (ie. with world geometry explicitly defined by planes and volumes); in the future other level styles may be considered, depending on demand.

• To be cross-platform. Ideally, the editor should be able to run on any desktop platform that the games it caters for can run on. Since the Source engine has expanded to include Windows, Mac and Linux, these three platforms should act as a minimum compatibility baseline.

• To provide an efficient methodology for creating levels. If map development is streamlined, tests can be run more frequently in order to gather more information and identify subtler bugs and targets for improvement, and so the time taken to realise an end product can be significantly reduced.

  This leads to the first of the Crowbar editor's core philosophies, abstract and automate, which is explained in detail later.

• To provide flexible editing depth. Although abstracting away from the basic geometric operations can help speed up tasks, the editor should also allow the user to work at a low level if they require it. Wherever possible, the editor should provide advanced settings to allow users to precisely tweak operations to their needs, and should make a set of low-level tools available for fine-grained editing.

• To cater to the entire mapping process, not just building worlds. To make administration tasks, such as adding custom assets or packaging them within a finished map, quicker and simpler, the editor should provide functionality to automate these processes.

• To be modular and extensible. While the functions within the Crowbar editor should cater to a wide variety of user operations, it should also be customisable and able to be tuned to a specific user's needs. This includes making support available for custom game asset types, compile tools, editor plugins and other utilities (eg. texture or model browsers), control over the stages of the map compilation pipeline, and scripting and macros for automation of common or bespoke tasks.

Abstract and Automate

Those who are familiar with the Hammer editor, used to create content for Valve's Source engine games, may understand how long-winded a process it is to make sweeping changes to a map. Brushes (geometry blocks) must be dragged out by hand in most instances, cut into shapes, positioned, rotated and scaled, and this makes even creating a block room (outside of using the "Make brush hollow" function) a relatively slow task. Combined with the practice of frequent testing and refining that is utilised by Valve and many third party map authors, and that provides the core development methodology of the Team Fortress 2 Mappers community, for example, this can significantly slow down the development speed of a map because of the cost of making the required changes as testing goes on. The more complete (and so complex) a map has become, the more time and effort is required to make even a relatively small change to an aspect as fundamental as the overall size of a room.

To help remedy this, Crowbar employs the principle of abstract and automate: abstract to a higher-level operation and automate the lower-level steps required to achieve this.

To take Team Fortress 2 as an example, gameplay is motivated by the ability for each class to utilise their skills within a map. The topological layout of arenas, their sizing and the positions and widths of their entry and exit points all contribute significantly to the overall experience of a map, and much of the time in the early 'alpha' stages of a map's development is spent on refining the overall layout so that gameplay flows and teams are balanced. In traditional Hammer editor style, this would involve physically changing the dimensions of the geometry blocks that make up an area each time a change was made, and updating all of the surrounding geometry to compensate.

An abstraction in this situation would be to be able to visualise and interact with a map solely from a topological point of view. The user should be able to define the general shapes and sizes of their arenas in as simple a form as possible, and define in what manner they are connected: how many bends connecting routes employ, their widths, and so on. Crucially, the user should be able to manipulate this topology without hinderance - for example, changing the position of one of the arenas should affect its connecting routes so that they remain physically connected to the arena itself.

The automation step would be to manage the generation of physical geometry from this conceptual representation. This could involve converting the routes between arenas into corridors made up of blocks, or the arena volumes into basic rooms. Once the user is happy with their design, they can 'bake' the geometry and remove the ability to manipulate topologically in order to proceed at a finer level of detail.

Abstraction and automation can be employed in a variety of different situations in order to allow the user to keep their focus on the more important aspects of their map, and to have the editor take care of the otherwise tedious lower-level details. This both helps objectives to be achieved more effectively, as the user is given more precise control over the conceptual aspect they are modifying, and also reduces the amount of time spent completing a given task.