or: I made a game and can't understand the code.

JUGGERNAUT: Awakening is the first of four games in the series made with VoidForce and Mattlaaa. It's a turn-based RPG with a few quests and medals to unlock. The story progression is pretty cool if you're into reading (if you've gotten this far, you might be). The code for an RPG usually doesn't have anything complex, just lots of tedious interactions. But when your code is terribly written, it starts to become a headache...

First compile: Nov 12, 2012
Last compile: May 31, 2013

We (I) went at a pretty relaxed pace since there was no deadline or anything. A lot of that time was either me trying to figure out how to do something or me fixing what I just broke. During the last few weeks, the game was up on FGL for potential sponsorships, but not many people want an RPG since the reading and filesize deter a lot of viewers, plus the game isn't THAT good. So, we put it in Mochi distribution to get it to spread while uploading it manually to the more popular portals.

Biggest problems:
Game was too hard, few bugs, kinda bland, slow-paced. There were some issues with balance initially, but you kinda get used to the game after a while of creating and testing it. But since every other comment mentioned it was hard, we lowered the levels and buffed the stats some. Not sure if it was enough, I think people are comparing the game to something like Pokemon where you can handle plenty of fights before getting healed up. The game looks and feels like Pokemon, so I guess that's a fair comparison. I'm definitely gonna push for mouse controls next time; part of the reason my code is terrible is that I couldn't use native events to control the flow of the game, and I had to store which button you were currently highlighting rather than the mouse telling me where it was. Apparently the keys are a bit awkward as well, I guess I just got used to them. And there are a few bugs, but I really don't want to look at that code anymore. The other issue was that it was bland, kinda generic. RPGs are all about cliches and tropes, but there wasn't really anything to set this one apart.

What went wrong: (a lot)
When you're making a prototype, it's fine to be a bit unorganized and ignore OOP. That's how it started, a demo of collisions using alpha maps. Then entering and exiting maps/houses. Then NPC interactions. Then quests. Then battle. Then items and the shop. Then cutscenes. Then saving and loading. Then the main menu and preloader. Then sound. Then fixing battles. Individually, a prototype for each of those would be fine since I was always experimenting with how to do them. But at no point did I refactor my prototyped mess. Every other day, someone would bring up a bug, most often in the battle sequence. Then I'd patch it up by adding a boolean or two to account for that corner case. Then those booleans created another corner case, etc. It was the equivalent of ignoring your car's windshield when it has a crack in it, eventually it spreads and you have to replace the whole thing.

Between when I started coding the game and when I thought I was finished, I learned some things. Applying those things while keeping the messy code from before is what confused me the most, to the point where now I can hardly understand what's going on. After getting virtually slapped by PSvils from 5000 miles away and remembering a discussion we had in Flash forum a while back that I kinda ignored (I'm an idiot, I know), I learned how to organize my mess for the future. Initially, I was going to basically reskin the game and add whatever new features for the sequel, but I'm gonna have to rewrite the entire thing to make any sense of the code. Organization, that is the lesson.

Another issue is that I didn't code with the future in mind. The more immediate future, like adding the next function of the game. With more forward thinking, my transitions wouldn't be hacky and all over the place. I would have structure in my code, not having half the variables persist after starting another save file (probably why the game crashes for some people, though I haven't gotten it to happen in 3 months of testing). I would have added functionality for the cutscenes to appear in battle: the pm containing "This cutscene will occur before the battle ends" made my code die. After that one, seeing that I had pms from Jordan in my inbox made me uneasy cuz it usually meant something else broke. And it always took me about a week to replicate the bug, longer to fix it. There are still a few bugs cropping up, but ehhh. I don't think redoing this engine for this game has much of a point: the game will probably be off the front page by the time I redo anything. Of course the next ones in the series will have a much better system. Idk, the code makes me queasy, but I feel like some people want to re-play the game bugless. I can go ahead and shelf it as a lesson learned, but is that selfish? I mean I've known about that bug for 3 months and it hasn't shown up for me once... *also I think some bugs are caused by not using the latest version of Flash player*

What went right:
The ideas that I prototyped are pretty solid. The alpha maps which tell the game about collisions and stuff worked fairly well. Any issues were usually resolved by "making the blue bigger" which was the color of the hitbox for certain things. The extra png per map would have been an issue with filesize, but they only contained like 5 colors tops and png compression is apparently really good. Without music, the game is about 1.5MB. I played around with the compression settings in Flash for a bit, but then I somehow fucked the sound quality to an unrecognizable state and it wouldn't revert. The total file size was under 6MB, but the audio was painful to listen to. But I had everything backed up in the cloud, so my mini heart attack didn't get any worse. So maybe it could have been a smaller filesize without making the audio sound like a dying hyena.

The cutscene engine I made is great compared to the rest of the crap that makes this game run. All the commands are in an XML file, and the code just reads the next line and executes the command rather than hardcoding everything (do people actually do that?). It never got to the point where I could tell the writer himself to add cutscene elements to the file; maybe with JSON it would be easier. However, I looked at the cutscenes more than 100 times each, so changing up the positions or how far the characters needed to move was easier for me to do anyway. It got messy towards the end when I needed to play sounds and show attack animations in a cutscene, but besides that, it's excellent.

Somehow it got frontpaged and daily 5th, so I guess that's cool.

And most importantly, I finished it. Since most of the image files were made before I ever needed them, there was never the bottleneck of me not being able to test something since I didn't have the art *cough*RobertSabrinaZachary*cough*. And the lack of a deadline certainly helped, especially since I had no clue what I was doing and Spring was my semester of death at uni. I mean, I still consider myself a fledgling game dev, so I'd say this went fairly well. This was a big learning experience for us (I don't know if Matt learned anything new about making music, but I learned enough to make up for that).

So, what's next? Refactoring the hell out of Juggernaut I's engine is pretty much necessary for the future games to be glitch-free. I think the art is mostly done already for II, so I have plenty of things to work on when we're ready to start it. Though we might go back and add some flair to the sprites.

If you've gotten this far, you definitely don't hate RPGs for all the reading involved. Go play one now. Preferably mine.