New Challenge Mode – Rock, Paper, Status

Hey everyone! I’m sorry for not updating this as frequently as I’d like to. Shortly after the last post I was very busy with graduation, moving back home, and finishing up my senior project, Epicubed. I have good news though; I have been working on Streets of Peril during my absence!

Today I’ll be talking about a new challenge mode I came up with and implemented, titled Rock, Paper, Status (RPS). I decided to scrap the Obstacle Course challenge that I may or may not have mentioned previously since I felt it didn’t add much to the game and I wasn’t sure exactly what I wanted it to be. So basically, this is the replacement for that. As the name may imply, it is similar to the well-known game Rock, Paper, Scissors.

This challenge mode utilizes the Status Effect system in a unique way: Damage beats Defense, Defense beats Speed, and Speed beats Damage. This means that if you have DamageBoost or DamageDown, you’ll have an advantage against enemies with DefenseBoost or DefenseDown. This idea actually stems from a challenge I thought of very early on called Changer. Like the Changer enemy, the player can change his/her Status to choose the best one for the situation. Unlike that challenge, RPS actually has these situations! Check out the video below to see RPS in action (again, sorry for YouTube butchering the quality; I have yet to figure out how to upload a quality video with the size of my game screen):

Each type of damage interaction ranges from Super Disadvantageous to Super Advantageous, which is determined by the attacker and the victim’s Status Effect. If the player has SpeedDown and attacks an enemy with DamageDown, that would be an Advantageous interaction for the player. As a result, only the enemy would take damage. If the Statuses were switched, it would be a Disadvantageous interaction for the player and the player would take damage for hitting the enemy! This introduces new dynamics that force the player to pay attention to their own Status, the Status of the enemy they’re attacking, and the Statuses of the enemies around them.

As you may have guessed, if both the player and enemy have the same type of Status (Ex. Defense), the interaction would be Neutral and both would deal normal damage. However, you may be wondering how to get a Super Advantageous or Super Disadvantageous interaction. You can get one by having the opposite Advantageous/Disadvantageous Status against your opponent. So if the player had SpeedBoost against an enemy with DamageDown, the interaction would be Super Advantageous and the player would deal double damage! Likewise, if the player had DefenseDown and the enemy had DamageBoost, the player would take double the damage for attempting to attack the enemy because it is a Super Disadvantageous interaction. In short, you’ll want the Boost of an Advantageous Status if the enemy has a Down and vice versa.

There are still a couple of bugs with the challenge that I’m hoping to fix, with the most notable one being that SpeedBoost/SpeedDown still affect your movement speed. It’s not a huge bug, but it makes the challenge less balanced than it should be.

Aside from that, I’ve been doing more design work and refactoring the code to allow for more flexibility than before. It’s about time I know exactly what I want in the game and exactly how each element should work. I still have a lot of work left to do, but I’m hoping to cut some of the redundant features from the game. Either way, once I’m finished with the design work, I’ll have more focus when programming and thus be able to work only on the things that matter. After that, it’ll just be polishing and playtesting!

I’m sorry for suddenly leaving for a while, but I hope to continue writing entries regularly again!


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!

DLC, In-App Purchases, and the Like

When I woke up today, I was hearing that an alumni from my university, who graduated with a BS in CS: Game Design, started a KickStarter for a mobile game his team had finished. Earlier this year I actually asked him if he was hiring, but he said he wasn’t. In any case, the game looked pretty good, and I hoped the best for them.

When I looked at it on KickStarter today, I wasn’t impressed, to say the least; I was actually rather disappointed. Why? The game was designed around micro-transactions, a practice commonly used in modern games, most common in mobile games, to maximize profit at the expense of the quality of their game (more on this later). The game I originally thought it was in my mind crumbled, and instead I was looking at, yes, “just another mobile game.”

Before I start my thoughts, I’ll say that I do think the concept of DLC (Downloadable Content), which is usually brought up in conversations about micro-transactions, is good, but only if done right. What does this mean? I’ll give a few examples:

-New Super Mario Bros. 2 for the Nintendo 3DS offers free DLC, titled the Gold Classics Pack, for their Coin Rush mode which contains classic levels from the franchise’s history, including World 1-1 from the original Super Mario Bros. on the NES. This game also offers three extremely difficult levels, titled the Impossible Pack, for hardcore gamers for $2.50.

The Binding of Isaac offers cheap (~$3) DLC, titled the Wrath of the Lamb, and contains more levels, almost double the items contained in the original, and adds in new, alternate rooms to explore on each floor.

These are two examples that I feel are DLC done right? Why, exactly? Let’s break it down; I’ll list what the original games have and what their DLCs contain:

New Super Mario Bros. 2

Original: 9 worlds with a total of 92 action-filled levels (a full game)

-Free homage to classic levels in the franchise
-Extremely challenging levels that are too hard to put into the original game in fear of players quitting, so they’re offered as an extra challenge

