Design Choices (devblog)


About Zenith

Zenith is a rewrite of The Sentinel, originally designed and programmed by Geoff Crammond in the mid-1980s. The clue here is what I said in my first sentence, "originally designed and programmed by...", so these notes are more about design choices for implementation rather than about originating a game idea.

The Original Game

Geoff Crammond demonstrated some genius to produce The Sentinel. The game idea was daringly abstract, and its basic rules implied enough strategy to provide interest that lasts through a variety of generated levels. Further, it was coded in a restrictive environment: 8-bit computers didn't quite have enough processing power to pull off the 3D rendering that we know and love today, and the polar 3D projection used in the game meant that the camera could be rotated simply by panning and drawing the new edge of the view, rather than rendering the whole scene for 3D each frame. In many ways, the restrictions of the time helped shape the game.

The Rewrite: Zenith

So, some 15 to 20 years later, we have enough technology to make the (now defunct) game fly again, and I decided to see how the game could be played if the previous technological restrictions of The Sentinel were lifted. This is the Zenith project.

OpenGL provides acceptable 3D rendering, so we don't need to re-invent a special 3D projection; we can use a standard OpenGL camera, and program in smooth mouse-driven motion, along with a zoom feature for the player to seek out distant targets. This improves on the most-complained-about feature of The Sentinel: the slow movement. Now, we can swing the camera around for a more natural survey of the surrounding landscape, and create an in-game map by moving the camera.

Keeping it Simple

In the interests of creating a game with good balance (i.e. a progression of challenges that holds the player's interest), I kept the graphics as simple as possible. Most commercial games will have their objects designed in a CAD program, like 3D Studio, and imported into the graphics engine at various levels of detail. Not so with Zenith, as the objects are created in the code, vertex by vertex, face by face, responding to the requirements of the game's animations. There are no textures - I just use just subtle colouring and lighting effects.

Drawn backdrops, textured scenery, pretty menu screens, particle physics, and animated cut sequences, would all have been distractions for me, and a playable game could be achieved without these 'distractions'. The only hand-prepared artwork you'll see is the loading splash screen (1/3 of the size of the game archive, in terms of storage), and the little 'success' and 'failure' icons for the end-game, which show either your synthoid or the Sentinel on the pedestal. I feel that extra media would severely slow down the development of the game, and impede the tuning of the gameplay. 'Keeping it simple' proved to be the best design choice of this game.

What's different?

Given the available processing power, the graphics engine could cope with some more variables. Gone is the fixed size of the landscape: we can play in 100 x 100 landscapes, the slopes can be any height, the 'steps' can be any height, the Sentinels can rotate at any speed, and at any increments, and so on.

There are two keys to success: (1) Programming the game to accept lots of variations and handle them all consistently, and (2) Setting the variables to achieve the required game difficulty.

Another minor difference from The Sentinel is that I didn't see much use for the 'meanie' object, so Zenith doesn't have one. Instead, 'partial sightings' from the Sentinel just reduce the probability of being scanned.

Animation has been introduced into the game, given that we have the ability to render many full frames per second. The bad guys rotate slowly, and game objects deform and fade as they are absorbed or created. This is one benefit of making an early design decision about the game models: by creating game geometry on the fly (rather than using preset animations), game objects can respond to any number of actions simultaneously. This makes the game very fluid, unrestricted by simple 'preset animations' that make many games look poor, and it is far more efficient in terms of memory, development time, and managing the animations. Again, less preset content equates to faster development.

Hook and Progression

We start the first level with a small landscape, with a single slow Sentinel, plenty of trees, along with a helpful hint box that guides the player through the first few moves. Almost everyone will be able to play that level without a problem, as it allows plenty of breathing space for the player to learn the game mechanics. The first level is probably the most important to get right from a game designer's perspective, because that's when the player will decide whether your game is worth playing further: if players do not grasp the simple game mechanics (objective, basic moves), then they will be disillusioned and frustrated, and might never play the game again.

I designed the first few levels to be very easy, as I think it's better to allow someone to win easily and then want to replay it at greater difficulty, than for them to give up entirely and literally throw their toys out!

So by level 30 (of 100), the player should start feeling the game bite back. There are more Sentinels, they scan faster, and the landscape has more slopes and features. The gentle initiation is over, and failure is a realistic prospect if the player does not rise to the challenge. After every game, there is the option to go for (1) an easier game, (2) something about the same, or (3) a more difficult game. This is another difference when you compare the game alongside The Sentinel. Zenith allows you to play any level at any time, but you'll start with a small amount of energy if you lose a game, rather than carrying a 'reward' amount of energy forward as you do with a victory.

I could have implemented a pass-code system to unlock levels, like the original, but I felt that this would not have improved the experience. This is giving some trust to the player, and I hope that the freedom offered is used appropriately, to quickly match the game difficulty to challenge the player :o)


To succeed in levels 80+ (of 100) needs the fast action and quick decision that you need at the end of The Sentinel Returns, and I make no apology for this: unless I'm very lucky, I can't beat Zenith at levels 85+ myself! In fact, I don't mind if the game parameters are set too high, as I believe a game should be able to challenge any player. The same goes for my Crossmines, which can set up an almost unplayable game, again exceeding the needs of the most demanding player.

In doing this, I think I've broken one of the 'safe rules' of commercial gaming, in that I've not brought the game to a conclusion - and by that, I mean that the commercial trend is not to make games last forever, but to make a player want to buy more content, more episodes, download more maps, pay for multi-player time, and so on. Another device that I've chosen to ignore is the 'instant gratification reward': I have no pings and trills accompanying floating stars and scores that is typical of Japanese-style casual games. My reward to the player is the journey, rather than the end, or the patronising rewarding of small steps.

Further Tweaks

The New Game box offers a Tweaks tab, which lets the player change the game's variables. There are options to control the aggression of the Sentinel and Sentries, change the availability of resources, and so on. These helped me achieve the right game balance, but I left them in the game in case they provided the player with extra value. There's also a console window, which can make changes to the game, change the graphics options, and display extra information - again, this was intended for development and debugging, and was left in the game for inquisitive players to explore. There is usefulness beyond cheating: during development, the console's parser evolved into a simple scripting environment, which is used to load in preferences and game settings, and the configuration files are, erm..., configurable. I suggest that any game writer equips themselves with a console and parser module, as it has proved invaluable to me for reporting and tweaking the game while it is running.