Updated Game Projects Page

I spent some time today to revamp the Game Projects page. It looks much nicer, and there are now separate pages for each project, making it easier to show them in more detail. If you have any feedback on how I can improve it further, feel free to let me know!


Current Projects

Long time, no post. I’ve been caught up in my current projects and haven’t had the motivation to make a post for a long while.

I’ve spent roughly a year and a half working on and off on a recreation of the battle system from the first two Paper Mario games. I was surprised to not find a battle system similar to theirs online and decided to write one because I love those games. At the moment, it’s fairly flexible and the damage formula is close to 90% complete. Visuals and presentation are lower in priority than the core systems, but I’ve started putting a bit more effort into making it look good to better show what it’s capable of. I’ve learned a great deal about writing flexible, modular code by doing this, and I’ve grown a much fonder appreciation for open source engines and frameworks, such as MonoGame (which I can learn from), over closed source ones like Unity (which I learn very little from in comparison).

I’ve been reverse-engineering the Paper Mario games and using any resources I can find to better my understanding of certain mechanics. The next step to increasing my knowledge is to learn PowerPC and MIPS assembly so I can read the ASM instructions for the games and gather more details on their inner workings.

Last is a map viewer for my fangame, Super Mario Bros. Online (SMBO), that I wrote in several hours. I have the original Visual Basic 6 source code, so reading in the map files, which are stored in binary, was easier than it could’ve been. Even so, it took a while since VB6 has several language differences (Ex. fixed-length strings) and stores binary data slightly differently than C# and other modern languages. In SMBO, you can’t view the entire map because the maps are larger than the game screen, so it was nice being able to see my own maps in full after such a long time. The map viewer also includes a screenshot feature, which you can see the result of below.

Mushroom Kingdom Entrance

