Ryan from Stone Monkey Studios here! I tossed out an email a few days ago about a Post Mortem for Mr. Wily, and we all came up with a few things to comment on. I’ll post them here in no particular order.
The game can be found here.
Ryan – Programmer
- We managed to work out a pretty solid plan in only a few hours.
- Working together for at least part of the time was very beneficial. It was good to bounce ideas off each other and have quick communication.
- Using Dropbox was great for getting content into the game quickly, but was very annoying for other things I’ll address below.
- In terms of code: It worked much better when I gave up trying to design things to be modular. In general, it’s good to have reusable code, but it generally requires more forethought. This is unfortunately more difficult (for me at least) in a rapid prototyping situation. Once I embraced the mindset of writing very specific code, my output sped up significantly.
- The original idea for the game was a pretty large scope. We managed to keep most of our key features in the game, but some of the ties that were meant to bind them together fell by the wayside. The stork/baron thing was only every tangentially tied to the rest of the game, but without even giving it a cursory explanation, it did not fit well at all. (Fortunately, the stork game itself is pretty fun in my opinion, so I don’t regret keeping it in.)
- Because of the large scope, there was a lot of polish that could have made the game better. Many simple things would have gone a long way.
- The plane could have rotated (Something Jon mentioned off the bat, but I just didn’t have time for)
- Text sizes could have been normalized, and placement was occasionally halfhazard, so there was a bit of inconsistency.
- I would have liked better control over starting a minigame. The explanation splash (“Get to the princess!”) should have been dismissible by space bar, and no other input should have been accepted while that was shown.
- Dropbox did not work with unity because you cannot exclude the VS project and various assemblies from dropbox, so every time someone would cause a reload on their Unity project, it would rebuild assemblies for everyone and cause problems. This was extremely frustrating as the programmer, because it would break predictive text, autocomplete, and just generally mess with me. I lost a surprising amount of time closing mono, closing Unity, and reopening.
- I think the “Coolness score” could have carried through the entire game with a bit of planning, and could have been an actual gauge of score instead of an arbitrary thing.
We discussed the idea of having losing states, but ultimately opted for this format so we could tell the story. I think the game works best as a short experience. The point is to build up frustration and then release it. If you could lose games, then it is much less likely that we can hold people long enough to give the satisfying payoff.
- Working with four people allowed us to accomplish much more than last time (and at a higher level in general); last LD it was just Ryan and Jon.
- Creating several mini-games to simulate the daily grind (and being able to control pacing by switching between them); this was a gamble (and a bit of a drawback, stated below), but it came together nicely.
- Sleep. It was good to get a good nights rest to stay productive during the following days.
- I really liked the art style, but it took significantly more time (from Jon’s POV) to model and unwrap (specifically trying to maintain the ratio 1 block in 3D : 1 pixel on the texture).
- Some of the mini-games did not have enough user agency. It would be nice to turn the bar fights into something like Punchout. The computer screen could be turned into a game (or maybe omitted).
- Finishing several different games kept us from polishing and expanding upon the individual games.
- Team composition. Our approach the theme was far more content-heavy than feature-heavy; fortunately, our team was comprised of 3 content creators and 1 programmer.
- Quick and ready communication. We actually jammed out at one of our places for a majority of each day, which was beneficial not only to meet up to quickly establish our direction for the design ideas, but also for all the little things. This is my first Ludum Dare, my first jam, and the first time I’d ported and created assets for Unity in any capacity, so getting quick pointers and assistance from the team made sure I didn’t waste any time when they already had the answer to my questions.
- Taking time for charm and personality. It’s easy to plan to implement every important feature and design, then cascade downwards to less important things, but I believe it to be equally important to take the time to inject a little personality into the product every now and then; doing so ensures that you at least have a little fun as you develop, and prevents you from mentally burning out.
- Despite concepting the characters first, they were among the last assets to be implemented into the game. All the animations were done on the last day, and while we actually have some assets and characters that didn’t make it into the game (the bar scene and the office had several assets created for them), we didn’t have time to put them in the game.
Did you find the goats?
Unfortunately, I had trouble getting in touch with Akkash for the Post Mortem due to the holiday season, but if we hear back, we’ll get his thoughts and comments either in an update or in a new post!Thanks for reading folks!!