So, what do we have this week?

We’ve been trying to put together some more interface graphics to help make your user interfaces more friendly and shiny. We’ve tried to keep them reasonably generic, so that you can brand them up with your game’s logo and your own font, but the goal is to give you the chance to get to your first prototype as quickly as possible. The obligatory screenshots follow;

Free High Definition Grunge Theme for your XNA Game (Click to Enlarge)

High Definition Victorian Theme for your XNA Game (Click to Enlarge)

These themes come with a background image (the Victorian Theme has 3 colour variations for the background image), a full screen overlay panel and a half screen overlay panel (for two player games, etc). The panels can easily be scaled down to the desired size if they are too big for what you need them for. Imagery is provided at full 1920×1080p and the full screen overlay should allow for overscan (although, you might want to shrink it an extra 10-15% for the Xbox 360).

Download the themes from our online asset library; Iron Star Media’s Grunge Theme, Iron Star Media’s Victorian Theme

I’d like to finish with a quick shameless plug… If you’ve not already heard the news, our Xbox 360 Shooter Ikaroids has recently been reduced to only 80 Microsoft Points, give it a look!

The free game assets on this site are released under the Creative Commons Attribution Licence. This basically means that you can download them, use them in your game(s) and modify them as you like. If you use them in your games, we’d appreciate a small mention somewhere in the credits / on the website (and a free copy of the game would be cool!). Basically, the only thing we don’t want you to do with our assets is sell them as assets to other developers, either individually, or as part of a collection.

They say a picture is worth a thousand words, so here’s are the particle sprites in this pack on a black background;

 Free particle effect sprites for game developers

The particles all come as 24-bit png’s and they’re intended to be used with their colour settings and alpha settings being tweaked as the particle moves about. If you’d like further information about how they were made – please don’t hesitate to get in touch.

If you’d like to use these in your project – Download the Iron Star Media Particle Effect Sprites Pack 01.

As always, if you have any specific requests for what type of assets we should be giving away, just leave a comment below and we’ll do our best.

The free game assets on this site are released under the Creative Commons Attribution Licence. This basically means that you can download them, use them in your game(s) and modify them as you like. If you use them in your games, we’d appreciate a small mention somewhere in the credits / on the website. Basically, the only thing we don’t want you to do with our assets is sell them as assets to other developers.

You can download Ikaroids from your Xbox by browsing to Game Marketplace -> Indie Games. There you can list games by title and find Ikaroids for your gaming fun. Alternatively, you can buy Ikaroids from your PC, so that it’ll simply download and install the next time you turn on your Xbox. Download Ikarois now from the Xbox Live Marketplace.

This post marks the first release of free assets that we would like to release to the community to help other independent developers who need assets for their games.

Below you will find a small collection of MP3s that you are free to use in your own game title. All that is required in return is that you credit us somewhere in your release notes. Of course, if you make it rich from a game that uses a selection of our assets, we won’t mind if you want to donate us a few pennies for our work.

The first assets we would like to release are tracks that never quite made it into our first XNA title – mostly because the theme just wasn’t right for our game. We’re still getting to grips with our music generating software, so we apologise if these tracks aren’t brilliant, but please bear in mind it’s the start of something that will just get better and better! We also hope that this starts a trend that of giving away assets that we can try to keep up on a weekly basis.

The tracks that you can download and use in your XNA / iPhone game projects this week are;

Menu 001 – Some relatively ’spacey’ menu music for a space based game.

Random 001 – Some reasonably generic drum-beat game music.

Random 002 – A little bit ‘folky’, this might make good tavern or docks music for an RPG!

Orchestral 001 – This is something a little more epic. I’m not sure where you would use this, but it might work for some FMV or equivalent!?

I hope that someone out there finds this useful. We’ll try to bring you another release of free assets (of some random variety) sometime next week!

As always, please leave any comments or thoughts in the boxes below.

Edit. Please let us know if you have any requests for types of music. We won’t make it to exact specifications, but if you would like something in a specific genre (e.g. more menu music, or friendly platformer music) that would give me a goal for future tracks. These were just me getting used to the software and I’d like to develop by making more in-depth (and better) tracks!

Confusing gameplay

While I’m not a fan of games that have so shallow a difficulty curve that it’s impossible to move without a dozen prompts explaining which button keeps your character breathing, I at least expect to know what is going on. If I have gone a full few minutes not knowing being able to tell pickups from enemies, and genuinely have no idea what I’m supposed to be doing, then something has gone seriously wrong. Instructions should be included where necessary, and explanatory, non-intrusive tooltips only where needed. I myself find it seriously annoying when popups keep interrupting me to tell me what button is which.

