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.

I should sleep now.

I have a song pretty much done, it’ll play for the “end credits.”

I succeeded at most of my goals for the day – did more polish than I expected, less content. But I’m in good shape. I just have to blast through the rest of the content tomorrow.

	dragon flight code
		get it spawning
	bird flight code
		birds placed in map are spawners?
			or we just have them run on a consistent cycle?
	spriting:
		obstacles for dragon area(attacking birds)
			(reuse birds for hunting segment)
	three tasks:
		diving
		hunting(birds)
		fly dragon
	some sounds
		hit
	finish sounds
	add two or three tasks
		mining
		collect fruit
		make fire
		
	Ending celebration/failure

I’m getting worried that I won’t hit the targeted scope at this point. The assets needed aren’t too much, individually, it’s just that I have a pretty hefty list and I don’t feel as confident about being able to pump out content consistently right up to the deadline.

Got some environmental sound in – waterfall noise, and it changes as you enter different screens.

However I haven’t made much progress on the gameplay lately. I really want to get some of the gameplay in there before I sleep.

TODO
	new block type for water - the surface toggles platforming/swimming, or somesuch
	start sketching out whole game and getting bgs in place

goals for rest of today:
	inventory working
		pick up stones
		one more button to drop vs. use("shoot")
	dragon flight code
	diving code
	bird flight code
		birds placed in map are spawners?
			or we just have them run on a consistent cycle?
	spriting:
		pearl sprites
		bubbles
		swimming sprites
		dragon sprite
			idling
			flying
			hit
		obstacles for dragon area(attacking birds)
			(reuse birds for hunting segment)
		throwing stones(instead of bow+arrow)
	three tasks:
		diving
		hunting(birds)
		fly dragon
	some sounds
		splash
		throw (replace the current thingy)
		hit
		_integration_
goals for tomorrow:
	finish sounds, add music?
	add two or three tasks
		mining
		collect fruit
		make fire
		
	Ending celebration/failure

In-game tasklist is working

Win and lose conditions are in(although there is no way to “legitimately” win, just a console command)

Day-night cycle and timer \o/

Some shots

Collecting some thoughts out loud. I already did about 4 hours of work today.

I have the basic platforming structure of my game in place. It’s shaping up to look pretty good(maybe not the best though, I see some pretty competitive entries art-wise) and I have a few more things to do on the art front. What I need to get done by the end of today is some actual content.  A few thoughts came to mind during the walk(in addition to stuff I had in my last post):

Diving for pearls

Minecrafting for gems

Riding a dragon

Shooting down a bird

Still have to do some structural thingies before that, though. Onward!

I spent about 2.5 hours making these:

This  ”rite of passage” game will involve the main character(the pinkish silhouette thingy) adventuring alone through the forest and caves, trying to complete various survival tasks within a time limit(before the sun sets). Examples:

	hunt the bear
	tame the tiger
	find fruit
	make fire
	build idols
	outrun the deer

As of right now my basic character movement and animation is going, with a walk cycle, jump, knockback, and recovery.

I still need to get some core features in – game restart button, view tasklist, display timer, show a title + help thingy. It’s looking good for the first night of work, though.

My concept for the game will be “rite of passage,” some kind of platformer in which the main character goes into the woods/caves/etc. to prove him or herself.

I am doing a timelapse, I started 20 minutes late though. Oops…

Demonstration app

Source .ZIP

My previous post described the stuff I built for this framework. To get an idea of what is in the demo, follow these steps:

