It was around 11pm when I left my house with a 1 hour trip ahead until I met the yet to be named Make A Game team. Having memorized half of the list of possible themes, I spent the little I could of brain waves keeping my car on the road, and tried to think of quick game mechanics suited for a 72 hour game development.
I was the last of the team to arrive; I met some new faces and joined in on the ready up ritual. There were still 3 hours until the official LD #21 theme to be revealed, so we started throwing ideas around, writing them down on our white boards and linking them to similar themes.
The awaited hour finally came, and the Escape theme was victorious. We quickly (and sleepily) gathered around one whiteboard and started discussing our previous ideas, along with new ones. Among them, the Survival Tetris game was highly praised. For some dumb reason, I went to my computer and searched if someone already had done such a thing. It existed, and in two quite different forms. In one you only controlled a stick figure, and in the other you controlled both pieces and a round character. We were bummed out.
It was late, our two hours of brainstorming didn’t end with a winning idea, as we decided to go to sleep at 5am.
As each of us woke up, we agreed that we needed to go forward with one of our ideas. We were wasting too much time thinking of a game to make rather than making one. Our most solid idea was our twist on the Tetris game. We didn’t know it yet, but we would have a lot of fun developing it.
Our game isn’t Tetris. It might look like it, and use some of its rules, but you wouldn’t play it like Tetris. Actually it would be a bad idea if you managed to complete and erase lines, because it would be a setback from your objective, which was to save a non playable character from something dangerous at bottom of the screen. You’d be making steps with Tetris pieces so that character can climb to its safety.
Initially we took inspiration from the idol scene in Indiana Jones, the game’s character would be in the central chamber of some ancient temple, and removing said treasure from its pedestal would trigger a huge spiked cylinder that would try and crush you from below. The whole temple would start to crumble, and the character would use the falling debris to escape being grinded to death.
Eventually we started thinking on different treasures and dangers, even on a feature to allow custom tilesets. Though we weren’t glad with the default spiked cylinder danger, it would be easily animated but lacked something, like personality. The dinosaur mommy came into form, as did its egg. Our character changed from an Indy/Spelunker lookalike to a something akin of the great animal taunter Steve Irwin.
Goodnight Sweet Prince
What Went Right
– Great references
We wanted a quick and fun arcade experience, and for that we had to make the player to play it fast. There had to be a rhythm that could match the speed the loop of which the pieces would appear on screen and drop down.
Every time we had some doubts on how to replicate that feeling, we’d turn to the current best example of a fast paced arcade game: Pacman CE DX. That game has so many small but important details that can be easily overlooked, from the music to the gameplay feedback. And we used it as our way to resolve impasses.
For the art style, we were constantly leaning over the shoulder of Spelunky. We loved the way Derek Yu can mask the mosaic nature of tilesets and we tried to apply what we learned from his work on that game.
– Knowing our priorities
By the end of the second day, we knew we were late on schedule. We didn’t have any prototype for some hands on and we had to start deciding what needed to be done versus what we wanted to have in the game.
Listing all of our features and deciding the importance of each helped us to, well, deliver an actual playable game. Leaving out stuff can be heartbreaking, especially on bigger projects, but we knew our challenge, and we knew we’d add all the stuff later.
What Went Wrong
– No Streaming
It was a shame, but we had spent some time setting up our SVN and getting our game idea together that we didn’t bother with getting any kind of desktop video stream. We also had a camcorder but lacked a proper tripod to have it up high filming the whole process.
– Lack of planning
This was everyone’s first time working with Flash to code a game. That alone made us lose valuable time when we decided to ditch Stencyl for FlashPunk, because the prior was having conflicts with our SVN. Basically, when the XML files that Stencyl saved were submitted to the SVN, they appeared differently to each user, with a modified structure or a bunch of errors that weren’t supposed to be there.
But what hurt our time the most was the lack of planning before getting started with the code. Each was tasked with a particular job, and there was no discussion on how to approach their tasks. This lead to some late changes that kept us from moving forward with development and having a proper prototype of the gameplay we aimed for.
For this Ludum Dare build, we only have two modes available: Survival and Time Trial. We were planning two more modes – Altitude Attack and Score Sprint – as well as multiple goal values for each mode.
The difficulty would also do much more than define how many lives you start with.
We had plans for a startup countdown before the game would begin proper, where a little cutscene would play out with the game’s character picking the egg and crapping his pants when everything started collapsing.
We wanted that the Score was a combination of remaining lives, height climbed and treasures collected. One thing that got in the build was the score multiplier that doubles your points each consecutive step climbed. But you probably didn’t notice it because we didn’t have time to put points coming out of the character’s head when he was climbing.
But worst than everything, we didn’t have time to include a splash screen with our team’s name!
In one year working on a game studio, I’ve learn that game developers can’t get too obsessed with their projects. There has to be a time when a game needs to be finished and released, with or without implementing all of the planned features. A finished game has much more value than a game that’s been in development for years, without a release date.
Though we are finishing the game after the competition, this is a lesson that Ludum Dare has taught our team. In this industry, every project has milestones that need to be met. We had a lot of setbacks and what we delivered wasn’t accomplished without staying up until a couple of sunrises, but concentrating on what we could finish instead of hanging to what we could add helped us reach the finish line.
It feels good to finish something.
FlashDevelop (IDE), FlashPunk, Audacity, Tortoise SVN, Adobe Photoshop CS4, Google Docs.
This article was originally posted on September 11th, 2011 at Ludum Dare.