Here is a quick overview of how to support a new game; if the game uses pretty much the same technology as one that QuArK already supports, this might be enough, otherwise you might actually have to learn something about how QuArK works.

But first, before actually doing anything, post to the QuArK forum and contact the QuArK development team to say what you want to do, in case somebody is already doing it.

At the minimum, there will have to be a gamecode for the game, defined in the source file prog/Setup.pas. Presently these are single-character alphanumerics assigned on the basis of what kind of engine is used:

• 1-9: Quake 1/HL
• A-Z: Quake 2
• a-z: Quake 3 & other advanced

Engines that do use shaders and might acquire curves should go into the last range (Quake 3 & other advanced).

If the game has technology similar to one already supported by QuArK, then this may well be all that's necessary in the Delphi code, and one of the current Delphi coders will be able to do it for you. Otherwise there may need to be coding for texture-display, model-viewing, terrain editing etc., and you might have to do some or even most of it yourself.

Then the game will need a  :config  and  :form  section in the file Defaults.qrk, grouped with the  :config  and  :form  sections for the games already supported. Please place them in alphabetical order so they will show up on the Games menu and config sections that way. This allows for easier and more consistency in the positioning of these items.

People usually copy the ones for the game that is most similar to the new one, and then change whatever needs to be changed. You should pick a recognizable abbreviation and use it consistently, e.g. SoF2 for Soldier of Fortune 2.

Also, the game needs to be added to the " QuakeCtx:form -group  Game -sub-group  Items -variable" list (in Defaults.qrk).

Finally you need to make addons for the game data. There are several of these:

The easiest way to make these is by copying ones from a similar game, and then adding/changing things to suit (the game abbreviation for starters).

A workable texture toolbox for SoF2 is:

  Textures.qtx =
  {
    Toolbox = "Texture Browser..."
    Root = "SoF2 Textures.qtxfolder"
    SoF2 Textures.qtxfolder =
    {
      Textures and Shaders.osfolder =
      {
        path = "base"
      }
    }
  }

Access of Mod & Custom Textures

Another way of setting up access to textures for Mods and Custom Textures is to set the "path" to that specific Mod folder and use the blanket command name "build" with a value of "1" setting as shown in the example below for the Mod "ET", a Quake 3 base game:

{
  Description = "Enemy Terror Add-on"
  Game Context.qctx =
  {
    Game = "Quake 3"
    SourceDir = "ET"
    GameDir = "baseq3"
  }
  Textures.qtx =
  {
    ToolBox = "Texture Browser..."
    Root = "ET (Enemy Terror).qtxfolder"
    ET (Enemy Terror).qtxfolder =
    {
      ET Textures & Shaders.osfolder =
      {
        path = "ET"
        build = "1"
      }
    }
  }
}

In addition, any custom textures and shader files will also be included that are placed in the "textures" and "scripts" folders or in their own sub-folder placed in these folders, with any name you wish to give them. These custom sub-folders can also have sub-folder within them as well for a better grouping of files. All of the folders will then be grouped in the Texture Browser under the caption "Directories" and will be displayed by their individual folder and sub-folder names.

For entities, if the game has a .DEF or .FGD file, you can use the 'File -> Convert from' facility from the QuArK-Explorer main menu, to produce a basic entity toolbox entry which in the case of SoF2 might start look like this:

  SoF2Entities.qtx =
  {
    ToolBox = "New map items..."
    Root = "SoF2 Entities.qtxfolder"
    SoF2 Entities.qtxfolder =
    {
      ;desc = "Created from entities.def"
      func_* entities.qtxfolder =
      .
      .
    }
  }

More info about the converters and their options can be found here: 'QuArK Conversion Tools'

Once things get into a useable state, or possibly even before, somebody with SourceForge access should start committing your stuff to the repository, and it will begin to appear in snapshots.

By `aftermath' I mean that if you initiate QuArK support for a game, people will tend to expect you to fix bugs in the game data, etc., and there always are some, so this can drag on for a while. People will also expect you to be able to answer basic questions about the peculiarities of editing the game. Also, if a converter was used: often the definition file is not up to date at all, so a lot of things might turn up later that have to be added to the addons by hand...