The Binding of Isaac

Original: 5 floors of randomly-generated rooms with roughly 50 different types of monsters out to kill you (a dungeon-crawling, roguelike game) and 100 collectible items to help you get through them

-98 new items
-A new mode: Challenge Mode – tackle 10 different challenges
-11 new achievements
-34 new secrets (unlockables)
-4 alternative floors to the first 4 floors, and 2 extra end-game floors
-6 new room types that could appear on each floor
-26 new enemies
-More stuff I don’t want to list

If you look, these games were complete before the DLC came out. The DLC is icing on the cake and is not necessary to fully enjoy the game. The DLC is extra content added for those who want it and wasn’t originally planned to be put into the game. Oh, and the DLC is priced at less than $5, so it’s not like paying the price of an entirely new game and getting less for it.

Now let’s go back to micro-transactions in most mobile games. I think they compromise gameplay at the benefit of making extra profit, and I think this is a bad thing. To start, let’s think about why people play video games. In most situations, it’s to get away from reality and explore someone else’s imagination packaged into a computer program. When you’re scrolling through the shops in these games and you see something cool, you check its price and then get bummed out because it costs you money in real life. Not only does this completely break immersion, reminding you about your reality, but it also makes you more hesitant, if not completely turn you off, from wanting to get that item/feature in the shop because it’s unobtainable through normal gameplay.


An example of micro-transactions in a mobile game. Note not only the ridiculous prices but how much emphasis is put on the real-world prices. The real-world prices are at the top and clearly stand out more than the in-game prices underneath. It looks more like you’re checking out items on Amazon than an in-game shop.



The same image as above except edited to remove the real-world prices on each item. Doesn’t it look much more like an in-game shop? These now look like items you have to actually earn through gameplay. Such a small change makes such a big impact on how the player perceives the game.


As a game designer, why in the world would you NOT want your players to obtain something you programmed and made art for? Imagine creating an exciting game mode that took you months to make, only to have very few of your players actually experience it because you wanted some quick cash for a part of the game that was originally planned on being included. It just doesn’t make sense to me at all. If you want quick cash, do something else; feeding off those people that always buy everything isn’t exactly the best way to represent yourself either. In fact, it actually sounds JUST like a scam and that’s because it is indeed one. The worst part is this is happening right now in one of the most dynamic mediums ever: video games.

A couple of days ago I played Spider-Man and Venom: Maximum Carnage (SNES) and the day before I played Sonic The Hedgehog 3 (standalone, Genesis). I played one playthrough of each game to completion, and I never got up from my seat until I was done. I was completely immersed into the games, and it was a great feeling. I didn’t have to worry about not being able to obtain something unless I shelled out money for it; what I saw is what I got. Everything IN the game is what is accessible. With micro-transactions in all these mobile and Facebook games, what you see is not what you get. What you see is MORE than what you get, and that’s just dumb and stupid.

Childish remarks aside, it really is disappointing to see the game industry go this way. What’s worse is that people support this direction by paying for these things that frankly, they should already have when they buy the game. Micro-transactions seriously go against the art of game design, whether the games themselves are free or not, because they kill immersion and limit access to their game’s features.

That’s why I’m making any possible DLC in Streets of Peril 100% free, and I said “possible DLC” because I’m including everything I’m planning into the game. If any ideas come to me after the game’s release then I will gladly work on them and offer them as free DLC. After all, why pay for something you already bought?

New Feature – Bonus Status Effects

Hello again everyone! I’ll just let you know that the subjects of my posts may be all over the place sometimes, so unless I mention it on another post then the next post won’t be on a particular aspect of game design or even Streets of Peril.

Anyway, onto this week. I finished my finals and presentations for my senior project and I have over a week off from school. I spent the past few days working on a new feature that I think will prove beneficial for Streets of Peril.

In short, it’s called a Bonus Status, and it grants the player a positive status effect when the player performs well. The main inspiration for this was one of my all-time favorite Beat ‘Em Up games, Spider-Man and Venom: Maximum Carnage for SNES (there is a Genesis version too but I think they’re mostly the same). They have a special bonus move called a Power Hit, which is an extremely powerful attack, and it procs when the player has high hit accuracy and doesn’t get hit too often. Your health bar will blink faster as you get closer to obtaining it.

So, I implemented something similar that will better utilize Status Effects in my game. I always thought that something was lacking in the core gameplay, and I knew it had to do with Status Effects because those are the main unique features in Streets of Peril that influence combat.

How it works is the following: every time you kill an enemy, you get closer to obtaining the Bonus Status, and every time you take damage you get further from obtaining the Bonus Status. When you’re close to reaching it, a small generic Status Effect icon will appear above your Status icon (or where it would be if you have no Status Effect) and start blinking. As you get closer by killing more and more enemies, it blinks faster until it finally stops blinking, in which case you’ll receive a positive Status Effect. If you currently have a Status Effect when you’re supposed to receive it, it’ll be put on hold until your current Status Effect is finished. You don’t know which Status you’ll receive until you get it. I don’t want to go into all of the details regarding which Status Effect you end up receiving, but the Status Effect the enemy you killed currently has and the possible Status Effects that enemy can spawn with heavily influence the choice.

