Thursday, April 17, 2014

End of March Progress Report

Oh wow! March just flew by didn't it? Well, time to put our best foot forward and work hard this April. It's going to be a month full of hard work and-
Oh... geez, April's already half over...
Well, uh, I guess I've been making good progress on my "Power Game" prototype that I've been documenting all year. Yeah, let's take a look at the progress I've made on that!
Uh... well, shit.

Real Talk

So, what happened?
The answer is a lot of things happened. Work at my day job started to get really hectic towards the end of February and that's still going strong, so I've had a lot less energy by the time I get home each night. Then there's been some tough times for friends of mine, so I wanted to be available to them, further diminishing time I had for working on the adventure portion of my game. When I did work on my game, I managed to make it really tedious to put text into the game and since my plan had been to write out the story, that made me loathe to work on the game. 
Perhaps the biggest problem though, is taking a step back and looking at my project's scope. I've designed an art heavy game and I have no means of making the art. I mean, I've been making do with my horrible approximations of art, but it really doesn't do much for morale. I see what other people are doing in less time and I feel like their smaller, simpler (graphically) games are doing more for them because they're actually learning things and making finished projects.

I haven't been completely delinquent in my game development though. I've created a few small projects experimenting with different parts of Unity, and while that's been fun it hasn't created anything very impressive or fruitful.

So What Now?

Well, I've identified my problems, and I've taken some time this past week or two to recuperate. I'll probably take most of next week easy as well, but my goal for April is to have a small finished game. There are three things I think will propel me towards hitting this goal:
  1. Greatly reduced scope. Despite my best attempts to check myself before I wreck myself, I keep trying to make games that are beyond the amount of time I have available. So part of what I'm doing with these small projects I've been making is busting myself down to the smallest possible scope I can let myself have. It sucks, but it has to be done.
  2. Ludum Dare 29 is happening on the 25th of the month. I'm going to participate and make a small game in 48 hours. The last time I did this, I actually came out of it with something, so hopefully a small scope and a hard deadline will kick me out of this slump.
  3. There was a job opening at XSEED Games for a Localization Editor. From the job description, it sounded like a dream job for me. I thought I met all the qualifications rather well and then some, but they told me that my background was too technical for that position and that I didn't have any sort of English degree or professional writing background. They're absolutely right, of course! I've taken five years of creative writing classes throughout high school and college, I've completed nine first drafts of novels in the last ten years and written several short stories, but none of it has ever been published! Tons of people have done this as well, so I'm really not special in that regard. If I want to get that sort of dream job in the future, I need to get published. I need to have work I can point to and say "I don't have a degree in English, but this is what I've done and here's how people have responded to it." Basically, I'm disappointed but determined to not miss out on such a chance in the future.
So for now, I'm going to try to relax and be in a good place for Ludum Dare on the 25th, keep up on my small projects in Unity, and come May 1st I'll reassess where I am and figure out what I can do to make a game in eight months. I'm down, but I'm not out yet.

Saturday, March 1, 2014

End of February Progress Report: More Prototype (also HDD failure)

Prototype Progress

Not a lot got done this month due mostly to a lot of stress coming from my day job. However, I did manage to find some time here and there to flesh out the framework for the Adventure portion of my game. Unfortunately, there isn't a lot of visual stuff, so here's a single .gif that shows off all the new stuff:

Here's what was in that gif:
  • A Config menu skeleton
  • Working saving and loading functionality
  • A title screen
  • UI Event scripting (e.g. display this portrait at this location, animate the portrait, change the portrait, remove the portrait, etc)
  • Word wrap in the message box
  • A lot of data validation and error handling
This is all pretty basic adventure game-y stuff, but it felt good to get it all set up and the work I did this month will make things easier for me down the road. Luckily, these things didn't take as long as they could have because of previous experience I have from making two Adventure game engines in the past.

Goals for March

