Archive for October, 2011

Ice Monsters

I’ve created these monsters quite some time ago (you can even see their sprites in my forum sig), but I haven’t talked about them at all. I think they’ll be a good way to fill some time while the CS+ craziness goes on.

First up are the ice roaches. The artwork for these critters is really simple – just a recoloring of Pixel’s unused gaudi sprites. Well, they were unused some number of years ago, but now you can actually see these new gaudis in CS+ Wind Fortress, I believe.

Why am I talking about CS+ so much? I must be going insane. Really insane. Surely I’m turning into the kind of mentally psychotic person that you don’t want your parents to see. Err… anyway let’s get moving with some more mod discussion.

I’ve given the ice roach some special behavior using that magical language known as assembly. He can now shoot projectiles at you (which are the same projectiles that those “jumping beans” shoot in the Witching Hour’s sandy desert region), and he flies with a vertical wobble, for a more organic-looking motion. Bouncing off the walls is also a plus.

Here’s a second monster, a much more interesting one in my opinion. The ice eye.

This guy can fly pretty well, and he also has a special weapon: bomblets. He’ll drop one of these small bombs every so often, which explode when they impact the floor, so be careful if you’re staying on the ground.

And those are the new enemies for the floating cities area. So that concludes my post. I’m not sure what I’ll be doing next week, but surely I’ll think of something. Goodbye for now, and see you next Saturday.

High Altitude Cities

I’ve been doing some map-making, TSC scripting, and spriting this week (3 different things! How amazing…), so now I can so you some interesting screenshots.

The new area will focus on ‘platforms of civilization’ – which are basically miniature cities floating in the air through some magical or technological means. You’ll probably be using elevators and teleporters to move around, though I haven’t finalized the transportation yet.

The tileset for this area is similar to the one for Outer Wall, but changed in a number of ways. I’ve also created a background image that shows a bunch of pretty clouds. Click on the thumbnails to view the full size image.

At first I planned to base these clouds off of the ones you’d find in Guxt. Right now, they don’t resemble Pixel’s style of drawing clouds at all, but I guess that’s okay. Originality may be better.

There’ll be a minimum of two puzzles for the floating cities. The first one has to do with the 7 seals, and the second one I… uh… haven’t designed yet. Both puzzles will be easier than the first one you find in the mod, so neither should really be too difficult.

As you can see, Em will be featured in the new area. There’ll also be some monsters that I’ll talk about next week or so, so be sure to stick around.

Weapon Repairs

Sorry that today’s blog post is a bit late. This week I’ve fixed up a weapon planned for the new release. This weapon is the burst capacitor, an energy gun that was available for testing at the very end of Witching Hour Demo 1.1.

For the upcoming Demo 1.2, I changed the animation of the burst capacitor so that the energy blast renders on top of tiles and NPCs instead of below them. This means that burst-capacitor bullets will not suddenly appear ‘underneath’ doors and savepoints, which used to look really weird.

This involved doing some assembly work where the bullet code actually communicates with the health bar to get the animation to appear on the correct layer of the screen. Since the health bar code can render anywhere on the game screen, this works out nicely. The burst capacitor also behaves in a weird way for a weapon: when the bullet is destroyed (when it damages an enemy or times out), the sprite doesn’t disappear but instead persists to finish off the animation.

Animation of the Burst Capacitor's Bullet

Now, I could give you a block of assembly code to read, but I realize that’s a great way to put a lot of people to sleep through the boredom factor, so I have something different this time. You can now download a mini-mod of version 1.2 and test out the newest version of the weapon. Give it a go. This mini-mod also includes a redesigned health bar for the newest version, if any of you would like to see that.

Download Demonstration – Test the New Burst Capacitor

I’d like to say that the burst capacitor is heavily inspired by Daniel Remar’s “Resonance Detonator” from his freeware game Iji. If you haven’t played Iji yet, go grab a copy now, since it’s a great game.

That’s all folks! See you next week.

Splitting the Atom

What does the word “atom” mean, and what does it have to do with The Witching Hour in this case? Normally, when you hear of the word “atom”, you’d think of some small component of matter, and these pieces of matter dominate the Earth as we know it.


An artist's impression of what atoms look like. No, they don't actually look like colorful pieces of candy.

That’s great and all, but “atom” has a more fundamental meaning. The first part, “a-“, means “not”. The second part, “-tom”, means “to cut”. Atoms are supposed to be “uncuttable”, meaning that they cannot be broken down into smaller parts. Today, we realize that atoms can be split, so the name isn’t very good anymore. Splitting atoms is a great way to build things that can blow stuff up, but we’re not here to discuss such matters.