Here’s are pictures of what it looks like:

The Bonus Status icon on the upper left side of the screen. It is represented by a gray arrow. I finally learned how to upload images onto WordPress!

The Bonus Status icon on the upper left side of the screen. It is represented by a gray arrow. It is currently blinking, but you can’t see it because it’s just an image. I finally learned how to upload images onto WordPress!

This is what it looks like when you already have a Status Effect and can't receive the Bonus Status; the gray arrow remains above your current Status Effect icon until the current Status is over.

This is what it looks like when you already have a Status Effect and can’t receive the Bonus Status; the gray arrow remains above your current Status Effect icon until the current Status is over.

Overall, I think it adds a little more flavor to the game and keeps things interesting by properly rewarding the player for performing well. I was always fond of seemingly-simple systems in games that have hidden complexity, so to have one of those in my game was icing on the cake (the cake being the feature itself, of course).

Well, that’s all for now. Until next time!

Streets of Peril – Then to Now

Hey everyone!

It’s been a while since I’ve been busy with my senior project in college, but I’m back. Unfortunately I don’t have videos ready of Streets of Peril’s development, but I do have some screenshots:

These are some early HUD designs for Streets of Peril. The first one shows the level and time at the top with player information on the left. The character icon and name are at the top with the health under them and lives to the right of the health. Under those are the current Status Effect, with its remaining duration under it, and the score to the right of it. The little icon under that is the character’s oxygen tank its health, which are present only in underwater levels. If your oxygen tank takes damage, it loses health; lose all of your oxygen tank health and you lose a life. Note the special icon for Status Effects: in this build, it would display one even if you did not have a Status so I ended up removing it because took up unnecessary space.

The second picture is more recent; the score is at the top, with the character’s Status Effect, icon, name, and lives under it. Under those are the amount of times left to heal from a Healing Over Time (HoT) item and the player’s health. The “Clam Shell” text you keep seeing is the temporary HUD that displays underneath a player’s normal HUD when interacting with an object. The Clam Shell item grants the Defense Boost Status for 10 seconds, which explains the character’s bluish tint.

The third picture shows all 4 players on screen in Versus mode. The score and lives have again been moved down and Wil’s special Free Bullets are to the right of his name. Since Wil’s offensive and defensive special attacks involve the use of his gun, he is granted free shots that regenerate every minute or so without using a special. Any shots that hit enemies after they’re used up will damage Wil like special attacks normally do for every other character.

Here’s the recent build of the game:

One obvious thing you notice is that the window size is much smaller! Since this game is made in XNA, the default window size is 800×480, so I stuck with that for a good bit before finalizing other aspects of the game. The switch to this 416×320 size was rough to say the least. I was forced to utilize all the space I had as efficiently as possible, but the result was great in my opinion. Here we’re in Versus mode with all four characters. You may notice that there’s no bar showing how long a Status Effect lasts, and that’s because all of these Statuses will last indefinitely. If the Status Effects lasted a certain amount of time, the icons wouldn’t move and instead there’d be a small bar under them like in the third screenshot (which showed the bars even with indefinite Status Effects). The score has been moved underneath the name, and the character icon rests vertically in between the name and score. Wil’s Free Bullets have been moved underneath the health, and to the right of those would be the Oxygen Tank icon (which now turns more transparent the less health it has) and the number of times you have left to heal from a HoT item. The temporary HUDs now work properly and display more limited information when interacting with other players. Overall, I think this design is great, but it may need a little bit of tweaking in the future.

You know, looking at all these pictures just shows me how far I’ve came. I’ve focused on so many small details, even ones that aren’t important at all or weren’t planned, and let my creativity run loose so I can deliver a polished, enjoyable game to players. Every little thing counts in game development. You may be tempted to ignore the little details, but putting just as much effort into them as the core mechanics and visuals differentiates good games from great games. Look at some examples of great games and you’ll see the same trend: Super Mario Galaxy includes an entire backstory that has nothing to do with the core game, but it gives it that much more charm; The Legend of Zelda: Ocarina of Time allows you to change the tone of the notes you play on your Ocarina when in reality you need only one (this gives players the freedom to do cool things like this: The Halo series is famous for having super secret hidden Skulls and Easter Eggs which contribute little to gameplay aside from aesthetics and a sense of accomplishment (Halo 2 Scarab Gun, anyone?).

It’s these intricate details that blow players away and show them how much effort you really put into your game. And we certainly know that people love it when they use something they know was made with love, passion, and devotion to the art. Game development is no exception, so if you’re an inspired indie developer, don’t compromise the quality of your product and make something truly great.