Sign up for our newsletter!

News

Exploring other fighting game audio

Over the last week or so I've been trying to get my audio engineering and sound design ears open wide and analysing audio choices made in many classic fighting games. This very afternoon I had a nice gaming session of Super Street Fighter IV (SSFIV) on PlayStation 3 (with a little Guilty Gear thrown in for good measure).

And here are my thoughts on the SSFIV playing and listening session:

Basically the priority in the audio - what is most in the foreground - is the sounds that give player feedback. The strikes, intensity of the strikes, whether they disabled a combo, hit or miss, ultra or standard, blocked or not. All the sounds with encoded gameplay information are clearly at the fore over all other sound in terms of the sound mix.

I thought it would be the vocals, however, the vocals are pretty well mixed in with the ambient sounds (slightly above, and with an EQ spread that lets them cut through the ambient audio a little extra).

Street Fighter also has a very 'exciting' (as in stimulating) mix, it's very full (busy), highly compressed (in terms of audio dynamic range compression not data compression), high amplitude bass and treble and just enough mids to fill it out and keep the overall audio robust and 'chunky'. This style of mixing I think will not suit Blade Symphony so much. It's more specific to the SF project - but that's the decisions they made for that project and it works fantastically for that game. Also, SF is designed to be played in noisy arcades, so you can't have a great deal of dynamics; that's reserved for more quiet locations (think of the dynamic range compression many DVD, Blu-ray players and TV's have built in - the quieter your listening environment the more they will give you 24bit dynamic range. The noisier your listening environment the more they compress the volume of sounds into the upper levels. That means less range but you don't miss the quiet stuff).

The fact it's mixed for arcades also explains some of the reasons why the information is encoded in the trebles and bass, not really the mids so much - mids get lost in noisy environments where as bass and treble tend to cut through better. So some of the decisions they made were obviously affected by the context the game intends to be used in. Blade Symphony, having a PC release, we can expect to be played in a different environment and so the audio mixing will take that into account. This exploration is a case of finding how good audio decisions get made - not about mimicking successful audio design choices.

At any rate it's all food for thought. It's clear that the people at Capcom working on SSFIV made very conscious decisions on every level - there are no accidents in the sound design or mixing. Inspirational stuff really.

Let's see what kind of functional and beautiful audio I can organise for Blade Symphony hey?

Redmine: Some news from the back desk

While in between project planning for our third project, periodic observations of our great competitive community and testing Blade Symphony, I figure now is just as good time as any to share our project management tool with those interested.

This year marked our first, since the start of Dystopia development, for switching from the well-built Mantis Bug Tracker to the even better, robust Redmine Project Management Tool. The reasoning was simple; at that time the team had an internal wiki, a repository browser, technical support achieved through way of forums and project management conducted by verbal and text communication through e-mail, HTML and IRC conversations.