Cutscenes/excessive narrative/playing as a character

While this is far less prevalent in Indie games, this is one of my biggest bugbears in games today. It seems that many of them are far more concerned with making a movie than they are a game, and it brings up the cost of production considerably. Besides this, I find it takes me right out of the immersive nature of the game when I’ve been playing it for a while, then suddenly the controls are yanked away and I’m forced to watch as my character does something incredibly dumb just to force the next scene. You start to feel more like you’re helping a character get through his/her movie rather than playing the game yourself. There are exceptions, where the plot is truly exceptional, and actually becomes a reward for completing a section, such as Metal Gear Solid, but by and large, I find the cutscene an interruption to something I was quite enjoying.

Prime offender: Too many to mention – but one that sticks out for me is Doom 3. If ever there was a game that didn’t need to change camera angle to third-person to show your nameless doing absolutely nothing, it was this one. A prime example of breaking tension by removing you from the driving seat.

Fake difficulty

This can encompass a variety of things. Sections that are only hard because they require endurance, such as a boss that requires you to hit a certain weak point… five hundred times over. Levels artificially lengthened by getting you to run across town back and forth performing meaningless errands. Or my personal favorite – the old ‘take away all your guns’ maneuver, usually done during a cutscene where your character acts like a complete imbecile in order to facilitate this.

Prime offender: Prototype. You’ve built up all these amazing powers, right? Lot of fun, right? Well kiss that goodbye, as a bunch of levels take them away for a while. Just to ‘add challenge’. Which is is all well and good, but I was having fun back there!

Lack of feedback

If I shoot a guy, I want to see it hit him. I don’t necessarily mean a gout of blood or anything, just a feel that something has impacted. Like there’s a connection between my weapon and him. That’s a tactile reward for performing actions, and in a great game it goes all the way from combat to selecting menu items. Through sound and visual FX, you should be able to ‘feel’ the results of actions, not fire a gun and then see a man fall over in the same way as if I hit him with my crowbar.

Unrealistic combat

This is mostly confined to first-person shooters, but I cannot stand it when I have to shoot a man 50 times in the chest with my pistol to finish him off. By the same token, if I get shot, I expect to die. Everyone being able to take a truckload of bullets before finally falling over just removes the sense of urgency and tension in combat. The prospect of sudden death, in my opinion, encourages far more tactical thinking, and is ultimately a lot more fun, as long as the game is balanced for it.

So there you have it, five things I’d like to see a hell of a lot less of in games. But like I say, there’s probably plenty more I could throw in, given the chance. Feel free to have your say on the subject in the comments section!

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.

Should We Add Difficulty Levels?

We originally decided against having the option of selecting the difficulty in Ikaroids. We figured the campaign would start off easy and progress to hard as you worked through it. What we didn’t account for, was the fact that we’d spent 4 months playing it during development when trying to set the levels…

The game came back from playtest with a number of comments stating that the game was too hard. However, we could blast through most of the levels without getting a game over and didn’t want to make it considerably easier so that players that are dual-stick shooter fanatics like us didn’t get bored.

It was clear from this point that adding difficulty settings was the most appropriate resolution to this problem.

Is it going to be a lot of work?

How much work it is to add difficulty settings to your game depends on the internal structure of your game. Most games will have a small number of variables that are easy for you to change depending on the difficulty setting that can have a massive effect on gameplay. This is where you should start to look initially.

If your game is a break-out clone, change the speed of the ball. If your game is a golf game, ramp up the chance of having strong winds. In our case, all of our entities are derived from the game base class, so we simply scale the hit points, speed, reaction speed, firing speed and AI targeting range to make them worse for easy mode and better for hard mode. The whole change took less than an hour and has opened the game to beginner players, as well as generating a reason for people to play through the game multiple times. 

So, we increased the re-playability of our game, made it easier for beginning players and make an exceptionally hard mode to make a challenge for hard-core gamers. Not bad for an hours work.

A particularly tough moment in Ikaroids (Xbox 360)

How easy is easy, how hard is hard?

The last challenge is to decide how difficult each setting should be. I have seen a number of games (both XNA and real) where the difference between Easy and Medium is fairly non-existant, and then hard becomes an absolute beast to tackle. Alternatively, some games make Easy so easy that it’s boring and then normal difficulty becomes the only real way to start the game.

Here at Iron Star Media Ltd, we believe that you should be aiming for the following out of each difficulty setting;

