You are here

2015-08-19 - Devlog - Quarries of Scred 2: Quarreling Quarriers - 001

Noble Kale's picture

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:

  • Player starting positions need to be indicated excessively
  • For games wherein the players are competing (but not aiming to kill each other as the goal), they need to start clustered together. For games wherein the players are aiming to kill each other, they need to be further apart
  • The base game itself isn't that great without a goal driving the players - something needs to instill a sense of urgency (A time limit, a goal to achieve first, a point to race toward)
  • Darkness mode was significantly better for the fact that the players saw only what was immediately necessary - the full view of the quarry is perhaps info-overload
  • The Attractor/repulsor items are pretty much useless and may need to be ultimately scrapped
  • Players need to be forced to stay close to each other to bring various things to bear
  • Laser range to be extended drastically - landmines need their explosive radius significantly increased
  • Game objectives need to be reinforced on the count-down screen. Countdown needs to be shown for each game
  • Player location needs to be more strongly indicated on respawn
  • Player deaths to be indicated more strongly

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.