It has come to my attention that March is NaNoReNo which basically means that there's a bunch of internet people making visual novels this coming month. It sounds like fun and will probably be motivating, so I want to participate. The only way I can do this though and have it not stop progress on this project is if I put together a rough draft of the adventure portion story! So that's my goal for March: create a rough draft of my adventure story IN ENGINE. 
Those last two words are important because my engine is definitely not finished. As I go about creating a rough draft, I'll learn a lot about what my story is even going to be about and I'll run into things I want to do that the engine can't perform yet. Finding these things will lead to me implementing those features at least in a first-pass form. With this goal in mind, I should also end up with a lot of rough art and features that will make for a very lovely post next month.

Roadbumps

A big part of the reason that not a lot got done this month is because of stress from my day job, but as hinted at in the title, the rest of the reason is that my windows drive is dying. All my work has been backed up, but watching my computer slowly die has really slowed down progress and everything else on my computer as well. An SSD should arrive today (Feb 28th) so hopefully by the time you read this post, everything will be resolved. (Edit: Everything took longer than expected, but all data is safely on a really fast SSD now)

Feedback

Please let me know what I can talk about in the coming month or what I can do better on posts in the future in the comments below.

Friday, January 31, 2014

End of January Progress Report: I Have a Prototype!

At the start of the year, I resolved to focus my efforts on making one game this year and making as best I could. I said that I wanted to spend January on designing the basic concept for my game and picking an engine. So, here's what I've accomplished this month:

Design 1

I've written down some bare bones designs for three games. The first idea is a game that I call "Legally Distinct From Chibi Robo" because that pretty much sums it up. There was recently a new Chibi Robo game on the 3DS which is not quite as charming as its predecessors, and I was musing on how I would make a game of that sort. I sketched out some ideas and wrote a bit about what I thought would work.

Design 2

The next idea is one I've had mulling around in my head for a while and will probably end up trying to make eventually, though it will not be my focus this year. It's a fusion of falling block puzzle games like Tetris or Puyo Puyo and the Visual Novel genre. This idea is pretty dumb and I'm honestly not sure how fun it would be, but also I'm not entirely sure how I'd pull it off, so it's gonna stay on the back burner. I did, however, write down a bit about it for future reference, so I wanted to mention it.

Design 3

Another idea I've had was to make a series of Warioware-esque microgames and string them together with a loose story and themes. Simple one or two button games that could be a fun distraction for an hour or two. I've had this idea in the past with rhythm games, but I lack any sort of musical talent, which makes rhythm games pretty much impossible.

Design 4

The last idea is a fusion of adventure game exploration and 2D platformer arena fighting with RPG elements. Your character is entered in a tournament where every fight is to the death. Winning fights allows you to increase your stats so that you can be more powerful next time as well as affecting the adventure portion of the game. The other big feature of this idea is multiple branching story paths, some of which are only available after you've cleared the game once. Ideally, the game shouldn't take long to play through start to end, but there will be plenty of (sometimes radically) different endings to see and different things to do.

And the winner is...

As you may have guessed by now from the level of description, I'm going with the final idea for my game this year. I really wanted to do "Legally Distinct From Chibi Robo" but 3D art is currently just out of my reach. Even for placeholder stuff. It's a problem I really need to address, but I keep putting it off. The second idea is much simpler than the one I'm ultimately going with, but I'm less confident about it being good or fun in any way. It really needs some prototyping and I think it needs more time on the back burner anyhow. The third idea I think could easily be done inside of a year, even with my hefty art handicap, but I want to try for something a smidge more ambitious. For now, it's relegated to being a fallback plan.
Design 3 inspiration...

...and this is what I made.
The zoom and mouth close are triggered when you push the "A" button.
This is art.

Engines

So what about picking a game engine? I'll get right to it: Unity 4.x is the only possible choice for me. I've got a bit of experience with other frameworks and game engines though, so let's quickly run through them to see why they aren't going to be the right choice for this game.

