As of spring 2017, it's been nearly five years since my first shot at a first-person engine with eight directions based on sprite scaling, inspired by a certain 8-bit classic. At the time I wasn't aware of any newer game made in the same style; in the mean time, the aforementioned classic was ported to modern platforms and even got a spiritual successor. It took me until the winter of 2015 to try again myself. Still not with a strategy game, mind you — in fact I tried for a roguelike, probably with Necklace of the Eye fresh in mind. Never got around to explaining why it fizzled out, either; a mistake I'll rectify below.
Point is, after 16 more months it was time for yet another take on the concept. And as it turns out, third time's the charm.
See, the biggest two problems with the previous version were that having to spend so much time driving like a tank around flimsy obstacles such as trees was a chore, and even with a wide field of view orientation was difficult. Back then, various friends suggested a kind of rear-view mirrors, but they showed me prior art and, like, ugh. Also, seriously? In the end, the better solution was... going third-person (though you can easily switch back simply by moving the camera right on top of the player avatar). A bigger drawing distance — 12 tiles out right now — and spaced out sprites making it clear when you're moving past them also help. All in all, a big step forward!
(Well, it's also a step away from the engine's classic inspiration, but it can't be helped. Besides, that's how art progresses. And hey, this gives me the means to make at least a couple of games I've been dreaming about for a long time now.)
It's hardly perfect, of course. This rendering technique has quirks, which will shape any game made with it. And you know what? That's great, because few games these days have a personality of their own, and even fewer dare to be strange. The engine calls for wide open spaces and a staggered, irregular arrangement of landscape features, but in return makes it very easy to define them: the map format is sparse, basically a list of objects with their coordinates. Said coordinates can even be negative, or up in the air, and you can first draw the map, then decide where the margins are. It's harder to draw walls along said margins (more on this below), but that just means you get to be imaginative about the way you keep players in:
- Don't. Let them exit the map if appropriate, say from a town to the overworld.
- Make the map wrap around.
- Warn them, then restore from the last checkpoint if they persist (like many shooters today).
- Use invisible walls, preferably with a good pretext.
- Make it so they can only walk on certain tiles, which you arrange in pathways throughout the level.
I'm rather proud of the last idea. Sure, it can make your game feel more like a stroll through an English garden, but those are pretty much made to evoke mystery and adventure in an otherwise safe and mundane space. In fact they can teach level designers a thing or two.
In the way of downsides, you want all sprites to be drawn in the same scale. You can make small adjustments in the engine, but it looks bad if you go too far. Stylized art and/or a good choice of theme will go a long way here. Worse, a compact row of identical sprites (let alone a compact block) looks absolutely awful. Never mind convincing — players can accept an abstraction — it looks ugly, and confusing on top of that. But a maze doesn't need opaque walls to be fun. Negative space is a thing, too, and the glimpse of another alley through a hedge invites the player to figure out how to get there better than any mission objective.
On the technical side, the engine relies on the same 2.5D camera I used in everything from Attack Vector to Glittering Light. It's naive, and has room for optimization, but it doesn't get any simpler than those 20 lines of code. Because this version of the engine is based on my first try, not the second, it's missing a few features such as changing the background depending on which way the camera is pointing. Speaking of which, rotations are now handled outside the camera, which may seem counter-intuitive, but makes sense given the camera itself can't turn. This is achieved with unit matrices for the cardinal directions, and "half-unit" matrices for the intermediate directions. It's all done kind of inefficiently, but could be tightened up for a realtime game. You'd have to change the logic to be less (or less transparently) tile-based, but the rendering subsystem proper doesn't care either way.
What I don't have right now is a game idea, apart from vague plans. But ideas should be coming along more easily now that I have the means to express them. A good reason to make experiments like this from time to time, wouldn't you say?