Sentinel Development Diary 2 / Getting Game on Screen
With the overall menus in place and a solid roadmap of the development ahead of us, the second proper session of development on our latest XNA title Sentinel sees the addition of the main game screen and the player entities. I’m going to talk about some of things that we did on this day, and the differences we made between this game and Ikaroids.
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).
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.
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.