Placeholder Graphics

During the early development stages, Jackson spends more time working on the menu screens and splash screens than the general art work. This may seem like a strange route to take as the game assets and entities are obviously more important. However, we learnt from Ikaroids, that you will often find out part way through development that your sprites are too big, or too small, or the wrong colour palette for example. If your artist has spent 4 hours producing a gorgeous 64×64 pixel player sprite, but you later realise that you need to add a zoom function and you’ll need the sprite to be 128×128, he might have to start over.

During game development, we make very simple sprites to represent the final sprites. This gives you the opportunity to crank out coding before the hours of required work are spent on graphics, but also let you test out the game mechanics with placeholder sprites.

Figure 1 shows the very first rendering of our game screen. The background was made in 2 minutes using the first slightly appropriate fractal from Apophysis – Fractal Flame rendering software. The planet sprites were made using Gimp with a cloud layer, a colour layer (multiply mode) and a radial gradiant layer (multiply mode). We also made a handful of other sprites for the player pieces, these were appropriately coloured primitive shapes with well defined borders (not shown in the Figure).

Figure 1. Sentinel - With placeholder graphics

First Steps for the Game Screen

The first step for our main game screen was to build and implement the Entity Manager and the base Entity class. Ikaroids was a classic 2D space game in which the majority of the entities played by the same rules – at least in terms of physics, collisions etc. In Sentinel there will be vastly different types of entities on screen – completely static ones, ones that step around a grid at fixed time steps and then ones that obey a set of physics rules. As such, we went for a base entity class that handles the very basic common features of all of these entities (their space on screen, collision detection etc), but then we wrote a number of derived classes – such as PhysicsEntity and PlayerEntity, which will form the base classes for the rest of our game. In Ikaroids, we also had a single massive list of all of the entities on screen, so that we could iterate through them quickly for collision detection etc. In Sentinel, we know that some functions will only apply to certain types of objects – so we actually split our entities into 3 lists – player entities, physics entities, static entities.

I like to code in the basics of the player entity as soon as possible, as it’s fun to have the player entity darting around the screen – even if there’s nothing it can interact yet. There’s a certain morale boost from seeing your (temporary) player sprite moving around the screen. We currently have a nearly empty EntityManager class that handles all of the entities on the screen, and loops through the entities on the screen to call ‘update/draw’ routines as required.

Conclusion

So, by the end of the second proper session of coding we had the menus, ScreenManager and InputManager from day one and we’ve made a pretty good start on the actual GameScreen component of the game. We have a couple of planets on the screen, a couple of controllable player pieces and we even had a physics entity that moves in a straight line and bounces off the edge of the screen (not very inventive, but it sets the ground work!).

We’re already pleased that we used place-holder graphics, as we’re not entirely sure about the planet design and theme. We might swap the planets out for more abstract space anomalies and we’re even considering making them a little smaller on the screen – as they take up a fairly high proportion of the screen at the moment.

Classes written (well, started…) today: SentinelGameScreen, Entity, PlayerEntity, BallEntity, EntityManager, GameGrid.

Today we document the first 5 hours of development with some planning, concepts and basic ground work.

Planning and Design

One thing that we learnt from Ikaroids was that you have to put in a sufficient amount of time into the planning and concept stage of a game before sitting down and cranking out code. It might seem like a chore, but spending a day or two thoroughly planning your title (more for a bigger title) will overall reduce the amount of time you spend on the project. When you have a good idea of the data structures you need before you start coding them, you can produce a good first draft of the class in one sitting, and you’ll have an overall idea of how it’ll all plug together.

From Ikaroids, we used the software XMind for quickly drafting our concepts into a basic plan. 

A Mind Map from the early development of Ikaroids

From here we fleshed out the details of the game in a separate Mind-Map, which listed the the campaign structure, the bad guys that you would face and some information about the pickups and mechanics. After generating a couple of Mind Maps, we fleshed out a sprite list in Open Office and then started work. We have followed the same steps for Sentinel, except with a keener eye for the details required.

Concept Artwork

It’s handy in the early days to pin down the artistic style of the game by drafting some concept art. This also gives the programmer some set pieces to start working with before the final graphics are ready. For Sentinel we produced a small handful of basic images using our graphics tablet (you don’t need a massively expensive Wacom for concept art, but veer away from the cheapest of the cheap). Using my Trust TB-7300, which has a superb response and detail level, I produced a few images depicting what the overall gameplay would be like, and the title / menu screens.

Concept Artwork showing the title screen of Sentinel

Concept Artwork for the Menu of Sentinel

These two pieces of concept artwork are exceedingly simple, but they set the overall layout of specific elements of the game. They also mean that the programmer can get started on the game without having to change too much later on. It also sets the style of and feel of the game which helps to generate buzz between the artist and the programmer.

Initial Coding

Today marked the start of coding for Sentinel. I know that I said that you shouldn’t jump straight in, but we have a pretty clear idea where we want this small title to go after only a few hours of planning and it’s a good idea to start the programming on your game aimed at ‘re-usable’ game components that will be re-usable in later projects. After Ikaroids we thought that this time around it would be much better to build a ‘User Interface’ library, instead of mashing all of the menus and screens together with code every time. 

After an hour or two of coding, we had a library consisting of a few basic UI elements – including Labels and Select Menus. With the UI groundwork in place, adding new elements is relatively simple and adding them / moving them around the screen is even easier.