Defect Demo is now on Steam!

We’ve had a bit of a brainwave. Instead of posting videos explaining how Defect works, we could just GIVE YOU THE GAME and let you see for yourself. Just head to our page on Steam to download the demo. It’s for PC/Mac and it’s available right now!

The demo is a very early preview of 7 of the game’s opening missions, and we’ve modified it so you can unlock nearly all the standard class ship components (those are the smallest ones). By Mission 7 you should be able to play around with building any kind of fighter scale ship that you’ve ever wanted!


There’s a short tutorial to get you on your feet, but we haven’t taught you everything. If you have any questions or problems, let us know. Head to the Kickstarter page and tell us what you want added and what sort of ships you want to build. Share the demo around and help us recruit new mutineers for the Suppressed Systems Navy!

Kickstarter Update: Shipyard Walkthrough and New Components

We're a week and a half into the Kickstarter campaign, so here's a catchup on what's happened so far.

Shipyard Video

For our first major Kickstarter update, Drew, our artist and designer, created a Shipyard Walkthrough video. It gives you some idea of how to build a ship, and some tips and tricks for getting the most out of your design.

New Components

As the game develops we keep on discovering new ships that we want to make, and new ways to really focus your ship design. These are just a small number of the ideas we have to choose from for upcoming pieces.

We want to get feedback from you about what kind of ship components you’d want too. You’ll be able to get your hands on all the concept art, final art, and descriptions of the stats and abilities of each component in the exclusive Kickstarter backer art manual.

Defect in the Wild

We’ve sent an early preview build of Defect with a few missions out to press, YouTubers and streamers, and it’s starting to get some coverage!

Northernlion gets it!

Deluks Gaming has an awesome animated intro!

Drew was on the Space Game Junkie podcast!

T-Shirt Design

We’ve been messing around with the design for the backer t-shirt for a while and have the following two options. Seems like the one with the logo is more popular.

Head over to the Kickstarter page to checkout this and the other cool rewards!

The Music System - 15 Years in the Making: Part 3

by Stephan Schutze

Part 1

Part 2

 

When things go wrong

Most of us have a strong preference for talking about our successes and accompl­­ishments.

We hope that everything we work on will be awesome and trouble free; but the reality is most of us learn infinitely more from our failures than from success. There is a reason why people speak of the benefits of working outside of your comfort zone. I also believe we need to be comfortable enough to be able to admit our limitations and admit we do not always know the solution to every problem.

Defect, like many projects has had its own share of challenges. Some stemmed from lack of knowledge or experience as I had never attempted a project design like this, while others were hard limitations of the hardware and software involved in production. I even caused some of the issues myself.

In sharing with you the experience of designing the sound and music for Defect, I feel it is important to share these challenges and how they were overcome, or not, as a critical aspect of the development journey. It would be misrepresenting the process to pretend there were no problems to overcome, particularly with such a unique approach to the design.

 

Too big for my boots

The first real issue should not have come as a surprise for me, but the final solution was not something I expected.

The music system for Defect has a lot going on. The number of Reference Events has grown to a significant number and the "depth" of nesting I am using is also more than I had originally planned. My system was designed to utilise individual sounds files essentially as samples and build up the musical score using FMOD Studio as a real time sampler of sorts. In general this works, and the system did indeed assemble musical themes and layer them to create the overall score during gameplay. The hurdle we needed to deal with was the cost.

For most of my career as a game audio professional I have encountered one major technical requirement of all the work I have produced common across every platform; "Use the least amount of memory possible." Efficient design, streaming and audio compression have always been my go-to tools to deal with this requirement. Defect is the first project I have worked on where I have broken that rule.

When we were first able to test-run the system within the game, it did indeed work and the memory usage was actually quite good for what was going on, but the CPU usage was off the scale for what was reasonable for audio. When fully operational, the system was consuming 20-30% total CPU time. This was affecting the overall performance of the game and was never going to be an acceptable situation.

Our tools allowed us to monitor these levels even at early stages of production, which was extremely helpful as a problem diagnosed early has a better chance of being resolved. I spoke with the team at FMOD to get a better idea of which processes would consume significant CPU cycles. I needed to understand what it was I was doing that was causing the problems and hope that it would not be a core aspect of my design. Through all the stages leading up to this issue I knew optimisation would be required, but it had never occurred to me that the fundamental design might not be possible due to software and processing limitations.

After running some tests on our project, the FMOD team reported back a variety of things that were contributing to the high CPU drain. The fact that it was multiple causes allowed more flexibility in finding a solution, but the overall trend pointed to one thing; my workflow methods designed to maximise memory usage were a central part of the problem.

Usually when I add any sound file to a project, I do so with the knowledge that it increases the efficiency of that sound file if I use it in multiple sound events across a project. A sound file that uses memory just by being loaded into the game becomes far more valuable if it is used as part of twenty sound events rather than only one. This is not to say that you can never have unique sound files, often this is the only way to get the best results, but it does expand the overall resource efficiency of memory to get multiple uses from your sound files.

To this end I tend to experiment with extremes of the processes I apply to my sound files. Pitch alteration is one of the most effective ways of extending the usefulness of a sound file. A sound used as a high, sustained looping note can work extremely well pitched down 2 or 3 octaves and used as a low bass drone. What I discovered working on Defect was that the more extreme the pitch shifting in real time, the more expensive the CPU cost becomes. My usual habit of using sound files in multiple locations pitched up or down several octaves was quickly becoming an expensive choice for the CPU.

Another drain on the CPU was compression. I had used ogg vorbis compression on the sound files as it provided the most extreme level of file compression while retaining audio quality. This was ideal for a game that was planned for deployment on tablets and mobile devices. Except again, uncompressing sound files required CPU time, and the complexity of my project meant that a very large number of sound files needed to be uncompressed regularly to allow the system to work. The result was a significant spike in CPU use.

I was very surprised to hear words from our lead programmer that I never thought I would hear as a game audio developer, and especially not for a mobile platform title, "Don't use audio compression for the music. Leave the audio files as standard PCM sound files." At some stage, (and I missed exactly when this happened), the world reached a point where our network speeds and storage capacity on our devices achieved a level where it has become more desirable, at least for this project, to use more memory as a trade-off to reduce CPU usage. This was a somewhat disconcerting position to find myself in, but it was very good to have such a simple solution to part of the issue. It would not solve the entire problem, but it went a long way to helping.

 

What you don't know

Other causes of the high CPU usage were also related to my ignorance of the tool I was working with. For all the time I have spent working with FMOD Studio, developing the training for it and even writing and updating the user manual, there is no way I could know every aspect of its functionality. I doubt any one person does. This highlights one of the benefits of a project this ambitious. It pushes me well outside the comfortable zone of working within my existing knowledge and capabilities and forces me to develop and learn.

