I am doing a quick post, since I’ve just moved overseas for a new position at GameLoft. I barely have internet so this will be less tech/meaty then I wanted but hope you guys gain something from it.
I want to talk about the importance of doing a proper analysis stage while developing game tech.
The following is an experience that will hopefully enlighten you:
When I was working as a mid-level tech developer for Krome Studios I was asked by one of the seniors to develop a Sound API and Tool. The senior developer had a very firm understanding what he wanted the tool and API to look like. He was quite experienced at making engine API’s but no experience with end user tools. The issue we had was with the sound tool rather than the API.
The tool was to allow the sound engineers to create sound mixers and sound DSP effects for use in the in-game audio environments. The concept was the following; the sound engineer would place a box in a diagram to represent a mixer, they would then be able to draw a line from one mixer to another to indicate the signal path. A master mixer box would always be on the screen and the user would have to connect the signal path eventually to the master mixer.
So the tool worked perfectly based on the specification specified by the senior developer. It was fairly bug free since the project went through a full QA cycle sucking up quite a few days of man hours, taking up the time of both the QA tester and myself.
The one huge problem with the entire project was that no one never actually spoke to the end user, the sound engineers. The process we took was basically based off a senior developer who had zero or little of the client’s workflow
The sound engineers were well known to be fussy with their tool suites and being hard to please. Because of this we decided not to show the sound engineers until towards the end of the project cycle. I did a presentation on how the product worked, and showing it off the sound engineers. The feedback without the users having used the tools was generally quite positive.
It was months before I heard any rumblings but the Sound Engineers absolutely hated the tool. The problem was this feedback never got back to us on the engine team floor until it was critical for a pending product deadline.
It was after that I started having communications with the “Client”. We decided to redesign the tool entirely for the user. What was discovered was that the tool although functioned perfectly did not suit their workflow at all. What they really wanted and what fitted with their workflow was having a graphical representation of the Sound Mixer Decks you find in real life rather than the diagram based view. The other major issue was the scale in which the values were stored. Instead of using scales well known to Sound Engineers such as Cents, dB, Octaves, we used values, which made more sense to programmers such as normalized float values.
What we ended up doing was sitting down with a few of the senior sound engineers this time. We actually sat down with a white board, and started preparing a dummy application. We got the sound engineers to pretend on the whiteboard they were using the application and show us visually how they wanted the program to function. It was a very iterative and interactive process often involving the programmers and sound engineers showing on the whiteboard some feature or other, and working out the best compromise between ideal functioning and what the programmers could achieve in the available allotted time.
The new version of the tool was developed, and this time rather than waiting til the end of the development cycle we started to release early to key people in the sound department. Being shown only on the developers PC meant that key stalkholders were aware that the program wasn’t production ready and avoid them getting frustrated with an incomplete tool. I have had in the past situations where I release a tool early and completely irritate the user. We found small things made a huge difference to the sound engineers. For example being able to drag/drop from explorer into the tool, these types of workflow issues we just don’t think about as developers. We also used better API’s to make the tool, the sound tool being one of the first to take advantage of the WPF library from Microsoft which allowed us to create controls that were visually very different to common controls but still shared the same functionality.
Krome engine and tech team changed dramatically after that experience. We started to become much more client focus, the clients being the game teams using our product. For example, we always had politics that the tech team must always develop the tools. Our internal API’s were not usable to outside teams. After I revamped the internal tools to use an automated generated C# version of the C engine game teams started to use C# API for their own internal tools. James Podesta a fellow author on this site can attest to how this made it much easier for the game teams to make quick tools, which the tech team just didn’t have, time to make and which were very specific to the title being made.
The engine team in general changed in focus, instead of just relying on the experience of the development team we would communicate with other teams.
The moral of this article is that we should always have a strong design/analysis stage with members of the client groups, particularly those client stakeholders who can grasp the more technical elements. Also it’s important to get programmers who care about workflow in the meetings. Get out there and talk to the target audience. The flip side, is make sure you don’t get the user frustrated by releasing beta products early and getting the end user frustrated with bugs. Control the environment where you show the prototypes to the user, at your computer where you can let them go through the application to make sure it works. Also make sure you are talking to the right group of users in the client group, some users are unable to communicate technically and this would frustrate both the developer and the less technical minded end user.
Another thing it’s amazing how a small change can make a huge difference to the target audience. Sometimes the smallest change end up making your target audience the happiest. Often things we don’t consider without having spoken to the clients.
Also think of your game teams as clients. It helps to think that you have to make a product that suits their needs, not developing tech for tech sakes.