Better Than the Worst:
A Newbie’s Guide to Sidestepping Ridicule
The 2008 Revival
Appendix

By Jeremy Bursey (Pepsi Ranger)

The following article addresses design methods I found helpful during my own game making process. Some may feature the long way around a topic. Some will be right on target. None offer a “correct” way of doing things in the absolute sense, mind you, but each works, or did for me. Plenty of OHR users have their own way of doing things, too, and nearly all will be happy to share their ideas. If you want to know something that isn’t addressed here, though, ask other game designers for advice on how to implement what you’re going for. If you think something you find here could be implemented an easier way, feel free to discuss it in a related forum topic. Again, these are just examples of my own game-making journey. Nothing said here has to be concrete for your own experience. The goal is to help game designers think outside the box while presenting simple methods to achieving extraordinary things. Though newbies will benefit from the simplistic approach this article produces, old timers will simply find a reason to try new things again. So with that, let’s get started.

One NPC for Multiple Tasks:

Anyone who played my games (specifically The Adventures of Powerstick Man) will know that I like using interactive scenery. This means allowing players to activate televisions, books, paintings on the wall, and bulletin boards to name some things. In the past I’d assign unique invisible NPCs to various object types to individualize each object (the player could read four different messages on a wall and have each one saying something different, for example). But this meant my storage space for NPCs quickly vanished, as the marriage of people and objects on one map consumed a monster of space.

Thanks to simple plotscripting commands like “set variable” and “hero x,” however, all my interactive objects can be assigned to one NPC.

Let’s say there are eight bulletins populating an office block. Each one says something different. Instead of assigning them to eight NPCs with individual text references, I can just create a plotscript identifying which bulletin the player is reading and have it initiate the appropriate message. To do this, I just use an “x” and “y” variable, “set variable” to “hero x” and “hero y” and use “if/then” statements to “show text box” if the player is standing at a certain coordinate (whichever one faces the particular bulletin).

Or if that’s confusing, thanks to the “quotations,” read the following plotscript to better understand the process:

variable (x)
variable (y)
set variable (x,hero x (0))
set variable (y,hero y (0))
if ((x==10),and,(y==31)) then(
show text box (234)
wait for text box
)
if ((x==23),and,(y==12)) then(
show text box (235)
wait for text box
)
end

Or let’s say I have a village populated with several guards, each wandering the streets, but all sharing the same walkabout picture. It might make sense to assign them all to different NPC slots with unique lines of dialogue (as opposed to one NPC saying the same line of dialogue in several different instances), but it would make more sense to assign them to the same NPC slot with randomly generated lines of dialogue.

In this case, instead of using coordinate-checking devices like “hero x,” etc., I’ll want to set a unique variable to produce a “random” number; then have the if/then conditional show a text box that links to the number that pops up.

variable (t)
set variable (t,random (1,2))
if (t==1) then(
show text box (234)
wait for text box
)
if (t==2) then(
show text box (235)
wait for text box
)
end

When you implement a plotscript that allows one NPC to say a number of things, depending on applicable conditions, you can stretch the life of your village, dungeon, etc. to levels beyond the ordinary. And that’s just one way to make your game better than the worst.

Universal Tags:

Consult Part Four for ideas how I use these.

Sprite Animation:

Perhaps my biggest method of character immersion can be found in the form of sprite animation. Instead of telling the player what happens, or even leaving it up to his imagination, I tend to show things in detail. This includes watching the hero shoving a character into a lake, seeing a character transform into a ship, or even displaying a detailed account of an NPC blowing up a wall. Where most games skip the transitional character frames and jump right to the conclusion (the NPC walks to the wall and the wall “disappears”), I like to give my characters some life. It’s my way of thanking the player for playing my game.

In Part Five, I addressed the issue of laziness. And I can tell you that animation is the worst place for laziness to thrive. There’s a lot of work involved in drawing individual frames for sprites and it’s compounded when that NPC is supposed to swing a bat at some point. The standard set of eight frames (North, East, South, West directions) can become sixteen, twenty-four, or however many it takes to show the character throwing a ball into the air and hitting it with a bat. That’s why you shouldn’t be making a game if you’re lazy. This stuff makes your game better, and you’re not gonna do it if you “don’t feel like it.”

But in case you do want to try it, here’s how:

You need to first draw all relevant frames for the given animation in the walkabout sprite editor. This will often spill over into multiple sets. That’s fine if it does; I’ll address that in a moment. When you’re done, you need to find your starting frame. Theoretically that should be “north, zero,” but you can start wherever you want. I always start an animation fresh.

This is where you begin scripting.

There are four plotscripting commands you need to know to get your NPC animating and several others if you want it animating without interference. The first one is the most dangerous.

“Alter NPC” is one of the most important commands in my arsenal. With this command I can transform the entire infrastructure of a single NPC from a walking guard to a step on event trigger. And while I rarely need to change such important aspects like “activation type” and “pushability codes,” I do find myself altering NPC pictures quite often to give my animations more detail.

The command is dangerous because it can wreck the very presentation of your NPC if you input the wrong thing. Therefore, it’s important to learn its uses before you get too crazy with it.

