It has only come to light recently in my discussions with other developers, as well as tutors at my University, that when I say I playtested Food Time Battle in Space for six months, or that I’ve been playtesting Space Game for three months now, that I’m just plain wrong. If we look back at the development of FTBS, it took me roughly about a month to work out all the kinks, and make sure that the game is playable and enjoyable. Due to the game being so tightly designed yet very asymmetric (I only had 12 cards to work with for each player to create and balance that asymmetry) it then took me five months to balance the game. To break that down more simply, development on FTBS was split into:
This blog post is going to briefly cover the key difference between the two, as well as discuss what your aims should likely be whilst in these two different phases of development. Playtesting
I am going to discuss this more in a different blog post, but there are two widely used processes for creating games. There is SCRUM, which is a form of rapid iterative processing. You essentially plan your game, build it, test it, review it and repeat. There is also the Waterfall technique, which consists of doing this method, but only once, which consists of a much bigger and longer planning stage compared to the rest of development. I personally prefer using the SCRUM method. The reason why I make this distinctive remark is because it is important to have the right mindset when going into playtesting. Your aims for playtesting should be:
Quality Assurance I’ve yet to find an efficient way to structure QA, but when I do I will let you know (consider signing up to the mailing list hint hint). What I will say though is that at some point down the line you will have to say to yourself, and your testers, that enough is enough, and that the game is done. I have been in a situation before where I was hoping that the playtesters, or even the game, would make that decision for me. To refer to FTBS again, I had a spreadsheet of the four different restaurants, and my aim was to make it so they all had the exact same win rate. That was never going to happen. You can play your game constantly, on repeat, forever, and you will always find things to change. I mean, just look at any other game you’ve played, I am sure that are some aspects of every game that you have playtime in that you would consider changing, and those games have been in QA for months just like your game. Despite this, here are a few things to consider when going through QA:
The Difference Between QA and Playtesting The core difference has to be that the end of playtesting is very distinctive. You have a beginning point, your first iteration of your game, and you have an ending point, when players continuously enjoy playing your game and it works. With QA, there is almost never an end in sight. Playtesting is very much for vetting the value of an idea, whilst QA is focused on determining the best way to deliver that idea. Both QA and playtesting are essential to game development, but I would say that if you go into the development of your game with different mindsets for each stage of production, it can save your sanity slightly when you hit month five of “playtesting”. |
AuthorHello, my name is Niall Crabtree, and this is my comprehensive blog showcasing all of my game development Archives
June 2022
Mailing ListReceive an email every two weeks with all the articles I produce so you never miss one!
|