SHELLS
The 'shell' for your Ghost is their appearance.
A shell is made out of images, ideally '.png' image files.
.pngs are preferred as they are very common and support transparency well.
These images will be of any visuals you want to present in your Ghost,
including, but not limited to:
the characters, their animations, accessories, and any items they'll interact with.
Some older shells use '.pna' files to denote transparency, but that's not necessary anymore.
The images that make up your shell are called 'surfaces'.
Surfaces will have the specific file name structure of 'surface*' where * is a number.
This allows the code to parse the images properly.
Surfaces start being numbered at 0. There's an upper limit to surface numbers, but it's very high.
Surface0 and surface10 have special purposes.
0 is the main character's default surface, while 10 is a side character's default surface.
0 and 10 can be reassigned, but for most purposes, leaving them as is works fine.
TIP: You can exlude the side character, if you want.
It's recommended to make their required surface a tiny transparent image.
A transparent character can still overlap other characters, but
the \s[-1] SakuraScript tag removes the character entirely.
However, the image being small helps prevent overlapping issues in the event \s[-1] is not properly added.
Shells can be very simple, or very complex. They can also be tailored to suit your ghost's needs.
I suggest briefly taking a look at both the 'master' and 'basic' shells in CHIPS
just to get an idea of what a shell folder looks like.
BASICS
Traditionally, characters had this pattern of expressions for their surfaces:
0, Normal
1, Embarrassed
2, Surprised
3, Anxious
4, Discouraged
5, Smiling
6, Closed Eyes
7, Angry
8, Sneering
9, Embarrassed anger
25, Singing
Characters sharing the same base list of expressons made it easy for Ghosts to
respond appropriately when sent external commands.
It also was useful back when Ghosts' coding could be swapped while keeping the shell the same.
Many modern Ghosts don't follow this list, however. The shell should, above all else,
benefit the Ghost itself and its purposes.
To make life easy for you, all your images per character should be the same size.
This allows you to not have to manually and pixel-perfectly adjust the images in your code.
Think of it like using the same size sheets of paper to make a flip book.
Because you don't need to adjust each piece to fit, it saves you a lot of work.
While there is no hard size limit to each image, there is a point where SSP will begin to crash.
Thankfully, this tends to be in the upper thousands of pixels, not a common size for Ghosts.
You should also leave plenty of space around the character to fit in any animations or poses you intend to add.
It's always the worst when you crop all your images down to size,
only to try and add something later and the pose ends up all cramped.
ORGANIZATION
To actually start using your surfaces, you'll place them into the shell folder.
The default shell is the 'master' shell, and you should always have a shell with a directory named 'master'.
The surfaces in the shell folder should also be named as discussed, following the 'surface*' format.
If you take a look at the master shell bundled with CHIPS, you'll notice they have
a couple of surfaces in the 1000s, and some in single or double digits.
surface0.png
surface1.png
surface2.png...
surface10.png
surface11.png
surface12.png...
surface1001.png...
surface1101.png...
surface2001.png...
surface2201.png...
They are organized by Sakura surfaces, Kero surfaces, and surfaces used for animation.
The 1000s surfaces are used for animations that overlay on top of the Sakura's poses, 2000s for the Kero.
Even these have even further categorization, with 100* being eye animations, and 110* being talking animations.
Figuring out a system for numbering your surfaces will be important for understanding it later.
It should be clear what numbers are associated with what. Using the basic expressions earlier,
each number would be associated with a new expression.
You don't have to use a system the same as CHIPS' default,
as long as you can understand it in the future, use whatever you would like.
SURFACES.TXT
Once you've organized your surfaces and placed them, we move onto coding in SERIKO.
SERIKO is a coding language that makes up a large portion of the shell coding. The animations are all made in SERIKO.
It's not difficult to use. However, if you need to expand past replacing images,
understanding the basics of SERIKO will help.
surfaces.txt is also fairly hardy, in comparison to most code,
and will not outright fail to load in the case of most errors.
This is a double edged sword, though. Because, it is easy to end up ignoring these errors,
which may cause issues with more complicated coding.
Go ahead and open the 'surfaces.txt' file from CHIPS.
This file contains the code definitions of your surfaces.
Every surface can be defined, if you'd like.
But you only
need to define surfaces you'd like to give additional features, like animation.
A basic surface definition could look like this:
surface1
{
animation10.interval,random,4
animation10.pattern0,overlayfast,1002,50,0,0
animation10.pattern1,overlayfast,1001,100,0,0
animation10.pattern2,overlay,-1,30,0,0
}
This adds a simple blinking animation to a surface in CHIPS.
To go over this quickly,
surface1 is the surface we're defining, surface 1.
{ and
} enclose the code.
animation10 declares the line as part of animation10. Each animation is numbered to differentiate them.
interval,random,4 declares the type of interval and the rate.
random is the type, which randomly plays the animation with a chance of 1/x per second.
4 is x in the given fraction, meaning the animation will have a 1/4 chance to play every second.
pattern0 denotes this is the first frame of the animation.
overlayfast is the method used to display the image. overlayfast will not go outside the bounds of the original surface.
1002,50,0,0 are used to define specific things. 1002 is the number of the surface that will play.
50 is the delay between this frame and the last in miliseconds. are x,y pixel coordinates to adjust the image by.
TIP: You can also use multiple surfaces.txt files. Any surfaces*.txt file will be checked for surface coding.
The * can be replaced with however you'd like to organize your surfaces.txt files.
surfaces_blue.txt, surfaces_kero.txt, surfaces0-9.txt, and so on, are all acceptable.
This allows you to organize surface coding any way you wish.
To learn about more complicated commands, I highly suggest reading the
surfaces.txt entry in UkaDoc,
and reading my annotated surfaces.txt in CHIPS. I learned a lot about surfaces.txt from studying others' shells, too.
Shell Variations
A.K.A. "Help! It looks totally different!"
Cracking open the shells of others brings onto itself a whole can of worms.
What the heck is an element? Why does it look like it's written completely differently?
How does it still work?!
So, there are two different versions of SERIKO syntax.
The one used in CHIPS and many newer English Ghosts is (descriptively) "new definition".
This is the one taught up above. But there is also "old definiton", which is not uncommon either.
It looks like this:
surface0
{
element0,overlay,surface0.png,0,0
//--Blinking---------------------------------------------------------------------------
0interval,random,4
0pattern0,-1,10,overlay,0,0
0pattern1,1002,5,overlayfast,0,0
0pattern2,1001,10,overlayfast,0,0
0pattern3,-1,3,overlay,0,0
}
//Excerpt from the GT template.
Fundamentally, it is very similar to new def.
The functional difference (besides how it is written) is that the delay is measured in 10 miliseconds, instead of 1.
A grandfathered in habit of using redundant elements is also a common sight.
"element0,overlay,surface0.png,0,0" serves little to no purpose by itself when used in the definiton of surface0.
The intended use of elements is for creating new base images by combining multiple images together.
The new base image will be comprised of multiple elements with their respective drawing methods.
However, by default... surfaces
already use the image they're numbered as, as their base image.
So, creating an element which defines this is unnecessary. All it serves to do is replace the base image with... the base image.
Pretty funny, huh? We've come quite far in our understanding of Ghosts.
DESCRIPT.TXT
descript.txt can be a bit of a strange file to work with.
It handles more than the SHIORI-side descript.txt does.
What I want to touch on are the ways you can customize your shell using descript.txt.
The main two pieces of customization, when it comes to descript.txt, are the menu and the dress-ups.
The menu is brought up by right-clicking the Ghost, and its visuals are coded entirely within descript.txt.
The text itself can be changed in the Ghost, but the text
color and menu colors are determined by the shell.
Dress-ups are a whole beast within themselves, so I'll leave them for last.
Options
To change various attributes about the menu, you should open descript.txt.
This is another file which is, frankly, a pain to set up on your own. So, I suggest starting with CHIPS or another template.
Once there, you'll see various options, including many color options and an option to set an image as the background to the menu.
You'll also set options related to the positioning of the Ghost, their balloons, and how you'd like to be credited.
This is also where you would change the default surface settings, if you wanted to do so.
All of what you'd want these to be set to relies heavily on the functionality of your Ghost, so unfortunately I can't walk you through it much.
The annotated descript.txt file does a good job of describing what each setting does, however.
The UkaDoc entry for
descript.txt is also very helpful,
as it documents all the different settings you can change.
DRESS-UPS
Dress-ups are a method of adding different options for the User to select from in the shell.
The coding for dress-ups is also called MAYUNA.
They're one of those things I struggled with for a long time in Ghosts.
They require more work on both the planning and drawing end,
and some know-how with both surfaces.txt and descript.txt.
Dress-ups are technically an animation, in coding terms.
But, in the original implementation, they are immediately flattened, and so need some finagling to be animated.
Because of this, dress-ups are best suited to stationary or rarely moving items.
Clothing, accessories, or other such things are the intentional use case for dress-ups, hence the name.
To explain a bit why dress-ups can be so time consuming...
any time your dress-up would move, you must draw it a new surface, and code it to apply to the new positioning accordingly.
My Ghost, Snake and Otacon, have quite a few dress-ups, and their shell took me forever to do!
They have fairly minimal movement, but because I decided to completely change their outfits with each dressup,
I had to draw and code their default surfaces about four times. That's just their outfits, not their hair or other dressups, either!
This isn't to scare you, but more to point out why dress-ups can be fairly rare or simplistic.
Having coded quite a few myself, now, I appreciate what folks put into it.
If you do decide to create dress-ups, the UkaDoc
dress-up section
of surfaces.txt will be invaluable. It explains it much better than I can.
I also highly reccomend the
dress-up portion of the GT Walkthrough, by Zarla.
It uses the old definition of SERIKO/MAYUNA, but her explanation can be very helpful to put things in layman's terms. I still reference it sometimes today.
GLOSSARY
| Term |
Definition |
| shell |
The appearance for a Ghost. Multiple shells can be created for one Ghost. |
| surface |
The base images and poses which make up a shell. |
| master shell |
The default shell for a Ghost. A Ghost should always have a shell folder named 'master'. |
| SERIKO |
Coding language for shells. |
| surfaces.txt |
The text file(s) SERIKO coding is read from. |
| descript.txt |
The text file various options about the shell are determined in. |
| dressup |
Additional shell options for a Ghost within the shell itself. Often accessories, but not always. |