Sunday, December 6, 2015

New Project: Unnamed RPG Maker MV Game!

It's been a while since I last posted anything on this blog and a lot of projects have come and gone in the meantime. The simple fact of things is that I've been busy (getting a new job, moving, having a baby, etc). But it's time to start a new project, this time in RPG Maker MV!

RPG Maker Again?

When I was a kid, I went over to my buddy Drew's house a lot. One day, Drew showed me some weird, half-translated program he'd downloaded somewhere called RPG Maker 95. From there, my life was changed forever.

This past October, Degica released the new RPG Maker MV! It boasts a number of improvments over previous iterations, most notably replacing RGSS3 (their proprietary Ruby build) with JavaScript (something I'm much more familiar with as a web developer) and mobile app export capabilities (though as it turns out there are some significant downsides to this).

To get used to the application, I've decided to make a small game in it. If possible, I'd like to release it on my new (upcoming) website. I figure I'd like to document the steps I'm taking as a way of thinking through things a bit more.

Oh, So The Game Makes Itself For You With RPG Maker?

No. No, no, no, no, no. It vastly lowers the barrier to getting started, sure, but making a good RPG Maker game is hugely more difficult than what people typically expect when they hear about this tool for the first time. With this lower barrier to entry, lots of people pump out low-effort games and perpetuate this other weird perception that games made with RPG Maker can't be good (some Steam releases sure haven't helped with this). It would be more accurate to say that games made with RPG Maker can more easily be bad. If you look at good RPG Maker games you'll see that not only are they possible, but they can be downright amazing! They just take a lot more effort.

What Makes Your Game So Good?