I learnt from the team at FMOD that for mobile devices such as iOS and Android the default sample rate for sound files was 24KHz. While this might seem trivial it was actually very significant for Defect. Regardless of what sample rate I set for the sound files I was using, FMOD would streamline the process at build time by resampling everything into the required rate of 24KHz. I had to ensure my banks were set to build 24KHz sound. The simple act of going through all my sound file assets and setting them to 24KHz and replacing them in the project meant that I could set the sample rate and audition the sounds in my workflow prior to adding them. This allowed me to maintain quality while preserving efficiency in the project.

I had approached the entire project with the idea of efficient CPU usage in mind. My overall plan was to limit CPU costs by mapping out efficient routing in the Mixer. This would avoid using too many individual effects thus reducing the overall cost of DSP objects within the game. This remains a valid approach, but in the case of Defect, I found that there were many other factors affecting CPU before I even got close to worrying about the DSP cost.

 

Being a bit too clever for my own good

One of the musical layers in Defect is the sound each of the ship energy core components produces. This was originally a low frequency drone. From a musical point of view I found I had too much low frequency content when this combined with percussion instruments and moving bass lines, resulting in the music becoming muddy. So I decided to use a high frequency drone instead. Kind of like a sustained string note hovering above all the other music. It was amazing how much this lightened and cleaned up the musical content.

As I described earlier, I had been using pitch shifting of some middle range notes to create the low drones to improve memory usage. When I switched them to high frequency, I just reversed the pitch shifting. In both cases I was shifting to extremes, which was not great for CPU, but more than that, I was being a bit of a smart-arse in how I created these drones.

I discovered a method many years back of creating looping effects that were not plain looping files. I have used this technique for environmental loops such as the sound of wind, or for a river or other variable loops. This technique uses the Scatter Sound module functions within FMOD Studio to "dovetail" sounds together. Essentially it plays a sustained sound file such as a river flowing, but before that sound file finishes, it fades in another sound file, then the original fades out, so they essentially crossfade in real time. Applying some other processing to the workflow allows for a more organic ongoing audio event instead of a simple, noticeable loop. It has been a very effective and quite efficient method of creating environmental sounds that I have used for numerous projects.

When it came to the core drone layers, I decided I could use this method for the musical layers. Utilising quite short sustained notes and dovetailing them together produced a good effect. I could even create two of the same module on different tracks and then pan them left and right to create a more open stereo result. The thing about all of this was that it was pointless and self-indulgent. I was being overly clever and applying a complex solution to a simple problem.

I wanted the core component layers, to be a simple high pitched sustained note. A subtle layer mixed in with the other musical layers. I didn’t need a fancy solution here; I needed a short, clean loop of a sound that had the right musical qualities to it. When I replaced all of the core sounds from being complex multi layered real-time sound objects, to simple, short mono loops, it was yet another step that reduced the CPU cost of the overall project.

This last point was a critical part of how I was thinking about this project. Certainly there are many aspects of this project that are complex, bleeding edge and even pretty clever. But those descriptions should not have to apply to every single aspect of the design and in fact should probably NEVER apply to every aspect of the design. It’s a little like creating some new complex and expensive technology to allow you to switch on a light. Most of us are perfectly capable of standing up and hitting a switch. Often the simplest solutions are the best ones.

I am glad we had the issues that we did early on as it helped demonstrate to me that I was being a bit of a smart-arse by trying to over-engineer every aspect of the game just to show that I could. Realising this while I still had time to strip back a few things was good for both this and any future projects I work on.

Each Component comprises of 2 to 4 themes as a progression

Each Component comprises of 2 to 4 themes as a progression

The fearless explorer

So far, working on an ambitious audio design like Defect has exposed a potential weakness in the approach of using processes that have never been fully explored. The very nature of doing something that has never been done before means that you are likely to encounter problems, often lots of problems. Experience, our own or drawn from others, essentially boils down to a list of things we should avoid doing. If I have more experience than you, it generally means I have screwed up more often than you have. So forging new ground by its very nature means exposing yourself to lots of screw-ups and often that means big screw-ups.

The risk of "issues" is part of the very nature of trying something new. It is critical to be open to all ideas, no matter how outlandish they may seem at first. The benefit of experience and skill comes in the ability to quickly recognise if your approach is a benefit or a hazard. So do not be afraid to try new things, even if they may seem of dubious value. Equally, do not be afraid to reevaluate or entirely abandon things if they are not working as they need to. I think the most important part of being a fearless explorer is being fearless enough to admit to yourself and others; "That was a terrible idea, let’s drop it and try something else."

 

Content; good or bad

One of the biggest challenges for any creative person is to be able to sit back and look or listen and ask themselves "is this actually any good?" We need to be our own best and worst critics, but we also need to be realistic about what it is we are creating.

In a previous blog post I referred to my process as "building music" and I think this is still an accurate description. I am under no illusions that the music for Defect is going to be considered as great art, and from a musical point of view much of it is quite simplistic in its nature. Does it work? For the most part, yes. The process of selecting from nearly 200 musical motifs and layering them up to create themes for the spaceships does usually create an effective and interesting musical backdrop for the game experience.

I have encountered an issue around balance between the various parts. Sometimes the music feels like it lacks energy and at other times it feels as if the layers are fighting with each other. This is a very difficult thing to balance. The very nature of games and how they work means balancing just the volume levels of the many aspects within a game is challenging. In the case of Defect, I have had to create musical motifs in isolation and hope that they will blend together during gameplay.

Initially, I found that less was more. My original percussion patterns were way too complex when combined with the other layers. My harmonies did not need to be as deep or change as often as I originally planned. But at all times the term "building" was a more appropriate label than composing for the music I was creating.

I do have slight concerns that I may have created music that is somehow less than it could have been if I had adopted more traditional methods of scoring for this project. However, the very methodology I have adopted allows me to tweak individual notes, individual instrument sounds and essentially not just balance the volume levels in real time, but actually balance the musical content as well. This is an ongoing process and perhaps my original design will allow me to craft the music into something where the musicality of the score matches its technical flexibility.

Themes are often created from multiple single notes

Themes are often created from multiple single notes

Out of our control

Working with computers is very much a mixed blessing. On the one hand we have the ability to rapidly develop prototypes, evolve ideas and complete projects so much faster than we ever could before. On the other hand, we need to deal with software development and all that it entails.

Software development is hard. I know many programmers and I have always considered what they do to be one of the dark arts, akin to voodoo. I don’t understand it most of the time. As a user, I need to make the most of the software tools I have available, however often that means bugs, glitches and crashes.

Creative work is hard, you have to get your mind in the right space to be able to focus your energy on developing ideas and then implementing those ideas into a project. This is often a fine balance between letting the creative mind wander, and tightly controlling the logical mind to allow the ideas to be formed into products. Software often gets in the way.

