Week 12: Testing, testing…

As you might have guessed from the (totally original and almost certainly never used before) wordplay in the title – this week we did some play testing of our game.

Last week we’d had a pretty rocky play test with our class. What we learned from that was that our game was a long way off being properly ready to test. Movement was janky, levels hadn’t really been tested, and a lot of the ‘juice’ was missing.

To add to the problems. we didn’t really manage to set up very well, or run through our game properly before getting anyone to sit down and play. As a result, sound wasn’t set up properly, there were a number of bugs that we didn’t know about, and basic things like controls were different to what we had expected.

So that went about as well as we expected.

Following that, the rest of the week was a pretty hard slog by a few of us, to get into a position that we were actually happy to show to our peers.

Credit to two of our programmers, who put in a huge effort to implement an entire new movement system, and sort out a whole bunch of bugs, and our level designer, who built three serviceable levels without being able to play through them.

The reason for all this extra effort was the planned play test for Tuesday of this week. We held a play test session at The Arcade (http://thearcade.melbourne/) – a collaborative workspace for indie game developers, and invited the resident developers to check out our game and give feedback.

I took some time off work to go into the Arcade early and run some levels before the play test. There were a few little changes to make to get everything in order, and I wanted to make sure we had our sounds and controls set up properly. (I then promptly changed computers without pushing my changes to the repo and lost them all, but you can’t win them all…).

Anyway – in the end it all went pretty well! we had three levels that could be played through from start to finish, and nothing was stupidly broken. A real improvement over the previous week.

We got some really useful feedback from the developers who played through the game, and they all seemed to not hate it, which is good, right?

Since then, we’ve been going through the feedback received, and getting everything ready for our final submission on Friday.

We had a team meeting on Wednesday and talked over everything. There had been some negativity following the previous test, so we took some time to highlight some wins that we had, just to make sure that we acknowledge good work and keep people feeling positive.

I think we are in a position to submit a reasonable alpha version of FourShadow at the end of next week. I don’t know that I think it is the greatest game ever created, but I do think we have some interesting mechanics that we can turn into an interesting game with a bit more effort.

As Andy (our tutor) said this week: Semester one – make the game. Semester two – make it good.

Bring on semester two…

High Score: Composition and Sound Art for Gaming

Yesterday (Saturday) I attended this pretty excellent series of talks put on by APRA AMCOS (A music and musicians representative body – learn more about them here: http://apraamcos.com.au/).

The day involved a series of four talks from musicians and composers that work in the games industry and was all about informing music creators what they needed to know/learn/find out in order to start getting involved in games.

I attended as a game developer hoping to learn a bit more about sound design and implementation. So I didn’t really end up getting what I thought I was going to get out of the day.

But, what I did get was super informative and totally worthwhile.

The first talk was given by Meghann O’Neill. Meghann ran us through a series of games showing progressively more complex music management systems that reacted to the player’s actions in more creative ways. These ranged from simple stings that were triggered by player death, all the way up to systems that would track the game state and play specific pieces of music in response. It was really cool to see some of the examples that she showed using sounds and music in different ways to give feedback to players.

Meghann also went into a fair bit of detail about the Australian and Melbourne gaming scenes. This included statistics of what roles are usually within game development teams (lots of programmers and artists, few producers and audio people).

After morning tea we heard from Jared Underwood and Ash Ringrose of SMG Studios. Jared is a musician and composer who creates music for Ash’s game development studio. Ash described it as a ‘monogamous collaboration’. This talk covered some really great info on creating a brief for a composer, as well as how to respond to a brief and how to work through the feedback process.

It was great to see this conversation from both sides. Ash made it pretty clear that he wasn’t really across all of the musical lingo, and Jared emphasised how much more useful it was to receive a brief that referenced a mood. As someone not trained in any sound design, it was good to hear that a useful brief can still be generated without requiring any particular level of knowledge.

They also covered how important is was to be honest and open in the feedback process. Responding to a brief is an iterative process and it is extremely rare to get the exact sound you are seeking on the first go. It’s important that you give honest feedback to get the best results.

Following lunch we heard from Maize Wallin. Maize went over a lot of the software programs that are used to implement sounds into games, as well as the programs usually used within game development teams. I was particularly interested to get an idea of the third party plugins that are used to provide greater functionality for audio in Unity. I’ve only worked Unity’s built-in audio functions before, so seeing what could be done with the plugins was an eye opener! I’m definitely going to dig a bit deeper into these.

Talking with a few of the other attendees afterwards it became clear that the majority of the programs that Maize had discussed were totally new to them. I gave a couple of people quick run downs of Slack and Trello and very basic explanations of Unity and Unreal. It was interesting to see how these tools (which I kind of take for granted now) were completely new to the rest of the audience. Maize pointed out how beneficial it was to have at least a working knowledge of all of these tools if you wanted to work within game development. Being able to sit in a job interview and say that you already know how to use all of these programs would be a huge benefit.

We ended the day with a Q&A session with Neal Acree, a composer of video game soundtracks. This talk was more about his experiences working to make music for games and game trailers and his history within the industry. It was interesting to hear about the various briefs and instructions that he has been given over his career, and the degree of freedom or explicit direction he had been given to develop music for games.

All-in-all this was a really good day and I learned a lot from it – even though it wasn’t exactly what I had expected it to be going in.

If anything, I would have to say that this event was a real lost opportunity for the game development industry. I was one of very few game development people in the room, and as a result I had a whole bunch of people wanting to talk to me in the breaks about game development and how I talk to, and about, music and audio.

It is clear that there is a huge pool of audio people who are keen to make contact with and work with game developers. If something like this happens again I would highly recommend that game development folk attend.

As a final note – it was great to attend a series of talks where half of the presenters were women. Great work APRA  AMCOS.

End of Week 11

So, this is probably a pretty odd time to start writing a devBlog. It’s already almost the end of the semester, and I have plenty of other work to be doing.

Maybe I should back up a bit.

I’m currently doing my capstone project for Game Design at Swinburne university. I’m in a group with seven other students, and we are all making a game together that is going to be on display at PAX Australia in late October.

As you can see from the title, as I write this post, it is the end of week 11 of semester 1.

There are 161 days until PAX.

We .. are not having a smooth run so far. There has been considerable difficulty in deciding on a direction for our game, and I have ended up in a leadership role that I don’t think I’ve done a particularly great job in so far.

Now, there has obviously already been 11 weeks of development, so I’m going to write up a post soon that will detail what has happened so far to bring you up to speed. But, to be honest, I only really started this cos I was waiting for something to download.

I’m going to use this devblog to write up reflections at the end of each week, and record/share the experience of putting our game together. I’m going to do my best to stick to a schedule, and provide an honest and open reflection on what has happened each week.

Stick around.