For the sake of this article, I’ll use it as an appearance changer. Let’s say the NPC I want to animate (ID of “3”) uses Walkabout Set 193 as its default movement set. I’ll need to remember this number when the animation is finished. The animation sequence that shows him throwing the ball in the air and hitting it with a bat uses Set 194 and 195 respectively. To get him to animate, I must first alter his appearance to show Set 194 (the starting set).

Before I do this, it’s a good idea to make sure I have control of him. If he’s moving, I’ll either need to “Suspend NPCs” or change his movement type to “Standstill.” The second method is better if he’s the only one that should be stopped.

Once I suspend NPCs, I’ll need to alter his appearance using the line:

alternpc (3,npcstat:picture,194)

By using this line, I just changed his picture set from his standard walkabout to his first set of animating frames. But it doesn’t mean he’s ready to start. First, I have to get him in position.

Since I tend to start my animations from the “north, zero” slot (the far left box in the sprite editor), I’ll want to set the NPC’s direction to “north” and his frame to “0.” Now he’ll be in position:

alternpc (3,npcstat:picture,194)
set npc direction (3,north)
set npc frame (3,0)

Okay, so now we see the opening frame of his baseball animation. What next? Why we change the frame to “1,” right? Wrong. First he have to initiate a “wait” command. Without a wait command, the script will just keep cycling through frames and directions until it reaches the end without ever showing us the frames leading up to the last (though it’ll show the last because that’s the one it ends on). When we put a “wait” command in there, it tells the script to pause just long enough to show the given frame. Once the wait command is written into the script, we can add the next frame, the next direction, etc. I usually tell the script to wait 2 ticks between transitional frames and 5 ticks on ending frames.

alternpc (3,npcstat:picture,194)
set npc direction (3,north)
set npc frame (3,0)
wait (2)
set npc frame (3,1)
wait (2)
set npc direction (3,east)
set npc frame (3,0)
wait (2)
set npc frame (3,1)
wait (2)
.
.
.
alternpc (3,npcstat:picture,195)
set npc direction (3,north)
set npc frame (3,0)
wait (2)
set npc frame (3,1)
wait (2)

When we get to the end of the animation (notice that we’re on Set 195 now), we’ll want to return the NPC to normal. That’ll mean reverting it back to Set 193 via “Alter NPC” after the last wait command’s issued and then return it to whatever direction it was facing when the first change happened.

If the NPC is moving before the script alters it, you’ll want to “set variable” to “NPC direction” before starting the animation. Then, for continuity’s sake, set the direction back to the variable when the script is over.

suspend npcs
variable (d)
set variable (d,npc direction (3))
alternpc (3,npcstat:picture,194)
set npc direction (3,north)
set npc frame (3,0)
wait (2)
set npc frame (3,1)
wait (2)
.
.
.
alternpc (3,npcstat:picture,195)
set npc direction (3,north)
set npc frame (3,0)
wait (2)
set npc frame (3,1)
wait (2)
.
.
.
set npc direction (3,west)
set npc frame (3,0)
wait (2)
set npc frame (3,1)
wait (5)
alternpc (3,npcstat:picture,193)
set npc direction (3,d)
set npc frame (3,0)
resume npcs
end

If you’d rather stop one NPC from moving than all of them, you can alter the NPCs movetype to “Standstill.” According to the Plotscript Dictionary, “Standstill” uses move code “0” while “Wander” uses “1.” Remember this when deciding what your NPC should do in the script.

alternpc (3,npcstat:movetype,0) #standstill
alternpc (3,npcstat:movetype,1) #wander

If you make a wandering NPC stand still before starting an animation sequence, be sure to change him back to “wander” when you’re finished.

Note: if you want to do all of this with a hero, use the command “set hero picture (hero, picture)” instead of Alter NPC.

Timers:

Perhaps you want to do something like what I did with the chain-smoking mayor in Part Five. You like the idea of adding life to wandering NPCs, but don’t know how to “automate” them. Well, there are two methods. The first one, the one I used for the mayor, requires the use of timers.

Now, timers are an amazing addition to the plotscript dictionary. You can set up pretty much any event you want to launch at the end of a countdown. The chain-smoking mayor is one example. Through timers I have him doing three things: lighting the cigarette, smoking the cigarette, and stamping it out.

set timer (4,60,18,@cigarette)
set timer (5,15,18,@smoking)

Notice there are two timers at work here. The first one regulates when he lights the cigarette (first pulling a new one out of his pocket) and when he stamps it out. The second one regulates how often he takes a drag while the cigarette is lit. If you break down the position of the numbers, you’ll see that “4” and “5” are the timer numbers, the “18” is the number of ticks per cycle (which makes each cycle one second long), and the “60” and “15” are the number of seconds that pass before the NPC changes animation. The last part is the script that runs when the timer expires.

Timers also have additional arguments that can launch during battles, but this particular exercise doesn’t need them.

So how do we get these timers going?

First off, we need a base script to launch them from. The script I’m using checks the direction the hero is standing when passing over the event trigger. Since the trigger (a step on NPC) sets near the map’s exit, I have the script estimate whether the hero is coming or going. If he’s coming in, the timer will start, if he’s about to leave, the timer will stop.