As much as workflow can shift and change, nothing breaks the creative process more than your software collapsing. I would like to offer a general comment to developers, made with the utmost respect. When your software crashes while I am in the middle of focusing on creation, NO, no I do not want to submit a bug report and spend chunks of my time helping you fix the product I have paid to use.

Whichever tool it is, Unity, UE4, FMOD, Wwise, ProTools, Nuendo, software crashes and bugs are possibly one of the greatest causes of stress and rage in our industry. I understand that reporting bugs may assist in improving those products, but I just want to use my tools to produce my work, and things outside my control breaking just makes me grumpy.

 

Guidance

I think this chapter of my account on working on Defect is as much for my benefit as for anyone else’s. The act of debriefing; arranging my thoughts and notating the issues I have had so far has helped to place things into perspective. It is important to have a record of events, both good and bad, but more than that we often do not fully understand something until we take the time to explain it to someone else.

Working as part of a team provides the support of outside ideas, solutions and perspectives, but when you are the entire audio team you can lose sight of important elements within your own thoughts. Obviously I would hope that some of this information may help others to avoid similar issues, but just as importantly this journal of events throughout the development of Defect is a good way to ensure my own approach sounds sane when I read it back to myself.

This has been, and still is an extremely satisfying project to work on and I am starting to think that I am actually more comfortable working outside my comfort zone. I am not sure what kind of paradox that is likely to create, but I am sure it will be interesting.

Source: Gamasutra

Kickstarter Launched!

Exciting news! Our Kickstarter campaign is now live! Now we need your help to ensure it is a success and therefore Defect becomes the best game it can be. Please back the project, even if you can only spare a few dollars. It's important that the project hits the ground running, as people who don't know us or the project are more likely to back it if it has made a good start. We also need your help to spread the word! We'd really appreciate it if you told your friends, posted on Facebook, tweeted, emailed your entire address book, phoned elderly relatives, hired a sky writer for your local neighbourhood, etc, etc. Every little bit helps.

Please head over to Kickstarter now to check out all the cool rewards and show your support!

Production Update and Kickstarter is Coming!

This milestone was all about polishing gameplay and the first levels, and preparing for the Kickstarter! There’s just over a week to go, so we’re putting the final touches on the Kickstarter video, rewards, stretch goals, text and images. Drew has spent a lot of time creating a new Defect poster, which will be used in many forms over the coming months. He’s already ordered a test t-shirt...

DefectPoster38.jpg

Lots of small improvements have been made to the controls and the UI. The primary control method for the ship thrust/direction is now keyboard and for the turrets, mouse. This means you can now aim a turret and fly your ship at the same time.

We’ve changed the way the Core damage system works so if the ship pieces above the core are destroyed, the Core is now open to attack.

CoreExposed1.jpg

Changing what ship piece you were in Direct Control of was proving to be fiddly. We had it set up so that you had to zoom all the way in to activate the Direct Control menu. It’s now been changed so that you can toggle the Direct Control menu on/off at any time. This allows you to repair parts of your ship while keeping an eye on the battle.

Repairing now uses the scrap you have collected from destroyed ships. Your ship becomes less controllable when your Crew components are destroyed. Enemies now repair their own engines, so they aren’t sitting ducks for long! 

All in all it's been a busy few weeks, and we can't wait for the Kickstarter to get kickstarted!

The Music System - 15 years in the making: Part 2

by Stephan Schutze

In Part One of the story of creating a dynamic and generative audio system, I introduced the general concept of developing a unique music system that allows me to create interactive, dynamic and generative music for Defect: Spaceship Destruction Kit (SDK). 

In SDK you build spaceships out of different parts and send them out to fight. After each victory, your beloved crew mutinies and steals your ship. You then need to go back and build a new ship, which you can defeat your old ship in. It’s an innovative game that tests your ability to create almost any spaceship you can imagine and then to defeat your own creations.

As each ship is built from components, so too is the music. There are currently close to 200 components in the game and each component has its own musical motif.

I believe the music system I am using in SDK can be applied to multiple different game styles, in fact, I’m already drawing on what I’ve created for my next game. In this second part, I will go into the fine detail of how the music system works in SDK.

At the time of writing, SDK is still in production, and therefore so too is the sound and music, however the system is currently functioning quite effectively.

A second of Smugness

One of the primary goals in creating this music system was to give me more control and also to have something that was incredibly ambitious without requiring ridiculous amounts of programmer time (and as a result money). The entire system as it now stands and works is all driven from a single FMOD Studio Sound Event and 6 parameters. It took our programmer less than two hours to get the entire thing up and running and will only require very small amounts of additional time to hook up additional parameters. THIS is the other aspect of our modern tools that people seem to have missed. A carefully planned and designed project in a quality audio middleware tool can have fantastic levels of complexity and not require hours, days or even weeks of programmer time to implement.

I built this project not only to minimize programmer time, but also to build something that could serve as a template for future projects. This system could easily be used to control pre-recorded musical elements (like a full orchestra), other sample based scores or any combination in between. Even at this stage I am fairly proud of what has been achieved.

I have already discovered that the layering of the instrumental layers and the style of the game means my individual motifs can be much simpler than I originally thought necessary. I “composed” various drum and bass and melodic patterns, but once they were in game I discovered that less notes was indeed, often more effective. Now I can instantly test each new pattern to make sure.

Game Elements

Now let’s take a look at the details of how the music is actually assembled within the game. Ships are built by the player in the Shipyard. Each ship can be built from a selection of component types.

I did not want to allocate musical reference for weapons or misc components, and a core is a compulsory component, so the music is divided into instrumental layers depending on the component types.

 

Then there were the aesthetic groups for components. I allocated instrumental group types to correspond suitably to the look of the components being used.

Looks b.png

So the component type defines the instrumental roll and its aesthetic design defines the instrument group type.

The game itself has multiple game states; each one of these is defined within the FMOD Studio project as a parameter value that can be used to change what the music is doing at any time.

The entire system across all levels is quantized so that layers stacked vertically and motifs placed horizontally will force transitions to always occur musically. Currently I have a single theme for Warp, Pre and Post Combat. So the unique themes for ships play in the shipyard and in combat. Scripted events can have flags placed anywhere I may need them so I can control the music in a scripted event to provide a cinematic result tracking time, start and end of specific events and actions and a range of other parameters.

When you develop a new approach to something, generally the process falls into a series of stages. This is both a natural part of trial and error, as well as a way to approach the task while minimising redundancy.

Stage One: Planning/R&D

Before I even wrote a note of music, or even considered what instruments I wanted to use, I needed to design a system. I needed a system that would allow me the level of control of the music in the game that I had always wanted. Working on the system, I spent a few months scribbling diagrams on pieces of paper, making rough flow charts of how elements would interact and communicate with other elements. I built simple events within FMOD Studio using just sine wave sounds to test the control. Could I actually achieve the results I needed? I spoke with other audio folk within the industry to get an idea of some of the control systems they had used in games to trigger audio events and if they found one system better than another.

