or: I need to stop writing my own code.

Previous Post Mortem.

Uprising is the second of four games in the Juggernaut series with VoidForce and Mattlaaa, and like fifty voice actors this time around.  I'd call it a success if I wasn't the one who had to look at the code.   In Flash Forum, people like milchreis and myself always tell newbies to "stop reinventing the wheel" and "use someone else's tried and true code."  This game taught me that I should take my own advice.

First compile: August 6, 2013
Final compile (so far): July 7, 2014
Lines of code: 18,097 (good grief)

The Bad:

Close your eyes (figuratively) as you picture typing words for almost a year.  That was me.  Eleven months is a long-ass time to be making a flash game.  The core features were finished by November, and coding menus and polish took the next seven months.  Coding menus should not take that long, but it does if you write your own code.  If you think playing an RPG is tedious because of all the battles and dialogue, you should know that coding a menu is worse.  More tedious than Gary Motherfucking Oak showing up after beating the Elite Four.  Does this button look good here?  When the game takes 10-20 seconds to compile, and it takes 30 seconds to get to the menu in question, your sanity dwindles as you realize it needs to be moved over by 3 pixels.  Wait, no, too much, go back a pixel.  I could have done a thing in those wasted minutes.

Then you realize that this isn't the first time in history that someone has had the same problem as you.  I mean, sometimes you just gotta roll your own isometric engine, but when it's so common of an issue, someone has surely written code to do it for you.  And when you find that code, you realize that it's written in a different (coding) language.  Or that using it would set you back several months.  So, out of necessity than volition, you keep on using your crappy code.  Thus was coding this game.  That button looks off now, it should be moved back another pixel.

Every time VoidForce wanted a change, I was the one who had to implement it.  I wanted him to correct a spelling mistake, but there was no way for him to.  He messages me at some nonsense British morning time, and I wouldn't have a chance to do anything about it until after class (or after I woke up at noon).  Changing an enemy's hp, compiling, uploading to NG, and PMing him that the change was made is a complete waste of time.  Next time, he will be able to change anything he wants.  Change where someone moves in a cutscene.  Change how much hp an enemy has in this map.  Change the order that dialogue gets spoken.  Change which audio plays in this map.  I won't need to touch it.  The next game will basically be a parsing engine that takes in a bunch of files that we both can edit.  GitHub or DropBox, though Git is a bit overkill.

My code sucks.  AS3 sucks.  The game's memory usage sucks.  Coding menus sucks.  Testing sucks.  Bug fixing sucks.  Yet the game gets daily 3rd on NewGrounds behind automatic-1st-place movies from SexualLobster and LazyMuffin, and it's been featured front page this entire time.  It seems that a game can be made of suck and still do pretty well, mainly because everything I've complained about is invisible to the player, bugs excluded.  But according to analytics, players like it in the first 6 minutes, then most stop playing.  On average.  Most people don't play past the first minute.  Preloading much?

The Good:

Analytics. Data.  The purest form of understanding a game's success.  Almost every aspect of the game is being tracked.  How long does the first quest take?  12.03 minutes.  Which site has given the game the most traffic?  uploads.ungrounded.net (NewGrounds).  What percentage of people who start the game finish it, and how long does it take?  0.33% and 4.74 hours.  How many people used a feature?  Not enough to warrant adding it next time.  If the average user plays for 6 minutes, and the first quest takes 12 minutes to complete, the average user does not complete the first quest.  We can use that knowledge to place emphasis on earlier immersion in the next game.  With 475,132 events tracked so far, we have a decent sample size to make judgements like these.  This image is people who click the game and people who press play vs time.

Last time I wrote that finishing the game was a good.  This time, being finished with the game feels better than finishing it.  It's my penultimate project written in AS3; one more until Haxe rules everything around me.  It was painful to code in AS3 knowing that I could be happily coding something else in Haxe.  The next game will be a pleasure to code, so that post mortem should be a happier read.  I'm not sure if it'll ever be "game was good, I had no issues" like I predicted a year ago, but there will be less complaining and more flowery, chocolatey happiness.

I can't enjoy the game because all I see is my code.  And my code is a pile of suck with analytics tracking how much suck there is.  Luckily, that mentality doesn't affect the game or the players, just the comments in my code.

Juggernaut II is better than the previous game, and the next one will be even more so.  It will be written in Haxe OpenFL ("A mobile version of the game?!" you ask.  No, go away).  And it won't take a year to finish.