The games I linked above are both VERY customized. They have custom art assets, custom music, and a lot of time and effort poured into their mechanics. As evidenced elsewhere on this site, I am not great at spriting or drawing and it may surprise you to discover I am not good at making music either. The most I can hope for is to make a game with some interesting mechanics and then to make it available for little or no money (this is a complicated topic that I'll expand on later as the game draws closer to completion).

What Mechanics Are You Offering Then?

I'm going to be combining things I've learned from past projects documented on this blog and elsewhere to create a short, open-ended adventure with the following neat ideas:

  • Multiple paths story paths
  • Class based skill system
  • Monster ecosystem and population modelling
  • Light supply & demand modelling

This is all subject to change, of course, and I'll be expanding upon these ideas more later, but I think this is a good starting point. Please look forward to my next entry where I'll discuss the game's critical path.

How to Enhance an SNES Game With the MSU-1 - Part 3: Failure and Success

Previous entries in this series are part 1 and part 2!

Utter Failure

In my first post in this series, I said I was going to document my foray into the world of SNES romhacking and I did. I learned a lot of assembly and had fun for the most part. But did I successfully create a patch for Zelda 3 to use MSU-1 music? As you may have guessed by the 2+ years between the last entry in this series and this one, the answer is a resounding "no." And that's okay.

It's Not So Bad

Frankly, I just didn't know enough about what I was doing. I didn't know enough about the MSU-1. I didn't know enough about the implementation of it in the SD2SNES. I didn't know enough about the SNES assembly language. I still don't know enough to do this sort of thing! That's okay, I've got plenty of other interests to pursue.

So why am I posting again after all this time? Well, I did want to document what has happened since I wrote the last entry in this series since those two posts are by far the most popular on this blog (and rightly so). I feel obligated. It's just taken me a while to get around to it. If you're reading this to attempt writing your own MSU-1 patch, perhaps I can offer you just a bit more guidance.

What Little Advice I Can Give: Ask For Help

The one thing I didn't do enough of was asking for help. There are plenty of people in the romhacking community who have already done this sort of thing. There are forums where you can post and ask them questions. There is absolutely no guarantee that they'll respond, and nor should there be. I didn't ask for help almost exclusively because I didn't want to bother these people. What right did I, a total newbie, have to ask for help if I hadn't tried myself first? Well, I did try and I wasn't getting anywhere. I should've asked for help. 

I want to stress that I am not one of the people you should ask for help. Everything I know about the MSU-1 I've documented here in these articles. I've provided links to everything I found. Ikari_01, developer of the SD2SNES even reached out to me on the comments offering to help. I should've taken them up on it, but by the time they reached out to me, I was already fed up with romhacking and had moved on to other things. If you're reading this, Ikari, thank you for your offer. If I ever try this sort of thing again, I'll not pass up such opportunities. As it stands, though, I got so frustrated with my lack of knowledge and progress that there's no way I can bring myself to try again.

A Link to the MSU-1

So where does this leave Zelda 3? It's gotten the patch that I always hoped it would, actually! Back in October 2014, Conn79 got in touch with me over GitHub where I'd posted my patch source code telling me that he'd been working (with others) on a similar patch. Luckily for everyone, he had succeeded where I'd failed! You can check out the thread about his patch here!

It turns out that all my work wasn't entirely pointless though, as it gave him the clue they needed to get SD2SNES working. You can read our discussion, with a bit more technical details of how it was accomplished as well as a link to the disassembled patch that was finally produced. And did you catch that bit at the end of our discussion? They asked for help.

Final Thoughts

Romhacking is super cool and I'd love to learn more about it and give it another shot some day, but for now I'm happy to sit on the sidelines as folks who have more experience than I do crank out great translations and cool patches. I'm perfectly happy to focus more on my programming craft for my day job and my hobby game development that I've covered elsewhere on this blog.

If there's any questions I can answer or any notes I can publish from my romhacking attempt, please let me know and I'll make it happen.

Good luck, all you MSU-1 folks! Please make lots of great music patches for me to play!

Monday, August 11, 2014

End of July Progress Report: I have taken a break

My goal for July was to take a break from programming my game and not do any programming outside of work! I was tired every day from my day job and forcing myself to work on the game was getting more and more difficult, so I wanted a break.

Did I meet my goal?

Yes! I did almost zero programming in July outside of work!

What did I learn?

I learned quite a few things, actually. First, I was reminded of the importance of pacing myself and being flexible with my schedule. I've actually delayed making this post for so long because I was going to Otakon this year and it just seemed like I didn't have the time for writing this up until today. Going forward, I intend to set myself a flexible schedule that still has some hard requirements that'll force me to keep making progress.

Also, by taking a break I allowed myself a lot of time to reflect on my project and consider it from different angles for a long period of time without having to fret about whatever I was changing that week. It has made me reconsider the worth of the voice mimicking in my game and later this month I'm planning on reviewing the code for it entirely and either removing the feature or streamlining it further.

Finally, I was reminded of the importance of doing things other than playing and making games. I haven't watched a lot of TV or read books lately. Being at Otakon and sitting down to watch some shows I hadn't seen before reminded me of how much you can learn just by doing things that aren't "working on your project." I need to block out time specifically for this each week as well as blocking out time for working on my game. It feels awkward, or even wrong to be spending time on "frivolous" things that don't contribute to my project goals, but it's super helpful overall.

Goals for August

This month, all I want to do is focus on level design. When I think about how to make a level for my game right now, I'm frankly just not sure where to start. How do I keep levels from feeling boring? How do I make levels interesting? How should I make levels at all? By the end of August I want to have some sort of answer for those questions, however incomplete, and also have at least started working on 5 different levels for my game.

Tuesday, July 1, 2014

End of June Progress Report: I'm taking a break

This'll be a short post.

I'm taking a break from game development for the month, even though it's killing me to do so. My day job has been really stressful and consequently I haven't had a lot of time to do game development in my free time. This has really sucked, but there's been no way around it and I keep beating myself up about not doing more, but that really doesn't help with my stress levels (and I would like to note here that I feel I am typically quite good at dealing with stress).

I'm feeling burnt out and work isn't going to be less stressful for another month at least, so I'm giving myself permission to not work on game development. In fact, I'm going to force myself not to work on it with the assumption that this break is just for the month of July and that this will help me be more energized to do the work in August.

No small part of me worries that not being able to handle this all at the same time means that I could never make it in the games industry. However, I've been reminding myself that if I were in the games industry, I (probably) wouldn't be working literally all day for six days of the week.

I don't know. Guess this is just another part of my grand experiment. Feeling kind of down this month.

On a positive note, I finished my first playthrough of Analogue: A Hate Story tonight and it was great! Also, I'll have some more things to post about the MSU-1 soon, so hopefully people will look forward to that; especially the people who have been posting in the comments of part 2 of that article series!

Sunday, June 1, 2014

End of May Progress Report: Core Features

Earlier in the month, I made a decision to really challenge myself and make my Ludum Dare 29 entry ready for a full release on PC and/or Android by the end of June. I also posted a list of things I wanted to do to the game before I released it. I've reorganized my list into several categories of descending importance: Essential, Secondary, Polish and Dead Last items.

What's done

I don't have as much done this month as I'd like because of things at my day job cropping up and causing a ton of stress. However, here's what I do have done (and keep in mind that I've omitted a lot of technical detail and additional notes under each of these items):


  • Make rooms you can go into from the hallway
  • Add suspicion for the NPCs when you are in an infected host
  • Add voice mimicing mechanics
