ld31_00

Play (and rate) it here!

Incep…I mean conception phase

On Friday evening I started brainstorming for the possible themes, paying some special attention to the now forgotten ☃. I wasn’t particularly keen on it, but judging from people’s reactions on the internet there was a high probability of it being selected. It also felt  particularly appropriate, as by the time I was scribbling possible game concepts I was freezing in the cold waiting for a gig.

IMG_20141205_221948

I regret nothing!

That hour and a half yielded red fingers and around 3 notebook pages of quick and more or less bizarre thoughts, references and ideas. “Entire game…”, as you can see, didn’t get too much love back then (In case you’re curious, I’d just written  something like “taking advantage of the UI elements as parts of the gameplay”).
brainstorming

Flash forward to Saturday morning. At that point I learn about the chosen theme, curse for around 30s and put my mind to work. While it wasn’t among my favourites by a league, I generally don’t make a big drama about the theme as I can’t fully understand it (the drama) either. I’ve read many complaints about it not being a real theme but a technical constraint, too restrictive, too generic, etc, etc. Even though some of these can be valid points, to me they don’t carry enough weight as to get angry over it. In fact, I feel that restrictions more often than not enhance creativity rather than hinder it, as they force you to get out of your comfort zone, think in a different way and try out unknown routes that can end up in interesting, original takes (as a proof, I’ve already played several today. I’m amazed at what people can accomplish). In this specific case I thought that the theme might work in several ways: as a technical restriction (no scrolling, no separate levels,…) or as…well, a theme (surveillance,…). Waves of stuff coming at you (a reverse beat ‘em up, for instance), monitoring some action through a display, shooting ranges, fighting, multiple levels crammed into a single view, puzzle games or single-screen arcade games, etc, etc… All of them seemed like some viable approaches. At some point I seriously even considered to make a TV broadcast programming simulator, but luckily discarded it when I realised that it would probably go way out of scope. In the end I decided to follow the arcade approach and started looking for references.

A couple of screenshots of good old Arabian, some helpful advice and references from Zener pointing me in the right direction, and thus the main concept for Dungeon of Jest was born: A single-screen platformer with a single level where sections of it change as you progress around the game, giving the impression that the dungeon is trolling our hero, giving her a more difficult time.

references

Arabian and King’s Valley 2

What went right

  • Level design on paper first. Other times I’ve focused on building the systems first and then building some crappy, nonsensical maps at the end, which just doesn’t work. This time I tried the other way around, and while the game can still use A LOT more level design work in terms of progression, pacing and more levels (obviously!) having paper designs helped me focus on what I needed done, and create a more fun experience than in previous editions.
  • Well-defined scope. Following from the references and the layouts for the levels, the scope of what I had to do became a lot clearer and easier to achieve. I had to give up lots of polish-related stuff (tweaking gameplay, better assets, animations, visual effects, music, better audio…), but most of the core experience made it to the game.
  • Dynamic level transformation. Implementing the section changes was easier than I expected. I kept separate level files, and then computed lists of changes in tiles and entities to move from one to the next. I could have made it more general (it could be interesting for a hypothetical future), but the first implementation worked well enough for the compo scope.
  • Last-minute dialogue text. Since the beginning I had wanted to make the character speak when key events happened to provide a bit of humour, guidance and context to the narrative (well, the game has no narrative at all, but it was in the backlog), but I left that for the final stretch. Luckily I could add it and I think that it was worth it.
  • Language/Library choice: This is the second game I build on Haxeflixel, and I’m very happy with it. It frees you from a lot of the groundwork and building for several targets is absurdly easy. This time I even managed to build an Html5 version.
  • Knowledge from past games.

What could have gone better

  • Knowledge from past games. Wait, what? Wasn’t this on the “good“ side? Well, yes. However, even if I mentioned that I applied some of the ideas learned in previous editions, the lack of a code base made me reinvent the wheel in some areas that I shouldn’t have had to. Entity and map management was the main example, especially since I used the exact same technology (Haxeflixel + Tiled) from the last game. D’oh!!
  • Belated technology choice. I wasn’t sure if I would use Unity or Haxe until I had most of the design work done, and I think that gave me a late start.
  • Lack of levels and gameplay polish. 3 levels are just too few and several people have already told me so. What’s worse, it is detrimental to the whole “What the…? The dungeon changed again!” feeling I wanted to convey.
    A better idea given the time constraints would have probably been to define a smaller level layout (with 25×20 there were lots of empty space) and create more of them.
  • Lack of visual/sound polish. I’ve estimated that I worked on the game about 30h, of which I prioritized basic gameplay over production values (which take me longer to create that I’d like to). This becomes evident on the lackluster graphics, no music, animations or any visual effect, plus the crappy sounds (added in the last half hour before submission). This area is definitely something that I need to, and want to improve in the future.
  • No narrative. The “take the orb to win” goal is simple, but void of any context. I wanted to have some background story and have it reflected in the gameplay, but that would’ve forced me to devote more time to asset creation (GOTO previous epigraph). Again, this is something I want to tackle in future games.

Conclusion and ideas for the future

I came out pretty happy with the game this time, even though there are lots of room for improvement. To everything that I’ve already mentioned there are lots of things that could make DoJ more interesting (or bloat it :D). For example, just to name a few:

  • More “levels”, obviously. I’ve said this already, but I can’t stress enough how vital this would be.
  • Having more than one “orb” at a single time, each of them triggering different section changes, for enhanced depth and all-new level design balancing headaches.
  • Procedural generation <3
  • More classic platforming features: Traps, puzzles, swings…you name it!
  • More enemies and more complex AI
  • More work on existing gameplay elements: better jumps, ladder docking…
  • Final bosses and new gameplay mechanics incorporated as you progress around the game, a la Castlevania.

I don’t know if I’ll make a post-compo version with some of these changes (I always say that I will and then don’t do anything, so I’m not going to fool myself this time), but for the next time I definitely hope to at least come better prepared in terms of code (have the language choice clear from the start, ffs!), and become faster (and better!) at asset creation. Well, and probably synthesize a bit more on the postmortem. If you’ve managed to read all the way until here, thank you!

Tags: , ,


Leave a Reply

You must be logged in to post a comment.

[cache: storing page]