XNA is a very powerful framework based in C#. If I made my game with it, I could easily publish to PC Desktop and Xbox 360. With more effort, I could probably also port to Mac and Unix. However, part of my game's design this year calls for action segments that play sort of like a 2D platformer. And I have a storied history of frustration with making platformers on XNA. XNA would work, but I'd rather develop in an easier environment if possible.

RPG Maker is pretty neat, and is actually flexible enough to include the sort of platformer and adventure gameplay that I want, but like with XNA it's a bit too much work to get it to happen. I really love RPG Maker though, and I feel like people give it a harder time than it deserves, but really it's better for games where RPG elements like stat building and equipment management is a bigger focus. Also, RPG Maker can only really deploy to PC Desktops, which is fine but I'd like to potentially port to more systems.

Construct 2 is a really fun little game engine. It deploys to the web with HTML5 and it's very newbie friendly. This makes it fantastic for prototyping and the editor is really good about visualizing your design process for you. However, it's a bit too newbie friendly right now. Debugging is a nightmare and it's really hard to go in and make major changes to big systems due to the very visual nature of the programming involved here. Recently the engine has been getting better, but I need something that I can easily debug right now.

At this point, my options are rolling my own engine (nix on this because it'd be even more work than all of the above put together), using GameStudio (I'm really not familiar with this and past attempts to familiarize myself had not gone well) or Unity.

I'd actually tried to learn Unity 3.5 before, but gave up because I didn't have any 3D modelling skills and Unity is a very asset driven environment. What has changed now is that Unity 4 has been released which contains a bunch of new features which includes expanded support for 2D games, which just happens to be what I want to do (and what I can make crappy placeholder art for)!

Prototype Progress

In order to make sure that Unity was the right choice for this year's game, I decided to try prototyping a bit with it. I goofed around for a while and read tutorials and looked at sample projects before starting, but once I got started, I was surprised at how quickly I was making progress. With that in mind, I want to show you my prototype game.

Adventure

Part of my game will be very story driven. You'll explore a city of unfortunates, oppressed by those in power. There will be different people to meet and, as the story advances, different choices for you to make. One of the big things I want to do with this game is let the player take the story in a lot of different directions and cause many different outcomes. In the animation below, you can see the map mode, which will let players travel about the city (it's very basic right now and only lets you go to the arena or quit out of the map). Then, you see a city street where the player can interact with people (who will be) on the street. You can also check your character's progression on the stat screen and level up your abilities for the fighting portion of the game.
This will eventually look more like an adventure and less like a first grader's art.

Action

When not exploring the city and being wowed by character drama, you'll be in the arena, fighting to the death against various opponents. This part of the game is tricky to make work right, and will need a lot of attention. It needs to be fun and deep enough for seasoned players of games like Mega Man X and accessible enough for players who maybe don't care as much about the fighting bits. I also want to include mid-battle cutscenes and dialog to spice things up depending on choices you've made in the adventure section. Finally, while I have some great ideas for the different battles players will come across, there won't be too many of them. This is for reasons of scope and ability, after all, I'm only one person and everything cool I add will need art and I am, obviously, not great at art.
This is some of the progress I've made on the placeholder player character.

Technology

Speaking of art, one of the things that has always impeded my progress in the past is taking the time to animate all the characters and such in a game I want to make and then putting it in the game and finding out it looks horrible. One of the chief reasons I wanted to pick Unity 4.x over other engines is that it has support for creating 2D animations of a given collection of sprites very easily. I could do things the old fashioned way and draw separate frames for each animation or I could front load a lot of the work and animate each piece of the character individually. As a means of demonstrating what I mean, take a look at this:
Cut my life into pieces
What you see above is all the art for the placeholder character. Each piece of the character was chopped up and loaded into it's own gameObject in Unity which allows me to create animations by dragging parts around and rotating them- rather than drawing key frames and flipping between them at a convincing speed. This placeholder art isn't perfect by far and there are lots of weird areas in the gifs I've posted above that you can see some strange things (like a hand becoming disjointed). But also keep in mind that I was able to create that art and all the animations you see on this page in about three hours.
I gave my game a walking loop.
Games love walking loops.