In many ways the biggest problem I had to deal with here was that “I didn’t know what I didn’t know.” It is very difficult to find the answer to a question when you are not even sure what question you should be asking. Creating these test events allowed me to experiment, break things, fail at things and learn slowly exactly what questions I needed to be asking myself. 

I think this is the first real benefit to the current generation of audio tools that we sometimes miss. Busy schedules and complex projects often do not allow us the time to sit down and try out new ideas and expand upon our skills. When you are pressed for time, it’s only natural to fall back on the skill sets we know and are comfortable with. By trying outrageous ideas directly within the audio tool, I was able to expand my understanding of just exactly what was possible.

Stage Two: Control down to the smallest level

In my years as a sound designer, I have always used a variety of control properties to provide greater variation of sounds in game projects. So the sound of a shotgun could be improved by providing a selection of shotgun sound files for random selection, then adding some pitch and volume randomisation to improve on the effect.  I had considered applying this to musical content, but pitch shifting would unmusically affect tonal sounds, and volume randomisation would interfere with precise control of dynamics. 

I started to play with EQ balancing using a simple 3-band equalizer module to add variety to a sound. So a single violin marcato note could be varied using multiple sound files; but it could have further variation applied by randomizing the exact values of the High, Mid and Low frequencies. Like any sound, the effective range of randomization depends on the sound itself, but I found I was able to achieve a good range of variation using these properties and keep the musicality of the sounds.

Stage Three: A fortuitous accident

In a situation that would have made Howard Florey proud, one of the most significant discoveries I made when experimenting with these ideas was mostly by accident. While testing some drum impact sounds to see what level of variation I could achieve using the 3 -band EQ module I stumbled upon an aspect of control that I had not expected to be possible. I was using a sound file of a single drum strike played at a Fortissimo level. The sound was suitably loud and sharp for a heavy drum impact. While tweaking EQ values however I started to notice that the drum sounded more subdued; not just quieter, but actually as if it had been hit with less force. I continued to work with just this one sound and after several days of tweaking various values, I managed to achieve something that would significantly impact the project I was building. 

Using sound files at the highest velocity produced by an instrument and then applying a range of property alterations I was able to produce very convincing results of that instrument note played through the entire dynamic range. So my FF drum strike sound file could be tuned to provide drum strikes at FF, F, MF, MP and P. The significance of this from a memory usage point of view was massive and it opened up many possibilities for the project that I had not previous dreamed of.

Stage Four: Building Music

The term “Building” is not one often associated with the idea of creating or composing music, but at this stage of the project, building was exactly what I was doing. I needed to further develop the system of how I would create the music for this project. Being able to tune the dynamic range of notes meant that I could create my music right down to individual notes. 

So I started to use FMOD Studio essentially as a piano roll sequencer. I used recordings of single notes as my samples, and placed them on the audio tracks aligned to beats and bars exactly as I would in a simple notation program. I was using Studio in a way that no game audio tool had really been designed to operate. At this stage I was still working on proving if this method was valid. I needed to work with the functions available, not all the functions I would have liked to have.

I built musical motifs, and layered different instruments together to create simple themes. The tool’s regular functions allowed me to apply effects where needed or automation of properties if I desired, but essentially I was making a template that I would later use to be able to compose music for the project. I quickly learned that some instrument sounds worked better than others and discovered what extremes of range I could utilize and still maintain a true representation of each instrument.

Stage Five: The Real Design

Eventually, I had enough information to decide on a design for the game itself. As always, the system I had created had limitations. Using samples in FMOD Studio meant I had to build up the sounds I wanted to use. Because of the differences in how much pitch shifting I could use with different instruments I found I needed to work out a set of sounds that would work well in the system. When it came to actually writing the music I would compose using these instruments.

Interestingly I had a several audio folk ask me about these limitations. The question was always “But why do you want to limit yourself like that? A true composer should write the music they need or feel and not be limited because of samples.” I found this amusing as we ALL are limited as composers ALL the time. There are very few of us that can go out and write for a 150 piece orchestra. Actually there are probably very few of us that could go out and write for a 50 piece orchestra for every project. Time, budget and availability are always limitations for game composers, so sadly I am not likely to have a 100 piece bagpipe ensemble with 400 Tibetan horns for my main theme, fun though it would be. I don’t really consider limitations of working in this system any greater to other limitations. I work with what I have available.

               Limited to using a 60 piece orchestra for Jurassic Park Operation Genesis

               Limited to using a 60 piece orchestra for Jurassic Park Operation Genesis

The Magic Event

One of the other functions that the current series of game audio tools provides is the ability to “nest” an event inside another event. FMOD Studio lets you create an event within another event like this, and it also allows for Events within the main Event browser hierarchy to be dragged into another event to create a parent/child relationship. When you do this, the child is actually a reference event. Any changes to the original reference event in the browser are instantly applied to all instance reference events. You can still make some unique changes to each individual instance object that do not affect other reference events.

I initially suspected that using reference events would be useful for my music system, as I wanted to create multiple layers, but it was not until I started to work with them directly that I understood just how powerful this functionality would be. 

To demonstrate this I will explain how “deep” I went with creating my layers. My project was designed so that at the top level, the Music event would define each of the game states, and then at each level downwards there would be further definitions to control the playback.

The current project looks a bit like this:

Layout.png

At each level a relevant Parameter defines exactly which sound files are triggered and the overall selections combine to produce the piece of music required at that stage of the game. Of the eight levels of nesting displayed, here most of them simply define exactly which elements are triggered. The Hull layer combines with five other layers to create the overall theme at any point in time. 

At each level a relevant Parameter defines exactly which sound files are triggered and the overall selections combine to produce the piece of music required at that stage of the game. Of the eight levels of nesting displayed, here most of them simply define exactly which elements are triggered. The Hull layer combines with five other layers to create the overall theme at any point in time. Although it is a complex control system, the actual number of sounds being played at any one time is not all that many, so channel allocation on a mobile device has not been a problem.

The benefit of reference events is that if I decided to change the sound file right at the bottom of that 8-level nested hierarchy, any change made to the main Event will instantly propagate across the entire project. This means I can simply swap out a sound file in an event from Taiko to Tabla and instantly audition every rhythmic pattern, motif, theme and musical piece that previously used Taiko and listen to them with a different instrument sound. This is immensely powerful, efficient and I am now starting to think that reference events should become the standard of EVERY audio event used within a game project. They increase the ability of the audio team to significantly edit and alter projects with the minimum of fuss. I will be continuing to assess this idea for future projects, but so far I have found them incredibly useful.

Next Stages

