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.
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 lasted through a variety of generated levels.
It was coded in a restrictive environment: 8-bit computers didn't 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 rotate 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.
Some 15 to 20 years later, I saw that gaming technology could make the (now defunct) game fly again, so I decided to see how the game would play if I lifted the earlier limitations of The Sentinel. This is the Zenith project.
I didn't use a game engine, because no engine at the time did what I wanted. Instead, I wrote my own engine against the OpenGL API. I estimated that my own code would lower my total effort, and the implementation would be more efficient and streamlined.
I chose OpenGL because it solved many 'bare metal' problems, with acceptable 3D rendering. Rather than invent a special 3D projection, I used a standard OpenGL camera, and added 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, I can swing the camera around for a more natural survey of the surrounding landscape, and create an in-game map by moving the camera.
In the interests of creating a game with good balance, and a progression of challenges that holds the player's interest, I kept the graphics as simple as possible.
Most commercial games 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. I created the objects in code, vertex by vertex, face by face, responding to the game's animation needs. There are no textures - I just used just subtle colouring and lighting effects.
To speed development, I cut out distractions like drawn backdrops, textured scenery, pretty menu screens, particle physics, and animated cut sequences. I could make a playable game without them. The only hand-prepared artwork you'll see is the loading splash screen and the little 'success' and 'failure' icons for the end-game.
These three assets occupied 40% of the installer file size, and sound accounted for another 20%. That compares to around 1% for the object files for the game code itself.
With this simplified approach, I was soon fine-tuning the gameplay. 'Keeping it simple' proved to be the best design choice of this game.
Given the available processing power available, the game engine could cope with more variables. Gone is the fixed size of the landscape: I 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 reduce the probability of being scanned.
I introduced animation to the game, given that I 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 fluid, unrestricted by simple 'preset animations' that make many games look poor, and it's far more efficient in terms of memory, development time, and managing the animations. Again, less preset content equates to faster development.
You 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 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 don't 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 easy, as I think it's better to allow you to win easily and then want to replay it at greater difficulty, than for you to hopelessly give up and never play the game again.
By level 30 (of 100), the game starts to 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 likely if the you don't rise to the challenge. After every game, you can go for an easier game, something about the same, or a more difficult game. In constrast to 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 energy forward as you would 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. I hope you use that freedom well, to find the right game difficulty for you.
To succeed in levels 80 and beyond, you to act quickly, like you need to at the end of The Sentinel Returns. I make no apology for this: I can only sometimes beat Zenith at level 85.
I believe a game should be able to challenge any player, so I've built in a margin where the best players can stretch themselves, beyond my expectations. 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. 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.
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.
I also create a console window, where you can make changes to the game, the graphics options, or display extra information. I intended for this to help me develop and debug Zenith, and I left it in the final game for inquisitive players to explore. During development, the console's parser evolved into a simple scripting environment, which I used to load in preferences and game settings, and let you create your own configuration. I suggest that any game writer equips themselves with a console and parser module, as it has proved essential to me for reporting and tweaking the game while it runs.