Difference between revisions of "Introduction to Modding"

From Open Surge Engine Wiki
Jump to: navigation, search
(Created page with '===Modding=== Open Surge is a game developed to allow user created content as much as possible. The modding scene has been around since the early 90's when people hacked games, f…')
 
Line 1: Line 1:
 
===Modding===
 
===Modding===
 
Open Surge is a game developed to allow user created content as much as possible. The modding scene has been around since the early 90's when people hacked games, found out how the content was generated and substituted it's content with their own.
 
Open Surge is a game developed to allow user created content as much as possible. The modding scene has been around since the early 90's when people hacked games, found out how the content was generated and substituted it's content with their own.
 +
 +
In Open Surge, it is fairly easy to modify any game content you wish.  It ranges in difficulty from replacing sprite files and adding images to actually modifying the source code to add functionality to the engine.
 +
 +
 +
== To Begin ==
 +
Lets start by learning a little about how Open Surge reads data from your images so that it can be displayed in-game.  To do this, we will look at the ring sprite file included with the game.
 +
...
 +
// Ring
 +
sprite SD_RING
 +
{
 +
    source_file    images/rings.png
 +
    source_rect    0 128 176 16
 +
    frame_size      16 16
 +
    hot_spot        8 12
 +
 +
    // spinning
 +
    animation 0
 +
    {
 +
        repeat      TRUE
 +
        fps        16
 +
        data        0 1 2 3 4 5 6 7
 +
    }
 +
 +
    // disappearing
 +
    animation 1
 +
    {
 +
        repeat      FALSE
 +
        fps        8
 +
        data        8 9 10
 +
    }
 +
}
 +
...
 +
In the above file, there are several things you will notice:
 +
1. there are lines that begin with //, these lines are there merely for your convince and are ignored by the engine.
 +
2. '''source_file''': This is where the image you are reading from is located.  The engine assumes that images are located somewhere in the game directory folder, so you do not need to specify the full file path.  Instead, you just have to specify where the images are located in the game folder.
 +
3. '''source_rect''': The first two numbers give the X and Y coordinate of the top left corner of the image you are defining.  The second two numbers give how big of a rectangle it would take to completely enclose every frame of the animation.
 +
4. '''frame_size''': Defines the size of each frame of your animation.  In this instance, the size of the source rectangle is 176 by 16, but each piece of the animation is only 16 by 16.
 +
5. '''hot_spot''': This is the place which the engine will use to determine the x and y position of your object.  It also is the place where the level editor grabs your object when you select it.  There are different reasons for placing hotspots in different places, however it is mostly a matter of preference.
 +
6. '''animations''': These are what your object will do in the game.  There are basically three different things that animations need to be fully defined.
 +
a) '''repeat''': this tells the engine if you want it to keep doing the animation as long as it is the selected one.  In this case, while the ring is inactive it will continuously spin because  repeat is set to TRUE, but when it touches a player and the animation changes to 1 it will play the animation 1 time and disappear.
 +
b) '''fps''': This defines how fast the engine will cycle through your frames.  In this case it plays 16 frames every second for animation 0 and 8 for animation 1.
 +
c) '''data''': This defines which frame you want to play at any particular moment.  In this case it plays frames 0-7 and then repeats under animation 0, and plays frames 8-10 and doesn't repeat under animation 1.
 +
 +
Now that we've examined a sprite file and determined what each of the components do, we'll modify it so that we replace the standard rings in the game with our own. 
 +
'''Warning: Changing sprite files makes a major change to the game.  Make sure to backup your sprite files before you change them so if something goes wrong you will be able to restore the original functionality to the game.'''
 +
 +
Below, I will provide a sprite which I wrote to include my own ring design in-game.  Afterward we will examine how my sprite differs from the original.
 +
...
 +
/ Ring
 +
sprite SD_RING
 +
{
 +
    source_file    images/collectables.png
 +
    source_rect    1 1 176 16
 +
    frame_size      16 16
 +
    hot_spot        9 12
 +
 +
    // idle
 +
    animation 0
 +
    {
 +
        repeat      TRUE
 +
        fps        16
 +
        data        0 1 2 3 4 5 2 6
 +
    }
 +
 +
    // end
 +
    animation 1
 +
    {
 +
        repeat      FALSE
 +
        fps        8
 +
        data        7 8 9 10
 +
    }
 +
}
 +
...
 +
Here are some things you should notice right off the bat:
 +
1. I use different lines that start with //, because they help me keep track of what my sprite is doing.  Remember, these are entirely up to the individual user and aren't required.
 +
2. The source_file is different, this is because I have created an image and it has a different file-name than the original.
 +
3. The source_rect is different, this is because my images are at a different location inside my image than the originals were.
 +
4. The frame_size is the same, this is because I used a standard size rectangle to create my rings so that they can seamlessly replace the built in rings.
 +
