From ASSS Wiki

Jump to: navigation, search
Error creating thumbnail: File seems to be missing: /home/mgb/public_html/wiki/images/b/b8/Discretionss.PNG
A Screenshot of SubSpace Discretion.

Discretion[1] is a SubSpace client created by BaK. It is open source, like ASSS, and is released under the GPL. Discretion was developed because of the limitations of the in-use client, Continuum. Furthermore, the lack of development of Continuum led to a situation where limitations in the client would never be overcome. Making heavy use of SDL, Discretion is cross-platform, and is currently supported under Windows, Linux, and Mac OS X. Discretion is intended to be secure through design, rather than through obscurity like Continuum. It is designed to make cheating impossible, rather than just difficult. There is also an extensive Discretion Module Tutorial on this wiki for those interested in helping out.

For cheating to be made impossible, the server must check the data players send it for cheating. This requires modifying the server, which rules out using Subgame. There is, however, a modified ASSS Server that allows Discretion clients to connect.

In order to encourage client development, Discretion is designed with a modular system similar to ASSS. There are interfaces which define actions for modules (such as "draw ship at 50,50"), and callbacks which signal when events occur (such as "player has been killed"). Where possible, magic values have been removed and are instead loaded from plain-text settings files. The goal of this is to eliminate any built-in constraints present in VIE SubSpace and Continuum. These magic values include the location / color of the FPS counter, 1024x1024 tiles in maps, each tile being 16x16 pixels, each ship image having 40 frames thus 9 degree turns, the number of fly over tiles, two sets of doors four tiles each per map, the 0x01 type packet corresponding to an arena login, friendly players showing up yellow in the stat box, the colors in the font file, the number of frames in the wormhole animation, the text that shows up when you press ESC, the number of ships, as well as all the settings Continuum does allow you to change such as the ship images, the game play settings, and the controls. The server is intended to be able to modify most of these, thus giving Zone developers maximum creativity and flexibility.



Discretion is divided up into several modules, dynamically linked into the main program much like ASSS. These modules are desired to be as generic as possible, with their Continuum-like actions coming from the settings, rather than the modules themselves. Thus Discretion is like a 2D grid game engine, with settings and graphics which make it look like SubSpace. The module interfaces are documented in the corresponding header files using Javadoc-style documentation. There are currently over 30 modules in the Discretion release. Some of the main ones are discussed below.

Settings Handler

The SettingsHandler modules loads the settings from ini-like plain text files. The main settings file is located in conf/MAIN.CONF, which #includes many other settings files. All these settings files are plain text, meaning they can be edited using a utility like pico or notepad. Individual settings can be specified in several formats, depending on how they should be interpreted. Supported types include integers (50, 0x30, 0777), strings (hello person), points/vectors/dimensions ((100,200)), rgb colors ((255,255,255), (0,128,128)), and LVZ-style screen locations ((C+50,50), (B-10,C+25)). There also exists a helper function to parse comma separated a list of strings from a single sting in shared/StringManip.h. This module interface also allows modules to load their own conf files, or save a group of settings to a file which the program can then read out of.

The front end program, cskinviewer uses the saving capability of SettingsHandler to keep track of zone data between program executions.

Module Manager

The Module Manager itself is a module which is loaded by the program, which then proceeds to load any other modules. This uses the setting Modules::Names which is a comma separated list of strings to figure out which modules to load. It loads module files, '.dll's in Windows and '.so's in Linux, from the bin/ directory. Modules are loaded in stages. During the first stage, LOADMODE_Init, modules register their interface, if any, with the Module Manager and register any callbacks they want to listen for. During the next stage, LOADMODE_LoadInterfaces, modules load any interfaces they plan to use. Finally, during LOADMODE_PostLoadInterfaces, modules can use their loaded interfaces to other modules to initialize themselves. Upon successful program termination, LOADMODE_Unload is invoked which allows the module to free any data or resources it's using. The module manager also facilitates callbacks. Where possible, C++ exception handling is used to aid in catching errors in a non-fatal way and reports the cause of the problem.

