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!

I think I’m done, at least within the compo time limit. I could spend the last few hours trying to fix more bugs, but I’m not very motivated so I’ll share some early postmortem thoughts instead.

I have a process I’ve developed for game design based around these concepts:

1. The way people become interested in a game is through its pieces. Good pieces = instant tutorialization and obvious mechanics. Therefore I now always start off by making good pieces and a fitting playfield for them. In the past I didn’t do this and my games sucked. Now they suck much less.

2. I try to achieve good game dynamics using the available pieces(or tailoring the pieces a bit more to fit). I use a very specific definition of a game dynamic, which is the intersection of two feedback loops produced via game mechanics. In general, the more intersections that occur, the more compelling the gameplay is going to be. Game events that occur outside of a feedback loop should only exist to support the fiction of the game pieces. That said, I don’t follow this rule too rigidly – it’s a model that I’m trying to test, not a dogmatic order – and I try to name and categorize what I’m achieving in broader terms. In this case the theme of “Escape” suggested someone nearly powerless, trying to escape hazards.

Starting from that little kernel of an idea, I drew some inspiration from other games: the “Deathrun” maps seen in some FPS games, Tower Defense games, Transformice… It seemed inevitable that I would do a multiplayer game where you had a whole group teaming up to get past a “big boss” type.

So I drew up my game’s playfield in Pro Motion, making some early assumptions that I’d have a low-res, single-screen game running more-or-less strictly on a tile grid. I was a bit worried that the playfield would be too small, but it turned out not to be an issue. As I drew I quickly decided it would be an ice cave rather than a generic cave, because the ice cave would suggest more interesting pieces. (as someone remarked, I could have done a lava cave instead. Different game, maybe that’s “Heartbreaker part II.”) Quickly I nixed the nascent generic obstacles I had first thought of(spikes, gun turrets, etc.) and replaced them with their ice-cave equivalents: icicles, slippery ice patches, and a yeti. I thought about the obstacles as I drew up the character portraits. First I did the Ice Queen – an obvious villain for the cold setting I was developing. Then I soon decided that it was tending towards a magical feeling, so instead of generic runner characters with torches or something, I opted for the counterpart Fire Mage. The “broken hearts” setting came out of that – I had been wanting to use the title “Heartbreaker!” for a while, though I had had a much different kind of game in mind for it. I had some trouble getting the portraits looking good, but left them for the time being.

By this point it was getting a bit late into my first evening, but I pressed on to set up my base code at this point. It’s all dribs and drabs from earlier projects – the build system, some timer code, the scene initialization process, the Player.IO connection code(the cloud service I’m using to host this and run the multiplayer APIs), the algorithm for collision, the sound management. I finished with just a tiny bit of proof that I could make a real-time multiplayer game – I’ve never tried doing a complete one start-to-finish, though I’ve worked with multiplayer/network code in other contexts.

The next day, I basically pounded away at the game until it succumbed to my will. It’s not pretty code and has some major architecture flaws, which is why I’m unmotivated to try a bugfix now. The biggest flaw is that out of inexperience I tried to push too much data into too little state, resulting in desyncs between the mages and the queen’s viewpoint, and various bits of oddness with how the characters move around(e.g. when a piece is brought onto the playfield the mages can be killed by its tween animation – a very unexpected game mechanic). Also, Flash is generally poor at networking for games – it supports some obscure stuff(various kinds of streams and proprietary protocols) and it has UDP in the AIR client, but if you’re making a web game you’re basically stuck with TCP, which means things periodically go berserk as the reliable delivery “catches up” with the game.

In any case, by the end of the night I had everything in a more-or-less playable state, which I mostly credit to player.io having a sane API and a decent service. I even had some players who got addicted to the game, buggy as it is. So I went to bed, and when I woke up(a few hours ago) I immediately got to work on some sound and music assets in Renoise, cleaned up the portraits a little, and got it all integrated. And that’s where I’m at now…

I’m a bit torn between trying to rearchitect the code after the compo is over and make a bigger game out of it, or just moving on with my main project, Moto. I guess I have some time to think on the matter.

http://www.ludamix.com/games/heartbreaker

It’s multiplayer After a few rounds of playtesting I got it to “still very glitchy but playable,” which is the most I’m going to aim for in the compo timelimit.

I’m going to bed now, when I wake up I’ll try to get some sounds in.

And a screenshot:

I just got the player.io API connecting to a dev server. I have some experience with this from other projects – it’s pretty decent for making a multiplayer or otherwise net-connected Flash game, though I had some issues getting it into haXe initially(my solution was to get rid of the type annotations and use Dynamic on the parts that were breaking).

The game design has developed from “Dungeon Master and Runners” to “Ice Queen vs. Fire Mages.” The title will be “Heartbreaker” – one which I’ve been itching to use for a while. The mages have been spurned by the Ice Queen, and now compete to escape her cold, deadly kingdom, using their fire magic to clear the path. Meanwhile, the Queen toys with them, placing ice-themed traps and obstacles such as spiky icicles, Yetis, and slippery ground.