Easy: Should be easy enough for your mum, sister, girlfriend to pick up and complete the first couple of levels. It might get a bit tough after that, but even someone with little gaming experience should be able to make progress by breaking a sweat. As a developer, you should be able to get through a third of the game in this mode without a challenge, after which, you might lose once or twice – but generally don’t find it a problem.

Medium: On regular difficulty, your game should still be accessible, but it might present a solid challenge to the non-gamers out there. Regular gamers should be able to play through the first couple of levels without much of a challenge, but then they might start dying a couple of times on each level before being able to complete them. All in all – you should be looking at ‘regular gamers’ having to tackle some of your later levels (but not necessarily all of them) a couple of times before progressing.

Hard: We are firm believers that it’s important to add a really challenging difficulty mode to every game. On hard difficulty, people that haven’t played your game before should struggle to get past the first few levels. Even seasoned gamers should struggle on  a number of levels and it should be exceptionally tough to get past some levels. However, don’t make a game tough by making it impossible, or by making boss fights really, really long – add some extra enemies or give them an edge, but don’t just draw it out for the sake of it. It should be a real achievement to complete the game on hard, and even as a developer – you should struggle to do so yourself. Don’t under-estimate the hardcore gamers, they want a challenge and you’ve given them the choice of playing it on an easier difficulty if they struggle.

Of course, this is just like, our opinions Dude, so feel free to take it or leave it. However, we can hand on hearts say that this simple addition has added much more variety to Ikaroids and has really helped to please the playtesters!

Game Screen Flowchart

Once you have your concept down and you have an overview of the main features of your gameplay, I like to do is consider is an overview of the general process that the user go through when playing your game.  These are the screens / interfaces that your players will go through when playing your game. While these may seem unimportant, they give you an overview of the game and also set the technical limitations of the game – do you need a a single player character select screen, or a co-op or even 4 player one? Do you need an option screen for user editable options? What options will they be?

Figure 1. Ikaroids Game Screen Flowchart

The Main Game Loop

The majority of the screens in Figure 1 will be stand-alone screens that set configuration parameters or load specific game objects for the ‘Main Game Screen’. The Main Game Screen is where you will spend the majority of your coding time (and asset generation time, of course!) and this will make up the actual game that you’re producing. Depending on how you are representing these individual screens in your programming (we made each screen a class that plugs into a DrawableGameComponent that acts as a screen manager), you will need to load the level and associated assets in the ‘LoadContent’ routine for the screen before the game loop starts.

I’m assuming that you’re programming for a console or a similar, linear programming environment (you’re not running your game through an event driven system, such as with a typical windows UI). In the majority of games, your main game loop will probably look similar to that of Ikaroids;

Figure 2. The Main Game Loop from Ikaroids

The main game loop is often similar for the majority of games, although the actual processes taking place at each stage are likely to be very different. In many simple games, there may not be any physics at all, and updating the entities in a game like Tetris is a rather simple affair. It’s worth writing down a few bullet points about what you need to happen at each of these stages, and this will give you a rough outline of how your game will play and what code and classes you need for the game to function.

Thinking about Classes and Entities

Now that you have a general idea of what will be taking place at each step of the main game loop, you can start to think about the code that you will need to make up your game. This can vary massively from game to game, but it’s always worth trying to ensure that you make every effort to (a) break as much as is reasonably possible into separate classes and (b) separate game logic from the game engine as much as possible. If you adhere to both of these strategies, you will find it much easier to fix and/or replace classes if you need to fix bugs or improve certain parts of the game, and you will also be left with a large number of reusable components that you can use in future projects.

With this in mind, I’ll give you a short run down of some of the main classes that we built for Ikaroids;

Figure 3. An overview of the main classes in Ikaroids

Now, of course, there are a lot more classes that make up Ikaroids. There are about another 50-60 or so that make up all of the separate entities, bosses, weapons, bullets, pickups, AI Packages, etc. However, the majority of those classes are extensions of the Game Logic classes shown in Figure 3. The Reusable classes are actually already in use in a second game project, and where we are using all but one or two of those classes. We’re also building more resuable classes in the form of a User Interface Kit to make producing user interfaces for the menus quicker and easier.

The Entity class above has a lot going on inside it, and it handles everything that any entity on screen requires. It contains a reference to a sprite (or a collection of sprites), a number of AI Packages, it’s position, it’s properties for the Physics Entities, it’s draw state (is it invisible?) and it’s game parameters (is it invulnerable? how much health does it have? what does it do when it dies?). There are many virtual functions in this class which are overridden by derivative classes. The EntitityManager stores a massive list of all of the entitities and then iterates through them to update them / draw them / see if they collide etc. As previously stated, this is by no means the best way of doing things, and is far from perfect – but it gives you a good starting point if you’re thinking of putting together your own game engine.

