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!

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.

Tools needed:

Photoshop

1. The Base Shape

For this example, I’m going to work with a basic sphere.  Draw a circle the basic colour of the surface you want to add detail to. In my case  I’m just going to use a simple metallic gray. Make sure your circle is on a separate layer to the background.

2. Shading the Surface

Next, using the Dodge and Burn tools, add shadow and highlight as required. I recommend setting the Exposure to 25% and the Range to Highlights, but of course this is just my preference.

3. Panel Shapes

Now create a new layer and call it something like ‘Panel Shape’. Change your foreground colour to something highly visible (red in my case) and draw a shape over the sphere. I recommend using the path tool for this. The tricky part here is getting a convincing shape, but this will of course be easier on flat surfaces. The important part is where the red area intersects the sphere itself, as this is the line we will be working with. It does not matter if the shape goes over the edge of the sphere. Then, fill the path with your chosen colour.

4. The Magic

Now, turn off the Panel Shape layer’s visibility, so that you can just see the sphere. Then, CTRL+click on the thumbnail image  in the Layers palette, so that you get a selection the shape of the Panel Shape.

Next, go to Select > Modify > Expand, and select 2 pixels. Higher numbers will yield deeper grooves. Once you have expanded the selection, CTRL+ALT+Click on the thumbnail image  of the Panel Shape in the Layers palette, which subtracts the shape of the shape from the current selection. This will give you a thin outline selection.

Then, select the Burn tool and set the Exposure to 100%. Then, on the Sphere layer, shade the parts of the selection area that are facing away from the light source, and 100% Dodge on those that are.

5. The Clever Part

CTRL+Click again to select the shape of the Panel Shape, as before. Only this time, we’re going to contract the selection. Select > Modify > Contract, by 2 pixels again. Then, invert the selection (CTRL+Shift+I). Next, CTRL+Shift+ALT+Click on the thumbnail of the Panel Shape in the Layers palette. This will give another thin selection, only this time inside the previous shading area.

Now, use the 100% Dodge and Burn again, making sure that the shading is reversed from before, i.e. dark areas touching light areas, and vice versa. It will take a little practice!

6. Repeat!

Repeat the process as much as required to produce an assortment of panels and effects. I used this extensively on many of my sprites, for example, this guy:

I hope you find this useful in making your own sprites!

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.

Tools used:

• Pencil/paper
• Scanner
• Adobe Photoshop (or similar graphics program)

1. Drawing the design

First of all, I sketched the design of the sprite in it’s entirety, making sure to pick a ‘neutral’ pose and position, picturing how I wanted it to be presented on-screen. Therefore I chose the standard ‘head-on’ view as this would be what the player would be seeing, but needs may vary for different sprites and games, so this is the time to visualise what the sprite is going to look like and what it is going do.

2. Scanning the drawing

Once I had a fairly defined sketch of the sprite, I scanned it at 300dpi. It doesn’t need to be a highly defined drawing, as all we are going to do with it is draw over it in Photoshop or another graphics program.

At this stage I also found it helpful to have an image of the background that the sprite is going to appear on in-game behind the pencil sketch as another layer, in order to get a better feel for the colours to use. I set a space background as the background layer, then brought in my scanned pencil sketch as new layer, setting the layer type to Multiply for the background to show through.

If your background is dark, obviously the pencil sketch will not show up too well, as I found out rather quickly! To solve this problem, I removed the white from the image, only leaving my lines. This was done with Mac’s Remove White Filter, available from here: http://morepunkinstuff.tripod.com/filters/Mac/mac.html. I then inverted the colours of the sketch (Image > Adjustments > Invert), which left me with just the lines of my sketch in a nice chalky white that showed up perfectly on the black void of space.

3. Basic Shapes

From here I could draw the shapes that I needed, copying, pasting and mirroring wherever necessary. I used different layers for everything, which made it easy to reposition if I had to. I had to consider which parts were going to move, in this case the eyes and arms, so that these pieces could be constructed separately.

4. Shading and extra colour

This was the fun part! To darken the shadowy parts, I used the Burn tool, set to 25% Exposure and 0% Hardness, and Range using Highlights, using varying brush sizes as necessary to give a soft gradient to the shading. Since each piece was on a separate layer, I didn’t have to worry about going over any lines, as the Burn tool only darkens what is already there.

After that, the highlights were achieved by using the Dodge tool on the same settings, making them slightly sharper to give a glistening look.

The eyes were constructed using three layers each – the eyeball, the iris and pupil, and then shadows and highlight applied to each piece individually.

5. Saving

Of course, I was saving all the time! But the final file format cannot be a psd. As long as you have kept well organised with regard to layers and groups, you should have no problem here. I took each separate piece, copied it to preserve the original, and merged it before copying it to a new image with a transparent background. I then expanded the canvas so that the dimensions of the image were multiples of four to make it suitable for a game sprite. I repeated this process for the other pieces.

All in all, this guy took something in the region of 5 hours to complete. He’s one of my favourite sprites so far.