Developing for the Nintendo DS is an attractive proposition for studios looking to work on relatively low-budget platforms. While the DS might not demand huge teams and colossal asset creation resources, developing for the platform requires a solid, structured approach and as much expertise as other formats. Here we’re going to share some of our DS know-how, drawn from years of working with some of the biggest publishers in the industry such as THQ, Ubisoft and Electronic Arts.

GETTING STARTED

– Assign good staff to your DS project
The DS may not be the all-singing, resource-rich monster that constitutes a modern home console, but that doesn’t mean it should be relegated to the platform your junior staff cut their teeth on. Bear in mind that handheld development is often an exercise in precise optimisation at a very low level and expert management of the resources available. Your lead coder should be as familiar with the DS and fixed-point math platforms as humanly possible, right down to being able to code for the machine in assembly if you want to get the most out of it. The DS is relatively easy to get into, but getting the most out of it does take some effort.

– Design to suit the hardware
The DS is surprisingly capable and, in some ways, supersedes the original PlayStation. However, your DS game design should consider the DS’s capabilities first and foremost. There’s no sense trying to cram a DVD-based PS2 design into the DS – instead, work out how to adapt crucial gameplay elements to the handheld’s hardware and make the most of the platform. The best DS game designs recognise this.

– Iterate quickly in the early stages
With the DS, iteration can and should be fairly rapid. Look to iterate quickly in the prototyping stage and don’t be afraid to dump features if they don’t gel early on. You should be able to make fundamental code changes and have a new build running on native hardware by the end of the day. Also, commence QA as early as possible, particularly if you’re implementing multiplayer, touchscreen control methods or novel uses of other DS features. Again, don’t be afraid to tear it up and start again if the feature isn’t working as well as you’d hoped.

ASSET GENERATION

– Utilise existing assets to save time
As is increasingly common, DS titles often have bigger brothers in development on home console hardware. Assets can often be repurposed, with some optimisation, to the DS. Good time-savers are distant LOD models, which can often be low enough in poly count to serve as main models with a bit of cleaning and re-texturing. Bitmap textures are also easily adapted, as can be most sound assets. Even animation data is reusable, though some keyframes and bones will have to be trimmed. If your design is 2D, bear in mind that you can often render out sprites and backdrops from existing 3D assets.

– Optimise intelligently from the start
This applies to pretty much all game optimisation, but optimise based on what the user will actually see and experience. For example, if you’re making a racing game, remember that the majority of the car won’t be visible, so cull polygon detail from the middle and front and focus on the visible back of the car. The same can be applied to most assets. With code optimisation concentrate on getting the core experience as smooth and solid as possible, this may mean you can’t implement all the features you’d like to, so prioritise what’s important. Somewhere near the top of the list should be a solid frame rate; your latest CPU-heavy AI trick can wait until the next version if it means jerky gameplay.

DS DESIGN CONCERNS

– Gameplay is still king, and always will be
The primary concern of any DS design should be gameplay. It should not be to make use of the complete hardware feature set, or attempting to break new ground graphically or in terms of control interface. None of it matters if the gameplay isn’t up to standard, and with the DS in particular you cannot afford to be lazy. The DS can’t rely on eye candy or sandbox open worlds to provide entertainment if the gameplay isn’t there. However, the DS can interpret the gameplay of a console game where next-gen visuals and physics are not an integral part of the experience.

– The DS is played differently
It’s easy to forget that the DS is often played in ‘dead time’ or whilst travelling, so allow for regular saving and order your gameplay into quick bursts. Aim for no more than 15 minutes of gameplay without a save opportunity. Similarly, bear in mind that the learning curve of your game should not be so steep that a player cannot be making progress in a matter of minutes. You cannot rely on users putting in the same effort they would with a console or PC game to get the most out of your DS title.

– DS features are great, but only if you use them well
Esoteric functionality may look great in a features list, but they need to be fit for purpose. Touchscreen control methods are incredibly tempting to include in DS designs, but you should be 100 per cent certain that the game concept requires it. Mixtures of traditional and touchscreen controls often don’t work, so if it’s best for gameplay, stick to one or the other.

– Use the two screens sensibly and intelligently
Twin displays offer a huge range of possibilities, but always bear in mind how the player is going to use them. The user can only actually look at one screen at a time, so minimise the need for players to switch focus from one screen to the other. Make these needs logically consistent within the game, or well signposted when necessary and never demand that the player pays attention to both screens at once. Finally, if you’re using the bottom screen as a control surface, avoid putting too much critical visual data there, where it could be hidden by thumbs, fingers or the stylus.

– Some features are more expensive than others
Some features that seem relatively simple will cause you headaches. QA for multiplayer is always time-intensive, so be aware, plan for this if you must include it and begin QA as early as possible. Online multiplayer comes with its own set design and technology implications, so don’t expect to be able to add it in towards the end of the project. It needs to be integrated from the very start.

– Don’t forget that you can design for different audiences
The DS is both gender and age group agnostic, so make the most of this freedom. Many DS players will not be familiar with existing methods of play and may be more receptive to new ideas, so experiment with game concepts that don’t adhere to traditional gaming values and
goals. However, you absolutely need to make sure that core gameplay rules are clear and easy to understand.

– Study the opposition’s failures
Given the numbers of very ‘average’ DS titles in existence, you’ll learn more by looking at what other DS games do wrong than what they do right. The key here is not to copy success, but to learn from other peoples’ past mistakes to avoid making your own. Of note here are things like control methods, save points and general interface concerns. A critical aspect to pay attention to is the first 10 minutes of play. It’s very easy to get this wrong and swamp the player with disruptive tutorials or too much story exposition.

THINGS TO LOOK OUT FOR

– Know your customer’s exact requirements
Make sure you know the exact ROM and EPROM capacities for your project before you start and agree on the feature set as early as possible. Bear in mind that your customer may have unrealistic expectations of the DS and may ask for additional content and functionality to be added at a later date, so if you can allow for contingency, do so.

– Know your TRCs!
Reference the DS’s technical requirement checklist at the design phase. There’s little worse than realising you’ve breached Nintendo’s own guidelines just before you go for submission. In-game text is one area to look out for – Nintendo have very specific guidelines for referring to DS features, so make sure any tutorials abide by the official terms.

– QA may flag bugs that are ‘features’
The DS’s quirky hardware will produce effects that, as a matter of course, appear to be bugs. Be aware of these issues and be sure to inform the QA team, be it internal or external, of anomalies that are simply artefacts of the hardware rather than coding issues.

– Test multiplayer functionality thoroughly and constantly
With any feature that uses WiFi, make sure you set up a ‘WiFi hostile’ environment for testing. This means filling the air with electromagnetic noise, so test your code in the noisiest places you can generate – even if this means bringing in hairdryers, multiple mobile devices, extra wireless networking hardware and so on. When testing online multiplayer, make sure you can connect through though at least two separate unique internet connections – don’t rely on both machines connecting to the same router or even the same Internet connection. The more robust the multiplayer code, the more focus QA can place on multiplayer content rather than flagging technical or gameplay issues. Also ensure multiplayer is tested constantly, from as early in the project as possible. Finally, bear in mind that multiplayer is the one area which can be broken by almost any other area of the game, so make sure your entire team is aware of any ‘gotchas’ and other potential pit-falls when touching any code which may be used for multiplayer.

www.exient.com

Charles Chapman and Dave Hawkins are, respectively, technical director and managing director of NDS, PSP, PS2, Wii, XBLA developer Exient. The studio has worked on a number of best-selling handheld adaptations of big franchises such as FIFA, Tiger Woods, Need For Speed and Madden.