Conclusion

So, did I achieve my goal for this month? Very much yes. I have a design, I have chosen an engine, and I even have an okay prototype. This month was a resounding success. However, it's all uphill from here. This month will ultimately mean nothing if I don't keep moving forward with this.

So what about next month?

February's goals are going to be for me to flesh out the adventure portion of the game code wise. If I can get a solid foundation there, then I'll be in great shape to tackle the fighting arena portion of the code in March. This means that there may not be a lot of great screenshots for me to post a month from now, since all the juicy bits will be related to things like text processing, but that's just how it goes.

Feedback

I know this was a long post, so thank you for reading this far. Please feel free to give me some feedback in the comments or directly via my e-mail. I welcome suggestions to make these blog posts better and if you have any comments or suggestions about the content of the article I'd love to hear that, too!

Thursday, January 9, 2014

A New Year and New Goals

Last year, I sat down and decided that I was going to release one RPG per month. They didn't have to be complete games and they didn't have to be very good, but they had to be kind of done and I had to release them. Looking back, it uh... well, it went incredibly poorly. I released two games, one of which wasn't even an RPG, and made a lot of progress on another, but mostly I was just feeling frustrated with myself. Eventually I got interested in the MSU-1 and did some stuff with that instead (which I'm still working on, by the way. I just haven't had much progress to report lately).

This year, I'm not doing that stuff. I want to settle on one game design and work steadily towards it over the course of the entire year. I'm not saying I should be done with the game by the end of 2014, but I want to be able to look back and be proud of how much I've done.

I feel like it's a personal flaw that I can't release one game per month for the entire year, but... I just can't. I want to make games for a living, but I just need to focus on what I can do for now. I can focus on trying to live up to my personal expectations later when I have more experience.

My goal for January and February is to create a design document for my game for the year, and also to select an engine. This may take a while because I want to explore game engines that I don't have a lot of experience with, such as Unity. So there might be a lot of learning involved in these two months. Either way, at the end of each month I'm gonna post my progress here and possibly solicit feedback.

Friday, October 11, 2013

How to Enhance an SNES Game With the MSU-1 - Part 2: Slow Progress in the Face of Adversity

When last we left off, everything was terrible and there was no documentation anywhere. Well, there's still very little in the way of documentation, but not everything is terrible any more!

Update: Part 3, the climatic conclusion to this series is now available.

And thus, progress was made.

Let's get right to the good stuff that I really want to show off: MUSIC!


The biggest development since the last post is that I now have music playing in the game and it sounds pretty frickin' sweet! I have about half the soundtrack replaced in the game right now and the only tracks I have that aren't in the game are the epilogue and credit scroll. So you can't play from start to finish without noticing that things are missing, but you can wander around much of the game and not notice!

How did this happen?

