Entry Page
I’m getting this down before I forget everything.
I had the explicit goal of doing a content-driven platformer, since I hadn’t gone for that before and it sounded like fun. I hedged this bet by doing a substantial amount of framework building to get the platforming going and to have a rough-and-ready in-game editor. Even so, it was an enormous crunch to complete this game.
Concept
I currently use a model for game design based around language; every game is described as an expressive medium in its own right, with a specific vocabulary and forms of sentence construction. The content of the game suggests possible sentences, compelling the player to engage in conversation as their vocabulary affords. It’s the most successful model I’ve used yet and lends itself to any genre without getting mired in worship of a specific mechanic, conventional structure, or balancing.
For this game I went off to Wikipedia and looked up “Loneliness,” and found a reference to rites of passage. This was a promising avenue since it let me work with concrete elements instead of the metaphysical. The basic idea took shape pretty quickly – some tribal warrior type of character doing various outrageous tasks to prove himself – inventory and a task list were the main elements introduced at this stage. I also included a time limit as a way to cap off the concept with a finite structure, although looking back at it I don’t think that was necessary. The day-night cycle added some extra flair to the graphics, but the details involved in being able to lose the game were a chore and don’t add much to the experience other than to pad out playtime.
Day 1 (6:00 PM-12:00 AM PST, Dec 16th)
I fixed some things in the framework early on and started on a prototype scene, developing my concepts in a text file. The day concluded with bits of graphics work to get my player and some tiles started.
The palette I used for this game is one I had made some weeks ago. It is developed from a very color-theory informed basis, using the wheel to build a heavily coordinated set of hues with a saturate-desaturate alternation through the values, and I credit it for 90% of the look of the game. As I get better at game development as a whole I increasingly recognize that fundamentals are the key to all the involved skills – if you get a better understanding of color and shape, you get better not just at illustration or pixel art, but at graphic design, typography, architecture, etc. Similarly: rhythm can affect speech, music, athletics; and writing tends to tie together most skills in doing this sort of self-reflection. (Coding can be reflective writing, too, if you stop being scared of it.)
Day 2 (12:01 AM-12:00 PM PST, Dec 17th)
Early in the morning I did the bulk of work on backgrounds. Although my framework has both scrolling and flipscreen modes, I chose flipscreen for this game specifically because it let me use a more detailed approach to backgrounds in each scene with less reconciliation at the borders. It also lends itself to better performance which is always a boost.
The waterfall came in at this point; the waterfall is both one of the coolest elements and also the most expensive. I told myself, “wouldn’t it be awesome if the first thing the player did was jump off a cliff and dive into a raging waterfall?” Although I had Pro Motion if I wanted a traditional colorcycle setup, Flash doesn’t support palettized color cycling natively, so I had to come up with a technique to emulate those effects on the spot – and I had never tried doing cycling anims before, although I had studied some of the most ambitious color cycle anims in the world earlier this month. I resorted to four copies of the background and did the rotation by hand, alpha fading one over the next and then swapping. A linear fade gave nasty looking results, but I found a way to overcome the artifact: first I squared the tween value, and then I tuned it some more with a specific exponent factor(my final value was 1.8).
I added in the day-night cycle soon after I had the waterfall in place. I figured that a color shift over the tilemap would look good and would help characterize the backgrounds, even if they didn’t change at all. As it turns out, it was not hard to set up a table with one entry for each hour of the day in game time(the game runs 6 AM to 8 PM – 14 hours game time, 15 minutes real time) and tween a Flash ColorTransform’s multiplier values. Between that, the auto-tiling sets I had made yesterday(this framework has nifty autotiling algorithms – I see room for improvement on more arbitrary uses of tiles though, like what I did on the trees), and the backgrounds, the look was feeling pretty well established. I still had plenty of sprites to work on, though, and the map needed filling out.
As the day drew to a close, I had the task list working, the timer, opening screen, and win/lose working, some sound, and one proof of tasks(pearl diving). I even got the environmental sounds working, which the game massively benefited from. In testing these things the in-game console was a huge help; you lose a lot of iteration time if you have to actually play the game to do anything. The final game has tons of leftover debug commands to tune the colortransform, set time of day, and set task completion, in addition to the map and graphics editing. So much happened all crammed into the later hours of this day that I’ve already forgotten a lot about it.
The last thing I did before I slept was the music. I don’t really like the end result – it starts off with an oppressive, John Carpenter Escape From New York feel, moves to a more contrapunctal style, and then finishes with simple repeated chords and arpeggios. All of those styles have merits; none of them exactly fit the game, in my opinion. However, I did not get a second chance. Ship it!
Day 3 (12:01 AM-6:00 PM PST, Dec 18th)
As on the previous day, I started in with graphics, and had most of my sprites done before my morning walk. One thing I found myself doing a lot, both on the previous day and this one, was to go back and polish completely random things. I did not restrain myself when this happened, figuring that if I had the motivation, I might as well follow through on it. In the timelapse you can see that I did a major revision on the opening screen, for example. The main character also went through four revisions – single color(too low-fi), outline color(too naked), and two revisions of clothing(too neon and then the final, which more-or-less hits my target of reading the outline first, and then the details).
Of course, what really loomed over my head was the completion of the rest of the gameplay. I switched back and forth between the various things to do – making sprites, integrating them as entities, map editing – until I finally hit the point where I really needed to start on more mechanics. If I remember correctly I did the dragon first, then the orange, some of the bird, then the lanterns, the rest of the bird, and then the pickaxe and gem.
The dragon was a scary problem to solve. Any time the character controller changes there’s a potential for massive bugs; fortunately I had had a bit of practice on it from doing the diving mechanics yesterday, in which the controller changes as soon as you touch(or emerge from) water. Those turned out to be more streamlined than I expected, with no actual swimming going on, and the same proved true with the dragon. I knew going in that I would place some entities and make a tweening path for the dragon’s flight to follow. Lack of planning meant that the path steered around the win/lose rooms, which is why the dragon flies up a cliff. After some work I had the player tweening along, and the dragon sprite following. But then the question was what kind of control the player had and how it was integrated; I realized it would be easiest to just add a y value on top of the basic tween y, and move the tween path down to the lowest level in the flight areas. The control turned out stiff but serviceable, and some patching up later, the dragon flight was done. I could have tuned that control to have more acceleration in it…oh well.
The orange was a straightforward addition to the dragon, and the basics of the bird were too – I already had projectile throwing from the framework demo and just adapted that to have a stone and use the inventory system(instead of a bow and arrow, an earlier concept that would have taken more effort). Around this time I finally got all the inventory working. I waited on finishing the bird in favor of the lanterns, though.
The lanterns were simple enough – touch and change animation, do a test to see if all are hit(the framework lets you iterate over tagged entities so this test can be done in a very reliable fashion). They caused a performance issue in that each one has animation callbacks every frame, though. In the final hours I somewhat optimized this so that they weren’t rendering offscreen, at least, but didn’t do anything about the callbacks themselves, which I suspect added a substantial load.
At this point I could see the finish line. I did some environmental sounds, the credits scroll, revised some sprites, got the bird’s flight in, did some more layout work, and finished the pickaxe section(which was again, pretty straightforward – I started from “projectile” behavior and adapted it to be more melee-like – it would have looked nicer following the player but I wasn’t about to care by then).
And….that was pretty much it. I finished with about 1 hour 30 minutes left on the clock, plenty of time to do my uploading and start the submission and documentation process. Later I got some feedback that indicated lack of clarity with dragon controls, so I added up arrow to it(instead of just jump); the LD website was (as usual) blowing up, so the change squeaked into the submission period.
What Went Wrong
Map editing was a bit slower than it could have been – more tool dev needed. Level layout suffered a bit because of this.
Performance got a bit impacted by the end; tuning the framework to let me optimize around flipscreening rules(e.g. making actors disappear when out of the room, putting the anim callbacks on the actors instead of a platforming controller) would help matters.
Some of the later aspects ended up less polished than I wanted as a result of time pressure.
The music wasn’t anything like what I wanted.
Some of the art techniques I used I was unfamiliar with; I could get faster/better at them.
What Went Right
Map iteration was great because it was all in-game.
The console, the console, the console. If you want to debug gameplay quickly, you need one.
The code did not degenerate into an unmaintainable mess, no siree. A lot of this stuff is reusable – and some of it I actually went and reintegrated into the framework base during the jam!
I finished all of that content!
The combination of the palette, the animation, and the environmental sounds really came together.
HaXe and NME were troopers, as expected. My personal stack for HaXe work is probably going to include NME more in the future(instead of my own hand-rolled build system), although I haven’t yet found a way to include SWF libraries seamlessly as in my own builds. Technology is never perfect…
Finally…
Although it was a really tiring, stressful endeavor to do this, I’m struck by the result. I find myself wanting to return to the little world I made. Maybe elaborate on it with a sequel, even. Maybe that’s why people get stuck so much on pixel platformers – for the amount of effort, you can fabricate concepts pretty quickly, especially if you have nice tools to work with.
As always, I credit maintenance of a sound lifestyle for keeping me healthy and sane during the compo. Getting out of the house, getting enough sleep. Taking my vitamins, balanced meals with a side of vinegar. Caffeine in moderation. If I’m going to party, it’ll be around other people, not just sitting in front of the screen. And even doing all that, I’m still exhausted by this, psychologically speaking.
+
=
Next time I design a spaceship game (or if I continue designing this one), I’m going to make programming movements a lot more me-friendly.
