Every Night I Dream I'm Better
AN INTERNATIONAL 48-HOUR GAME JAM
EXPLORING THE WORKS OF @PeterMolydeux
MARCH 30TH - APRIL 1ST, 2012
At any time, there's about 4-5 game ideas I'm fleshing out in between working on puzzles for Mallow Drop. I had wanted to do a top-down adventure game like the old Zelda titles for a while, but the idea required massive amounts of level design to be interesting for a player.
"Visualize an open world game set in a white box. During the night you dream and can place elements from your dream into the blank world"
For an open world game, everything clicked with the idea of a dream world. I started basing ideas around the idea of those forests that often appear in Zelda games, where if you don't follow an exact sequence, you end up at the start. They're very dreamlike and they create the feeling of being lost and not in control of the environment around you in a way I didn't think I could get across with graphics alone.
If there's no need to follow real word rules, there's no need to follow real world geometry - and so level design could be cut out of the process to save time.
The white box was obvious - I can't think of anything that brings up escapism more than being stuck in a hospital.
"Every Night..." was designed and built in 48 hours, in the Boxy2D engine, partly as a creative challenge, but also as a test to see if I could complete a game without using the Flash IDE.
I'd been thinking of switching over to Flash Builder for a while, but ended going with FlashDevelop as it was way more portable and I'd be working on a netbook.
Doing a code-only project felt good. I swapped between FlashDevelop and SublimeText as needed (SublimeText had better find/replace tools). I edited assets without needing to update them in the IDE. It felt right, and I got into the groove of coding a lot faster than usual.
I jumped into coding almost as soon as I'd worked out the mechanics. In 3 Hours I had circles attacking each other, but working as fast as possible without much time for planning led to two major bugs:
- which several people pointed out, if you leave by the VERY corner, you can get stuck in a wall on the next screen - this was a design oversight, that thankfully didn't come up during judging, but could have bit me on the ass.
- working fast doesn't leave a lot of time for optimisation, and for some reason flash was just not unloading screens from memory. It was fine for a single playthrough, but eventually the memory would creep up too far. This is the main reason why the game needs to be refreshed completely to start over, but I also wanted to give that slow music time to play a bit longer as most people just wanted to get back to the forest stage as fast as possible, and that piece of music pretty much got lost otherwise.
The Cut: What got left out of the game
- more items and interactivity in the "hospital room" area, to give the feeling of time passing in the hospital room somehow. One of the goals of the game was to make you feel that longing to get back in. It worked for quick gameplay, but the balance didn't feel right to IMMEDIATELY jump back into the game the way it does.
- better graphics.
- the ability to choose what stats get boosted from the shops, or multiple shops that boost one ability.
- damage counter graphics when you hit enemies, and when they hit you.
- boss fights/larger monsters - the bear was planned to be much bigger, but due to time constraints, I based the sprite off the player sprite to get the graphics in quickly. This would have added to the sense of danger.
- the possibility of coming across "set pieces" within the forest.
What makes jam coding awesome:
- The pressure really pushed me to make a game I didn't think at the start I was ready for.
- Working continuosly for long periods without distractions really helped get into a "flow" with the programming.
- Having a hard deadline forces you to stick to a realistic goal. There was no way I'd make a 10 play-hours game in 48 hours, but I made a 5-10 minute game with a beginning, middle and end.
What makes it suck:
- Having such a harsh time constraint forces you to plan then build, and doesn't allow a lot of time for tweaking as you go.
- It can also force you to make the choice between features and stability.
- I went solo for this jam, and while @brainfed donated some fantastic music to the game, the art really let the game down.
What I'd do differently next time:
- I'd like to enter with a team, as while I can get into a flow with coding, art was a hard slog. 48 hours is not enough time to do every aspect equally well.
- I went with a gameplay mechanic that I knew was solid, with an abstract message. Next time I'd probably be much more direct in the message, and be more experimental with the gameplay.
It's hard to sum up the experience of Molyjam. In other citiees there were more entrants, or different skill sets, but for me in Sydney it was amazing to see that among the finalists:
- Almost no team used the same tools. We had a C++ entry, a Flash entry, a GameMaker entry, and a few Unity entries.
- One guy had NEVER made or worked on a game before.
- Some teams were groups of artists, some were devs going solo - no team worked the same way.
And most of all getting good, constructive criticism from the judges (who played through EVERY game until they finished it or broke completely) was something I'll never forget and is something everyone hoping to make games should experience.