I am still developing both this system and the actual audio for the project itself, and I think there is still a lot to be done. The nested nature of the project means that I cannot utilize FMOD Studio’s mixer in the usual way. Although each reference event does exist as an input bus in the Mixer, when the main Music event is triggered it triggers the nested instances of each reference event, so their main input buses will never activate. Thankfully, I have discovered that I can place a Send in each of the nested instances and create a corresponding Return Track in the Mixer, so I will be able to create individual inputs for all 200 components and assign them to group buses for DSP effect efficiency as well as utilising snapshots and sidechains to provide even greater control of the many layers. The obvious one is to channel-duck certain layers when new layers come in, so the victory and defeat layers could reduce the volumes of existing layers automatically.

This trailer uses music from the game.

At all times I will need to be aware of resource usage on the target platforms, but in all honesty this game at a pre-alpha stage is more complete than some projects I have worked on when they were shipped. This is the advantage of using engines such as Unity or UE4 (this game uses Unity) and sound engines such as FMOD, Wwise or Fabric. The game can be running and functioning at a far earlier stage of development which makes everyone’s job easier and saves time and money.

Trouble Ahead

This two part series is going to be extended as new issues arise and the project needs to be adapted for various reasons. I think this entire process is worth documenting and as a few problems have come up it is important to write about the bad as well as the good. Stay tuned for more updates us the project continues to develop.

Part 3

The Music System - 15 years in the making: Part 1

Dynamic music creation and implementation for Defect: Spaceship Destruction Kit

by Stephan Schutze

Introduction

Every so often you are offered the opportunity to work on a project that allows you to push yourself and the tools you use far beyond common expectations. For me, this came in the form of the sound and music for Defect: Spaceship Destruction Kit (SDK).

In SDK you build spaceships out of different parts and take them out to fight. After each victory, your beloved crew mutinies and steals your ship, making you go back and build a new ship, in which you can defeat your old ship. It’s an innovative game that tests your ability to create almost any spaceship you can imagine and defeat your own creations.

For a long time, I’ve been experimenting with and exploring the possibilities of generative audio, the process of creating sound effects and music in real time, with no repetition. It’s a fascinating area and only recently has the software and technology of games evolved enough to start doing what I’d always dreamed of.

In SDK, this ship-building approach has given me the opportunity to implement aspects of generative music, layered implementation and dynamic cuing to control the music within the game. The further I explored this process for SDK, the more I found myself inventing a whole sound system that was flexible, resource-efficient and dynamic.

Beyond SDK, I found the system I created can apply to many different kinds of games. Using generative or dynamic music can provide effective control over the sound and music in a game.

In the past, I have encountered people whose reaction to the idea of generative and dynamic music is along the lines of, “But we want a fully orchestral score!” The great thing is; these are NOT mutually exclusive approaches. An orchestral score can work beautifully for the grand cinematic scenes, or to introduce giant boss monsters and interesting characters, but for the hours on end that a player may be wandering the open world, a generative score can provide unique musical accompaniment. This can adapt dynamically on a beat, introduce layers to build tension or indicate significant actions and then dynamically blend into a more traditionally composed piece performed by a full orchestra.

The other benefit of this approach is the efficient use of resources, something that even large projects can benefit from.  Music that can be created to play in real time from a small handful of sound files can be useful in games when levels or areas are loading to minimize loading bandwidth. This kind of music also works well to create efficient transitions or simply to maximise resources at certain stages of game play.

15 years in the making?

Essentially, this music system took 15 years to design and produce. I am only halfway joking when I say this. My very first game project, Starship Troopers Terran Ascendency on PC, started nearly 15 years ago. Back then, my role was to produce audio assets, both sound and music, render them out in the requested format and then pass them on to a programmer for implementation. The next step generally involved a level of hoping and praying. Essentially, the success or failure of the audio, from an implementation point of view, depended far too much on the project schedule and current level of interest in audio of the programmer assigned to sound and music.

Even back then, I was sure that there must be a better way to handle this process. I wanted to have more control over the audio I was creating. I also realised that the process was inefficient, prone to communication issues between audio folk and coders, and risky from the point of view of introducing bugs into a project. I knew what I wanted to do, I knew the possibilities that computers provided us creatively, but I had no idea how I could ever convince someone to provide me with the tools that I needed.

Luckily for me and other audio teams, we have since been provided with a range of audio tools that greatly improve the workflow and control compared to what we had 15 years ago. CRI, Fabric, FMOD, Wwise and other middleware audio solutions have dramatically improved the way we both create and implement sound in games. Having worked with these tools extensively, I know that I, and I am sure many others, would struggle to cope without them.

These tools have all gone through generational changes and have evolved over time, and those of us working in game audio have developed our processes along the way. What’s great about the development of these tools is the extremely receptive nature of their developers. They want to hear from their users and they work very hard to provide us with the tools that we need. To be perfectly honest, I think they have actually left some of us a little behind. The current capabilities of tools such as Wwise and FMOD are actually pretty staggering, and I think many of us are not yet utilizing their full potential.

I have an excellent relationship with the teams that produce both Wwise and FMOD, however my familiarity with FMOD Studio is currently greater than that of Wwise, so it was with FMOD Studio that I decided to attempt to create the project I had always wanted to build.

15 years in the dreaming and thinking, I was lucky to be given the opportunity to work on a fantastic game concept like SDK. The support of the development team and their openness to new ideas is what has allowed me to make an ambitious attempt at something new. My goal was more than just to create a dynamic music score for the game, it was to be able to compose the music directly into the tool in a way that would let me quickly and easily test each musical layer or cue for its suitability and effectiveness.

How it works

The music system is designed to highlight and support the game design, so I will be explaining the concept of the game as much as how the music works. As I explained earlier, SDK involves designing and constructing spaceships for both a single player campaign as well as multi-player combat. The player is provided with a range of components to select from; these components provide various functions for the ship but are also designed to allow the creation of a wide range of aesthetic finishes. So the look of a player’s ship is likely to be as important to many players as its combat ability.

As each ship is built from components, so too is the music. There are currently close to 200 components in the game and each component has its own musical motif. More than that, it has its own musical motif for when the player is in the shipyard, a different one for combat and may ultimately have a different motif for each game state. The challenge here is to allow the various layers of motifs to stack together and produce unique themes for each ship a player creates while maintaining musicality, sounding suitable for the game state and aesthetic design and blending a variety of different instruments successfully.

Once combat starts the game also tracks both player and enemy hit-points and introduces more layers to support the player’s move toward victory or defeat or even a blend of both states. The music system uses this data to add an additional dynamic layer to the sound and music.

I am fully aware that there is a very real danger of this system collapsing under its own ambition, and my goal is not to simply create a smug demonstration of just how many elements I can cram into the sound design just simply for the sake of it. In designing this music system, I have very deliberately aimed extremely high in my expectations. We have the technology and tools to be doing so much more than we have so far been with game audio. Even if I fall short of the mark, I think the effort will be worth it. Even if this particular project does not 100% achieve the dynamic, generative, blended awesomeness I am aiming for, my hope is that others can pick up and continue to move us forward.

