Game specification: Difference between revisions

From Spring
Jump to navigationJump to search
Argh (talk | contribs)
Argh (talk | contribs)
Removed TDF reference; cleaned up, added current example
Line 9: Line 9:
The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.
The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.


===Specification===
===Modinfo.lua Example===
Modinfo.lua, like any Lua language file, can contain active code, should you want it to.  But it is mainly just designed to refer Spring's Virtual File System (VFS) to the correct game files and any dependencies of your project.


This is an example of what this file should look like:
Here is an example:


<tt>
<pre>return
// Description of the mod control file recognized by spring:
{
game='myNiftyGame',
shortGame='mNg',
name='My Nifty Game',
mutator='official',
version='1.0',
description='The Awesome Game I Made.',
url='http://www.my_nifty_url.com/',
modtype=1,
depend= {
depend01.sdd,
depend02.sdd,
},
}</pre>


[MOD]
{
  // The name is shown in the selection interface
  Name=XTA version 0.61;


  // These can be shown by the selection interface
'''Dependencies''' are files that your game depends on to operate.  This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.
  Description=XTA 0.61 beta makes stuff balanced and cool;
  URL=http://www.clan-sy.com/;


  // What kind of mod this is
'''Modtype''' determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.
  //  0 - Hidden (support mod that can't be selected, such as OTA_textures)
  //  1 - Normal, only one can be selected at a time
  // 2 - Addon, any number of these can be selected. Could be used
  //      for single units for example.
  //  others - perhaps mutators and addon races that can be
  //          enabled in addition to xta for example?
  ModType=1;
 
  // Number of other archives this one depends on   
  NumDependencies=1;
  Depend0=taenheter.sdz;
 
  // Number of other archives this one replaces
  NumReplaces=1;
  Replace0=xta_se_v060.sdz;
}
</tt>
 
Most of these entries should be easy to understand. Dependencies and replacements needs some consideration though.
 
Note: the order in which depencies are numerated, is inverse to the hierarchy,
i.e. (example taken from OTA mod pack made by zwzsg):
 
<tt>
[MOD]
{
  Name=Shiny TA v5.5;
  Description=OTA Evolva new BP v5.5;
  URL=http://www.fileuniverse.com/spring/;
 
  ModType=1;
 
  NumDependencies=1;
  Depend4=tacontent.sdz;
  Depend3=tatextures.sdz;
  Depend2=OTA_data.sd7;
  Depend1=Evolva_models.sd7;
  Depend0=UTASP_UnitPics.sd7;
}
</tt>
 
the last item in this list is Depend0=UTASP_UnitPics.sd7, which should overwrite the buildpics contained into otacontent.sdz, which is included in the tacontent.sdz, thus UTASP_UnitPics.sd7 should be loaded the last to overwrite the previously loaded unitpic files.
 
Altough the list is written in the right order, the dependencies seem to be numerated inversely, with UTASP_UnitPics.sd7 having the lower number and tacontent the higher, this is anyhow the correct way to do it.


===Dependencies===
===Dependencies===

Revision as of 11:12, 25 February 2010

Overview

This is a specification of how Spring will support mods and switching between them.

Spring looks for games in the folders "maps", "base" and "mods", and all their subfolders. It is recommended to put your game in a subfolder of /mods. Spring supports multiple subfolders within /mods: /mods/my_nifty_game/game.sdd and /mods/my_nifty_game/game_support.sdz are both correct.

On startup, Spring will search these folders and their subfolders for files called "modinfo.lua". This file declares all dependencies of this game, such as additional graphics, sounds and the like.

The general idea is that this file should be used as a manifest file to let Spring know what to do with the archive it is found inside, so each archive file in the mods directory is supposed to have one. Archive files that do not contain this file are ignored, and aren't available to Spring's Virtual File System.

Modinfo.lua Example

Modinfo.lua, like any Lua language file, can contain active code, should you want it to. But it is mainly just designed to refer Spring's Virtual File System (VFS) to the correct game files and any dependencies of your project.

Here is an example:

return
{
	game='myNiftyGame',
	shortGame='mNg',
	name='My Nifty Game',
	mutator='official',
	version='1.0',
	description='The Awesome Game I Made.',
	url='http://www.my_nifty_url.com/',
	modtype=1,
	depend= {
		depend01.sdd,
		depend02.sdd,
		},
}


Dependencies are files that your game depends on to operate. This may be anything- a map, another game, a folder named "my_nifty_sounds.sdd" that has a bunch of sounds in it and a modinfo.lua file to identify it as a valid file archive to Spring- basically anything goes, so long as it, like your game, is identified as a usable archive by having a modinfo.lua file in it.

Modtype determines whether Spring's archive system sees the game as a game, or as an "invisible" file that can only be called as a Dependency. If set to any number except for 1, it will not be visible to end-users as a "game", but you can still refer to it in the depend table.

Dependencies

Listing the dependencies allows a mod to not load the OTA textures at all for example, if it only uses original textures. Only one mod of type 1 can be selected at one time. Also, if a mod of type 2 is depending on a type 1 mod, that mod has to be selected first.

Some examples on how this could be used:

  • An OTA mod that restores balance to be more similar to OTA could use modtype=1 and depend on XTA. Since XTA is now in the dependency graph, type 2 mods that depend on XTA would now also be usable.
  • A new total conversion with a few extra options (not sure what that could be.. but anyway) could use a hidden base package and provide several type 1 mods that are small files that depend on the base.

When playing, the files would be loaded in the order defined by the dependency graph. The files could also be checked with an MD5 checksum or similar to make sure all players have the same file.

Replacements

When releasing new versions of a mod it is recommended that a new unique filename is used. In this manner it would be possible for the lobby to download archives from a fast webserver based on the filename. But if a new name is used for a support archive with content for example, it would break other mods that depends on the archive. To avoid this, replacements can be used.

Replacements simply specifies which other archives this one replaces. So if a new archive specifies that it replaces old_archive.sdz, any other mod that depends on old_archive.sdz would now use the new one instead.

It is probably not always a good idea to use this for new versions of a mod however, since if you hide the old version people would not be able to switch between the old and the new version. So only use replacements when you are sure that it is what you want.

Final words

If a player does not have a certain mod when trying to join a game, the info in description etc could be sent to allow the player to download it.. The filename could be sent as well, so that the client could try to download it automatically from a few predefined redirect servers (similar to the system unreal tournament uses).