Some coding done

The first session of coding (2 Feb 2015) found a workable API for the graphics. It gave me smooth frame rates on many platforms (I'm hosting the game in a web page), at least for the rudimentary graphics that I tried in my own project, and the complicated third-party demos that I ran. This answers the most frequently-asked-for request: "Can it be written for [iPhone|iPad|Android|Mac|Windows 13|Psion Organiser]?" Yes, it certainly can. Well, mostly.

I'm determined to give this game some 'UI modes'. Zenith didn't really have them; it was simply a player view, or a map view, and that was it. Occasionally some Windows-API elements would overlay that, when the game loop was paused. This time, it will be like the typical commercial game you see now: menus are drawn within the game canvas, over the game graphics.

Rendering Architecture

As with the original, I've made some architectural decisions that will help it run efficiently (and this time, on many platforms). I've already had it running on Apple devices, Android, and desktop - this made possible by HTML5. The rendering component will run at low frame rates when (if!) the game is dormant, and there are options for lower resolution rendering, to help the high-dpi devices with power usage. The simulation runs independently of the rendering, so these changes shouldn't adversely affect gameplay experience.

Priorities

My first priority is to have a main menu working, and be able to play a single landscape in a Quick game. There's a LOT to do. The biggest challenge is not necessarily coding this project; it's staying focused on the simplest form of objective, without deviating on 'side quests', without trying to cram in extra features, and without trying to code for all eventualities.

Stretch Goals

So with the fast path in mind, lots of other considerations, which could be within the design scope of the game, are relegated to 'stretch goals'. Some examples might be:

• Hosting player accounts, saved games, recorded scores for online comparisons and challenges.
• Multiplayer or computer-controlled opponents
• Advanced geometry (but we have some great ideas for the default landscape geometry)
• Adaptive rendering, a pet subject of mine. I'll invoke it if I'm getting performance issues.

Principles

Some principles I will be following:

• Computed animated models (as before), rather than imported animations.
• Procedural generation where possible; preset assets to be used where it's more efficient for the client to handle, so long as it avoids bloat.
• Relatively little texturing, and simple-as-possible geometry.
• A repeatable experience, so people can talk about their games, and have others try them.
• I won't be making every level neatly solvable. The top end will be very hard to play, perhaps impossible.
• I'm taking tight control of the brief.

So, what web font shall I use?

I'm only partly joking. I think an accessible font is required to make the experience uniform across all platforms. My main menu (pictured above) used an Adobe font that came with CS6, so I'm sure I can't use that in the final game. I'm liking the look of PT Sans Narrow. It feels gentler than Gill Sans Condensed, and despite some slightly jarring letter shapes (but fewer than Gill or the alternatives I was looking at), it's not too condensed, and flows well enough to be used in short phrases or longer passages (of which there will be few).

Can I see it?

In case you're wondering, you can't see it yet, and I won't unleash it until it's fairly playable.

I'll continue with this when time allows, which is, for the foreseeable, not very often!