Archive | April 2014

Development Tools

Hello again everyone! This time I’ll be talking about development tools and how they’ve helped me as both a game designer and programmer.

Development tools can be, simply put, amazing (but they can also be terrible). My first experience with development tools included a level editor for Super Mario World called Lunar Magic, created by a programmer known as FuSoYa. It was a truly revolutionary editor and took the ROM hacking scene to new heights. To this day, Super Mario World remains one of the most hacked (recently termed as “modded”) games, and it’s all thanks to Lunar Magic.

So, how was Lunar Magic? Check out the picture below for the editor menu for levels:

Lunar Magic’s Level Editor Interface

At first look, it seems rather complex, but it’s actually very simple and easy to use once you’ve fiddled around with it for a few minutes. You can easily see where each enemy will spawn, as well as the spawn point of Mario and the contents of ? Blocks. Taking and placing objects is as easy as opening the object window (the flip block icon next to the Baby Blue Yoshi icon), clicking on an object to place, and right-clicking on the level to place it. This also automatically copies it, so you can place as many as you want easily! Once an object is selected on the level, you can move it around by dragging it. Furthermore, if you hover over the object on the object window, it tells you information about the object, such as special properties that it may have. For example, certain X values will cause a flying ? Block to give out a Fire Flower instead of a Cape Feather.

Lunar Magic’s Object Placement Window

I could go into more detail about Lunar Magic, but it would take far too long since it’s packed with too many features to count. However, we can learn what makes Lunar Magic such a good development tool and apply that to our own tools.

I’ll make this brief. Lunar Magic has a visual layout, which makes it extremely easy to see what you’re doing when you’re modifying levels. It also has simple controls, a simple UI, and flexibility, meaning that performing an action such as placing objects is easy to find, easy to perform, and allows you to easily repair your mistakes (Ex. press Delete and simply click on the object window again if you accidentally placed a different object than the one intended). Looking at this, it’s easy to see why Lunar Magic has been so successful.

For Streets of Peril, I originally thought that I didn’t need a tool such as a level editor. That is, until I started designing levels in code. In all honesty, it was pretty terrible since I had to compile each time and go to the level only to find out that an enemy spawned too late or something similar and I had to revise it. It was trial and error programming on a large scale, which I dislike (yes, this means I dislike HTML). Eventually I realized that I can’t design levels like this and went on to make my own level editor, which was both a great learning experience and tool. It served its purpose for a while, until I could no longer deal with its lack of flexibility. If say I messed up what Status Effect an enemy had, I’d have to fill in all the changeable values again with just that minor change. The worst part by far, though, was that each object had a separate spawn point, difficulty level, and minimum number of players required for it to spawn. If I forgot to change one of those values after placing an object, I’d have to either remove the object and place a new one or fill in all its values again, remember the hotkey to change the value I need, and place it on the level again. Not to mention, all of the editing features were hotkeys that I memorized, so no one else on the team can actually use the editor, and the editor was built into the game itself inside a single class, making the game larger than it needed to be and making the editor extremely hard to modify.

So in short, I’m currently in the process of redesigning my level editor. Here’s a mockup of how I want it to look:

The layout plan for Streets of Peril's new Level Editor

The layout plan for Streets of Peril’s new Level Editor

And here’s how it looks so far:

My current progress on the Level Editor. So far it's pretty faithful to the mockup, but it's not fully functional yet.

My current progress on the Level Editor. So far it’s pretty faithful to the mockup, but it’s not fully functional yet.

It’s nowhere near as good as Lunar Magic, as that editor was made for public use and had a development cycle of 5+ years, but it’ll be good enough for me, Nick and Bek to use. One notable difference is how I have things organized. For one, it’s actually a separate application this time, so I’m free to do whatever I want without cluttering the game itself. Instead of each object having its own offset and etc, I can now create a Spawn which has those properties. Inside the spawn, I can create as many objects as I want and offset their locations relative to the spawn’s so I don’t have to go through the tedious process of moving each object in the spawn separately and instead just move the spawn itself. I also have editing menus with my own custom controls (textboxes, drop downs, etc.) that will make editing easier, faster, and more flexible. I’m going to have a lot of fun using this when it’s complete.

So to wrap this up, development tools can make creating a game fun and enjoyable, especially when they’re well designed and offer much creative freedom. Notable examples, aside from Lunar Magic, include the StarCraft/StarCraft II map editors and Garry’s Mod. I hope that editors such as these inspire more game developers to develop their own tools. The experience gained from doing so helps you familiarize yourself further with your own game, and who knows; those tools may even be reusable in a future project!


Commander – A Unique Boss

Hello again everyone! This time I will be talking about one boss in Streets of Peril that I’ve been working on lately.