What does it mean for a TSC command to be “atomic”? It’s uncuttable – meaning it cannot be broken down into smaller TSC commands. This is true of practically all commands. Take the commands <MOV and <WAI. The Cave Story command <MOV will move a player to a new set of coordinates on the current map. <WAI will pause the TSC script for a certain amount of time.


The difference between the two is that <MOV takes almost no time to execute (computers are fast, after all), but <WAI is purposely designed to take time to execute… that’s its only goal.

Do you remember multi-threaded TSC? It’s still in the primitive stages of development, but now it’s possible to let either the user or modder run 2 TSC events at the same time.

Here’s how multi-threaded TSC works. It’s actually a not-so-complex mechanism:

  1. Run the first command of Event A.
  2. Run the first command of Event B.
  3. Run the second command of Event A.
  4. Run the second command of Event B.
  5. and so on…

If all TSC commands ran in a split-second, this would work out just fine. But the many commands that have side effects, like <WAI or <MSG, will cause problems because they will prevent the other event from running. It takes some time to get through <WAI, and it takes some time to get through <MSG (because the player must wait for the message box to show all its text and then close).

To make multi-threaded TSC run as smoothly as possible, we need to ‘split the atom’, so to speak. If each command with time-based side effects could be chopped into a bunch of smaller commands, that’d be great. Here’s an idea for manipulating <WAI into a non-atomic command:

I think the idea to making WAI non-atomic is to make it a self-modifying TSC command: <WAI0500 should wait for 1 tick, modify itself to be <WAI0499 (by changing the big TSC string itself), and then not update the script position.

The script position should only increased by 8 when <WAI finally reaches 0000. Each <WAI command will split itself (essentially) into a bunch of 1-tick <WAIs, which means individual <WAIs will not clog up threads.

EDIT: Actually there is an issue with this particular implementation of non-atomic WAI. When an event is called the first time, the WAIs will work fine, but when the event is called again, all its WAIs will look like <WAI0000. To fix this, each WAI must have a method for storing the original number of ticks and resetting itself once 8 is added to the script position. This could be done by reserving a special hex byte, such as 0x00, that will signify the instruction is a non-atomic WAI.

In other words, <WAI0500 will transform into <(0x00)(0x01F4)0499 once executed. The first part is 0x00, which signifies that this instruction is still WAI. The second part holds the original number of ticks, 0x1F4, which is 500 in decimal. The rest are ASCII bytes that are decremented accordingly until they reach 0000. Once that happens, the command is reset to <WAI0500, the parser moves on, and all is well.

Whoa… technical information overload. Don’t freak out if you don’t get it because most people won’t understand it anyway. Instead of letting <WAI wait for the full time all at once, we can make <WAI run only a little bit at a time so that it’s not an unsplittable command anymore.

Thanks for reading this (rather huge) chunk of text. I should have more pictures next time… at least I hope I will. Have a good week everybody!

Good Grief.

That riddle from 2 weeks ago. You do remember it right? Instead of giving you the explanation to the riddle in words, I’ll give you a picture to look at. I like pictures.

A difficult riddle indeed. Grief Syndrome is a game created by Twilight Frontier, also known as Tasogare Frontier in many circles. They’re a rather famous Japanese game making group.

Haha… here in this blog post you see words, words, words, words… oh wait here’s a picture. Did I tell you that I liked pictures? Yeah. This one’s a screenshot of Grief Syndrome.

Big as it is, the above picture is just a thumbnail so click on it if you want to see a higher resolution version.
Even better than pictures, here’s a video of the gameplay. No, I’m not the narrator of the video, but thanks to the magic of the Internet, you can find audio commentary on practically any game that isn’t completely obscure!

What does this Japanese game have to do with modding? Eh? Well, I’m planning to make a weapon that’s more or less inspired by this genre of games. Grief Syndrome falls in the the genre of “run ‘n gun”, which is sort of like “shoot ’em up” but also totally different.

Ever played Super Smash Bros. (as in Brawl, Melee, or original)? The idea is the same. When you press a certain key (such as the left arrow) and then hit the attack button, your attack will act differently than when you’re just standing. Likewise, if you’re attacking while pressing the up button, the attack button will perform something different than if you’re on the ground and holding the down button. This is what I like to call “Motion Based Attack”, because I really don’t have a better name for it (button input combinations?). It’s a common feature among fighting games as well as run ‘n gun, so I think that incorporating a motion-based attack weapon into Cave Story would be pretty interesting.

At this point I haven’t started coding the thing. But by now, you probably want to play some Japanese homebrew games or start watching some LPs… or both! So I won’t stop you. Have a good week everyone.