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:

1. GetTopSolidPixel - Returns the y-coordinate of the top-most solid pixel within a tile given the tile's size and the left and right boundaries of the area in question.
2. GetBottomSolidPixel - Returns the y-coordinate of the bottom-most solid pixel within a tile given the tile's size and the left and right boundaries of the area in question.
3. GetLeftSolidPixel - Returns the x-coordinate of the left-most solid pixel within a tile given the tile's size and the top and bottom boundaries of the area in question.
4. GetRightSolidPixel - Returns the x-coordinate of the right-most solid pixel within a tile given the tile's size and the top and bottom boundaries of the area in question.

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.)

1. Make sure you have all the Linux Project support files. These are delivered as a separate package because they are relatively large, and some people may not want to download the extra content if they don't plan to distribute or run their projects in Linux. See the Scrolling Game Development Kit 2 Downloads Page for details.
2. The easiest method to make a project that runs under Linux is to start with the new "Scrolling Game Development Kit Linux Sample" project listed among the available new project templates (after the Linux package has been properly installed). However, it is possible to convert existing projects to run under Linux as well. The Remaining steps will describe this process.
3. Load the project to be converted, and select <Blank> from the "Reset Source Code" pop-up menu in the file menu. If any of the framework code for the project has been modified, these modifications will be lost when resetting the source code.
4. After this is taken care of, if your project has sound, the fmodex.dll file in the Source Code folder of the SGDK2 project tree needs to be renamed to "libfmodex-4.22.01.so". This is the Linux version of the FMODEx library with which SGDK2 has been tested. To do this, open the file for editing and select the Rename command from the file menu. Renaming that file actually causes SGDK2 to pick up a different file when generating the project output. Instead of copying FMODEx.dll from the directory where SGDK2 is running, it will copy the new filename. Of course that assumes that you have to have that file available from the Linux support package.
5. Notice that after the code was reset, a new file called app.config was added to the Source Code folder in the project tree. There is one configuration setting in here that will force Mono (the Linux implementation of the .NET Framework) to re-map every request for FMODEx.dll to the new filename. If you happen to be trying a different version/name of fmod in Linux, you will need to modify this configuration file. When the project compiles, it will be copied to the output directory as Project.exe.config where Project.exe is the name of your project executable file.
6. If you are using any other unmanaged DLLs you may need to perform similar conversions for these, using FMODEx.dll as an example. Of course there needs to be a Linux version of each available.

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.