Currently the system works. The various game states transition seamlessly, the ships each have a unique theme in the Shipyard and in Combat and I have two general combat victory pieces that blend in bit by bit as the enemy takes damage. What makes the creative process so interesting is that I am effectively composing directly into the game. The ability to add or edit a component theme, hit export in FMOD and then import in Unity and run the game is as close as I have ever been to in-game composition. The turnaround time to audition content in the game is only a few seconds and this means I can test each new addition in context almost immediately with no external help required. I can run the game linked to FMOD to allow live updating of mixer levels and effect automations, so for a theme that may consist of repetitive note patterns and variation of the overall sound using effects over time I am absolutely composing within the game itself as it is playing.

In the second half of this series I will go into greater detail of exactly how I have created my dynamic music system and applied it to SDK. 

Defect Greenlit! Plus 1300% more missions!

Thanks to your support earlier this year, Defect has been successfully Greenlit! You'll be able to pre-order and download through Steam ... when it's done.

We've also just wrapped up Milestone 7! We've been busy creating the single player campaign missions: check out the following sneak peeks.

Above you can see the player taking direct control of the ship's turret. When the captain is manning this weapon, it allows the player to aim and fire, and has an improved turning speed. "Great kid! Don't get cocky!"

In this time lapse video you can see the current iteration of the shipyard and the ship construction process. We've made some slight improvements to the power and crew graphs. You can see the coloured Power bar and Reserve Crew bar decrease as the ship gets more advanced. If either of these is too low, your ship will not be fully operational.

Admiral Borld gives you the heads up on your next mission. Each of the Hexagons represents a mission. Completing a mission unlocks the neighboring ones. This gives you the ability to choose your own path through the campaign, unlocking various ship pieces at the end of each level.

Here's a sneak peek at one of the campaign missions, showing off some fast paced intercepting...

What's planned for Milestone 8? Aside from continuing to improve the gameplay, we'll have our Kickstarter campaign which is soon to launch. Stay tuned for more information!

End of 2014 Update

As 2014 comes to an end, we are nearing the release of Defect SDK. There's still a lot of work ahead of us, but we are on track for an early-mid 2015 alpha release. So what exactly have we been working on? Leading up to PAX Australia, we worked hard on the AI, created the intro cutscene and the first single player mission. We improved the UI and did a bunch of optimisations. We added a lot of sound fx and the dynamic music system (more on this in another blog post). Based on player feedback, we changed the control system on tablet to a virtual thumbstick style control that can be placed anywhere on the screen. This allows the player to control the ship with one hand and use the the other to control the camera and manage ship components. We're still experimenting to find the best method of control of the ship on PC and Mac, but we will most likely have a few different options available in the final release (ie mouse, keyboard, controller).

PAX was a huge success, with lots of people stopping by our booth and giving Defect a go. Based on player feedback and our observations, we then made lots of improvements. One of the things we were struggling with was ship-to-ship collision. It's hard to get it to look right and get the AI ships to steer around each other, especially small ships around large, oddly shaped ships. We decided to try removing ship-to-ship collision, so now ships fly over each other, with smaller ships flying over larger ships. It looks and feels a lot better, so we are going to stick with it and now work on tweaking the small vs large ship battles.

Now that the tech for that first mission is done, we'll be focusing on making many more missions over the next few months.

PAX Australia 2014

A few weeks ago, Defect had its first public showing at the PAX Australia expo in the ANZ Indie Pavilion. The turn out and attendance at our booth was more than we could have hoped for and we'd like to thank everyone that stopped by to play, sign up and give us their feedback.

Our stand had a PC, an iPad 3 and a Nvidia Shield, giving three people the chance to play at once. We also gave out limited edition, official Defect badges starring Zeke, the space seagull. If you grabbed one, consider yourself one of the lucky few 1000 people to be in possession of such valuable memorabilia.

If you couldn't make it to PAX this year or get a chance to play for yourself, not to worry, we'll be calling for early access beta testers soon, so make sure you sign up for the newsletter if you haven't already.

IMG_3464.JPG

 

Developing for Window Phone 8

Each new platform presents challenges for game developers. Using middleware like Unity helps a lot, but each platform has its own way of doing things and Windows Phone 8 (WP8) is no different. In this blog post, I’ll talk about WP8 game development from the perspective of a programmer who is porting a Unity game (Stunt Star: The Hollywood Years) from iOS/Android. The final product can be found on the Windows Phone Store.

 

Free Stuff!

First of all, sign up for BizSpark. You can get free access to various Microsoft software you’ll need for for WP8 development, including Windows 8 and Visual Studio. If you are developing for iOS as well, you’ll probably be using a Mac of some sort, so I recommend dual booting using Apple’s Boot Camp.

 

Plan!

If you are using Unity, there’s plenty of WP8 information available, starting with Unity’s own documentation. This MSDN article is pretty good as well, as it gives a lot of general info about the WP8 platform. Same goes for this PDF. This Unite 2013 video is good, as are some of the Building Windows Games with Unity event videos, but they might be getting a little out of date now. Microsoft’s documentation isn’t great, especially when you are searching for implementation details. I’m not sure what you can do about this, except to allow more time than usual when researching.

Make sure you read the App certification requirements for Windows Phone thoroughly during the planning phase and again towards the end of development to make sure you’ve got everything covered. The Windows Phone Store Test Kit helps in this process. There are a few things to look out for. Make sure you use the hardware back button and don’t have any in game back/cancel buttons. Have the app name, version number and technical support contact information in an easily discoverable location (for example, always visible in the credits). If your game has background music, make sure you have volume control for it. Toggles can only flip from on/off, not different states like kph/mph. This MSDN blog post is a good starting point.

Plan to make use of WP8 specific features, such as Live Tiles. You are much more likely to be featured if your game shows off the device/OS. Stunt Star uses a Secondary Live Tile to link to the Daily Challenge screen. The tile informs the user if a new challenge is available, and the back of the tile describes the current challenge.

An example of the back of Stunt Star’s Secondary Live Tile.

An example of the back of Stunt Star’s Secondary Live Tile.

If you use a textbox in your game (for example, to edit a Tweet string), be prepared to do some extra work as the WP8 keyboard doesn’t have a text field displaying what is being typed like iOS and Android. Also be careful of using the browser component, as it can use a fair bit of memory.

If you are using Unity and are using any plugins (you should be), make sure they are supported on WP8. We found that some plugins said they were supported, but they didn’t actually work. Check the Asset Store comments, the Unity forums and the plugin creator’s support channels. Also, some WP8 native libraries won’t work as Unity uses the older .Net 3.5, which often isn’t supported. Prime31’s plugins are pretty good and the store, ads and Essentials plugins are free for WP8 for a limited time.