The first map in the 6-map large Mushroom Kingdom town (Map #183)


Long Overdue Update

Hello all. This past year has been very eventful and I have a lot to share.

To start, several months ago I made the tough decision to put Streets of Peril on hold for an indeterminate amount of time. It was too taxing on me to code during the week at work and on Streets of Peril over the weekend, so I figured I’d stay focused on one project for now. Additionally, I think it’s best if I just start over from scratch, since there’s still a lot of garbage leftover from before the refactor and it’d be easier to start it up again in MonoGame rather than port it over from XNA. Besides, I had a lot more fun working on and playing the Challenges in Streets of Peril and think it’d be better if I can form the whole game around that type of variety instead of tacking it onto a mostly generic Story mode.

Next up is the game I’m working on at my job. Before I get into the details, I want to emphasize that the company, me included, worked extremely hard on this game and I’m not trying to undermine our efforts in building it in any way. Out of respect for my company and coworkers, I won’t be mentioning any names, nor even the name of our game. This is mainly to raise awareness in how the mobile games industry is doing things and why I think it’s a problem. Now onto the details:

To be completely honest I thought the game started out great, but now I’m disappointed in what it has become. Although I still despise in-game shops that charge real-world currency for virtual items, I would have been fine with us having just a shop as our way of making money. Now the game has a big pay-to-win emphasis in that users who pay real money will undeniably have a clear advantage over users that don’t, going so far as letting users cheat (yes, cheat – details later) if they pay premium currency. On top of that, we implemented gambling-like game mechanics for no purpose other than to make more money (that was the answer I was given when I questioned it), and to receive special rewards you need to collect specific sets of items that you can obtain in the gambling process, (which is illegal in Japan for a completely valid reason but my company wrongly insists it was because it made developers too much money) which can easily cost users $500+ USD each.

About the cheating: in-game, your character can use a special ability a specific number of times. Once per game, by paying premium currency, you can use the ability an additional time. The special abilities were carefully balanced so that more powerful abilities had very limited uses, and this throws all that out the window and rewards players who pay to win.

Which brings me to my next point: compromising gameplay. If you’ve read my previous post about in-app purchases you’ll know what I’m about to delve into. However, this time I have more experience working with people designing these features, and it truly was eye-opening, in a bad way.

The criteria, if you can even call it that, for implementing a micro-transaction is if it’s convenient for us to do so. This means after a game is lost (or even won), when the user first starts up the game, and during the tutorial. So the user suffers through numerous popups, and the user is now allowed to forgo essential game elements and NOT learn from mistakes by simply paying money. But by constantly paying money, there’s essentially no point to the game because the user never needs to work their way up to anything and can always easily recover from their failures. That is not an involving game experience and is what I regard as bad design. If it wasn’t clear by now, that sort of design means that money is more important to the developers than the game itself because users are able to bypass everything the game is about by spending money. Actions speak louder than words; while I have no doubts there are numerous passionate developers out there, I fail to believe teams that say they’re passionate and treat their games the same way.

In addition to our unnecessarily large budget for this game, the mobile stores are all or nothing. This means that if we don’t hit big with this game, we probably won’t be here for round 2. I simply refuse to support an ecosystem that supports consumers’ sense of entitlement to get everything for free (the majority of profitable mobile games are free to download because users are hesitant to purchase software) and has no room for anything other than the most popular games. If you think I’m alone in my despise for in-app purchases, look at the comments on an article regarding them and in many cases you will find the majority of users against them.

I grew up in an age of gaming where games were highly immersive and made no compromises. From endless hours of gameplay to fantastic stories, games in that age were varied and truly enjoyable experiences. Developers ensured they made terrific games because people would not buy them if they weren’t up to par. I want the new generation of gamers to experience the greatness that I did, and I’m ashamed that the majority of the industry is failing to deliver this. I don’t want this generation to think that video games are just time wasters focused on pay-to-win schemes and spending large amounts of money. Video games are my life and I would rather quit game development altogether than work with the current, cancerous trends if they continue much longer. However, there is still some justice. The majority of these games will be dead shortly after they’re released since the industry generally doesn’t plan for the long-term. Meanwhile, one can still buy any pre-7th generation console game and play as long as they’d like, and that’s more important to me as a developer than any amount of money.

I know this post has been long, but to end on a more positive note, my work environment is fantastic, all of my coworkers are great, and I couldn’t ask for a better first job out of college.

Furthermore, I’ve been working on a Final Fantasy-styled turn-based battle system as a small side project and learning experience. I’m using SFML.NET (I think XNA/MonoGame is better so far), and I have a large portion of it done already. I will be posting a YouTube video of it in action in a later post when it’s complete.

Refactoring Mostly Complete

Hello everyone; I have some good news: all level objects now derive from the base class I talked about last time, completing a large chunk of the refactoring! Some things are partially broken, such as character hitboxes, but those can be fixed easily and are subject to change anyway, so it’s not a big deal.

Right now I’m currently rewriting the object movement code, since the previous code wasn’t too great on runtime due to its accuracy and was very hard to read. This new method of movement is awesome because if the player manages to get stuck inside a tile or solid object somehow, he/she can easily get his/her character out by simply moving! I wasn’t going to do this at all originally, but since I’m modifying collision detection anyway I figured it was appropriate.

I just wanted to share a quick update on the game’s status; until next time!

More Engine Refactoring

Hello everyone, I hope you all had a great holiday and happy new year! You may have noticed that I disappeared yet again! But I have some exciting news: I am officially employed as a Front-End Developer and am in the process of moving into my new apartment! I’ll be working in a new gaming startup to help build a fun new kind of game that will be released on mobile! So far the monetization techniques we’re using don’t get in the way of gameplay, so that’s great! The team is very small, consisting of roughly 8 people including me, so I’m sure it will be a very nice experience.

Onto Streets of Peril: I have been doing A LOT of refactoring to the game engine, and I finally have a very flexible base class for all objects that appear in levels. I have already properly converted Item Containers, Weapons, and Items to inherit from it, so I’m making progress slowly but surely. This new base class was inspired by the Unity engine’s GameObject class.

One of the biggest changes was separating the movement planes. Previously, a Move() method would handle movements in the X and Z direction, THEN handle height in the Y direction immediately afterwards. This forced me to always call Move() even if the object wasn’t moving in the X or Z directions to prevent it from being stuck in the air. With the new base class, the ObjectMove() method only handles movements in the X and Z directions and a method called ObjectFall() handles height in the Y direction and is called after the object performs its specific logic. This allows all objects to be affected by gravity in the same way, and I don’t have to write a single line of code to have this behavior present in a derived object.

Next, the base class implements most things far more efficiently! For example, I no longer check through every single solid object in the level each frame to determine if an object is grounded. Instead, I have a reference to the solid object the object landed on; I check if the object is still on it, and if not set the reference to null. If the object isn’t on a solid, the reference is null, which tells me object can’t be on a solid and allows me to simply check if the object’s height is the same as the tile it’s on.

Lastly, there’s SO much more flexibility thanks to this base class! By simply modifying values or calling methods, I can modify object behaviors and disable an object’s gravity, make it immune to Status Effects, stop it from Updating or Drawing, enable/disable collisions with walls, solid objects, or camera boundaries, and SO much more! It took a long time to write it, and I’m extremely satisfied with the results to say the least.

I could talk all day about the new base class; I’m just happy I finally have a solid foundation for my world objects. The knowledge I gained from writing it will also greatly help me with my new career since I’m one of the developers. I’m not exactly sure how much time I’ll be able to dedicate to Streets of Peril once I start my job, but I will definitely work on it as much as I can.

Until next time!

Game Projects Page and Streets of Peril’s Camera

Hello again everyone! If you haven’t noticed, I made a new page at the top titled “Game Projects.” Here you can check out various games I’ve worked on and even download and play some of them! I figured the blog was a great place to put it so I can give readers a better idea of my development background. I hope you like it!

Anyway, onto Streets of Peril. I haven’t done too much in the past week, but I did finish something significant: refactoring the Camera. It is now much more efficient in runtime and code and loads levels from the Level Editor in a more organized manner. I also removed a Vector2 variable called “OffSet” from the SubLevel class and now only depends on the Camera’s location for keeping objects onscreen when the Camera moves. It’s so much better and I’m glad I got it done!

Unfortunately, I don’t have much else to talk about. I’m simply going to continue refactoring and will do my best to finish soon. Until next time!

Streets of Peril – Design Changes

Hey everyone! Sorry again for suddenly disappearing, but I have good news: over the past couple months I have been working on a Windows Store game with my brother Alex titled Defend Your Fort, and it will be released within the coming weeks! Check out the Facebook page here and Like it to be notified of updates. The game will be free for the first week of release!

Anyway, onto Streets of Peril. As the title of this post indicates, I will be discussing the design changes I have finished for the game. I’m a lot more confident in the game now than before, and I’m currently in the process of refactoring a good portion of the code to facilitate the implementation of these changes.

There’s a very long list, so I’ll briefly talk about the important ones.


If you’ve seen the videos on my YouTube channel, you may have seen footage of underwater levels. They are some of the selling points of Streets of Peril since they do not exist in any traditional Final Fight-styled Beat ‘Em Ups (that I’ve played at least; do not hesitate to show me a game that does have them) and are thus one of many unique elements in Streets of Peril. Unfortunately, they weren’t very special if you look at them closely: everything moves slower, falls slower, and jumps higher. The only unique element is that all players and enemies have an Oxygen Tank which can be destroyed, resulting in an instant death. Aside from that though, underwater levels were essentially just a slower version of normal combat.

So when changing underwater levels, I came up with the following:

-Fighters (Players and enemies) can now swim in the water by jumping. This is very similar to how platformers like Super Mario Bros. handle underwater levels. While swimming, Fighters can move freely in the X or Y direction. There will of course be unique swimming animations for each Fighter.

-While swimming, Fighters have a limited moveset that excludes grabs or any special attacks pertaining to grabs. This means that Crystal and Grunt are unable to use their aerial grabs in underwater levels. Dashing results in a faster swim and access to a lunge attack.

-There are still combos while swimming, but some need to be revised to make more sense, specifically combos ending in kicks.

-Getting knocked down while swimming results in the Fighter falling back to the original height it was at before taking damage. This is currently how it works for my Diver enemy, which was inspired by Jet from Streets of Rage 2.

-And finally, when the Fighter is on the ground in an underwater level, its moveset returns to normal. This means grabs and anything else allowed in normal combat is allowed when the Fighter is grounded. However, jumping or falling off a ledge will put the Fighter back into the swimming state.

Oxygen Tanks will still be in underwater levels, so watch your back! Overall I feel these changes add many interesting dynamics to underwater combat and make underwater levels feel unique instead of simply feeling like slow-paced normal levels. Oh, and all of these changes will also be present in Versus mode!

Minecart Rush

I eventually found that I simply could not get the unique minecart level I had before to work from a design perspective. Fighters were limited to this tiny space in the middle of the screen, resulting in the enemy AI not working correctly since they had too little room to do anything. It was also not practical at all: players could simply hit enemies off the minecart as they fell down and easily beat the level. In turn, if players got knocked down by an enemy, they were pretty much instantly dead because they’d fall off the minecart.

As a result, I completely reimagined the level, and it now acts as a mini-boss battle. There’s one Minecart Rider enemy on the right side of the screen throwing objects at players, and the camera is constantly scrolling to the right slowly. Players have to hit the objects back at the Minecart Rider to damage it, and each time the Minecart Rider takes damage an enemy falls down. Players will have to deal with the enemies and the Minecart Rider simultaneously, maintaining the pressure that is prevalent in the rest of the game.

Bonus Tokens

Bonus Tokens are unique items that grant the player access to a Bonus Stage at the end of each level. Before the design changes, I did not know exactly what to do with them but was considering them to appear in item containers if special conditions were met.

Unfortunately, these special conditions would not only be annoying to implement but would also be impossible for the player to figure out unless he/she just happened to satisfy them on a particular playthrough. As a result I have decided to simply hide them in the levels. They’re hidden well enough so that you’re not likely to come across them all on your first playthrough, but you’re guaranteed to find them with enough patience and experimentation.

No, this doesn’t mean you have to go through every pixel behind the foreground in every sublevel spamming the Item key and hope to pick one up. Most of them will be visible in some way, and the ones that aren’t have some sort of scenario that makes them likely to appear. For example, the Bonus Token in Level 6 isn’t anywhere in the level itself, but if you wait long enough on the last bit of the Minecart Rider’s health, he will throw it at you instead of one of his normal objects. Cool, huh?

In short, I feel these design changes greatly improve the game and make it that much more unique. It’ll be a lot of work for sure, but at least I know exactly how everything should work, which makes my job much easier.

That’s about all for today; thanks for reading! Until next time!