This is a great question and not one I can entirely answer. I was working with my patch code and trying to figure out why nothing was working when it just started working! There's very little in the way of helpful documentation out there and I've been largely unsuccessful in getting help in forums (though admittedly I haven't tried as hard as I absolutely can... yet) but I think that the reason it began working has something to do with getting my assembler to write with 8-bit registers instead of 16-bit registers. I'm not 100% sure on this though, but I've been thoroughly avoiding looking this gift horse in the mouth for the time being and just focusing on getting everything else working before going back and fixing this.

At the end of this adventure, whether it ends in success or I give up out of frustration, I'd like to post what code I've got online in the hopes of helping others somehow. Perhaps when they come looking for a way to program for the MSU-1 on Google!

Why isn't this done yet?

There are, of course, problems still. The music doesn't play in the latest version of Higan and it doesn't play in bSNES v060 (which is the oldest version I can find online and the one that has debugging tools). Instead, it only plays in bSNES v075. I have no explanation for why this is, though I'm sure it relates to why my code suddenly started playing music. Time will tell on this one.

Another problem is that although I've got about half the soundtrack inserted into the game, I don't even have the other half of the soundtrack! As you can hear in the video above, I've been using the Zelda ReOrchestrated album for A Link to the Past as a source for the music. The main reasons I've done this is because these songs sound great and they're pretty close to the in game tracks in terms of pacing and such, so they match up with cut scenes and events in-game well. Though perhaps the most important reason I chose to use ZREO's soundtrack is because it's free to download. Anyone can download the soundtrack, convert the music via an application (WAV2MSU) and a batch file I can distribute with my patch and then just have everything work together in the same folder. I could die happy if Blake Robinson did the entire soundtrack to this game so that I could just use that, but then people would have to pay for the soundtrack, and I'd like to have a freely distributable version to go with the patch. The ZREO soundtrack is not complete though, and missing tracks are things such as the Guessing Game House theme which people don't cover very often since they aren't as memorable as, say, the Dark World theme. So not having half the music in the game is a big problem.

Then there's still a handful of programming problems to tackle, with the main one right now being fading the music out. In Zelda 3 when you transition between areas and the game tells the music to change, the SPC code gently fades out the currently playing music for about a second as the screen changes, then the new music kicks in. Since I'm bypassing the SPC almost entirely now, I don't get this and there are sharp transitions between pieces of music as you can see in the above video with the transition from the church to the light world theme or the transition into Kakariko Village towards the end.

Things are looking up

The good news is that all of the above problems are being dealt with. Where the last blog post on this ended in despair and uncertainty, this new one ends with hope.

Byuu, the guy who made bSNES/higan, is pretty active on his own forums so figuring out why the rom plays music in one version of his program and not another is probably just a matter of getting his attention for about five minutes so he can point out what I'm doing wrong. Then I can go and correct it. Even if I can't flag him down though, things are at a point where it works SOMEWHERE which is a lot better than when it didn't work at all anywhere!

A music major friend of mine, Shane Johnson, has agreed to help fill out the soundtrack! So there won't be any sudden silences or shifts to the original soundtrack. This is fantastic news and is much better than my fallback plan (learn to compose).

Finally, I've been trying to get the fade out loop to work with varying degrees of failure. In theory it should be pretty simple, just check to see if we're fading out and if so decrease the volume by a smidge and do this once per frame. The problem is finding the right way to do this without throwing off the rest of the program. For example, I would think that the NMI function would be the place to do this, but when I do, I get something like this:

Which is not ideal. I'm confident that I can fix this if I just spend more time experimenting and studying the code, but it might take a while.

If you know anything about any of this or would like to offer your help in general, please feel free to get in touch with me!

Sunday, August 25, 2013

How to Enhance an SNES Game With the MSU-1 - Part 1: There is No Documentation Anywhere

UPDATE: Here's part 2 if you've been here before!
Extra Update: Here's part 3 if you've been here before!

Introduction

Hello! In this series of articles, I'm going to document my first foray into the world of SNES romhacking. I have a specific goal in mind that I want to achieve, but it will be easier to show you rather than tell you. Please watch a bit of this and in particular, pay attention to the sound:


That's the game I want to hack. Zelda 3, more popularly known in North America as The Legend of Zelda: A Link to the Past. What I want to do with it is this:


How this is possible requires a brief history lesson. Back in the day, Nintendo worked with Philips and Sony to try and get a CD drive add-on to the SNES. It didn't work out. However, in developing his highly accurate SNES emulator bSNES (now called Higan) a person by the name Byuu implemented a co-processor chip called the MSU-1. The MSU-1 allows for the SNES to, among other things, play CD quality audio. The guy in the video above, as far as I can tell, never released his code for getting the MSU-1 to work with Zelda 3 though, but since I know it's possible, I've decided to attempt to replicate his work myself.

I'm afraid that the basics of assembly are too much for me to go into here (not to mention my own tenuous grasp on them), so instead I'll refer you to some tutorials.

Getting Started


So let's say we have our game's rom file, a hex editor and either the latest version of Higan or an SD2SNES. These are the minimum tools we need to get this show on the road. Now, there's a very nice guide here which tells us roughly what code we need to get the MSU-1 to play audio. I call this the Kawa document, and we'll be referring to it several times in our quest for MSU-1 audio in Zelda 3.

So now we have the code we need to get audio playing. Using the Kawa document, we also note that we need an audio file to play and an XML file. The XML file in the Kawa document says that part of it depends on the ROM. Sadly, I have been unable to find any sort of reference document which states exactly what goes into the XML file. There is a tool called SNESPurify though, which will generate an XML file for us, and then all we need to add is the <msu1> element from the Kawa document's example. 

Also mentioned in the Kawa document is that we need a data file, either gamename.msu or msu1.rom. What is in this file? The Kawa document doesn't say exactly and I've been unable to find much in the way of definitive documentation on that either. However, I did manage to find several forum posts which say that the file simply needs to exist, without any data in it, to signal to Higan that the code being executed uses the MSU-1. For the time being, I'm assuming that the empty .msu file is what I need.

Next we'll need some audio to actually play during our game. After a lot of looking around, I decided to use the Zelda Reorchestrated soundtrack for Zelda 3. It's free to download and stream and it's a very nice sounding take on the original soundtrack. It might not be perfect (for example, I haven't checked to see if this soundtrack will loop properly) but it's good enough to get started with. With a quick application of wav2msu tool, we have some valid .pcm files to use.

