So I ended up really liking my game, For A Small World This Place Sure Has Big Problems. In terms of what the game accomplishes, it's probably my favorite Ludum Dare game I've submitted.
However, I gotta be honest, I don't really expect that to translate into my highest score ever. Even though I feel like I nailed a bunch of my personal "big things", I don't think that those will translate into the "big things" that make up a particularly well-scoring game.
So let's talk about the good and the bad.
The Bad - My prioritization
Jesus christ you guys, I added so much stuff to my game - but so much of it was dumb and irrelevant stuff. Like, I spent tons of time on my cinematics - I was geeking out because I had just discovered that I could use coroutines in TypeScript for cinematics and I was amazed by how much faster I could code with them, so of course I overcompensated by spending even more time adding even more cinematics.
In the past, I've continually had this problem where I'll tack on a ton of features, but they'll all sort of be half baked. The same thing sorta happened here. The problem was that I had this storyline in my head where I was like "oh you should meet the professor, and then he should take you to his house, and then he should show you the earth... then you get sucked in... etc". The problem with this storyline is that the game doesn't actually start until AFTER "you get sucked in." So I did all that stuff, it took like a day, and then I was like, "wait a sec, I have no game..."
In the future, what I think that I'll do is immediately prioritize making a room where THE GAME IS ACTUALLY HAPPENING, exactly as it will happen in the final version of the game. In this game, it would have been a room where you're on the planet, the prof is tossing the planet around, etc. Not only that, but that room should look and feel exactly like the room will look in the final version. e.g. the graphics should all be in place, sound effects, particles, etc. I think it's really crucial to get that feel right immediately, and I totally failed to prioritize correctly to do that in this game.
That is definitely the single biggest thing I got wrong in this game.
When I said above that I don't think that my individual wins will translate into an overall good game, this is why. As much as I loved individual aspects of this game, a lot of them feel cobbled together with tape rather than assembled into a good game like, you know, actual good game developers will do.
This is very frustrating to me because I feel like all the pieces are in place for me to make a really good ludum dare game, but I end up focusing on weird/wrong things and screwing it up.
Sigh.
Live and learn!
The Average - My tools
So I basically decided with a day before the deadline to use a little scrappy library I had written on top of pixi.js for this game. This ended up being both a good and bad choice.
It was good because pixi.js is amazing. I swear, throughout the entire Jam, I think I only had one contention with pixi.js (something about RenderTextures not working). The library is simple and elegant. It works perfectly, and it's incredibly fast. Compare this to, say, phaser.js, which I had tons of issues with in the past - phaser is such an internally inconsistent library that it is incredibly confusing to get up and running. Even Unity is not as consistent as pixi is. PIXI I LOVE YOU.
However, using my own little library was probably not the best choice. The biggest problem was that I had hand-coded a tilemap library, which made every single tile a separate sprite. I had believed that Pixi could handle it, because even on my crappy system Pixi can handle 10k sprites. Well, it turns out that this is the Ludum Dare where I didn't just need one renderer... I NEEDED THREE. (One for left screen, one for right screen, and one to render the BACKGROUND of the tiny world screen.)
So instead of 10k sprites, I had a max of ~3000 (since the sprites were rendering 3 times), and instead of one screen of tiles, I had two, so that's only 1500 tiles a screen, which is a screen smaller than 40x40. Oh crap - my maps were actually larger than 40x40! So that 10k buffer - which I had thought to be a lot - was actually not enough, and my FPS was tanking. Let me just tell you, having perf bugs in the middle of Ludum Dare is one of the crappiest things that can happen to you. The last thing you want to do in LD is waste like 5 hours on trying to eek out an extra 10 frames/sec, especially because the methods by which you resolve perf issues (especially in JS) are often obscure and unclear. I consider myself to be a decent programmer, but god, I hate that so much.
...and so yeah, I did end up wasting a high number of hours on perf to get my tilemaps faster.
That all sucked because I knew that if I had used a real library instead of my own hacked thing, none of that would have effected my LD in the slightest. I know in Unity that Tiled2Unity just uses a single shader. I would have done the same, but coding up a tilemap shader is not exactly something I wanted to do in the time constraints of LD!
On the positive side, I used TypeScript. I am super duper proficient in TypeScript, and that language was never a problem for me. I guarantee it allowed me to code and refactor twice as fast as I would have been able to code using JavaScript. I love TypeScript.
On the negative side, the lack of a decent IDE for pixi.js kills me. Tiled is a great, great tool, but it's only a small part of the Flash-like IDE experience. I was a flash developer when I was a kid, and I have to say that I still haven't found anything nearly as elegant or refined as the Flash IDE was back in the day.
It's so frustrating to have to restart your game every time that you make a change to the x coordinate of something to see if it worked out in-game or not.
The Good - My Music
I thought that my music was awesome! And apparently so did Newgrounds, because they frontpaged it on their site almost immediately after I posted it there for feedback. That was a huge ego boost. :)
Though I have to admit, the music gets the mood of my game totally wrong - lol. This is because I actually wrote the music for the game early on, before I knew what type of a game it was going to be (that is, a funny one), so there's a big mood clash there, and that's kinda awkward. I don't know how other people will see this; I'm a bit curious!
The ??? - My Graphics
I told one of my friends that I made a vow with myself to never again save graphics for the final day in Ludum Dare.
The reason I said this might not be the reason you think, though. See, the thing is, I actually really enjoy doing graphics, but I just never get an opportunity to. I always save them for the end and then rush through them at light speed. That's exactly what I did in this game, and it was a huge mistake! I only spent like an hour MAX on my graphics, and they look so much worse than I know that I am capable of. Every time I see them, it makes me really sad that there was so much missed potential because I didn't schedule graphics well into the timeline.
The other problem is that I have no idea how to animate at all, and this is always a big issue in my games - everything is so flat and static. Half the problem is not knowing, and the other half is not feeling comfortable with incorporating animation into the code. There were a lot of steps to do that I just didn't want to bother with when I could be doing other stuff faster, so I didn't. If I felt more comfortable integrating animation into the code, I would have been much more likely to do it.
I put in a funny joke (I think) where everyone is on skateboards because then I wouldn't have to draw a walk cycle. :) But the core problem is still there.
I want to be a better animator.
Vow #2, making it right now, is to become a better animator for LD39. :)
(TO BE CONTINUED...)