Latest Entries »

Needs More Olive Oil

GIR told me over IRC that the screenshots for floating cities look too saturated, so I’ve set out to fix that. I’m not very good at figuring out when bright or saturated colors cause eye-hurtiness, since I ran into this issue multiple times. To desaturate the tileset, bg, etc. of the new area, I’ll start off with something that’s not part of the new area at all: the HUD.

The new HUD (heads up display) uses a dark navy blue scheme to frame the health bar and exp bars. This fits in closely with the message boxes, which are now also navy blue. Therefore, the user interface gains some consistency that it didn’t have before. I’m not entirely satisfied with the darker HUD and message boxes, especially since I’m thinking about switching to grayish blue rather than navy blue, but I’ll stick with it for now until I attempt some better colors and/or find a better design.

What about the new area itself? I’ve tried simplifying the clouds into a two color background. Again, this is sort of a work in progress, but here’s what I’ve got:

In this background, I toned down the color of the sky to a lightweight purple. This clearly brings out why the HUD and the tiles for the area are just “too bright”, which is why I said I wasn’t satisfied with the new HUD yet.

More stuff to come? Yes. I’m also improving the look of the cylindrical pillars before fixing up the tiles. I inverted their shading scheme for a more realistic look.

During the week, I studied the art inside SNES games like Secret of Mana and how those game artists properly did their shading. Because of that, I changed the shading for these pillars significantly. The final result is a much more convincing metallic looking cylinder.

So that was 4 pictures related to the mod itself. Certainly a new record for me, or something. If you have good advice on how to add more olive oil to a mod, don’t forget to leave feedback. Enjoy your week everyone!

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.