script,Smoking Mayor,begin
variable (x)
variable (d)
set variable (x,hero x (0))
set variable (d,hero direction (0))
if (x==22) then(
if (d==west) then(
set timer (4,60,18,@cigarette)
set timer (5,15,18,@smoking)
)
if ((d==east),or,(d==south)) then(
stop timer (4)
stop timer (5)
)
)
if (x==24) then(
if (d==east) then(
set timer (4,60,18,@cigarette)
set timer (5,15,18,@smoking)
)
if ((d==west),or,(d==south)) then(
stop timer (4)
stop timer (5)
)
)
Hotel Maid
end

Notice also the script uses multiple if/then commands in the same beat. This keeps all relevant script responses grouped to the same launch source. This is important if you want to prevent the script from doing crazy things to your game.

On a side note, if you’re wondering why I have a script called “Hotel Maid” launching at the bottom of this one, it’s because I want all relevant scripts (the NPC automation scripts) triggering at the same time. As of this writing, the housekeeper is the only other automated NPC in this particular area, but I’ll probably have a guy who wanders from room to room in there, too, by the time this is published. His script will launch after the housekeeper’s launches to keep everyone together, so the above script is technically incomplete. Veteran OHR users already know the importance of grouping scripts together in a single launch source, but newbies don’t so I thought this bears mentioning. (Actually, the above script is technically wrong as “Smoking Mayor,” “Hotel Maid,” and future character scripts of its type should all fit under a master launch script, not just stacked with “Smoking Mayor.” But I’m not worried about it since it all works the same.)

Now, with what do we fill the timer scripts? If we go back to the NPC animation example, we’ll discover that the “cigarette” and “smoking” plotscripts are quite similar. But alas, since timers can be tricky, some extra stuff beyond mere animation has to be considered.

First off, we want to make sure the timer only manipulates the NPC on this map. Therefore, we have to set a variable to check the “current map.”

script,cigarette,begin
variable (m)
variable (n)
set variable (m,current map)
if (m==60) then(
.
.
.
)
end

This is important because the timer’s sometimes slow on the draw when it comes to stopping and could miss its chance to turn off before the player enters another map. If this happens, the risk is high that the wrong NPC could be “smoking.” We want to keep the timers relevant to the current map only.

Once we’ve established the map conditional is correct, we can have the script check whether the NPC is holding the cigarette. We’ll need to use a new command—the counterpart to “Alter NPC” called “Read NPC”—to do this.

Now that we know how to use “Alter NPC” and “set variable,” using “Read NPC” should be a breeze. In my script, it looks like this:

