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!

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.

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!

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!

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.

Resolution Smesolution: Adventurers University Part 1

Last month's RPG was a resounding failure on nearly every level, and I haven't posted anything here about the current month's RPG so it must be going equally terribly and will miss its end of month release as well, right? The answer here is yes and no.

Character creation courtesy Neon Black's composite character script!

First let's talk about the current month's RPG. In my last post I mused about maybe making an episodic game which would let me reuse certain assets like maps and characters between games and ideally help me to put out better games on a more timely schedule. Specifically when I said this I was thinking about Adventurers University (abbreviated afterwards as A.U.).

I should mention that all the dialogue you see in this post is first draft.

A.U. is an old idea a friend of mine had when we were running a Dungeons and Dragons campaign together. It was a school dedicated to crafting the finest adventurers and attracted all the best talent. The curriculum wasn't stuffed with boring lectures, but was hands on and mission oriented. Each student was matched up with a team of three other students and managed by a mentor (an experienced adventurer who had proven themselves and likely retired from full time adventuring). When I ran my first quest with my group in this setting one of the players called it "the best session I've had in years." So after February's crushing failure, I think it's not unreasonable for me to want to revisit something that had previously gone so well.

In this month's game, you are a new student at A.U. after being forced to leave your hometown. Luckily, you were recruited by a teacher at A.U. who was passing through your village at the time. The game begins with you arriving at the university and meeting your teammates. Then you're quickly whisked away on your first mission to the once great town of Loamhurst where all you have to do is deliver a package. However, trouble is afoot in Loamhurst and the task may not be as easy as you first think...

I feel like choices are really important in RPGs and JRPGs are usually lacking in them. I'd like to change that.

I lost all my notes from the first time I ran this game back in college, but it's stuck with me and I recall pretty much all of the important details. The challenge is in adapting this all to a computer RPG. In my original run of the game time management was an important part of the adventure as was a bit of code breaking. These are easily adapted (or discarded as in the case of the code breaking aspect) the challenge is replicating the feeling of having a living world for the player to interact with. In Dungeons and Dragons the person running the game just needs to adapt to whatever the players decide to try, but in a computer RPG you have to plan all the contingencies and all the things that the player wants to try in advance. In short, you need to offer a convincing number of choices.

Choices should always matter! Even the small ones.

The problem here is that doing this game right means a lot of choices and a lot of choices means a lot of dialog. I can do this, but the chances of me getting it done by the end of March is slim. There's just too much to write, balance, playtest and fix before the end of the month. So this game will probably miss its end of March release date.

There will be a lot of recurring characters in future months. If all goes well...

At the same time, this is going too well to just get abandoned. Also, I really will be able to reuse assets from this game and that will be a big help. So what I'm saying is that while it'd be really cool to release one game each month, I can't always do that, but if I keep abandoning unfinished projects at the end of each month, I won't ever release anything (also I'll just get burned out). This month gets a pass then, and if I don't release this game by the end of this month, then it will be released by the end of next month.

February RPG: "Red Strings of Fate" Not Being Released!

Well that month went by quickly.

Sadly, February was a spectacular failure on my part to actually put rubber to the pavement and get the work done. It's so embarassingly unfinished that I can't even bring myself to put what little there is up for download. Instead, I'll use this post to explain what my goals were and what actually managed to get done. Since February has Valentines Day in it, I decided that it'd be great to do some sort of romance themed game.

Here's some pictures of my failure in progress.

The Plan

In my head, you'd be able to choose between a few different characters or create your own of either gender and then select one of 4 - 6 romantic interests (also spanning both genders). The story would begin with your character lamenting their lack of high school love life in the way that teenagers do, but then your character would mention finding a summoning spell.

At this point the lights come up on the protagonist's room where we find that you've already managed to summon Cupid to your aid. Cupid, being trapped until you fulfill your goal, lends you the power to see and manipulate (to an extent) the red strings of fate that attach soulmates to each other in myth and legend.

She's such a unique character.

Your choices are so diverse.

Then you are fully equipped to set out on your quest to woo your chosen one. You set out and endear yourself to them with the aid of "endearment points" which let you see a bit into the future relating to your loved one. So for example, in the screenshot below, Helen is about to run out of fabric for a sewing project. Wouldn't it be so handy if you were just passing by later with the fabric she needed? So you go out and grab some fabric and after you give it to her your red strings of fate are closer together. After you repeat this twice more (giving me a nice three act character arc for each romantic interest) your strings are close enough that you can go to an endearment point at a location close to your interest's heart and twist your strings together, thus binding the two of you together for eternity.

Now what I wanted to do here was let you get to the point where you are about to twist those strings and then decide that you're manipulating their feelings towards your end and that's not how relationships should work. Your character dismisses Cupid and works towards a lasting relationship with the romantic interest the old fashioned way: without super powers. The game ends on a positive note.

This screenshot shows you being far off from some lovin'.

Initially I was going to just have some sort of "bad end" where you ended up with this more or less completely devoted love-slave and your character goes on doing their thing. The more I thought about it, the more this didn't sit well with me because in a lot of games where pursuing a romantic interest is the goal the player doesn't consider the feelings of the (fictional) character that they're pursuing and wouldn't this be a great place to say something about that?

My revised "bad end" wasn't an ending at all. Instead, your character would throttle Cupid and take his powers for yourself and select a new romantic interest from the previous list (minus your new boy/girlfriend who is totally okay with this because they're your mind-slave) and continue the game with your previous conquest at your side. Eventually this would again escalate and- well, I won't bore you with all the details but you get the idea.

What Went Wrong

I am a master map designer.

There were three major problems that led to my disaster this month. The first is that, as you may have guessed, my scope was WAY too big. There's just no way I could've done all that work in one month; not that I expected to in the first place, but just having such lofty goals can be discouraging. The second was wanting to use art assets I didn't have. I envisioned this as a modern day setting RPG and I couldn't see it working any other way. I didn't have art for that setting already, so I had to go and get some because as I've mentioned elsewhere on this blog, art creation is not my strength. Not having acceptable art led to me spending way too much time looking around on the internet for proper art assets and then fiddling with them to get the art just right and then trying to build maps so that I could build the rest of the game. The result was incomplete maps that I wasn't happy with and no game.

This map isn't so bad though. Just not good.

Finally, I just didn't put in enough time. At the start of the month I knocked out the red string of fate interface pretty quickly and was happy with that, but then I stopped working on the project for most of the rest of the month. There were days here and there where I'd pick it up and do a bit of work, but it was never enough to actually get anywhere. Then, when I was reaching the end of the month in the past few days I was panicking and cutting scope drastically but there just wasn't enough to build on.

I can blame things like Fire Emblem Awakening coming out or claim that maybe I had some burnout or something, but at the end of the day the fact is that I just didn't put in the time to make it good. Which sucks, but I guess that's the lesson I need to take away from this: just because I'm using a tool (RPG Maker) that does a whole lot for me up front, doesn't mean that I can slack off on working consistently. Like Perry Dawsey would say, "Ya got to have discipline."

This is the point last night where I gave up.

Looking Ahead

So even though I'm a bit dejected from my failure this month, I'm mustering up hope for March. I want to do something that doesn't require any extraneous art assets and something that can keep me motivated from month to month. I think this means that I should shoot for some sort of episodic thing. I don't know. Gonna keep thinking about it and worst case, I'll just wing it tomorrow. Whatever I do, I want to make more blog posts about what I'm up to, so stay tuned.