Adding rooms (and a method of travelling between rooms) is a big upgrade for my game since the ludum dare version is nothing but a series of hallways. Now I can make much more interesting mazes that can be more convincing as a science facility.
NPCs will now act with suspicion when they see you. If you're outside of a human host, you get recognized as an escaped alien parasite instantly and they will react appropriately (Scientists will attempt to run away and call guards and guards will attempt to murder you on sight). However, if you're inside a human host when you're spotted by an NPC they'll stop and consider you. Perhaps your eyes aren't aligned quite right, or perhaps your human host is twitching oddly, but eventually any NPC looking at you will notice something is wrong, assume you're an alien, and react appropriately.
The coolest feature, in my opinion, that I've added is the ability for the player to hear certain phrases spoken by NPCs and then, when inside a human host, parrot those phrases back. So, for example, early on you can learn to say "Hello." This comes in handy when a guard or scientist is suspicious of you but has not yet decided you are an alien in disguise, you can say "Hello" to them and they will respond back with something like "Oh, hey Jim." and their suspicion is eased.

What's left to do

There's plenty left to do from my list, but near the top of the list is creating a method of deciding what thing the player wants to say when they're inside a human. I've been working on this, but Unity's GUI tools have a long history of not being great. Recently, however, there was an announcement about new GUI tools that are coming out some time this summer. In light of that, I'm going to write a quick hack to get around not having a UI and then try to put it off for as long as possible in the hope that I can use the new GUI system.

Here's the rest of the to do list (again, abridged):


  • Make a menu or something to set the voice clips
  • Add switches that toggle doors on and off
  • Remake the first two levels with the new stuff (e.g. rooms)
  • Add at least three new levels


  • Clean up my code base
  • Make new art for all the new levels
  • Fix the resolution on the windows build
  • Add touch screen controls
  • Make an animation for background doors opening and closing
  • Make an animation for hall doors opening and closing
  • Make animations for characters walking into and out of doors in the background and make them play


  • Add music
  • Add sound effects
  • Add a menu
  • Add an ending
  • Fix movement bugs
  • Fix guard animations
  • Tighten up the elevator script
  • Make new art to make the levels feel lived in
  • Add more voice work
  • Maybe add a sound effect and a start-up time to bursting so that you can't do it on accident?
  • Fix Bugs

Dead Last

  • Test all my new levels and mechanics
  • Release the game for $1 on PC
  • Release the game for $1 on Android and iOS

Goals for June

I'm going to stick to my guns for now and try to knock out all of these things by the end of June. I am, however, very doubtful that this will happen. I may miss my deadline and this will take until sometime in July. Releasing this game is an important step in my quest to get a job in game development.

Next month should also have screenshots since, as soon as I'm done with this post, I'm starting on reworking levels. The changes this past month weren't very visual.

Saturday, May 10, 2014

A Change of Plan

I work best on a tight deadline and I acknowledged as much during my last blog post. That fact has been stirring around in my head for a few days now and I think I'm going to do something crazy and change my May goals.

Below is a list of all the work I have left to do on my Ludum Dare 29 game, Beneath Your Skin (not necessarily in this order):
Add music
Add sound effects
Add more voice work
Add an ending
Fix movement bugs
Fix the resolution on the windows build
Add suspicion for the NPCs when you are in an infected host
Add voice mimicing mechanics
Add at least three new levels
Add touch screen controls
Make new art for all the new levels
Make new art to make the levels feel lived in
Make rooms you can go into from the hallway
Tighten up the elevator script
Fix guard animations
Test all my new levels and mechanics
Release the game for $1 on PC
Release the game for $1 on Android and iOS

My new goal for May is to do at least half of that list. My goal for June is to do the rest.

Why the rush? I've known for a while that the best way for me to get a job making video games is to just start making video games. The problem is that I'm not finishing anything. To fix that, I'm going to do something crazy and just devote as much as my free time as I can handle to just shipping a game. The game will probably not be as good as it could be, but it will be something I feel good about releasing to the public and that will have to be enough.

Release or bust.

Monday, May 5, 2014

End of April Progress Report: Ludum Dare 29!

Last month ended pretty shamefully with me not working on my prototype much at all. However, it's May now, and I need to review what I did manage to accomplish last month and determine what I'm going to try to accomplish this month. Let's start with my prototype that I made (largely in January and February).

Power Game Prototype

The "Power Game" prototype is currently dead in the water. Editing the script is a huge pain right now and the whole project is larger than I can handle at the moment. Mostly the failure for me here is a lack of experience with Unity combined with a large scope and no art. It's being indefinitely moved to the back burner until it becomes feasible.

Ludum Dare 29

Ludum Dare is a 48 hour game jam where you try to make a game according to a theme all by yourself. No existing private code is allowed and any art/sound assets must be made by you within the 48 hour period. It's pretty intense; especially if you have problems with scope like I do. Compounding it further is my own lack of artistic talent, which is a problem when you have to make all the art yourself.