Now all that's left is inserting the code from the Kawa document into the rom.

Editing the Game

The first thing we need to do is find where the game changes the background music. This is a bit tricky and varies from game to game, but the general bits of it are the same. The SNES SPC-700 is the chip that deals with the sound in your SNES and the way you communicate with it is by reading/writing memory addresses $2140 - $2143. If you follow the code with a debugger you can find where it writes a value to memory and signals a change in music track. Once you have found this point in the code, you've found where you need to hijack the code.

In Zelda 3, for example, at 09F4A6 in RAM (LoROM I think?) we get the code to load value 0B into the accumulator and then store that value to $012C. This plays the fairy theme at the file select. This is the point where we need to hijack the code to play our own MSU-1 fairy theme. There is some unused space in the ROM at 04EC1C where we can write our own function to play our music. So our first step is to jump to a subroutine at that location. We start at 0004F6A6 in the ROM (which is 09F4A6 in LoROM). Together, the LDA and STA there already use 5 bytes, so we have to make sure our own code matches. Here's the code I'm using presently to replace those 5 bytes:
22 1C EC 04
EA          
The first four bytes are a JSL jump to our unused space in the ROM where we're going to write our function, and the last byte is a NOP in order to not disturb the code around the hijack point.

The next thing to do is to convert the code in the Kawa document to something we can use. Combining code from the section about checking for the MSU-1's presence and the section about playing an audio track, we get this assembly:

LDA $2002   \ Checks the first letter of the MSU ID
CMP #$53     |it should be 'S' which is hex 53.
BNE #$13    / If it isn't, we skip over the MSU-1 code.
LDA #$FF    \ Set the volume to 100%
STA $2006   /
LDA #$01    \ We set the track number to track 1
STA $2004   /
STZ $2005   | The MSU-1 won't play until we set $2005
LDA #$03    \ We set the MSU-1 to play the selected track
STA $2007   / on repeat.
RTL         | We return to the hijack point. This is the end of the MSU-1 code.
LDA #$0B    \ This code is only hit if we skip over the MSU-1
STA $012C   | code. This just plays the normal non-MSU-1 song.
RTL         / This is useful if the rom is played on something which doesn't support the MSU-1.
 Compiling that code by hand, we get:
