Crew, A Futuristic Detective Game (Post-Mortem)

Posted by (twitter: @metkis)
December 20th, 2013 6:46 am



The 28th Ludum Dare 48 is my first game-jam. I decided at the stroke of midnight and after seeing the theme that this this time I would finally be competing. The experience has been a great eye-opener for me about what it takes to make a game in any length of time, and it’s been a great win for me to meet with so many people that were willing to give my game time and say something nice or constructive about my work. You can find my game here, if you missed it or would still like to give it a go.


What went right:

  • I finished the game in time for the competition It was a busy weekend for me with a birthday party to go to and work to get done. I got plenty of sleep still and managed to finish the game in what I thought was a fair amount of time. I wouldn’t say the game took more than around 16 hours of my 48, which includes all art, music, sounds, and programming.
  • I decided to use GM:S I started the project in Unity and just decided to switch to GM:S which I thought would expedite the process of making it. I was right. I think the game would have taken a lot more time in Unity, fidgeting around with their 2D support and getting the code right on first go.
  • The idea I thought of a lot of mechanic-based ideas in the beginning, most of which were implemented by other developers numerous times. When I thought of this idea, I decided to go with it. It’s not really something I thought I would make, either. It’s not a completely simple game mechanically, so there was a lot more programming involved than I would have liked. Still, people were intrigued by the idea and I got a lot of support on Twitter for it.
  • Mood and visuals I got a lot of complements on the look of the game and people liked the music and sound effects. Funnily enough, the game wasn’t pixel-art in the beginning and was instead a more comic style shown below. I decided to try Rezoner for music creation and it worked in a pinch. I created the music in 15 minutes and two sounds were created with it as well. BFXR was used for my sounds and worked great.
  • I tested my boundaries I suck at any sort of random generation, and I needed to use a lot of cross-referencing and code to complete the game. Some part of me would have rather leaned on simpler mechanics like built-in physics or a pre-made platforming engine, but I didn’t My code ended up making up the whole thing and it was really tough for me to figure out how to solve some of the problems I ran into, but also really rewarding.


What went wrong:

  • The dialogue system Close to finishing my game, the dialogue system seemed to be working great. I was designing something that would give each character their own specific dialogue while also offering hints at the killer. I was really happy with how it was turning out, but time ran out, and the system was repeating dialogue between characters. Because of the mechanics this meant it was sometimes very difficult to find the correct killer of the captain.
  • Not user-friendly I consider my game to have a lot more rules than a lot of jam entries. I’m actually okay with this quality to the game. The problem in user-friendliness comes with a lack of an in-game tutorial and a unified selection system. The game displays some selections differently from others. As a designer, I should have applied the process of KISS (Keep It Simple Stupid), but I was in a rush in the last hours.  This is the number one complaint I got, and one of the first things I will fix if I decide to go any further with the game.

What I would do differently:

  • Spend more time on the competition, or move to the jam My problems could have been fixed with more time. I haven’t uploaded a post-comp version because I’ve been busy too. I didn’t regulate enough time to fix the dialogue system or add in a tutorial so the game remains imperfect. In my spare time I will fix it up, but I knew going in it was going to be rough and perhaps should have settled with the jam instead of the competition. I had other ideas about what the game would be, but had to cut them short because of my time. Clues would be included and the scoring system would have been deeper – all the wouldofs in the world don’t really matter, though.
  • Spend more time on prep some of the issues I had would have been fixed if I just expounded more for myself on how I was going to handle the mechanics. A lot of it, for me, was “Shoot, I still need to have x system.” Then I was rushing to finish that. I think good prep is the foundation for good design in general. This seems especially true in game design.
  • Make something with less code focus / use more examples I wrote a lot of the game with my own code, which isn’t great. If there’s such a thing as programmer art, then there’s certainly artist programing, which is what I felt I was doing. The systems held for the most part and I have few true bugs as my dialogue problems come more from design issues than poorly written code; however, in the future I might try to lean on other open libraries so I can finish things faster and make sure things work how I need them to.

Final words: 

I got so much more support for my game than I ever thought I would. Indie Statik had my game in a list of featured LD48 games, some cool people retweeted it, and I got a lot of love here on Ludum Dare’s page. In a time when I’m really questioning my ability to make games, it really put a smile on my face and gave me a lot of drive to work harder next time. Even if the game didn’t turn out how I wanted, even if it wasn’t as fun as I expected, I’m still glad I just made something instead of saying I was making something all the time. I have to take this time to THANK LUDUM DARE AND THE GREAT DEVS HERE for giving me a great time and something to be proud of.

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]