1. Press Ctrl+` to open/close the console
2. Type “help” in the console to show the available commands
3. Type “loadmap testmap” to run the demo level. Arrow keys move, A and S jump/shoot.
4. Type “edit” to enter the map editor, “setdef”, “setentity”, and “delentity” to browse/set the painting tool. While editing the camera is scrolled with the arrows or ctrl+arrows. Type “play” to resume play.
5. Type “tileedit” to enter the tile editor. Commands are shown at right.

In the past I’ve tried building “frameworks.” They never did what I expected them to do. But this past week I’ve worked on another one and it’s actually shaped up reasonably well. Calling it “TriadNME” – it is a haXe/NME/Flash10 2d platforming engine with applicability to other 2d games. Some notes on interesting elements of the design and things I discovered in the process:

• Mostly based on stealing existing good code from old projects. Proven code is golden, and possibly worth more than the architecture itself. I would actually consider Triad a second generation framework(the first being some bits of code for timing, the entity system, build system, etc.)
• Very centered around the haXe dynamic/static typing mix. Entities are anonymous objects, with a component system based on “conventions” of data layout(field names, an array of component destructors, etc.) attached to them. I’ve used this for about a year on many projects – it feels like the right mix most of the time.
• Lax approach to performance to favor reusable functionality. Essentially, I give myself room to use a layer or two of  indirection(callbacks, lookups, etc.), but try not to go much deeper. So, e.g., instead of a hardcoded timer I now use an Alarm class with callbacks. Character controllers, camera movements, etc. are similarly based on callbacks, thus it’s easy to go from (e.g.) flipscreen camera to scrolling and centered around the player. If I want to regain performance from those things – I can usually rewrite the specific functionality.
• Minimal contextual instancing. By this I mean – at the start I prepare all the core structures(whether as singleton instances or as static classes) and never destroy or replace them. Instead I call reset methods and toggle visiblility on the Flash displaylist. As a result, I never have to litter tests in the code for whether a certain kind of data is available, because it always is. To change contexts, I disable some functionality. As a result, there’s a whole body of code that simply doesn’t exist, since disabling is (in general) easier than destruction. This goes hand-in-hand with the approach to performance.
• My approach to algorithms has generally improved. I’ve started making my own “xxxTools” static classes for common algorithms – so I have some for math/trig/probability now,  some bits for strings and hashes, some bits specific to my AABB/tile collision system. Conversions between measurements (degrees/radians, pixels/tiles) and alignments (centered, left, right, above, below) are a major part of the toolbox and my core data structures tend to include a lot of conversion methods. Similarly, more structural algorithms like ”array of objects with name fields” to “string hash of objects” are starting to come into play. In the past I had a horrible tendency to rewrite simple algorithms and inline stuff that didn’t warrant the customization, but hopefully I’ve come around on that.
• [haXe-specific] – I use many more anonymous structures. HaXe is structurally typed and lets me add a bit of extra type checking just by wrapping everything in a little structure – e.g. most of my points are {x:Int,y:Int} or {x:Float,y:Float], instead of being a class. This adds a bit more flexibility in writing the data because I can just inline the structure into a function call instead of going through writing a class, a new() method, etc. Doing this lowers performance for the Flash target somewhat, but adds a ton of code clarity.
• While heaping on engine-level features with sprites, rendering, physics, I specifically tried to engineer them so that they’re easy to rip out if I don’t want to use them for LD. This had the effect of making them modular without an explicitly “modular/pluggable” system design – a field on the main class, one call to initialize, one call to reset, one call to update. Take those out and the system is essentially gone, although other things might reference them – but that’s more of an “integration” problem and usually just requires more things to be deleted.
• The in-game console is increasingly central to the workflow. I try to cram as many in-game tools as I can because – besides the obvious iteration improvements – it has a knock-on effect on the architecture where I need to keep data in both editable and playable forms, thus it starts decomposing towards the “real” constraints.  The console works as a way to quickly expose editing functionality. This is something I could continue to refine considerably with tool-specific namespaces, unix-esque pipes, etc.
• I opted for a tilesheet format that uses a “smallest size” of tile and rebuilds larger ones from that, similar to the character-mapped graphics of older consoles(NES, SMS, etc.). This has some interesting effects on editability – with an in-game editor the downsides are mostly covered, but the benefits in internal architecture are surprising: the structure of graphics access is greatly clarified when you have three ways to inspect a tile sheet – by set name, by set index, by tile index. It works particularly well with the autotiling algorithms I’ve made(one of the main reasons I started down this path). It also means that the framework should port more easily to a 3D-accelerated setting since only the rendering methods have to change – the original data for sprites and tiles is already a nice NPOT-sized thing.

I am entering that stage of low sleep where one is productive again(got up at 6pm, it is now 1pm). Therefore I shall waste it on words!

1. I will be doing next LD’s jam(team project) and compo(solo). So I am setting myself up for double the pressure \o/

2. In preparation for next weekend I am taking my Longcat code and factoring it up to make it a framework for simple platforming and shooting, including built-in map editing as well as image editing. If I find time it will also get sound editing built-in courtesy of SiON.

That’s all for now!