Note that some initialization tasks should not be done in LOADMODE_PostLoadInterfaces since they require modules be initialized in a specific order. For example, the Text module, which writes text to the screen should not be initialized before the Graphics module is, since it would be unable to load the text image. Thus some initialization tasks are be done in callbacks, CB_LOADIMAGES in this instance.


The Graphics module allows one to load images and draw them to the screen or map. When an image is loaded through the interface, an image handle is given to the calling module which is used to refer to the image. This handle can also be used to get the image size (taking into account that some images are framed animations), or free the image when it's no longer needed. Blank images can also be created and drawn on, thus allowing one to predraw complex images instead of redrawing them every frame. Images, when drawn to the screen, are drawn in layers. This allows several modules to queue up images to be drawn out of order and still result in a correct drawing. Some layers include L_Tiles, L_Weapons, L_AfterWeapons, L_Gauges, L_Chat and L_TopMost. Images can be drawn relative to the screen, or relative to the map. Images can also be blended such that they appear translucent, as long as the user has Graphics::UseBlending set to 1. Rectangles of a constant color can also be drawn to the screen or on to another image. The images are queued up to be drawn during the CB_PRERENDER callback.

Although providing a basic interface, it is uncommon to Graphics module directly for loading images. Instead the UniqueImage module allows one to specify an image in the settings and refer to it in code by a name. This is much easier than loading the image yourself, and easily allows a single graphic to contain many different images, which is not uncommon in SubSpace images (the bullets image, for example, contains images for all sorts of bullets rather than just a single type). The UniqueImage module makes sure to only keep a single copy of the image in memory at all times. The UniqueImage module, in turn, is used by the Animations module to provide simple access to SubSpace-style animations. Thus, a programmer can code something like 'draw animation "bullet explosion" at 512,512' and it will handle loading the image, figuring out how many frames there are, the speed of the animation, and how long to display it for.


The Controls module permits the programmer to provide actions("move forward"), while the settings specify exactly what keyboard or joystick input they correspond to("up arrow key"). Controls should be registered in the CB_CONTROLSLOADED callback. Also, since this a generic module it does not capture any of the physical controls itself, instead relying on other modules to handle that aspect.

The SDL Key Controls module handles capturing keyboard input and sending it to the Controls module. The Mouse module does not use the Controls module directly, instead providing its own interface which allows one to create mouse hotspots and be notified of mouse clicks or movements within these hotspots.


Similar to how ASSS has timers implemented in the mainloop module, Discretion has a Timers module that provides a timer functionality. One can register a function to be called in X milliseconds, or every X milliseconds until it's canceled. Discretion is currently not multithreaded beyond SDL, so that a timer in an infinite loop (or any piece of code that gets to run, for that matter), will result in the program freezing up. Thus you should not use blocking calls in timers or take up too much processing time which will degrade performance.

The Net module uses a timer to send and receive packets.


The Text module provides an easy way to draw text on the screen. This is the standard subspace text and can be specfied by color. This module draws the text on one line for a single frame. Therefore, you must call the appropriate functions in this interface during CB_PRERENDER every frame for however long you wish to display the text. There is support for drawing text relative to the screen or to the map, as well as blending text and drawing on any layer.

The Textbox module uses Text to draw its text, but provides additional features such as drawing textbox borders and allowing easy textbox loading from files. EscapeBox and PlayerList, in turn, use Textbox. Chat also makes use of the Text module when it draws player chat to the screen. The Flash module, which handles messages similar to SubSpace's kill and prize messages, also uses the Text module. Pretty much anywhere you see text, the Text module is at work.


The Physics module provides functions which can give you a particle's new position given its initial position, velocity, and time elapsed. This is used for ships as well as weapons. The position can be advanced in such a way that is affected by the map (such as bombs going around a wormhole), or not. Particles can bounce off the level or explode on contact.

The SelfShip module uses Physics to compute the new position of the player over time. SS_Items uses Physics to find the position of a bullet after a certain amount of time.


The PerPlayerData module provides a simple way to have data that is common to every player. This is similar to ASSS' PlayerData module in that a struct of memory can be allocated for every player and referred to using a key. The module also facilitates simple sharing of per player data between module such as "name", "x", or "y".

The PlayerList module uses the sharing facility of PerPlayerData to get the names of the players on the player list.