Microsoft don’t supply any leaderboard/achievement system for non-Xbox Live games, so you’ll have to use your own or a third party one. We decided to use Parse, whose Unity Plugin didn’t work on WP8 at the time, so we had to use the REST API. The advantage to using the REST API is that is now works on any Unity platform.

 

Do!

Some .Net functions aren’t supported on WP8, but most the ones we needed have been replaced by Unity (see the UnityEngine.Windows namespace).

Be aware of the App memory limits for Windows Phone 8. You’ll want to use texture compression and DXT5 looks pretty good. I can't tell the difference between it and 16 bit for most textures, and it's half the size.

Microsoft Terminology Search webpage is pretty useful when localising standard platform terms.

Test on a number of devices. Take a look at AdDuplex’s Phone Statistics report to decide the important devices for you. Fillrate seems to be an issue on some phones, so higher spec phones with bigger screens might run your game slower than lower spec phones. Microsoft were able to provide us with some loaners, which helped a lot. The Windows Phone Australian Developer Community is useful for Australians.

Stunt Star did need some optimisation as Unity simply runs slower on WP8 than on other platforms, specifically script to native boundaries are slower in Windows. Reduce your script to Unity Engine calls as much as possible. Always performance test the Master configuration in Visual Studio and run without debugging, as there are significant performance differences when debugging and/or running non-Master builds.

 

Test!

Ensure you test thoroughly. Test switching in and out of your app by holding the back button to fast app switch. Pay particular attention to parts of your game that use social media or display modal dialogs.

Test having poor and no internet connection via the Simulation Dashboard in Visual Studio. Test losing internet connection at every step of social integration and in any other feature that uses the internet.

Test changing the device’s region. Some regions, for example France, uses “,” for decimal point and some, such as the US, uses “.”.

You can submit beta builds to the Window Phone Store, which is crucial for testing IAP. Unfortunately there was no way to copy all the metadata from the beta to the release version of the game within the Windows Phone Dev Center.

 

TL;DR

Overall, WP8 simply isn’t as well supported or documented as iOS/Android, but it is still a pretty good platform to develop for. Get to know the ecosystem, research and plan, make use of WP8 unique features and test thoroughly.

 - Paul (@pbaker05)

 

Update: Stunt Star has been featured in the Windows Phone Store in a number of countries, including the Indie Game Spotlight.


Stunt Star: The Hollywood Years can be found on the Window Phone Store, the Apple App Store and on Google Play.

Localisation

Localisation vs Culturalization

We just went through another round of localisation for Stunt Star, so I thought I’d talk about localisation a bit. Firstly, there is a difference between localisation and culturalization. Localisation is mainly about changing the text and voice in your game to a different language. For example, you might have made the game in English and you want people that speak French, German, Italian and Spanish to understand and enjoy it, so you add versions of the text in those languages. Culturalization is changing the game to suit a different culture. For example, changing the story to better resonate with a people in a different part of the world.

Plan

Localisation is much easier if you have planned for it from the start. Avoid using text in textures and use a dynamic font system so that you can easily translate to non-alphabetic languages which have a large number of characters (eg Japanese). If you use people’s names in leaderboards, you’ll have to make sure that your font supports the characters in their names. Allow a bit more space in your UI, as the German version of a phrase tends to be longer than the English version. Don’t use voice unless you have to, as six versions of it is going to be fairly costly! It’s a good idea to not have strings directly in code, as each of them will have to be found and replaced later.

Every game I have worked on has been in at least English, French, German, Italian and Spanish (EFIGS). Some games had separate versions of English for UK, US and Australia, separate versions of French for France and Canada and separate versions of Spanish for Spain and The Americas. A few have been in Japanese as well. It’s a good idea to do some research in pre-production to work out which language will be worthwhile for your game. This depends on the type of game, it’s content and what platforms it is on.

Implementation

We tend to use a spreadsheet with some importing/exporting tools to store the localised strings. For Stunt Star, we used Localisation Package and Google Drive. Each string has a key, maximum length, the string in English, a field for every other language and notes for the translators (eg if the string doesn’t need to be a direct translation). The key is what is used in code/data to reference the string. You can also add fields that check that the localised strings aren’t too long. Some strings don’t need to be direct translations, so it is good to allow the translators to be creative and put something more appropriate for that language. We used this for some of the fail messages in Stunt Star - I guess this is a way to sneak in some culturalization. You can have a separate spreadsheet for different areas of the game if you don’t want the entire thing in memory all the time. Also, have a separate spreadsheet for strings that aren’t in the game (store descriptions, keywords, achievements, etc).

The strings get exported from these spreadsheets into separate files per language and sheet. On first boot, the game chooses the language based on the device setting, showing the language select screen if the device language isn’t supported. The game then uses the current language to lookup the string key and use the appropriate string. We have a debug button that is always on screen that cycles strings between the string key and the actual string for each supported language for quick testing.

Localisation Tips

Check if the platform you are targeting has a standard set of terminology that is already localised. Quite often things that the end user interacts with have standard names, for example, "Live Tiles". Microsoft have a handy search page which can be found here.

To get the best results, get whole phrases/sentences translated, even if your string is made up of dynamic things like score. Subject-verb-object ordering can be different in different languages. For example, “Get 5000 cr on Cornballs 2 level 15 with the Monster Truck.” should be one string and the English version might be: “Get <score> cr on <chapter> level <level>.”, and the Italian version might be: “Ottieni <score> cr nel liv. <level_num> di <chapter>.”

Also, send the translators a general introduction to the project (themes, tone, audience, platforms, genre, etc) and the game if possible. It’s also best if the translations are made by one person and then checked by a native speaker. Most good translation services will offer that. We used Localsoft on Stunt Star. Even better if the strings can then be tested in game by a third party. Finally, put the translation team in the credits. They have allowed you to get your game out to many more people!

To sum up, localisation isn’t too much work if you plan ahead a little and it will allow you to reach a greater audience. I’m pretty sure platform holders are much more likely to feature your game if it is localised as well.

 - Paul (@pbaker05)

Stunt Star: The Hollywood Years is available on iPod, iPhone, iPad and Android in English, French, German, Italian and Spanish.

Shipyards Engineering Report Beta 4

To the Cloud!

This milestone we’ve been working on several areas, one of the more exciting of them being the addition of online features. Whilst not all of the online capabilities have been implemented, several of the more useful features are now to ready to go.

One of the more obvious online components is the ability for a player to login. This is all pretty standard fare - the player creates an account and then uses this account to log into the game. Doing so unlocks several aspects of the game that are otherwise unavailable whilst playing offline.

Cloud Storage