Prototyping

The last thing I’m going to talk about is prototype code for your game. Before you leap into coding your game in it’s final form, it’s a a good idea to write some prototype for parts of your game. As your classes are now reasonably small and modular, you can whack some code together pretty quickly to make sure it works. This is especially useful to get you thinking about just how something is going to work. Are you going to load your levels from XML files? If so, put together a mock XML file and file reader before leaping in and writing the final version. This allows you to see all of the problems and questions that you’d not thought of, so that you can answer them before writing your final one. This leaves your code free from hacks and generally cleaner and more reusable.

Prototyping is also useful for testing performance in your code. However, you have to be careful when it comes to performance. One word of advise – if your prototype is ‘good enough’, don’t spend all of your time trying to make it perfect and even more optimised. It’s not worth worrying about wasting  a few CPU cycles if your game doesn’t need it. Drawing a thousand sprites to the screen is no problem at all for XNA on the Xbox 360, and while it might sound like a huge task that will need you to make sure that every bit of garbage is reduce and removed, in reality – it’s not a problem. And if your code runs fast enough – ie. doesn’t cause any slowdown for the game you want to produce, it’s not worth the time it will take you to make it work 10% faster. Don’t write messy code, but don’t worry about writing the 100% perfect optimal codebase either – if it works under a stress test of the worst conditions it’s likely to face, don’t waste any more time on it – put that time to better use on other parts of your game!

Last of all – be flexible!

Perhaps the most important thing to remember, is that however much you plan – you will always want to make changes after you’ve started coding. Be flexible. If something that you thought sounded great just doesn’t work in the game, you should remove it. We spent hours coding up a system where time would dilate near a black hole – but it just didn’t work as a game mechanic. Above all, it wasn’t fun – and so it had to go. This flexibility is key to making a good game, and having a clean code base that you haven’t hacked up, with a good clear definition of which bits of the engine plug in where, you can easily make these changes along the way, even if it’s different to your original plan. However, start your game without planning, and these changes will be much more difficult and may even stop you from finishing your game!

Over to you!

I’d love to hear of your own game planning and development experiences. I’m by no means an expert in the field yet and would love to hear tips and tricks from you or any improvements you might like to suggest to this article. I hope that you found it useful.

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.

On face value, working to ensure that the contents of your console / XNA title fit may sound like a trivial task. However, we have learnt our lesson well, and after our first project – we have come to realise that it’s something that you have to consider right from the beginning. Not everyone has a 42 inch 1080p screen like you might, and making sure your game works across all types of displays can cause a real headache if left to the last minute. 

Background Information

Before you start thinking about the title-safe area, you’ll need to know a little bit about where the problem comes from. I personally play my Xbox 360 on a 720p 32″ inch flat-panel. After writing a small XNA application, turns out we’re only actually seeing about 95% of the screen. Even on a modern TFT display, there is still some of the original picture lost – which we call overscan (some of the picture is being drawn ‘off the screen’).

People may be playing your game on one of a huge variety of screens. Before even thinking about overscan, consider the different types of screens shown below;

An overview of home TV screen resolutions

As you can see from the figure above, some gamers will be approaching your game with 2.1 million pixels on their 42″ plasma screen but others will be playing it in their bedroom on only 400 thousand pixels. Not only that, but some will have their screen in 16:9 ratio and others 4:3! All this before we even consider overscan…

If the above wasn’t enough of a headache, you also have to consider that some TVs will not display the edges of the picture. The ‘title safe’ area of a television – the area that is guaranteed to be visible, is approximately the central 85% of the screen. This means that you might (but also might not) lose a whopping 7.5% off of all sides of the picture.

The BBC advise that, in the worst case scenario on some TVs, you might lose up to 5% on the top and bottom of the screen and 10% on either side. It has been suggested that Microsoft advise that you should consider a safe area of 7.5% on each side of the screen (leaving 85% of the center of the screen as the title-safe zone). I would suggest working towards 85% of the screen as the title-safe zone.

Problem 1. Screen Resolution

You have to support all resolutions in order for your game to be accessible by everyone. Luckily, in XNA this problem can be circumvented, as the Xbox allows you to program for the 720p mode and it will automatically scale it to 1080p or SDTV for you. However, for text-heavy games, you may need to consider different interfaces for different screen sizes…

Possible Solutions