This boss is named Commander and does what his name implies; he commands enemies, aka his minions. As long as he has minions, he will negate any damage done to him, except Poison. So this means that while you can hit him, grab him, and knock him down, he won’t lose any health. As a result, your goal is to dispatch his minions then fight him alone.

My inspiration for this boss is from platformers like Mario and Sonic, where bosses have cycles. I was disappointed that traditional sidescrolling Beat ‘Em Up games didn’t have something similar, so I thought I’d put something like that in with my own little twist.

Before I forget, Commander is the boss for Level 4, the Forest level; if you were thinking that he would be extremely hard for a first or second boss, you would be correct. I’m striving to make most of my boss fights unique, intense, and very fun. That’s how they usually are in platformers and other sidescrolling action games, after all. I hope that there will be bosses fun enough to fight that players can’t wait to fight them again in their next playthrough(s) of the game.

Anyway, here’s a quick video of how the boss works:

YouTube often butchers the quality of my videos, and unfortunately there’s not much I can do about that. I used free recording software called Bandicam because my trial for Camtasia Studio, which is currently my favorite recording software, expired.

Anyway, Commander’s behavior isn’t complete yet, so all he does is walk up to you and call minions after a certain amount of time when he doesn’t have any. The minions are simply normal enemies that defend Commander when he tells them to, which includes right after he calls them. Commander can also tell them to go off and attack the players when necessary, and the minions automatically go on the offensive when Commander gets grabbed or knocked down.

There’s definitely some polishing to be done, but it’s getting there! If you have any opinions on this boss idea, feel free to post a comment!

Refactoring and Managing Code

Hello everyone! This time I’ll be talking about properly refactoring and managing code for development. Not counting empty new lines, brackets, or comments, I’ve written 17859 lines of code for Streets of Peril so far, and I’ve learned a lot of techniques since the first line I wrote for it. For those unfamiliar with the topic, Code Refactoring refers to changing the internal structure of the game without changing its external behavior. Now before I start, I’ll claim that I’m not an expert at coding yet, but hopefully my tips will come in handy. As a heads-up, I’ll be showing C# code; if there’s any syntax I won’t expect you to know, I’ll explain it. I’ll assume that you know basic programming concepts such as inheritance and the like. With that said, feel free to leave a comment if I still didn’t make something clear enough for you.

Refactoring: Subtyping

One of the most important things I learned when making Streets of Peril was the concept of inheritance. If you can subtype something to make it easier for yourself, by all means do it. This means having more classes, but think of the benefits: isn’t it great when you don’t need to take so many little factors into account and let the subtypes handle themselves? I’ll provide an example:

In the Normal mode for one of the challenge levels for Streets of Peril, Survival, you’re in an underwater level with an Oxygen Tank. This differs from normal Oxygen Tanks in that every hit you take will also hurt the Oxygen Tank, leaving you with 5 hits maximum before you lose. I initially tried so many different things to change my general collision class to take this into account. From tracking the player’s health before damage to passing in a delegate (function pointer) to the collision class, everything seemed lackluster.

Finally, I came up with the following: I created a new subclass that inherited from the character used in that challenge, Graham, and named it SurvivalNGraham. This class had only one change, which occurred when taking damage:


public override void TakeDamage(float activeTime, bool FacingLeft, int damage, Status enemystat, Hitbox enembox, TileEngine TileEngine, List<Collideable> Solids)
base.TakeDamage(activeTime, FacingLeft, damage, enemystat, enembox, TileEngine, Solids);

//Make the oxygen tank take damage whenever Graham does
if (OxygenTank != null) OxygenTank.Break(activeTime, 1, enembox, TileEngine);

(My apologies for not knowing how to properly format code in WordPress yet)

As you can see from the code, all I did was make the Oxygen Tank lose health right when Graham took damage, regardless of how much damage was done. This tiny block of code solved EVERY problem I was having with this game mode, and it was all because I subtyped properly!

Refactoring: Efficiency

If you took programming courses at all, you’ve probably heard that you haven’t coded something as efficiently as you can. Then you begin to worry about everything else you coded. I have news for you: in this day and age, you don’t need to be as efficient with managing your memory in general. Obsessing over whether you should use a 16-bit integer or a 32-bit integer will only hurt you more than it helps you.

With that said, there are still some benefits to refactoring your algorithms, which are by far the deciding factor on how your game runs. I will show an example:

In Streets of Peril, whenever an Item Container took damage, it would check if the health was 5 less than the sprite changing point and change the container’s sprite if so; in other words, every 5 health taken from an Item Container would change its sprite to a more “broken” one. I had to consider that if a large amount of damage was done to the Item Container at once, it would still switch to the appropriate sprite. The algorithm went like this:

