So I’ve finally decided to do a proper dev diary. This is probably something I should have done a while back.
There’s not much I can do about the lost time, so I’ll dive right in with what’s happened in this last week.
In short: we playtested and we crunched. And surely, we will again.
More on all that, after the jump.
So we had our first lot of playtesting last Saturday. We playtested with 6 people, each in groups of two, and specifically tested people who considered themselves gamers, as we weren’t specifically testing the tutorial and wanted to throw them in the deep end a bit (so if we didn’t ask you, it’s probably coz of that, because you aren’t in Sydney, or coz you didn’t sign up).
We weren’t ready for online testing yet (we haven’t actually gotten our automatic data collection up and running yet, which is a little embarrassing), so we did this all old-school. We tested a flash tutorial followed by a flash vertical slice individually. We then brought the players together to play the same level on XNA (using xbox controllers) in co-op mode, before getting them to play various co-op and competitive multiplayer modes.
Between each test, we conducted an interview (we felt that an informal process would likely lead to more open feedback) with the player(s) with some set questions and others not set.
It, in short, worked pretty damned well.
What went well:
- Got some excellent qualitative feedback about the game, and a laundry list of little things we can change to improve it drastically.
- Feedback was pretty consistent throughout the tests
- people were generally happy with the gameplay even if the levels themselves were too hard
- The interviews were very insightful and encouraged the players to make suggestions, some of which we’re now going to prototype!
What went not so well:
- Each test took 1.5 hours, and while it was totally worth it, we need to speed things up for our own sanity and get our asses into online testing.
- While our mostly qualitative data gathering got us what we needed for this test (as it was mostly exploratory), we found that the small about of quantitative data we tried to collect during gameplay (recording number of deaths and which waves they were in) was incredibly difficult due to the pace of the game.
- We only had 3 testers on the day, which meant that while one player could be observed by two people (one taking quantitative data, the other watching for areas of frustration etc.), the other would only be observed by one (which was much harder in terms of gathering data).
While that seems like a lot of cons, most of them are things that need to be fixed for our next test, rather than things that we needed for this one (as it was, as mentioned, rather exploratory).
The main things we learnt about the game (there were a lot of tiny things):
- Our use of colour is currently not highlighting the right aspects of the particles. Whether they’re particles or antiparticles is most important, followed by charge (the current scheme is the other way round.
- Respawn after death requires more time and the player should respawn where they die (we actually had different respawn schemes in XNA and flash, and the XNA was by far the easier for players)
- Survival gameplay only goes so far – we need more building/using forces to your advantage levels (we already knew this but it was definitely confirmed)
- The tutorial explains most things fairly well, but fails to explain the forces at all
- Waves need to be better spaced out and named.
All in all, a really good experience. Our next playtesting deadline is in 2 weeks when the IGDA runs their ‘Bits and Pieces’ event. By then, we’re looking to be ready for some online testing as well (sign up here).
Our current goal/deadline for Particulars is to have it ready (and polished in gameplay, though not necessarily in graphics/UI) for the Indy Game Challenge. This means that time is supremely short, and that we’re kinda in a perpetual crunch mode.
The problem with this is burn out, and it’s something I’m currently very aware of. Our last deadline (being ready for the aforementioned playtest) was fairly hectic, and we really only have about 2 weeks to do a lot of gameplay experimentation before we have to go into full production mode. Plus, we’ve got a great playtesting opportunity coming up with Bits and Pieces, so the clock is ticking to get more content for that.
So we’re kinda surfing from crunch to crunch.
My current solution to this was to squash this week’s dev effort into the weekend. Anyone in the team who can work the whole weekend (and we’ll be doing this in a co-located space) is exempt from any work during the week. The more time you can put in on the weekend, the less stuff I’ll be giving you to do during the week. And so on.
This strategy has done fairly well so far in that it’s given everyone some breathing room, though it remains to be seen as to whether we’ll get everything we need done, done.
I’d love to hear from other devs about this issue – how do you deal with an elongated crunch like this, particularly when everyone’s part-time?
Next week – voice acting auditions and the results of the crunch-squash (god that’s an awful name for it).