The theme this year was Under the Surface, so I decided to make a game where you played an alien parasite who burrows under people's skin and controls them from inside before bursting out of their chest like in Alien. My lack of artistic talent makes the game less violent looking than it sounds from that description, but I guess the violence is just implied. That's fine though because the more realistic the graphics got for a game like this, the less palatable it would be.
The exit is just behind this blue-locked door! But how to get there...

What went well

  • The art looks great (considering the artist). I'm pretty hard on myself for not being a very good artist, but when it came time to scratch together some art for Ludum Dare this past month, I feel like I nailed it. The art isn't super awful, and it's pretty easy to tell what everything is. 
  • Unity made adding new content easy. After several attempts (including "Power Game") at making a lot of code to drive the game forward, I feel like I really got close to The Unity Way of doing things. As a result, when it came time to start building new levels, it only took me an hour to put together the entire second level of the game. Most of that was fine tuning, since I was able to drag and drop almost everything else.
Hello there officer, I'm certainly not an infected human being
controlled by an alien parasite.
No, sir.

What went poorly

  • Unity and Monodevelop (the code editor for Unity) crashed on me several times. Monodevelop also stopped responding to mouse input on the list of opened files frequently, which would have been a problem if I wasn't already used to using keyboard shortcuts to navigate. More problematic was on Sunday around 9 hours before the deadline when I clicked between Monodevelop and Unity too fast (I think?) and got an error telling me that my code solution was unable to be overwritten. At that point, Monodevelop stopped being able to debug my game code. This persisted even after I more or less fixed it, and breakpoints only work in most areas of my code. This caused me a lot of frustration and stress. I lost about an hour or so to figuring out what was going on.
  • Levels went poorly specifically because I should've made more of them. There are only two levels in the current version of the game. My general unfamiliarity with Unity and uncertainty of what exactly I was going to build for levels made me over-engineer a bit and I took too long working on making the game work and not long enough making levels. Ideally, I would have spent less time debugging Unity's crashes (as mentioned above) and integrating art into the project (animating individual sprites for characters took longer than I was expecting because I couldn't simply swap out spritesheets) and a little more time working on more levels. I think a reasonable number of levels to shoot for would have been five.
  • Sound is very lacking in my game. There is no background music or sound effects. I had been planning on using to generate looping background music, but that fell through when I realized Unity didn't support MIDI and I had no way to make up for that with the time left in the competition. I did take some time to pull out my keyboard and try to make a 10 second loop, but it ended up being really grating on the ears after more than a few loops, so I just cut it entirely. The sound effects got dropped when I found myself spending the last hour or so of the event debugging a small error that completely broke the game.
Just a parasite hanging out in an air vent.

Overall, Ludum Dare went extremely well and really bolstered my confidence. I'm looking forward to seeing what feedback I get on it and I'll detail that here next month.

Pigeon's Quest

Pigeon's Quest is a game where everyone dresses like birds for some reason. I mentioned the title to my wife sometime late last year and it's been in the back of my mind ever since. Only recently (last month?) did I have the epiphany that it's based on the game Snake. If you've never played Snake before, you can play a basic version of it here using the arrow keys to move.

So far, I've got basic snake gameplay implemented. You move a smiley face around a game area and when you run into other people, they follow your smiley face appropriately. If you pick everyone up on a stage, it instantly takes you to the next stage. There's a lot to do, and after Ludum Dare I've got some ideas about streamlining what's already there. This is definitely a thing I want to work on some of the time, not all of the time.

I've got some neat ideas for innovating on the snake gameplay, so I'm excited about that. I'm very worried about the art though and when I come to that point, I think I'll just save up some money and hire someone who is far more talented than me to make the art. I'll update my end of month posts with any progress I make on this though.

Goals for May

When I left off with my April post, I mentioned that I wanted to use Ludum Dare to kick me out of my slump and I think I succeeded in that. As I type this, there are two pages of improvements and level sketches in my game ideas notebook for my Ludum Dare game. My goal for May is two-fold: I want to spend some more time developing my Ludum Dare game into something closer to complete and I want to work on Pigeon's Quest some more. I don't know if I can get either to a finished state by the end of the year, much less a state where I feel good releasing them, but I figure it can't hurt to try, right?


In closing, as I've mentioned I have been thinking about scope a lot lately. How big is too big? How do I recognize when my scope is too big for a project? How do I better estimate how much work I can do in a set period of time (a month, a day, a year)? How can I trim down scope for ideas I come up with that are too big?

I don't have any answers for that yet, but I am reading about it. For example, I recently found this article where a guy talks about how he loves making small stuff. I don't think that style and speed is for me, but it's definitely a good viewpoint and there's plenty of advice I could use in there.

Do you have any tips for dealing with scope issues? Do you have any links handy to articles or talks about people dealing with project scope? Please let me know in the comments!