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?

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.

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.

Haven’t updated much in the past week. I’ve been doing minor boring tweaks here and there; I’m mostly trying to get off my ass and implement enemies, damage, death, etc. You know, the actual gameplay.

Much more robust collision is getting implemented. I also figured out an optimization I could make that makes the collision routine involve fewer line-line intersection tests. Fun.

Sloped tiles now work ingame, as does a rudimentary version of dashing. I tried working on walljumping a little but it’s tricky to get it to look/feel right.

I spent today upgrading the collision code to handle things like sloped tiles, “cloud” tiles (which you can pass going up but not down, unless you press Down), and that sort of thing. Still some issues with it to iron out, but it seems stable.

I added something I’ve been meaning to add for a long time, which is support for “scroll bounds”. Basically these are rectangles you define in the editor that are then used ingame to restrict how the camera moves. What this does is makes it so you can have corridors or towers where the camera isn’t constantly panning except along the major axis. It also lets you place doorways you can’t see past until you pass through them. Also, for very small rooms, it keeps the room itself centered onscreen rather than unnecessarily panning.

After spending a bunch of time unnecessarily optimizing the scripting system, I started adding some actually useful stuff to the editor.

1. Tileset loading is a lot faster because colorkeying and chopping tilesets into 16×16 tiles is all done in unsafe code. It is now basically instantaneous to reload all tilesets.
2. Added the ability to show/hide individual entities.
3. Added the ability to show/hide whole groups of entities (roughly based on types.)
4. The editor viewport now shows entity names so you can see them without having to look at the property editor.
5. There is now a “Find Entity By Name” feature (Ctrl+F) that will locate an entity by name and center the view on it.