Altering the savegame behaviour of TDM

Introduction

From TDM 2.03 on it will be possible for mappers to change the savegame behaviour of the game. This means, that you can restrict the possibilities to save the game in a manner that appears suitable to you and for your FM. These restrictions can be

- Disallowing quicksaves or manual savings completely
- restricting the savegame count to a finite number (like in Project I.G.I. 2 or in the Hitman games series)
- using checkpoints instead of manual savings
- using consumeable tools to save the game, or objects in the world
- and so one

I've tried to keep the system as simple as possible, to easely allow using it in any desired manner.

Why restricting the savegames?

There has been a long discussion in the forum about this matter, so it may be interesting to first think about its purpose. I would advise any mapper to indeed first think about why they want to use it. Using a feature just because it is available is definetely not the best way to go.

Disallowing the player to save whenever he wants can have several consequences on the gameplay. I just want to list a couple of thinks that come to my mind here:

- increasing the difficulty
- creating tension
- supporting tactical gameplay
- implementing another kind of reward system (when restricting the number of saves,
  the player may be able to receive additional ones by fulfilling side-quests etc...)

It is obviously up to the mapper and of course the players on how strong those aspects will take effect. But it is definetely worth thinking about what can be achieved with this, and whether it suits certain types of gameplay or mission paradigmas.

But enogh of the forwords. Let's get to on how to use it.

General Setup

There are three entities that comes with TDM 2.03 serving the purpose of manipulating the savgame mechanics.

info/atdm:savegame_admin is the main entity. You do need exactly one of those in you missions to allow for changes in the savegame mechanics.

targets/atdm:target_savegame is a simple target entity, which will store the game under a name defined in its spawnargs.

playertools/atdm:playertools_savegame is a base class, which can be extended to create inventory objects that saves the game when consumed.

I will describe all of these in the following sections.

The savegame admin

The main entity provides a couple of spawnargs to alter the savegame mechanics.

save_permission values: 0(default), 1, 2

- 0: no restrictions (default TDM behaviour)
- 1: no quicksaves
- 2: no manual saving

save_count_limit values: an integer (default: -1)

Set this to a non-negative number to restrict the amount of saves to said number.

The entity appears as a blue box of size 16x16x16 in DR. It comes with three script functions.

void enableRestriction(float enabled): Dis-/Enables the limitation of the amount of savegames. 
 To disable it, pass zero as argument. 

The amount of used saves is stored. So if the player has five saves and used three of them before the restriction gets disabled, enabling the restriction later on will leave him with two saves left, independend on how often he saved the game in between.

 float isRestrictionEnabled(): Returns 0 if disabled, 1 if enabled.

 void addSaves(float saves): Gives the player the amount of saves passed as an argumant. 
 Negative numbers will reduce the savegame count left.

The savegame_admin scriptobject is deriveable, which allows you to derive scriptobjects from it to extend or alter its behaviour.

The target entity

The target entity holds the spawnarg savegame_name. The entity will save the game under said name (possible overwriting an older savegame with the same name). If no name is said, the game won't get saved and a warning gets printed to the console.

 WARNING: savegame_name not set on entity entity_name

entity_name is the name of the entity. Use this information to find the entity in DR and fix the problem.

The entity does not provide additional script functions.

The playertool

The playertool entity is completely set up from the functional side. Derive an entity from it and set spawnargs like inv_name or inv_icon on it. It doesn't provide additional script functions.

Additional script functions

There are three more script functions left. You will normally not need them, except you are going to implement a more complex setup.

The player entity has two additional script functions. You can call them on the player (player1).

 - void saveGame(string savename): Saves the game under set name
 - void setSavePermissions(float permission): corresponds to the save_permission spawnarg on the 
 admin entity above

In addition, there is

 fload sys.getMissionStatistic("totalSaves")

which will return the number of times saved.

--Obsttorte (talk) 14:35, 11 January 2015 (UTC)