while (Health < (BreakHealth – 5))
if ((BrokenCounter + 1) > Sprite.MaxFrame) return;

BreakHealth -= 5;


(Note that I have comments here in the full code segment, but I took them out because they were directed at another piece of code that I’m still not sure about including or not)

Now let’s see here. It will repeatedly go through this process until either the container’s (BreakHealth – 5) no longer equaled or exceeded the container’s Health. This certainly works, but can it be done better? Of course!

Basically, what I did to improve this algorithm was to turn it into a calculation. I won’t post all the code since it’s a bit longer, but I checked the current health of the container and subtracted that value from the BreakHealth, then divided by the constant factor determining when the sprite will change (it’s no longer just 5), now called “SpriteChangeHealth.” This gives me the number of times I need to change the sprite, and best of all it only needs to be done once! I even changed another algorithm I had into a calculation with some help from a friend, as that calculation involved computing a series decreasing at a constant rate!


There’s another part to efficiency that I want to bring up, and it has some to do with subtyping. What if you need to access a field that is in some of your subtypes but not all of them? In an AI system like mine, this is often the case.

In C#, you can use Reflection to get a field, or you can have the fields be public in the subtype, cast your base reference to the subtype, then access the fields there. The problem with these approaches are they tend to be pretty messy. Here’s a line of code I used to have in the Uppercut action of my enemy AI system:

System.Reflection.FieldInfo info = Enemy.GetType().GetField(“Uppercut”);

To tell an enemy if it’s performing an uppercut move, I had to set a boolean called Uppercut to true or false. Since I didn’t know if the enemy in question had this field (granted, they all should if they’re going to have the action, but the extra error handling really helps if something slips by), I used Reflection to grab it based on the type of the enemy. If the enemy didn’t have it, I wouldn’t do anything, otherwise I would set it to true at the start of the action and set it back to false at the end.

What did I end up doing instead? I created a very general SimpleAttack action that allows me to pass in an animation and hitbox for the attack. This not only allows me to use SimpleAttack for virtually any one-hit move, but it made my whole life much easier by allowing me to use the proper hitbox and animation for the action and enemy I wanted! This also means that I no longer needed the “Uppercut” variable again!

Using Reflection in C# to get fields is unchecked by the compiler, since it doesn’t know the type of the enemy until runtime. This makes it impossible to know if the code will run or not before compiling and causes runtime errors if something goes wrong. This coupled with the fact that the GetField operation is a slower one compared to the ones the compiler can and does completely approve of makes the method I chose much more preferable.

Oh, and while I’m wrapping up Refactoring I’ll say that variable runtime is bad. What is variable runtime? An example can be choosing a random number and hoping it wasn’t already chosen with a while loop. Instead, create a list of the possible number choices if you can and choose a random index from that list instead. This way, when the numbers are chosen, you can remove them from the list and narrow your options until you have none left. It’s much more reliable and has no potential to take longer than it should.

Refactoring: Naming Conventions and Commenting

This section will be pretty short, but I can’t emphasize how much you should comment your code. It seriously helps both you and anyone else that may be on your team when there’s a glitch somewhere and you can’t spot it quickly because you have to read through the code again to figure out what it does. In fact, I’m on a team right now for my senior project, and I’m the only one on the team that regularly comments!

Now, it’s understandable if you just want to get something done and leave the commenting for later. I do that A LOT. The problem arises when you don’t return to it and comment it while it’s still fresh in your mind. I prefer longer, more detailed comments, but others are fine with short, quick comments. Here are some examples of what I consider good comments:

//Makes the player character lose health – called when a hitbox collides with the player’s hurtbox

public virtual void GetHit(int damage)




/*A Bonus Status Meter to be referenced by players; when the meter gets to 100, the player will gain a positive status based on the status of the enemies killed*/

public class BonusStatus



There’s also naming conventions. I know that the game industry has standards in place for naming things like classes and temporary variables, but I have my own standard that I maintain across Streets of Peril. I name all classes and important class variables in Camel Case (LikeThis), and start timers with the name “Prev,” so I’d have something like “PrevJump” which dictates how often you can jump.

Method names are equally important, since you should know what they’re doing without having to look at the implementation. If you’re having trouble naming something, which I often do (it’s been almost 2 years and I haven’t settled on a name for Streets of Peril yet), at least make it up with a comment above it describing what it’s for or what it does (which I always do for classes and methods). Also if you’ve ever done any programming, you’d know not to name fields or methods arbitrary things like “q” unless it’s relevant in some way (Ex. “X” for the X position of a game object).


Well that about wraps things up this time! Next time I will talk more about Streets of Peril itself, I promise!