This document contains important and frequently asked questions and answers that explain aspects of Scrolling Game Development Kit 2 that most users should be familiar with in order to effectively use the program.
It's important to understand how the rules defined in plans and the rules defined in sprite definitions interact, in order to understand why sprites behave the way they do in many cases. During each loop of the game, all the rules for all plans are executed in sequence (one plan's rules execute, then the next plan). The plans are executed according to their priority (which can be ignored if you don't care about the order in which the plans execute). After all the plan rules have executed, then all the sprite rules execute. The important point is that sprite rules execute after plan rules, so don't expect the effects of a sprite rule to be available during a plan rule's execution until the next frame. By executing the rules in this order, it's possible to have a specific plan provide input to a specific sprite, and then allow the sprite definition to act on the input.
Open the "Player.cs" file from the "Source Code" folder in your project. Search for "UpArrow" and you will find the first of many values that you can change to alter the default keyboard layouts. Look at all the keyboard layouts defined in the function for examples of valid values that you can use for key specifications.
These 3 objects are used to define graphics at different levels/layers in a project. At the lowest, most basic level are graphic sheets. Practically all graphics that will be used in a game will be contained in a graphic sheet in some form.
The next level up is the Frameset. A frameset can be used to define how graphics in a graphic sheet can be transformed. This allows you to, for example, draw a single graphic (in a graphic sheet) to represent a creature facing in one direction, but rotate it to 4 different directions in a Frameset and show the creature facing any of these directions in the game. If the original graphic in the graphic sheet is changed, all 4 rotations will implicitly reflect the same change. Another benefit of the Frameset is that the size of the project is smaller because each rotation (or other transformation) doesn't have to be stored as a separate graphic when it can be transformed dynamically by the frameset.
Finally, a Tileset is another layer of abstraction that is used for defining graphics on a map layer. Since a tile on a layer needs to support the ability to animate or display graphics from multiple frames simultaneously, and a frameset does not allow this, the Tileset is introduced. A tileset associates numeric values stored in the layer's tiles with frames in a frameset, and adds the ability for a single tile number to refer to different frames depending on a counter value (so the tile can animate as the counter changes) and to refer to multiple frames for the same counter value (so a single tile can display multiple graphics overlapping).
If this seems like a lot of effort to create a simple set of tiles that can be used on a map layer, keep in mind there are shortcuts. If you just want to use a graphic sheet's graphics directly on a map layer, it's relatively easy to create a frameset, select all graphic sheet cells and add them to the frameset, then create a tileset associated with the frameset without any tile mappings. A tileset without any tiles defined will default to associating each numeric value with a frame in the associated frameset at that index. So it's not necessary in a tileset to explicitly map every (or any) tile to a frameset frame because each tile value will, by default, map to a frameset frame.
Most sprites will need to walk on solid ground or be prevented from walking through solid walls. Sometimes they even need to be able to walk up hills. To do this, SGDK2 provides "Solidity". The "Solidity" folder in an SGDK2 project contains solidity definitions which define how various categories of tiles should be shaped. For example, you can have one solidity definition that defines all cloud tiles as solid, so some cloud-walking sprites can use that definition and be allowed to walk on clouds. Another solidity definition could define the cloud tiles as empty, allowing a sprite to walk through clouds unobstructed. Each solidity definition encompasses one entire set of rules for all tile categories and shapes to which a particular type of sprite needs to respond. Realize that only one solidity definition is required to define how a sprite interacts with tiles no matter how many shapes or types of tiles you're dealing with. The purpose of multiple solidity definitions is to allow different sprites to respond in different ways to the same tiles. Often times, only one solidity definition is required in a project.
A solidity definition consists of a simple list of associations between two other objects: tile categories and tile shapes. Each tile category can be associated with one tile shape, indicating that every tile in the category should assume the specified shape. While a tile category can only be associated with one shape, multiple categories can be associated with the same tile shape. So before defining solidity, it's necessary to define tile categories. You can include all tiles from all tilesets that represent a particular tile shape in a single category. See details of the Tile Categories UI for information about this process. Tile Shapes, on the other hand are built-in to SGDK2 to some extent. A pre-defined set of shapes is provided in the default source code generated for a project. You can, however, add your own tile shapes. Each tile shape is defined by a set of 4 functions:
To define a new tile shape, edit TileShapes.cs (in the project's source code folder), and start by creating a copy of an existing tile shape with a new name. For example, make another copy of the entire SolidTileShape class, and change all occurrences of SolidTileShape in the new copy to whatever shape you want to create. Then change the implementation in the 4 functions mentioned above to define how your shape should behave. After recompiling the project, the new shape should show up in the Solidity Definition editor.
The SGDK2 IDE itself does not run (at least not well) under Linux, but the projects created by SGDK2 can run under Linux as of SGDK version 2.1.1. In order to make the projects run under Linux some modifications had to be made to the default framework code for SGDK2 projects because some of it was relying on Windows-specific behavior. The new code, however, will work universally under Linux and Windows. (Mainly this code relates to keyboard input, and as of this writing, there is no support for Joystick input under Linux, so the new code disables the Joystick input under Linux, but leaves it enabled when running under Windows.)
After all this has been done, when you compile your project, the output directory will contain all the files necessary to run your project under Linux. It will also contain all the files necessary to develop, edit and re-compile your project using MonoDevelop in case further debugging is necessary under Linux. Note that you may no longer be able to run your project in the Windows environment simply because FMODEx.dll may no longer exist in the project's output directory. You can manually add it. Also, be aware that you can delete the intermediate output files (a command in the File menu) if you don't care to have all the source code available, and then only the files to run your project under Linux will remain.