5. The hot_spot is the same, this is because I didn't see any need to change this from what it already was.
 +
6. The repeats are set to the same values, this is because my ring acts similar to the original.
 +
7. The fps is the same, this could be modified if I wanted to speed up or slow down the animation.
 +
8. The data is different, this is because my frames must be presented in a different order to be a complete animation.
 +
9. sprite SD_RING(located at the top) remains the same.  This is so I don't have to modify any game code to replace all rings with my rings.  It also means that I have to remove the old sprite definitions from my sprites folder so that the engine doesn't try to define what a ring is twice.
 +
 +
'''More Coming Soon'''

Revision as of 18:43, 13 January 2011

Modding

Open Surge is a game developed to allow user created content as much as possible. The modding scene has been around since the early 90's when people hacked games, found out how the content was generated and substituted it's content with their own.

In Open Surge, it is fairly easy to modify any game content you wish. It ranges in difficulty from replacing sprite files and adding images to actually modifying the source code to add functionality to the engine.


To Begin

Lets start by learning a little about how Open Surge reads data from your images so that it can be displayed in-game. To do this, we will look at the ring sprite file included with the game.

...

// Ring sprite SD_RING {

   source_file     images/rings.png
   source_rect     0 128 176 16
   frame_size      16 16
   hot_spot        8 12
   // spinning
   animation 0
   {
       repeat      TRUE
       fps         16
       data        0 1 2 3 4 5 6 7
   }
   // disappearing
   animation 1
   {
       repeat      FALSE
       fps         8
       data        8 9 10
   }

}

...

In the above file, there are several things you will notice: 1. there are lines that begin with //, these lines are there merely for your convince and are ignored by the engine. 2. source_file: This is where the image you are reading from is located. The engine assumes that images are located somewhere in the game directory folder, so you do not need to specify the full file path. Instead, you just have to specify where the images are located in the game folder. 3. source_rect: The first two numbers give the X and Y coordinate of the top left corner of the image you are defining. The second two numbers give how big of a rectangle it would take to completely enclose every frame of the animation. 4. frame_size: Defines the size of each frame of your animation. In this instance, the size of the source rectangle is 176 by 16, but each piece of the animation is only 16 by 16. 5. hot_spot: This is the place which the engine will use to determine the x and y position of your object. It also is the place where the level editor grabs your object when you select it. There are different reasons for placing hotspots in different places, however it is mostly a matter of preference. 6. animations: These are what your object will do in the game. There are basically three different things that animations need to be fully defined. a) repeat: this tells the engine if you want it to keep doing the animation as long as it is the selected one. In this case, while the ring is inactive it will continuously spin because repeat is set to TRUE, but when it touches a player and the animation changes to 1 it will play the animation 1 time and disappear. b) fps: This defines how fast the engine will cycle through your frames. In this case it plays 16 frames every second for animation 0 and 8 for animation 1. c) data: This defines which frame you want to play at any particular moment. In this case it plays frames 0-7 and then repeats under animation 0, and plays frames 8-10 and doesn't repeat under animation 1.

Now that we've examined a sprite file and determined what each of the components do, we'll modify it so that we replace the standard rings in the game with our own. Warning: Changing sprite files makes a major change to the game. Make sure to backup your sprite files before you change them so if something goes wrong you will be able to restore the original functionality to the game.

Below, I will provide a sprite which I wrote to include my own ring design in-game. Afterward we will examine how my sprite differs from the original.

...

/ Ring sprite SD_RING {

   source_file     images/collectables.png
   source_rect     1 1 176 16
   frame_size      16 16
   hot_spot        9 12
   // idle
   animation 0
   {
       repeat      TRUE
       fps         16
       data        0 1 2 3 4 5 2 6
   }
   // end
   animation 1
   {
       repeat      FALSE
       fps         8
       data        7 8 9 10
   }

}

...

Here are some things you should notice right off the bat: 1. I use different lines that start with //, because they help me keep track of what my sprite is doing. Remember, these are entirely up to the individual user and aren't required. 2. The source_file is different, this is because I have created an image and it has a different file-name than the original. 3. The source_rect is different, this is because my images are at a different location inside my image than the originals were. 4. The frame_size is the same, this is because I used a standard size rectangle to create my rings so that they can seamlessly replace the built in rings. 5. The hot_spot is the same, this is because I didn't see any need to change this from what it already was. 6. The repeats are set to the same values, this is because my ring acts similar to the original. 7. The fps is the same, this could be modified if I wanted to speed up or slow down the animation. 8. The data is different, this is because my frames must be presented in a different order to be a complete animation. 9. sprite SD_RING(located at the top) remains the same. This is so I don't have to modify any game code to replace all rings with my rings. It also means that I have to remove the old sprite definitions from my sprites folder so that the engine doesn't try to define what a ring is twice.

More Coming Soon