Projects & Tests :(

Agh, not enough time to work on platformer recently.

I did get a little time to implement a prototype of a throwing knife weapon, which is interesting, but I still need to add some actual enemies and gameplay.

Also, I messed around with the scripting language, doing some completely unnecessary (but fun) work like control-flow graph optimizations and peephole optimizations. Some graphs follow:

Before optimization (notice jump-to-jumps) and some slightly redundant bytecode:

output_beforedot1

Before

After:

After

After

There’s some weirdness still, like right now the STVAR (store variable) opcode doesn’t actually eat the top-of-stack because it results in less instructions for a naive code generator to support things like A = B = C, but now that there’s peephole support I’ll probably change it to be more reasonable — the codegen can just emit DUP, STVAR to support that, all statements will be suffixed with a POP, and I can add a peephole rule to change that to just STVAR for the common case.

There’s also a bunch of things that it still doesn’t support, like right now it doesn’t actually assemble the basic block graph into linear code yet because I haven’t thought of a smart way to choose how to order blocks so it can take advantage of fallthrough and not need a JMP at the end of every basic block, or a JT <ifTrue>, JMP <ifFalse>.

It also doesn’t do anything really fun like variable liveness analysis, common subexpression elimination, or code motion; it’s also a stack based architecture so there’s no register allocation to be done. Maybe I’ll spin this into a separate project to write a JIT or something, so I can actually get a game done while also satisfying my bizarre compiler desires.

Collision cleanup

Cleaned up some issues with the “new-ish” tile collision system, including an issue with sliding on slopes, adding “thickness” back to walls (i.e., so the player’s bounding rect is not zero pixels wide), and a little optimization. I also fixed some 1-frame glitches in animation that occur when you dash.

Back, maybe?

After a long hiatus I have been getting some time to do a tiny bit of work on Platformer again. Unfortunately, I am spending that time unwisely by prematurely optimizing the script VM. I think I am basically up against the limits of how fast I can make a VM loop for a dynamic language in C#/.NET — the only improvements left are going to be incremental — so I really ought to just wait until script actually slows something down and then just move that into C#. But it’s kind of fun to mess around with optimizing.

Spelunking

Experimenting with some “larger” tiles — i.e., making 32×32 blocks instead of just 16×16. It gives you more room to fit in details and looks a little less monotonous. This is inspired by the “fat” tiles used in Joakim Sandberg‘s work.

screenshot00031

I also tracked down a bug that was causing the editor to very rarely get stuck in a mode where you couldn’t use Undo or Redo. It only occurred when you moved a tile selection, but dropped it exactly back where it was originally. The code was doing a return without popping a level off the undo-tracking stack.

Sprite XML improvements and finally, a background

The sprite XML files no longer are processed by XNA’s content framework, and the processing for them is just generally less convoluted. This means that it is easier to change the loading code to add new features, and in the future could allow for live reloading of sprite XML files during testing.

I also added some time-saving features to the XML format for sprites. For example, you don’t have to specify the size of a visible quad because it figures it out from the texture, and you can place hitboxes relative to visible quads so you don’t have to do any arithmetic if the visible quad is offset from the origin. You can also specify default frame lengths for an entire animation.

I don’t know if that made sense to anyone, maybe I’ll write up a post describing how the sprite XML files work overall later.

Also, a background!

Makes a big difference, don't you think?

Makes a big difference, don't you think?

Gameplay may actually show up soon

I have got the attack/hit boxes from the sprite XML files properly interacting with each other, so now you can actually hurt entities and be hurt by other entities. It needs a lot of cleanup, since this is just a first-pass effort, but pretty soon I’ll actually be able to work on the parts that actually make a game fun, rather than endless technical details.

screenshot0006
Lenny beats up an innocent punching bag. With a sword.

Probably should have done this sooner

I actually started laying the foundation for real gameplay today. You can get hurt, die, and respawn, and it remembers the last “checkpoint” you touched so you don’t have to start from the beginning of the level again. Checkpoints are basically just a number that says you got to them, not a snapshot of all entity states or anything — so this is again a very retro system for resuming a level after dying. Also, there’s an HP gauge! It is actually a little too high-contrast for the existing sprites, so maybe I’ll have to tone that down. The blue gauge underneath it is planned to be used for a “special” bar that increases as you beat up enemies, eventually letting you execute special moves — think arcade fighting games.

screenshot0003