The Level module provides a simple interface to possibly many different types of level formats. Modules can load levels through the interface, as well as get the map or tile size. Furthermore, forces on the level, such as wormholes, friction, or gravity can be applied through the interface.

Currently, the only map format implemented is oldlvl which supports regular SubSpace LVL files. This provides a somewhat more generic implementation, which a customizable amount of doors or custom animation tiles (wormholes, space station, and asteriods), as well as having wormholes with different properties on the same map.

Front End

The front end, not exactly a module, is implemented as its own program, cskinviewer, contributed by Smong. This program allows one to download a list of ASSS servers from a Directory Server, and choose one and login. It uses the SettingsHandler to save the current zone list to the settings. Custom zones can not be added through the interface yet, but can be added by hand by editing conf/profiles/ZoneList.conf.

The front end executes in_game, which in turn loads the Module Manager which runs Main SDL which runs callbacks to load the various SDL Subsystems and starts the program's main loop.


Development for Discretion is ongoing and everyone is encouraged to contribute. Graphics are always helpful, and if you have an idea feel free to make it. In the spirit of free software, it would be best if eventually all VIE owned graphics were replaced, as their copyright status is unknown. This includes the ships, bullets, default tileset, and all other graphics from VIE SubSpace or Continuum. Also, a Discretion skin is yet to be made for the front end (the format follows that of Continuum's, see the skins directory in your Continuum folder). Additionally, many features are in development or unimplemented. If one wanted to help out, just contact BaK, or start working on graphics or a module. There is also a Discretion Module Tutorial which shows you how to create a simple module. Some planned modules include:

Star Background

A StarBackground module that draws stars and planets similar to how Continuum does it. It would be great if this looked better than Continuum as it would lead to better immersion, making the gameplay more fun. This could also be used to draw all sorts of backgrounds, such as grass for earth-based zones, to provide an alternative to tiling LVZ all over the map. This would be a good module to make to get introduced to Discretion development.


A reverse compatible LVZ module is desired to allow current zones to easily switch over to Discretion without remaking their lvz files. This could provide additional functionality not present in current lvz such as lvz that depend on ship locations to allow animations within shipsets. The easier way to make this is probably to make a static image/animation module which uses the settings and UniqueImage and Animations to draw images on the map and screen. Then, an lvz compatibility layer module would be made which translates an lvz file into a .conf file and uses SettingsHandler to load in the images from the generated file.


Subspace and Continuum include a radar for locating enemies. This will have to be implemented in Discretion. The users should also be able to make the radar bigger by pressing a key (alt).


Sound provides immersion in video games and gives them an authentic feel. We need a way to play sounds when certain actions occur such as a bullet being fired or player bouncing off a wall. WAV sounds will have to be implemented for reverse compatibility, but mp3 is not out of the question for longer sounds such as victory music or just music in general. After this is done, a built in mp3 player could be made to allow players to change songs from within the game. SDL_mixer[2] provides mp3 capabilities and may be used.


There are many items SubSpace uses which must be implemented. Care must be taken here to prevent cheating. For example, it would not be difficult to write a program to detect right before a player is about to get hit and automatically portal out or repel. Thus, these items may have to be modified to be on a timer, so that using a portal might require your ship to take a second to "charge up" instead of instantly warping. Also, it would be great if weapons didn't have to follow boring straight lines and instead could turn. Thus I could specify in the settings the direction a weapon would travel if the ship were facing straight up and it would happen. So a straight line would be (0,t), a curvy shot may be (sin(t),t), a shot that speeds up over time may be (0,2^t).

Custom Client Side Code

The server should be able to provide code that can be executed client side. There are two types of code that will be provided: updated versions of modules, and game play related code. This is especially dangerous since a malicious server owner should not be permitted to compromise players' computers. The module updates can be done by providing a RSA signature with the binary .dll or .so which can be checked before executing any downloaded files. As for game play related code, a Java virtual machine could be used with a Security Manager that allows nothing beyond basic functions. Then, an interface could be provided to the game code that could be used by the code. Thus, binary .class file could be distributed for an arena that aren't allowed to delete files off your computer, but are allowed to access the game play relayed interface thus permitting graphics to be drawn or players to be warped around.

External links

Personal tools