The last little while, I've been working on a multiplayer version of Quarries of Scred, my first commercially available game. The multiplayer variant is aimed at local, competitive play (I've thrown around the pros and cons of network play, and co-operative play and decided against them both. This'll be covered in a later piece).
It's been an interesting experience thusfar - in that I've not really developed for multiplayer before (there was a very terrible networked QoS build almost two years ago that never made it out for feedback), and there's a lot of new things to account for. This evening, I spent some time playing the game with my wife, and we've come to the following conclusions:
So - what we can immediately infer from the above, is that a lot of work needs to be done to really show the player relevant things and make them stand out. I've vaguely considered that perhaps we need to halve the size of the quarry and double the graphics size - this would reduce visual complexity significantly
Another thing we can noticeably see, is that the goals need to be there - the players need an impetus to move quickly and engage. In short: Competitiveness needs to be incredibly encouraged beyond what we see already.
While the testing wasn't as encouraging as hoped, it's still a good thing to have identified these problems much earlier in the dev cycle. As it stands, QoS2QQ is currently on about 40hrs of development (having piggybacked a lot of work from QoS1, obviously) - so there's still a reasonable amount of time to develop ways to handle the above issues. At present, the obvious time to work toward is the display of the game at PAXAus 2016, but I'd like to have the game in the hands of the public much earlier than this.