AD 02 20
C9 53 D0 13 A9 FF 8D 06 20
A9 01 8D 04 20
9C 05 20
A9 03 8D 07 20
6B A9 0B
8D 2C 01
6B
So, we take our hex editor to  00026E1C (04EC1C in LoROM) and start copying that hex in. At this point, assuming that our folder and files are named correctly, we should be able to run the game in Higan or the SD2SNES (or any other emulator that correctly implements the MSU-1 chip for that matter) and be able to hear a nice CD quality musical version of the fairy theme when we reach the file select screen. Except we don't.

What Goes Wrong

1) Higan currently doesn't care for the Kawa document. At the very least it doesn't like .xml files, opting instead for a format called .bml which seems pretty similar, but there still isn't any information I can find about what exactly is supposed to go in there. Just a few scattered example files that people have posted for various games. Even using these examples as a template, I've been unable to get Higan to load my edited game at all. In fact, the only version of the program I've gotten to work with it is bSNES v060! And even then it suffers the same problem as when I try to run it on the SD2SNES...

2) SD2SNES doesn't play the MSU-1 music either! This is especially unfortunate since this is the platform I care about getting this to work on the most. Unfortunately, if Higan's specifications for using the MSU-1 have moved on, then the SD2SNES has been left behind and any new tutorials that will be written for the MSU-1's use in Higan won't apply to the SD2SNES.

3) The SD2SNES apparently doesn't recognize the MSU-1's presence! When I run my code on the SD2SNES, it appears to compare the MSU ID but then it branches and plays the normal music track. I used the bSNES v060 debugger on my patch and noted that the value it was getting from $2002 was in fact not #$53, leading me to believe that I must be doing something wrong in my code because I have other MSU-1 enhanced files that play fine on the SD2SNES. It is just mine that doesn't seem to work. It doesn't help that every example I can find online doesn't seem to do anything different from what I'm already doing.

4) The documentation for this chip is too scarce. I've sifted through every forum thread I can find on google that mentions the MSU-1 looking for some sort of technical information, but rarely have I found anything concrete and the Kawa document is the closest thing I've been able to find to a tutorial on how to use the chip. Also a bit maddening is that many of the resources that are linked point to byuu.org which makes sense since Byuu is the one who made the MSU-1 A Thing. However, back in May of this year, he redesigned and migrated his website and hasn't reposted all the old content yet. After a lot of frustration and thinking, I found that the wayback machine has a cached copy of the MSU-1 article from his site, but unfortunately it doesn't have much that helps me with my above problems.

5) I've posted a thread asking for help on a rom hacking forum, but no one has replied yet. I'm at the point where I'm attempting to post on Byuu's personal forums asking for help, but I really wish I didn't have to bother the people who frequent it since I'm sure they have better things to be doing than helping some stupid newbie. Another roadblock to posting on Byuu's forums is that I need to get my account approved by an administrator which hasn't happened yet despite having signed up a week ago.

Conclusion

I'm pretty much at a dead end right now. I would LOVE to be adding the ability for myself (and others) to put a custom soundtrack into Zelda 3 and other games, but I'm finding myself unable even to get a single song to play!
What's the most frustrating though is that I can't figure out what's wrong. I've tried following every example I could find online, but none of them have been able to get this working on either SD2SNES or Higan (or any of the many versions of bSNES I've downloaded).
Unless I can get someone to tell me what I'm doing wrong and nudge me in the right direction, there will never be a part 2 to this series.

Update: Good news! There is a part 2 to this series now! Click here to check it out!

Sunday, April 28, 2013

Ludum Dare 26 out of nowhere!

Well, this isn't an RPG, but it's my 1 Game a Month this month!

I heard on Friday that this weekend was Ludum Dare 26, a 48 hour game competition/72 hour game jam. More info can be found at www.ludumdare.com/compo



Anyways, I decided almost unconsciously that I was going to do it and... well, I did!

Click here to play my game, "War in a Bottle" right in your browser! Can you beat it? Probably! It isn't very long! I apologize for some of the jumps being tough.