Design for 720p: The easiest, quickest and nicely satisfactory solution to the resolution problem is to design your game for 720p. As it’s the “middle” resolution, you get a fair indicator of what your game will look like across the board. Make sure that the text is bigger than you need it to be on your 720p monitor and test it on an SDTV monitor before you go to release. Your game should still look detailed on a 1080p screen and your graphics should all scale nicely (as long as none of them are too small).

Design for different resolutions: While this may generate some extra work behind the scenes, if your game heavily relies on text in the interface, or you want to make the absolute best use of the screen that the player has, then it’s a good idea to think about having 2/3 different subclasses of your “HUD” or “View Screen” classes so that you can design the output for the user.

Problem 2. Text / Icon Size

On the one hand you need to make sure that text and icons are visible on the smallest possible screen (a 14″ SDTV), especially if your 720p game is being scaled down to 480i. Alternatively, you don’t want to have text taking up a third of your 1080p screen… 

Possible Solutions

Use Icons: Icons are useful in making your game more attractive across a variety of screen sizes. If you explain what the icons mean on a ‘how to’ page with nice big chunky text for your SDTV users, then you can get away with using just fixed sized icons in your game across all screen sizes. If your icons are distinctive and clear, this means that you can get awaywith placing icons in a suitable location to make the best use of your screen on any resolution.

Let the User Decide: It might be relatively easy for you to add a ‘text size’ option to your option screen. If you allow for small, medium and large text then the user can choose the most appropriate text size for their use. If they are using a small screen, they can choose to use up more of their screen with bigger text (to make it visible), but on larger screens users might opt to have the small text – as their screens are large enough for it to still be visible.

Use Voice Acting: In many circumstances, it might be possible to backup important text items with voice acting. If you have a weapon select screen, using icons and having the name of the weapon read out will accommodate for a situation where you have made the text small. 

Problem 3. Play Area / HUD Border

You need to accommodate for screens that only show 85% of the picture. However, if you cram your interface in so that it goes around the edge of the screen with a 7.5% border on each side – you end up with a large ‘dead’ area outside of the play screen that the 80% of gamers that don’t have an overscan problem will see as ‘wasted’ space. This is possibly the hardest problem to resolve if you have left it until after development!

Possible Solutions

Minimise your HUD: This is the option that we went for with Ikaroids. By minimising the HUD so that it only consisted of 2 icons, a bar and a number, we could cram it all into one corner (which was 7.5% of the way from each edge of the screen). Gameplay still takes place underneath our HUD, so we made it low contrast and non-obtrusive.  This is a suitable solution for games that don’t need to display information.

Go ‘HUD Free’ with Popup Menus: If this option suits your game, you may want to remove the HUD altogether from your game. Additional information can be found by pressing ’start’ on a popup menu which may (or may not) pause the action when it’s present.

Add a big fat border: In some games, such as board games and the like, it’s more than possible to simply add an artistic border to the outer 8% of each edge of the screen. The border might represent celtic flourishes around your game board or other suitably present imagery. As long as none of your game elements (board or score charts) verge into these areas and your game play is simply – this is a perfectly adequate solution.

Let the user decide: If you need a detailed HUD at the edge of the screen, and you’re conscious of maximising the use of the playing field by making the HUD as slimline as possible, you might want to have a slider bar that sets the coordinates of all of your HUD elements. Quake 1 did something similar to accommodate all gamers (although, their options weren’t for overscan, just for low-pixel gamers). Having a slider bar set a value for the overscan and moving all of your HUD items in from the edge by a specific number of pixels is reasonably simple, as long as you code for it from the start.

A case study… Ikaroids

In closing, I wanted to give you an example of how we updated Ikaroids to make it fit the ‘title-safe’ area. First of all, here is an example screen shot from before we realised that we had a problem. The title-safe area is depicted in red.

An example from Ikaroids of a bad title-safe area

In the above example, you can see that many of the HUD elements are not visible on all types of screens. The score for example is so much cropped you can’t really tell what the numbers should be. In the below example, you can see that we have rectified most of these problems. The elements are all understandable even at the worst case scenario. In this example there is minor cropping, but this is the worst that it should ever be. It’s also worth noting that we had to modify the camera too, so that the edge of the map was visible. Our original camera pan only a tiny amount outside of the level (so you couldn’t ever see the edge of the level if you had large overscan). We rectified this in the most recent version.

Ikaroids with an Updated HUD to fit the title-safe area

We’d love to hear from you

I’d love to hear about how you’ve overcome these challenges in the past. If you have some natty ideas that you would like to share with the world, please feel free to leave a comment below.