Goblinstomper! Development Diary (V): Oh God He’s Talking Game Mechanics. Wake Me When He’s Done.

Let’s talk game mechanics for a second.  I’ll try to keep it from being too dry, but it is what it is.

Right now with the game I’m trying to set up something I can play through fairly quick.  To see how it works, that short of thing.

In order to do this, the game needs to be able to let me traverse from map to map.  Later we’ll worry about little things like combat and items and magic spells.  This, though, is a vital part of a successful game.

Setting things up as a rule is fairly easy for RPGMaker.  You just set up an Event, that is a marked location with a list of commands for the game, on the map.

For instance, let’s look at the castle map again:


The doors and the four guards on the screen?  All Events.  While the Player can only interact with three of them (the door in the center and the two guards beside it), each has it’s purpose, from as simple as being a part of the scenery to being a character wandering the map.  Some events (though none here) aren’t visible and will never be known by anyone outside the programmer.

Were I to set up a means to move from this map to, say, the throne room, I’d set up a series of commands in, say, the door, that will do the job for me.  There is even a command in the Editor to make everything even simpler.  Not just to Transfer the player from Point A to Point B:


All of this great, if the map only has one small entrance (as displayed above).  What if you have a larger area that the player can conceivably leave from.  Like this:


Here, Hero can walk either to the left or right, and, in theory, leave for the next map screen.  We can set up Events that will transfer him as easy as I’ve said, but that’s still some work.  Ten Events in all.  While I can cut-and-paste Events, it’s simpler just setting up commands in a single event.

Enter SHEMP.

SHEMP is a part of my Standardize Event Labels (SEL) system I mentioned a little while back.  As an Event, I use a SHEMP to run cut scenes, which includes moving events around, relaying dialogue to the Player, and other fun stuff.  I also can set it up to “watch” the game and act when a certain set of circumstances comes up.

In this case, I’ll have it “watching” for Hero to reach a part of the map.  Once Hero hits that point, SHEMP steps in and moves Hero to the next map screen.  If I wanted, I could also have a conversation pop up, start a fight, or play an animation.

To do this, I need to know the X,Y axis coordinates of the map:


X stands for columns across left and right; Y stands of rows from up to down.  The circled area on the lower right tells me just where the white square is on the two axis (X,Y).  And yes, one of the bigger points for this blog post entry is to remind Mr. Waters which is X and which is Y.

You have no idea how often I’ve gone running off to double-check that tidbit.


For this particular job, I’ve arraigned my map so that the Player can only reach certain parts of the X axis.  Points lower than 2 or higher than 14 can’t be reached.  Thus if the Player moves Hero to those points, SHEMP will notice and begin the Transfer.

All of which looks like this to me:


I’m not going to go further on this matter that this at this point in time, as I’m running out of ways to make this entertaining and I’m not sure how entertaining this is in the first place.  However, there are a few points I’d like to make as they might come up later.

  • See all that green text?  Each one details a certain part of the program’s process.  None of this is necessary, no one but me may ever read it, and even I’m questionable.  That said, I’ve searched Events once too often trying to find a specific line to fix, or figure out just what the hell I was thinking.  This makes things easier.
  • If you read the whole set of Contents (why?) you might notice something called a Common Event.  This is a string of commands that gets used in more than a single Event.  In this case, it’s the string that lets SHEMP “see” where the player is.  As I plan to use this trick a lot, it makes more sense doing things this way.  Saves on clutter, too.
  • Should your eyes wander over to the various commands on the left (how bored are you?) you’ll see that the Trigger boxes right at the bottom.  I’ve mentioned this earlier, but the Trigger tells SHEMP when to act.  With the SHEMPS, it’s usually set to Parallel for processes like this one.  Parallel runs in a loop in the background and allows the Player to act.  Any of the other choices will either mean SHEMP will never start looking or will keep the game so busy looking it will never let the Player move, thus trapped in a never-ending loop.
  • I look at all the commands here and marvel.  Real programmers need to know so damn much of this, it boggles the mind any video games get made.

Tomorrow, we return to setting up the next stage of the story.


2 Replies to “Goblinstomper! Development Diary (V): Oh God He’s Talking Game Mechanics. Wake Me When He’s Done.”

  1. “I look at all the commands here and marvel. Real programmers need to know so damn much of this, it boggles the mind any video games get made.”

    Many don’t. As far as programming goes, I imagine that, basically, it’s like learning another language of communication.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s