First off, I want to say thanks to everyone who has made this my best Ludum Dare experience to date. Shuutshimi has been very well-received thus far and I was even able to learn a couple things post-jam from it. I mentioned earlier that I was considering skipping this one due to other priorities getting in the way of the 72-hour jam, but it was those interruptions that forced us to think smaller and more reasonably than we otherwise would. We had less than 48 hours all-told due to weekend and work commitments which shaped the way we developed the game, and it was a lesson that we – and I feel, myself in particular – desperately needed to learn.

 

What Went Right

Practically EVERYTHING went right. I know that’s going to kill the suspense of the remainder of the article, but it’s true – once the competition kicked off, Wanyo (artist) and I (coder) threw some ideas back and forth for a while. Once we had a list of ideas, we picked a genre for the game, discussed variants on that genre, and picked whatever would be easiest to develop. From there we culled the list of elements to what was relevant to our game, and then culled the list further on perceived ROI until we had a manageable list. Then we went to work. Once Any Yes (audio) showed up, we gave him a quick explanation, and we were all set to work.

 

The Coding

In the past I felt my coding to be notoriously sloppy – sure, the end product works, but I tend to refactor my code a lot as my understanding of the requirements grows. I kind of plunge in head-first and fix my mistakes later, or as I go. But with Shuutshimi, apart from extremely minor things (eg making it a one-line change to add more hats into the game from the existing 3) I did just about no refactoring. I guess I’m learning from my mistakes!

 

The Drawing

I feel bad that we didn’t stream Wanyo’s screen/our development studio, because the visuals are the face of the game and often where our character designs are fleshed out. I find it interesting how our character designs begin and evolve, because they reflect the overall tone of the game which, in this case, was incredibly silly. One of the biggest time-sinks from our last Ludum Dare was the unreasonable amount of spriting involved in the main character – well over 70 sprites. That’s not very achievable in 72 hours, much less 48, especially when other graphics are required. The design of our Cute-Em-Up, however, demanded at most 8 frames of animation per object, allowing way more time for polish and additional assets. We had to cut one of the enemy characters from the jam unfortunately, but what made it into the game looks excellent, in my opinion.

 

The Composing

I didn’t even consider how Any Yes was going to react when he was greeted with the following words: “We need as many ten second songs as possible!” Any Yes would have to elaborate on his process here, as it’s not something I can really observe. I understand the basics of Famitracker: My own words on it are “You put numbers into the program and it makes beeps and boops based on those numbers” but beyond that – in addition to music theory and composition and all that – are pretty lost on me. I can make a passable stand-in for visuals, but what Any Yes does is beyond my understanding. The shop music was replaced partway through the jam with something a little catchier, and I’m way happier with the change. I didn’t like the first draft of the title theme at first, but it took very little time to grow on me, and once the title screen was in place with scrolling backgrounds, it felt so perfect which is why, when he suggested changing/modifying it further to something way more energetic, I was reluctant. I should just flat-out trust what he’s doing because, as those of you who’ve played the game would agree – what made it into the final product is fantastic.

Hey, I’m allowed to think the game’s soundtrack is awesome, I had nothing to do with it!

 

What Went Wrong

No screenshots in the Post Mortem (this). I’m at work and supposed to be working, so I’m making this as quick as I can.

The fourth enemy got cut from the game due to graphical time restraints.

The bubble background was originally supposed to move to the left as well, but also bubble upwards. At first the plan was randomly generated, individual bubbles, but time and complexity got in the way. Not enough ROI.

The backgrounds in general were supposed to have their own scrolling rates to give a parallax effect but again, time restraints. In retrospect it’d be really easy to do, but we didn’t have the time.

The 10-second tracks. They’re great, I just wish there were more of them. In a 20 or 30 round game, you’re guaranteed to hear a lot of repeats.

Clarity. We thought it would be interesting to make the upgrades a “learn what they do post-acquisition” thing, which worked great for the most part, but there’s a decent amount of depth to it and a lot of subtle things going on in the background that I don’t expect anyone to know about unless they read the Sourceshimi. Also, the “Press X(B) to go back” style of displaying controls is probably confusing. (B) meant B on the XBox360 controller (the brackets are like, ROUND BUTTON) but I doubt that was clear.

 

Overall Impressions

Definitely my best Ludum Dare, and I’m sure my teammates agree. Learned a lot, FINISHED A GAME (though we’re still doing post-jam content updates), felt really good about my code, and delighted to see it so well-received that people are writing articles about it. This has been a hell of a learning experience, and an even heller of a motivational drive to keep doing that thing I love doing.

 

Making games.

 

(And…scene)