Having a full-on project management solution that incorporated these technologies, making them redundant, was a great move for us in terms of effectively getting work done. After a workflow was developed and streamlined (which I hope to go into detail about it's inception at a later date,) we began using Redmine and helping it assimilate our other technologies that were made redundant.

Before I go any further, let me first explain the reasoning and the process behind making Redmine our project management tool of choice. At first, we knew that we wanted to begin down a long road of creating a more transparent and truthful development studio, for the benefit of future consumers and fans, as well as for our own. Groups like Unknown Worlds and the Minecraft development team, just to name a few, apply more of an open development model. This open development model is one of a number of great methods that independent and smaller development teams can use to ensure a quality product that is very efficient to develop, due to help from it's community and fans -- but more on that later.

Along with the desire for our development to be more exposed to the public, we wanted to:

  • Nullify the usage of our various other tools
  • Have a greater depth of features offered by Mantis integrated with a Project Management program
  • Have the ability to configure more specifics regarding our workflow, permissions, project standards and definitions
  • Offer a medium for consumers and fans to communicate more efficiently about technical support problems and to offer suggestions.

We began evaluating exhaustive lists and after reading countless forum threads, losing ourselves in project management software reviews and test-running multiple solutions such as Trac, Pivotol Tracker, dotproject and openProj, we decided on Redmine because of a multitude of factors:
  1. Free, open source, widely used and regularly updated: Allowing us to configure every bit of information on our install, receiving bug fixes and new features with tons of documentation for it's usage, all at a low cost.
  2. Self-hosted, self-maintained: Some more popular project management tools are hosted proprietorially and as a result, their regulations regarding content-rights and ownership sometimes lie within a gray area. Your project and team are also subject to their downtime, problems and maintenance staff. With the downside of having to maintain your own solution, comes the upswing of being able to access and observe parts of the tool that you you wouldn't otherwise be able to, choosing the best and most efficient programs and tools to compliment it.
  3. Plugins & Themes: Having more customization options available at an end-user level enables us to make changes to the design of the tracker, enabling better visualization or efficiency. Additionally, the ability to change your project management methodology or add an overlooked feature through the use of plugins particularly interested us.
  4. Winner of many back-of-the-box features: Along with the above features, Redmine also had many capacities on a project manager, developer, test lead or test side to benefit the project, including integration of a task/time tracker and a defect tracker, hearty methods of visualization such as a dynamically-generated roadmap and Gantt chart, a file storage and sharing system, revision software linking and control, customizable workflow, group and member hierarchical management, robust custom field organization and much.. much more.

After it's creation, integrating an item workflow, setting up custom fields, permissions and item standards, we migrated all defects from Mantis over to Redmine using a migration script. The major goals in learning this project management software is to effectively plan and schedule future projects, as well as coordinate a better teamwork dynamic among the developers.

That being said, we have been utilizing Redmine as much as we could in the last 10 months, and will start to make changes to the way we conduct development in the future. We intend to field technical support tickets through Redmine, take development suggestions for features and changes, and give the public an outside view of our development methodologies and strategies on top of already allowing defect authoring by the community.

With that in mind, I wanted to invite everyone interested, to travel over to our Redmine page if so desired, register an account, browse around and feel free to report previously un-documented defects for Dystopia, and in the future, Blade Symphony. Seeing as we're taking a gamble in allowing the community to take part in the development of Dystopia, we're asking that it not be abused and that people do their best to remain a positive contribution to it's activity.

I might give more information about how we've used Redmine and how we intend to use Redmine in the future in another post or in a post about workflow, but for right now, I think I've explained some things. Look for more later.

From the galactic gathering

I bet you thought we were nice. Just some nice people who really like making games.

Allow me to correct your misunderstandings: We are evil.

But whatever our motives, one thing is for certain, we are making games.

Devapalooza 2009 & 2010



In approximately two days, I will be one of nine developers in Puny Human stepping on a plane or getting into a car for our second annual developer meet up.

Graciously coined "Devapalooza," the developers of Dystopia and our other projects all meet up for a week to hang out, eat sushi, drink beer and develop games. This year, we will all be boarding our transportation bound for a week in Kansas City, Missouri to spend a week doing the most development work we possibly can in the time allowed to us.

First, I'd like to go back and re-visit last year's meet-up, Devapalooza 2009.

Image Image Image


Last year at this time, we were at the height of re-tooling Dystopia using a new engine, working around and fixing new problems, and planning for what we wanted to include and where we wanted to take Dystopia from then. Besides Dystopia work, we were ramping up development on our next project, discussing a lot of hypothetical, potential story lines, atmospheres, art styles, combat moves and game play. By the end of the week, we had made progress on both projects.

Image Image Image


In between games of Q3A, HoN and L4D, we achieved a lot at Puny Human and had a lot of fun in the process. We intend to do the same thing this year at Devapalooza 2010, which starts this coming Saturday October 2nd, and will be wrapping up the following Sunday October 10th. During the course of the week we'll be revealing and talking about our new project, having a community question and answer session, (hopefully) joining the guys from Podcast17 for an interview among other things. It will all be streaming over USTREAM throughout the week and talked about on our twitter and facebook. Be sure to stay tuned as we develop games, get opinions about different things we're working on, and talk candidly about our next project.

Image Image Image Image

Updates from Twitter