Some arts(spritesheets not shown – for effort reasons):

I am going to aim for a multiplayer game in this LD, using the player.io AS3 API to handle all the nasty issues of connecting, hosting, etc. It will be very straightforward, based on the “Deathrun” maps you see in some FPS games:

The first player to join is the dungeon master. Subsequent players are “runners.” The runners try to escape the dungeon by reaching the exit, and the first one to succeed becomes the new DM.

The dungeon master tries to defeat the runners by moving around various traps in the level. The DM has limited(recharging) energy to move the traps. I am planning to implement these traps:

• 4-way gun turret
• Hidden land mine
• Sticky patch(slows)
• Bullet reflector

I don’t know if I’ll see an entry through for either compo or jam this time, but I’ll give it a try.

Going to be using haXe/Flash9, and some bits of my old game code(don’t know what yet, but it’ll all end up published in the end) for the code side of things.

For art I guess I will do my usual Gimp/Pro Motion/Inkscape mix, and sound-wise I will probably stick to 8-bit stuff with sfxr or somesuch.

In the first few hours I’m gonna juggle my thinking about the entry with another release of my main game project, Moto. Got some new graphics and stuff to show

It turns out to have some astoundingly deep gameplay for how few elements are in there. I don’t think I took the level design nearly as far as it could go.

Play here.

Play

I have all the tiles in now, and more sounds(“Expert!”). It was a bit tricky for a number of reasons:

• Still coming to grips with the way Pro Motion works. It’s a realllly powerful tool, but that leads to several kinds of modal situations that are unintuitive(working with alpha, picking up tiles so that they can be placed – for some reason you can’t just click in the palette).
• I also wasted time making tiles in an inefficient way or making tiles I didn’t actually need for the system I ended up using.
• I had to make a “chunked” tile engine based on the basic one, which splits each tile of collision into 4 graphical pieces. This also meant some data entry, fortunately I didn’t have too many pieces.
• For some reason, Firefox started caching the swf and refusing to let go. I finally got it going again by manually re-entering the URL.
• I also had to add a second layer of transparent 20×20 tiles on top of the background. This wasn’t tooo difficult but the swf-caching problem really slowed me down.

Anyway, now I think I’m going to do level design, get a title and win screen together, and call it done. I seem to be on track to use almost all the time available. This is probably the best I’ve ever done with any game jam situation, usually I get demotivated or stop at an early point

Check it out here. Although the sound effects are a bit sparse right now, just “shoot” and “explosion”…I’ll probably do a few more.

For your sampling pleasure

All of the note data was made in Busker – I just laid out some notes, then applied a chord sequence and a style. Then I did the instruments and mix in Mixcraft. Not totally happy with it, but hearing it again, it feels like I spent way more time on it than I did.

Now it’s on to some sound design in Renoise.

I would have taken pictures but I don’t have a good setup for that right now. Breakfast was bacon, turkey sausage patties, and a scrambled egg fried in the fat of the other two. Then a “Fiberful” fruit bar, and then my usual supplements(a multi, additional D, calcium, an Omega-3, and whey protein), followed by some green tea to wash it all down. This is food that makes me work well. Heavy carbs like beans+rice, potatoes or cereal just make me feel hazy, ill and unmotivated.

Just got up, showered, shaved, and now I should probably find something to eat.

But today’s the day where I make Pincer look and sound awesome, as well as hammer out all the level design. Wish me luck!

Against my better judgement, I went ahead and implemented Dijkstra’s Algorithm. The time cost was large: 3 hours, most of it spent on a bug that I resolved by not being macho and using the 2D field class I had been using for every other 2D grid(tiles, collision) and really should have used for the nodes from the get-go.

But it works. I need to give the pirates a proper LOS check though. That can come tomorrow.

I figured my other AI could be a pathfinding one. Surely I could just reuse some pathfinding code for haXe? No, of course not. The library I found showed several signs of poor manufacture(particularly, using the extremely slow Enum construct to identify whether nodes are start/end/clear/blocked instead of, say, an integer value) and threw an exception in use.

Now I’m left torn between writing my own pathfinding code(done it several times before) and integrating it into the Roguelike collision system, or to go with dummy run-at-player AI. The latter would be a much safer bet, but I think that having a pathfinder mob, besides being useful library code, would add more dynamism to the game – with the water and bombs, there’s plenty of opportunities for the player to snipe at them or send them into traps, rather than it always being a head-on combat situation.

This is probably one I should sleep on, really. I’m at the end of my day.

This game has some basic combat going now.

First you have to cross along the line of fire of the pirates(who, at least in this incarnation, just shoot in cardinal directions) to get to the ammo.

Then you have the option of picking them off like a sharpshooter, weaving in and out of their fire line, or blowing up the bombs, which will conveniently chain their explosions. It’s awesome, albeit a bit hard to read with the colored blocks. I think I will go to bed in another hour or two, add a few additional forms of AI to vary things, and then do the level design and polish.