Whilst logged in, players are able to store their ship designs in the Cloud. This allows the player to easily transfer ship designs between multiple devices. If you happen to lose internet access at some point after logging in, don’t worry, the game can handle this too. Whilst disconnected, your ship designs are saved locally to the device and uploaded later, when internet access is restored. The ship design synchronisation also handles ship design conflicts that may occur when the player makes changes to a ship design on multiple devices.

Online Gameplay

Now that players can store their ship designs in the Cloud, things start to get interesting. Instead of just doing battle with ships of your own design, you can choose from various mission scenarios that test your mettle against other player’s ship designs. The enemy ships can come from the global player pool, or ships that your friends have designed. Either way, you can now get out there and show off your ship design, or ‘borrow’ design ideas from other players.

Direct Control

Over the last few weeks, we've been adding a new feature. Players can now directly influence individual parts of the their ship whilst playing the game. Think of it as the Captain giving his undivided attention to a certain part of the Ship, increasing its overall effectiveness. This gives the player the ability to tweak and adapt their ship’s performance during combat.

When under direct control, the effect on each piece is different. For some pieces, the change is a passive boost. For example, if the player were to take control of a crew piece, the entire ship is given a slight overall boost. Taking control of a piece of armour, such as a hull piece, will increase the armour’s ability to absorb damage, whilst decreasing armour loss. Other pieces result in an active boost. In the case of turrets, this gives the player full control over the aiming and firing of the weapon. Of course, there is a trade off, because no Captain can aim a weapon and steer the ship at the same time. Not every piece off the ship has the ability to be directly controlled by the player, only pieces that offer a worthwhile boost were considered.

A ships turret being aimed by the player

A ships turret being aimed by the player

Players will often create many of their ship pieces using the symmetry feature - but who’d want to have direct control over individual pieces that really should be linked? In the context of direct control, symmetrically placed pieces are grouped together, and any given boost is divided evenly over the entire group, so no advantage can be gained.

Taking control of piece is as simple as selecting a piece from a list in the in-game HUD. As some ships will have duplicated parts, the selected part is clearly highlighted. So as to not clutter up the screen with too many HUD elements, the direct control list only becomes visible when the player is zoomed close in on their ship.

Selecting a piece to control

Selecting a piece to control

Initial testing of the direct control system against an A.I. opponent has shown that the A.I. may also need to be able to take direct control over ship pieces, otherwise the player may end up with a distinct (and unfair) advantage over their A.I. counterpart. To make it fair on human players, the A.I. would need to be restricted by how often it can change which piece it has control of. But A.I. is really a discussion for another blog post...

Shipyards Engineering Report Beta 3

Last week we wrapped up milestone 3. The game has come along a quite a bit since the last milestone with new animated menus, a construction tutorial level, more ship pieces, functioning weapons and improved AI behaviour as well as a bunch of sound effects from Stephan Schütze

We now have a tutorial mission that introduces you to the controls and how to build your first ship. You start by creating a simple vessel and within moments you're creating your own crazy ship to take it on. We’ll be expanding on this in the next milestone to include more combat related information.

Our next milestone is less than a few light years away, June 30th to be exact. By then we should see a whole host of new content and features such as dog fights with multiple enemies, further enhanced AI, more sound fx and online challenges!

Android Fragmentation and Unity

If you take a look at some of the stats on Android fragmentation, it can look quite scary as a developer. Graphs here: http://opensignal.com/reports/fragmentation-2013/. Don’t be put off by this; Unity does most of the work for you. There will always be some weird device/OS combination that will have issues, but don't worry about them, focus on the other 98%. This is easy to do if your game is free, as you don’t have to give refunds to people who have major issues. Also, don’t even try to support non-standard versions of Android.

android phones4.jpg

Obviously you’ll want to test on at least a minimum specification Android device regularly. If your game runs fine on an iPhone 3GS, it should work on a 512MB RAM device like the Sony Xperia Go. Testing regularly on a Samsung device like a Galaxy S2 is also a good idea as Samsung has almost half of the market.

The main decision to be made is texture format. We used PVRTC 4 bit for transparent textures and ETC 4 bit for most other things. Sometimes uncompressed 16 or 32 bit textures were used to improve the quality when compressed didn’t look good enough. You should test on at least one device with each of the four main GPU types (Adreno, Mali, PowerVR, NVIDIA) to make sure your game looks great on them all.

In terms of 2D content like the UI, make it high enough resolution for the current best devices and move it around based on the aspect ratio of the screen. Use screen space, not pixels for positioning/scaling.

The best way to avoid any nasty surprises is to get everyone you know with an Android device to test your game. Email them the APK and track stats with Flurry or Game Analytics. Even better if you can see it running yourself and make sure it's all good. Don’t rely on end customers to tell you something looks funky on their device. There is a good chance they haven’t seen your game running on anything else, plus they probably won’t go to the trouble of emailing you about it.

To sum up, Unity handles most of the hard work, you just need to test on a few more devices and make some smart decisions regarding texture compression and UI placement.

 - Paul (@pbaker05)

Stunt Star: The Hollywood Years is available on iPod, iPhone, iPad and Android.

Shipyards Engineering Report Beta 2

Shipyard

LatestShipyard1-1.jpg

As you can see from the image above, a lot has changed since the last update. We’ve experimented with different control methods for moving the ship pieces around and have now settled on using handles for both touch and mouse input. There are separate handles for move, scale and rotate.

types.png

Drew has created lots more ship pieces, about one a day! We’ve moved “cores” and “crew” (the top two buttons on the right) from “miscellaneous” piece types. Which core you choose now determines how big you can make your ship.

Efficiency.png

We have hooked up the green circle and percentage display to the piece’s efficiency. The efficiency of a piece is based on how many other pieces it is connected to, so that the more pieces it is connected to, the less efficient it is. Too many and the piece’s capabilities get reduced. For example, the thrust of an engine.

stats.png

The bottom middle of the screen has the piece name and its crew/power requirements. The two bar graphs to the right of that are the ship’s power and crew capacity. As you add pieces, they use up some of the spare power and crew capacity and the bars go down. Adding crew pieces increases crew capacity.

Fighting

Weapons, radar, armour, health, shields, power and crew have all been added, along with a target practice ship, so it’s now possible to have a small battle. Weapons consist of laser beams, laser bolts and missile launchers, each of which can be setup as turrets or fixed direction. Radars boost certain stats. Shields always stop laser weapons and some can even stop missiles. Lots of weapon and impact visual effects are now in and working and ship pieces now look different, depending on if they are “alive”, “damaged” or “destroyed”.

Next

Our focus in the next couple of months will be to continue on improving the fighting and AI. To aid in that effort, we are happy to announce that we have a new programmer joining the team, Alister Hatt (@AJHatt). Alister has many years of experience as a lead programmer and has focused on AI, tools and analytics in previous roles. We have all worked together in the past, so Alister has quickly settled in and has been productive from day one.

 - Paul (@pbaker05)