if (m==60) then(
set variable (n,read npc (12,npcstat:picture))
if (n==359) then(
.
.
.
)
end

Notice how the command following the “Read NPC” is another if/then statement? That’s because we want the script to identify how the NPC looks. In this case, the standard (nonsmoking) version of the Mayor of Primex uses Walkabout Set 359 as its default, and the script needs to know this because it needs to know whether to have the mayor light up or have him stamp the cigarette out. Obviously, he can’t stamp something he’s not holding (or drops), so we have to get him to remove it from his pocket before he can go through the smoking process and successive stamp. Everything to follow the read NPC conditional is an animation script showing the mayor preparing his cigarette for consumption (including the use of an altering move type).

At the end of the first if/then statement, another one follows, this time the if/then for the smoking default set. The same sequence applies, but with a different alter NPC picture at the end of the conditional.

if (m==60) then(
set variable (n,read npc (12,npcstat:picture))
if (n==359) then(
alter npc (12,npcstat:movetype,0)
set npc direction (12,south)
wait (5)
alter npc (12,npcstat:picture,361)
set npc direction (12,north)
set npc frame (12,0)
wait (2)
set npc frame (12,1)
wait (2)
.
.
.
alter npc (12,npcstat:picture,360)
set npc direction (12,south)
set npc frame (12,0)
wait (5)
alter npc (12,npcstat:movetype,1)
)
if (n==360) then(
alter npc (12,npcstat:movetype,0)
set npc direction (12,south)
wait (5)
alter npc (12,npcstat:picture,364)
set npc direction (12,north)
set npc frame (12,0)
wait (2)
set npc frame (12,1)
wait (2)
.
.
.
alter npc (12,npcstat:picture,359)
set npc direction (12,south)
set npc frame (12,0)
wait (5)
alter npc (12,npcstat:movetype,1)
)
set timer (4,60,18,@cigarette)
)
end

Did you see how the script ended? Yep, there’s another “set timer” command sandwiched between two ending parentheses. You’ll always want to do this if you want a timer to start again when it expires. Without it, the mayor might light up, but he’ll never stamp it out.

Here’s something else to consider. The main script uses two conditionals back to back. Considering both conditionals change the NPC’s appearance and that both launch a different animation depending on what picture Read NPC finds, we run the danger of the main script launching both animations back to back. For this reason we have to remember to leave the “set variable” outside the parentheses. We only want the timer to set it once per execution.

The second timer, the one that initiates the NPC taking a drag, works the same way as the first. However, it only checks for the NPC’s “smoker” appearance and executes the animation every fifteen seconds if the conditional is true.

Automated Loops:

The second method for automating NPCs works similar to the first, but uses “while/do” or “for/do” commands instead of timers. Normally, under the conditions I’ll present in the following paragraphs, while/do is the better choice. But since I’m bad at ending while/do commands that don’t involve “key is pressed” scancodes, I’ll stick with what I know and that’s for/do commands.

First off, to use a for/do command, you need to set aside a variable. That variable will always be used to initiate the launch cycle.

variable (i)
for (i,1,5) do(
.
.
.
)
end

Once you start the for/do command, everything that happens between the parentheses will happen as many times as the following two numbers determine. In this case, the cycle will run five times.

Of course, because for/do commands expire after the last cycle finishes, you always run the risk of automated NPCs getting “stuck” in one mode if the number runs out before the player leaves the area. For this reason, it’s better to master “while/do,” as that only runs out when you tell it to. But for now I’m just gonna tell you to run the for/do cycle at least a thousand times. It’s unlikely a player will hang out in that same place for that long anyway.

Now, it’s important to decide what’s happens in that cycle. Since we want the housekeeper to interact with certain objects as she gets close to them, we’ll need the script to check her location every few ticks.

script,Hotel Maid,begin
variable (x)
variable (y)
variable (d)
variable (m)
variable (i)
variable (j)
for (i,1,1000) do(
set variable (x,npc x (18))
set variable (y,npc y (18))
set variable (d,npc direction (18))
set variable (m,current map)
if (m==60) then(
if ((x==17),and,(y==81)) then(
if (d==west) then(
.
.
.
end

As you can see, this method requires a number of variables to set. Let’s break it down:

First, we have the usual coordinate, direction, and map variables to consider. All four conditionals must be addressed each time the cycle is run; therefore, all must be within the for/do block. Perhaps most important in this regard is the “current map” check. If that variable isn’t set and checked every cycle, you’ll inevitably cause an NPC with the same ID number to do weird things on other maps. Since the for/do doesn’t stop until it runs out (or until you initiate an “exit script” command through another conditional—a variable that doesn’t match Map 60, for example), this problem will happen if the current map variable is set outside the block. Do not forget this.

Also important, but not as damaging to your other NPCs, is the need to check for positioning and direction. According to the script above, the housekeeper (NPC 18) has to be standing at coordinate 17,81 facing west (the floor tile next to the table with the lamp on top in the picture in Part Five) before she’ll spray her wood cleaner and polish the table. If all four conditions are met, a sequence similar to the mayor’s smoking animation will play out. The script also instructs her to do other things at different spots around the map, but there’s no need to get into that. It all works the same.

The only other thing to keep in mind about this method (besides ensuring that all conditionals receive closing a parenthesis) is how to end it. Figure the animation will run each time the four conditionals are met, but the condition won’t always be met. And well, since we’re being realistic here, something has to happen once the animation is finished. Since we don’t want that ending to be a rapid fire countdown to expiration (something that’ll happen way too fast if the conditionals keep coming back false), we’ll want to treat it like an animating frame and add a “wait” command at the end.

alter npc (18,npcstat:movetype,1)
)))
wait (5)
)
end

I set mine at “5” so it gives the script ample time to check the housekeeper’s position at every tile (especially the ones that satisfy the condition), but keeps it slow enough that it won’t tear through the cycle before the player leaves the area.

It also benefits to know that wait/do commands need a wait command at the end of the script in order to work. So if you should you try the NPC automation method with that, don’t forget to wait.

Now that you know two methods to automating NPCs, there’s no excuse for not using them. We can add a lot more personality to our games if we give them a try.

Extended Tile Animations:

Sometimes animating a character isn’t enough. Sometimes to get the sequence you want you have to manually animate maptiles. And though the idea of physically altering a scene through plotscript seems daunting, the execution is very easy—I do it in cut scenes all the time, from blowing up walls to opening trapdoors—and the effect is often cool. If you want to take advantage of plotscripted tile animations, here’s how:

First you need to know what you want. Do you want a one-time animation (like opening a trapdoor), or do you want a cycling animation (like a six-frame lava tile spitting a geyser every few seconds)? Once you’ve decided what you want, the implementation is easy.

Before you actually script the animations, you have to first know which commands will do it.

To physically change tile appearance, you’ll need to use “write map block” and “write pass block.” The first one identifies the specific coordinate and tile number (in three convenient arguments). The second identifies how the hero interacts with it (is it passable on any given side?). Both need consideration before altering anything.

write map block (3,7,12,0)
write pass block (3,7,0)

Now let’s examine what each number means. In the first line, for writing the map block, we see four numbers. The first is the “x” tile, the second “y.” Pretty easy, right? But what about the third? Clearly there’s no “z” tile in a two-dimensional game, so what could it mean? Why, that’s the tile number, of course. If you hit Enter while in tile mode, you can see the tileset you’re using.

Finding the corresponding number to a tile is probably the worst part about this feature. It means you have to start counting lines. The easiest way to do that is to remember that each new line starts with a denominator of 16. Therefore, the first line starts at 0, the second, 16, the third, 32, etc. until you reach 159. From there, you just count.

If for some odd reason you want to replace the old one with an animating tile (the kind you have to set with a defined range), then you need to find where the given animation range starts and label the first tile 160. If the new tile falls into the second range, then the first line (in that range) starts with 208.

The last number in the argument line is reserved for layers. Usually this defaults to zero, but if you’re dead set on changing that plant tile to a refrigerator, then you’ll want to write “1” (if your object tiles stand alone on Layer 1).

In the second line, for pass blocks, the arguments are reserved for “x,” “y,” and “bitset.” The bitset is the argument that decides whether the tile gets a north wall, south wall, east wall, west wall, overhead, damage response, vehicle trail, or nothing at all. For the bitset numbers, it’s better to consult the plotscript dictionary, but the overview is that the bitsets can be written out as constants. If you want the tile fully passable, write “0” in the last argument.

Okay, so now we know how to change the tile in plotscript. But how do we make it animate with other tiles? It’s easy. We do it with “wait” commands.

write map block (3,7,12,0)
wait (3)
write map block (3,7,13,0)
wait (3)
write map block (3,7,14,0)
wait (3)
write map block (3,7,15,0)
wait (3)
write map block (3,7,16,0)
write pass block (3,7,0)
wait (3)
end

In looking at the script above you may notice there are five instances of maptiles animating. The space for defining tile animation by default only has room for four. Therefore, by using this plotscripting method, you can create elaborate animations that are not readily achieved in CUSTOM.

This is especially true for cyclical animations, like water tiles.

Let’s say your water tile is supposed to fling waves in random directions. If you’re defaulting to a normal three-tile animation, you probably won’t get the effect you want. Therefore, you need to create a looping script to encompass your series of tiles. “While/do” and “for/do” commands like the one in the housekeeper example both work in this case.

But there’s a catch: there must be a “current map” variable written into the script, and it must be executed at the beginning of each cycle (hence the declaration needs to be inside the loop). Otherwise your water tile will turn your building in the next map into animated garbage. Don’t forget to implement it.

If for any reason you want to animate multiple tiles of the same type using the elaborate system, you’ll also want to set a variable for “x,y” coordinates and have them update by one in a loop inside the loop.

variable (x)
variable (y)
variable (m)
variable (b)
variable (i)
variable (j)
set variable (x,3)
set variable (y,7)
set variable (b,12)
for (i,1,5) do(
set variable (m,current map)
if (m==3) then(
for (j,1,20) do(
write map block (x,y,b)
set variable (x,x+1)
)
wait (2)
set variable (b,b+1)
)
)
end 

It’s a bit confusing at first, but if you study the position of each line (and parenthesis), you’ll see that the “set variables” outside the “for/do” blocks decide where the first block will be written, while everything in the “j” block writes a horizontal chain of new tiles 20 deep (all at once, as it doesn’t wait), and everything in the “i” block (which houses the “j” block) tells the script to write a new tile to the horizontal chain five times.

If you want to create a whole new ocean, you’ll need to implement a separate chain for “y” lines, too. Hopefully you can grasp the structure well enough to figure out how that fits.

Each Step Tile Changing:

Perhaps you just want to alter tiles as the hero passes them (like making footprints), but you only want them to affect certain types of terrain. This is where “read map block” and the Each-Step plotscript trigger come into play.

This is actually very easy. The foundation works much like the extended animation trick, but without the wait ticks. Instead of just writing map blocks to a script, though, you’ll first need to find out what kind of tile the hero is stepping on.

Let’s say the tile you want affected is the sand tile. First, you need to identify the corresponding number for the sand tile. For the sake of this exercise we’ll pretend it’s 4.

Next, we need to write in the standard variable check for a hero’s position. I’ll assume you’re well familiar with that by now.

Now you’ll need to implement the new command “read map block.” To do that, you must first set aside a new variable to manipulate.

variable (x)
variable (y)
variable (r)
set variable (x,hero x (0))
set variable (y,hero y (0))
set variable (r,read map block (x,y,0))

Notice how the new command fits into a “set variable” block? Most “read” commands only work as variable setters—something to remember for your later experiments. Did you also see the arguments attached? I left the “x,y” coordinates as variables because we want the script to check each tile the hero stands on for each step. The “0” signifies the layer.

Remember the sand tile’s number? Now we’ll want to script it as an if/then trigger.

if (r==4) then(
.
.
.
)
end

This checks if the hero is standing on the sand tile or something else. As you know by now, if he’s standing on the correct tile, the stuff inside the parentheses will trigger. In this case we have to assume it’s writing a new block to the “x,y” slot.

Before you call the script complete, you’ll also want to add another conditional to consider hero direction; then write whichever footprint tile matches the physics. You’ll get particularly friendly with copy/paste in these instances.

Once everything fits to your liking, attach it to the map’s Each Step script trigger and give it a run. You’ll be “oohing” in no time.

Ticking Clocks:

Perhaps you’re interested in the idea of putting clocks in your game that match real time? Well, if you weren’t a minute ago, you might be now.

This is actually a tedious quest if you want to know the truth, but easy to script once the graphical legwork is finished. First you need to draw sprites for multiple hand positions. To give you an idea what this means, I drew twelve hours worth of hand positions for Powerstick Man V2 at five minutes each. That translates to roughly 144 sprites. Tedious, yes, but now I have a working clock in my game.

To display the right time, you first need to use the right plotscripting commands. There is one of two ways to do this. My game uses the first method, as the second wasn’t possible until recently. That method is to use the “time at play” commands.

seconds at play
minutes at play
hours at play

It’s unlikely you’ll want to concern yourself with “seconds at play” considering the number of sprites you would need, so for the rest of the exercise we’ll keep to the minutes and hours.

Now, to use the commands above, you’ll have to attach them to a variable. Once that’s established, you’ll want to use logic operators to decide which sprite to flash on the clock. This is where you’ll want to get comfortable with greater and less than signs.

To actually display the right hand position on the clock, you’ll want to break your if/then conditionals by fives—twelve per hour—and assign each conditional to alter the NPC’s picture, direction and frame.

script,Hour Set 2,begin
variable (h)
variable (m)
set variable (h,hours of play)
set variable (m,minutes of play)
if (((h==3),or,(h==15)),and,(m<<5))
then,begin(
alter npc (4,npcstat:picture,223)
set npc direction (4,south)
set npc frame (4,0)
)
end
else,begin(
if (((h==3),or,(h==15)),and,(m<<10))
then,begin(
alter npc (4,npcstat:picture,223)
set npc direction (4,south)
set npc frame (4,1)
)
end

There are four parts to the above script and each go on and on, so you really gotta be hardcore to implement this one. But the detail is worth it if you stick it out.

The second method is to use real time for your clocks. The implementation is the same, but the commands are different. In this case you’d use “system hour,” “system minute,” etc. instead of time at play. Again, it’s a cakewalk wrapped in a marathon.

Now, this explains how to do it, but not how to trigger it. To get the clock to update every five minutes, you’ll either want to attach the script to an Each Step trigger, attach it to a step on NPC just outside the door leading in, or attach it to a timer. You’ll know what it needs once you build it, but remember it doesn’t do any good if it’s not updating constantly.

Dramatic Cut Scenes:

I addressed the art of cut scenes in Part Six, but didn’t really share my implementation methods. Therefore, I’ll toss out a couple tricks here.

First off, to build a great cut scene, you must first decide when to trigger it. Normally that decision should come on an incidental basis, but theoretically you’ll want to show it either after a major boss fight or at the end of an act. It depends on how you pace your story. I’ve launched one in the middle of a dungeon, so the timing is conditional upon need.

Next, you need to have a vision for it. Will it happen on the map the player’s on or a different one? If it’s on the same map, you’ll just need to familiarize yourself with “fade screen in” and “fade screen out.” If you’re changing maps, you’ll need a whole new slew of tricks at your disposal.

For the sake of argument, we’ll assume you want to use a different map.

Now, you’ve decided the action is going to happen on a new map, perhaps one exclusive to the cut scene. What next? Well, we have to assume the hero won’t be part of that cut scene (if we’re changing maps, we’re probably showing an event that’s happening far from him). Therefore, we’ll want to suspend him.

Most scripts should suspend the player anyway, but in this case it’s especially important. We don’t want the hero tramping onto the scene if he’s supposed to be engaged in a slime fight a thousand miles elsewhere. Suspend the player.

Now that all control is lost from the player, we can create the cut scene of our dreams. I like the convention of starting it on a black backdrop.

Every cut scene should be developed according to the author’s standards, but I find it helpful to assign a special map to launch all cut scenes. The key is to find an indoor map with a wide berth of black space.

Once a starting map is determined, we’ll want a starting position. That’ll mean transporting the hero to the new map via “teleport to map.”

Now, by all rights and purposes, we’ll still see the hero here, so we need to fix that. We need to fade the screen out first. This can be done in a normal or colorful way, but for the sake of drama we’ll want to keep things normal. Thus, we’ll want to use the color code for black.

Once we think we’re faded, we’ll want to wait just a few ticks before jumping our hero to the new map. This will ensure that the engine doesn’t give us any “glimpses” of the hero’s quantum leap. After a few ticks, we can instruct the hero to jump.

This is the time to implement some directorial controls.

No cut scene is dramatic without the right music, and generally the map’s default music is not right. We need to change this, starting with a suspension of map music and ending with the call for the right music. We can do this with two commands (which you’ll see in a minute).

When we jump to the new map, the last thing we want to see is the map’s name displayed at the bottom. Seeing this will take the player right out of the moment. We need to cancel the map name display before going any further.

Okay, now we can start the cut scene.

Assuming the hero has jumped to the new map (under the cover of a faded screen), we’ll want to set his position well into the black field. From there we can do one of three things: we can focus the camera to the designated focal spot and move the hero elsewhere; hide the hero under a layer of black overhead tiles at the focal point; or change his walkabout picture to something invisible. I usually focus the camera and send him elsewhere.

However it’s handled, the next step is to wait a couple ticks before fading the screen in. Like in fading out, we want to ensure the player doesn’t catch glimpses of mistimed events before the scene comes into focus. I usually put ten ticks between each fade.

Once the screen fades in and we’re sure the hero is MIA, then we can start the cut scene. How it begins should fall largely on where it begins. If it starts on a black backdrop (like I’ve been doing lately), we’ll want to overlay it with a message. That message can be anything as long as it’s relevant to the cut scene. I tend to start with “meanwhile.” Other phrases like “elsewhere,” “in another time in place,” and “now for something completely different” tend to lead well into scenes, too.

And now to see how this all looks in script form (complete with commentary):

suspend player
suspend NPCs
wait (10)
#after you take the player’s control away, give him a moment to reflect
suspend map music
#don’t let the wrong music play for your scene
fade screen out (0,0,0)
#the triple zero defaults to black
wait (10)
#give the engine a chance to catch up to the visual
teleport to map (48)
cancel map name display
#make sure the map name doesn’t interrupt the drama
set hero position (0,10,25)
focus camera (10,21,20)
wait for camera
#get your hero to the appropriate place to hide for the cut scene
#put the camera in control of the direction now
wait (10)
play song (81)
fade screen in
#wait a little longer to get your scene ready
#make sure you start the theme music by now
show text box (2293)
wait (45)
advance text box
#display your opening message (or scene)
wait (10)
#give the player time to reflect
fade screen out (0,0,0)
wait (10)
teleport to map (58)
#get on with the cut scene
.
.
.
stop song
camera follows hero (0)
#do not forget to put the focus back on the hero
wait (10)
resume map music
play song (get ambient music)
#don’t forget to put the regular music back on
fade screen in
resume npcs
resume player
#and don’t forget to put the player back in the game
end

Developing the cut scene is entirely up to you, whether it’s simple or epic. I tend to throw in the obligatory sprite animations and occasional tile changes to keep things interesting, but you can do what you want. Just make sure that when all is said and done, you put the hero back where you found him and give the player control again. This should be common knowledge, of course, but then so is using vowels. Can’t be too trusting around here.

Dramatic Pause:

As a quick aside to cut scenes, I just want to throw out the concept of dramatic pauses. You can spark life into your character by leaps and bounds if you consider implementing this simplest but most effective of all development tricks. All you have to do is divide “reflection” moments in dialogue or action with a “wait” command and set it for anywhere between 15 and 40 ticks. You’ll quickly find that characters sink into the player so much deeper if you allow him to experience natural moments of reflection with the character, rather than rushing him through three sets of dialogue masquerading as one.

Intensified Maps:

One of the biggest draws to designing an RPG is creating the world. We not only flock to the engine to create cliché stories, we have this raving ambition to build fortresses in mountains, movie theatres in space stations—anything that ignites our imagination. And often we can see our dream come true.

But sometimes the technology falls short. Many graphic designers can attest to this when the elaborate castle uses up all 160 tiles and still needs another 12. Frustration abounds. That medieval coffeemaker has to get the boot.

Thanks to the improvements of plotscripting technology, however, tile limitations are a thing of the past. With a handy little command called “load tileset,” multiple palettes can fill the void of a single map. Here’s how:

Let’s pretend we’re building a town. The south side of town has buildings, fountains and parks. The north side has a farm, farmhouse and barn. Both sides require use of the same grass and tree tiles. Neither can look complete without going over the 160-tile limit. What do we do?

First, we draw the tiles for two different tilesets, the southern half’s graphics on one, the northern half’s graphics on the other. Tiles needed for both sets (like grass and trees) should be copied and pasted into the same position in both.

Once the sets are complete, we need to draw the portion of town using the first set. When that’s finished, we go into the map editor, change the tileset to the next set, and resume work on the north end. The area dividing the two halves should only use tiles universal to the map.

When the map is finished, it’s time to implement a plotscript. This is where we’ll want to write a script that checks hero position and direction.

Assuming the hero is facing north at the trigger point, we’ll want the script to load the tileset for the northern half as he passes into it. Likewise, if he’s facing south (at a trigger point just south of the first), we’ll want it to load the original tileset for the south.

variable (y)
variable (d)
set variable (y,hero y (0))
set variable (d,hero direction (0))
if ((d==north),and,(y==4)) then(
load tileset (2)
)
if ((d==south),and,(y==5)) then(
load tileset (1)
)
end

Notice the position of “y.” The tileset for the south side is triggered one tile below the one for the north. This is to prevent heroes who are facing south to wreck the tileset should they move north again before crossing the trigger line.

When the script compiles, be sure to attach it to a Step On NPC for triggering; then set two parallel lines of triggers across the hero’s travel path between the two areas, making sure the trigger area uses tiles both halves share (so the player can’t see the switch happening).

If the trick is implemented correctly, the player will never know the map shares two tilesets and you can get away with having extra detail in your scene.

The Mysterious Recording:

For those who stalked the Castle Paradox forums in spring 2007, you’ll remember a controversial event that lead to the rise of Epic Marathon 4. A fake security guard named Buford announced he found a mysterious recording involving what sounded like the start of a conspiracy, to which the community dropped a brick. Though the details of the recording were fuzzy, it was clear somebody had too much time on his hands.

Now that we’re talking about the effectiveness of creativity, I suppose it’s time to reveal how that recording came about.

For anyone who had the opportunity to listen, they’ll remember it sounded like a guy whispering to another about “something big happening soon.” Forensics in sound would suggest the event took place in a courtyard next to a fountain, probably on the outskirts of a party. With distant music, chirping insects, and babbling water, there was no other place to record it but outside.

Or, if one might dare reality, no other place to record it but at my bedroom desk.

Okay, so how did I record something like that at my desk? Did I download a bunch of sounds off the Internet and mix them together? Hardly the case. Nope, everything was original, minus one Batman Beyond: Return of the Joker soundtrack. Here’s how:

First off, I should mention there was a steady buzz plaguing the whole recording. Though it helped muffle the words I tried to disguise, in the end it was just a misjudgment in sound filtering. I had left on both my fan and my air conditioner not thinking either would interfere with the recording process. Lesson learned. So when I suggested you turn off all devices prior to recording in Part Six, I meant it.

Next, I had to make the first track—something all sound recordings need. Before I could record it, though, I had to create the space. I opened Microsoft’s built-in Sound Recorder and made noises into the microphone for 33 seconds. Then I hit “stop.” Now that I had a template, I could start recording sounds.

I was going for that outdoorsy feel, so I started with the insects. The type of insects I’d use, though, I didn’t know, but figured crickets (or something like crickets) should be a staple. That’s when I started making cricket noises into the microphone.

At least, I thought they were cricket noises. They could’ve been frog noises, but I didn’t know for sure. The important thing was that rolling my tongue made a nice swampy sound I was happy with. I saved the finished track as “Background 1.”

One creature noise usually isn’t enough for partial realism, so Track 2 set the foundation for another. For the space of thirty seconds I started making what I’m sure was frog sounds. I recall having to go to the back of the throat for that one.

Track 3 was easily the hardest one—the one simulating the fountain. For starters, faking a fountain is bad news for a computer desk in general. It usually means something’s gonna get wet tonight. Secondly, to imitate a fountain means breaking out props that could take your sound in the wrong direction. The method I chose ran the risk of sounding more like an aquarium (or someone peeing) than a fountain. But when you layer it with a bunch of other sounds, it’s easier to get away with the possible side effects.

To create the water effect, first I had to accept that I’d be pouring water into something. That meant using a cup and a basin.

Now, common sense should tell you that to make the pouring water sound real, I had to pour water from the cup. Fine. What it won’t tell you is that the pouring meant more than just dumping it into a bowl. I had to pick the right bowl. Since I tried to make it sound like it was cascading into a cement basin, a ceramic bowl was not gonna work. I had to go hard plastic. Pouring it into an empty bowl wasn’t enough, either. If it was to sound like hitting water in a bowl, then it had to hit water in a bowl. I found that a puddle was just enough to give it the right sound.

Intensity counted, too. When I poured the water into the plastic bowl, I had to be careful not to dump it all at once. It had to trickle in, little by little. I even tried to send it through a cheese grater just to get that broken effect. Sometimes these things have to be considered. Covering the glass with a wash cloth before pouring can help in these matters, too, if the bowl is big enough to catch runoff.

For Track 4, I had to find the right song to play on my CD player (softly). I thought the epic score of Batman Beyond had just the right blend of party drama to fit not only the mood of the recording, but also to create a sense of believability that it was playing at the party. Though you normally won’t need a soundtrack for your sound effect, it’s a good idea to know how to dress it if you decide it does.

On Tracks 5 and 6, I pulled a couple branches off a tree and waved them together in front of the microphone to sound like trees rustling. This was actually the worst effect to simulate as rustling leaves sound better when they’re still on the tree. But sometimes you gotta use them anyway, as the recording will sound more authentic with partial sounds than with no sound at all.

With Track 7, the final track, I whistled over the rim of a glass to simulate wind. Like the tree branch effects, this could’ve been better in reality, but then wind is the trickiest of all sounds to record. To capture it accurately, you have to blow into the microphone, and unfortunately that means killing off every other sound in the compilation. So don’t blow into the microphone. Whistling softly over a glass rim is the next best thing, and it protects the integrity of your other sounds.

One of the nice things about Sound Recorder is that it allows you to record new sounds over old ones. Starting with Track 1, I mixed each new recording in with the one before it until I could hear all seven tracks simultaneously. Then I labeled the complete mix “mysterious recording” and uploaded it to Castle Paradox, where the rest of you had a chance to hear it. Everything was done from the comfort of my own desk and everyone was none was the wiser. It didn’t take genius, just an ounce of creativity. You can do it, too. Just figure out what you want and use whatever you have around the house to achieve it. If you have a laptop with built-in microphone, then you’re in even better shape to accomplish this and have no excuse to make the most of it.

Ending Statement:

So there you have it, a new library of ideas to help your game leap out of the screen. The tips above are suggestions, mind you, and you don’t have to use any of them to make your game great. But if you want your game to stand taller than its neighbors, you should consider implementing something special to give it personality. All it takes is heart (and imagination).

Also, there is another side to game design that I didn’t talk about: methods involving technical feats like limiting inventories, changing stats, etc. To balance the gameplay elements of your design, you should learn those, too. However, I’m electing not to discuss them here, because I think practical, dramatic methods invest the player into your story more than technical feats, and for the sake of this article, the emotional investment is more important to discuss. As your game develops, though, you should consider exploring these avenues to improve your arsenal.

I would also encourage veteran developers to write an article like this one for other areas not discussed here. Sometimes we can stretch our imaginations further if other people get on either side of us and pull. If you have an idea, start writing about it.

And that’s it. Thanks for reading this mega-feature. Hopefully you finished it in under a week.