Fray: War, Tears and Playtests. news

Hello fellow earthlings! As time flows on, so does Fray's progress. Last week was pretty busy as we continued to work on level design and art production. Also, as we discussed in our last update, we did the game's motion capture at Quantic Dreams studio last week, and it was... entertaining!

Motion Capture:

We had an intense day of Motion Capture shooting on Friday, and it was a lot of fun torturing our poor lead programmer. Indeed, we got to push, shove, pull, hit, throw and punch him in all directions, all the while having a huge smile on our faces. Working with Quantic Dream on this was really great, as they were very professional and always had solutions for any small issue we had. We can't wait to get to work on the animations and adding them in the game.

The images above are just a teaser for an upcoming making-of video I am currently working on that should be ready in a few weeks.

Playtests:

As I told you last time, we are preparing some playtests for the game. These are internal, with only a few people coming over to try the core gameplay mechanics, but they should enable us to spot issues early in the dev cycle and correct them before they become unchangeable.

Our game designer, David, has written a piece on the methodology he will be using to test the game mechanics, and we hope this will be useful to other designers.

After weeks of fighting with Unity, we are at last able to play on a full functional mock-up of the game and it is finally time to launch our qualitative playtests (Microsoft.com). At least it gave us some time to think on how to set up these sessions!

We really think that players have to be integrated in the production cycle as soon as possible, and that we must take their feedback into consideration. We first played many times a board mock-up of the game, testing the core gameplay, and after 6 months of production it is now time to call our friends (and their sisters) to serve as lab rats for the playtests. As Jesse Schell says "playtesting is like an engraved invitation that reads: "you are cordially invited to tell me why I suck"", playtesting is hard for the designers and developper's self esteem, but they are the best way to insure that the game will be fun and usable by the players.

Here is how we are going to do it.

Each test will be designed to last between 1 and 1.5 hours.

At their arrival each tester will be welcomed with a cup of Veuve Cliquot's champagne, a toast of foie gras and will be invited to set up on our Philip Stark designed autovibrating sofa. Or maybe it will be coke and a plastic chair. At least one of these will be true.

The leader of the session will have a brief chit-chat with the tester, in order to know him better, and to expose how the test will take place. The main goal of this pre-test is to present the game, get the tester used to speech with the session leader and make him confortable, as he is not the one who is being tested, the game is.

Then we will take approx 45 min for the test, we want to focus here on core gameplay and middle functions. 2 scenarios will serve us to test this. The first will help us to focus on how easy it is for a player to learn the basics of the game and continue playing with it, while still learning strategies. The second will provide useful information on how the player can build tactics to resolve conflicts and reach short term objectives. We will gather data thanks to screen and webcam recording software on one hand and by the presence of a game designer who will lead the session and write down any useful insights from testers on the other hand. In order to let players play as if they were at home, we will use the think aloud technique (En.wikipedia.org).

Letting the user express his feelings regarding his experience with the game with only very few interventions of the session leader will insure the gathering of relevant data regarding our game. During the session we will pay attention to tester behavior and will sometime stop them during the scenario to focus on a specific problem; this kind of interruption will not have to be reproduced more than one time per scenario, and only if we have to extract a very contextual data from its mind.

The more interesting part will be to hear players thinking aloud, take relevant notes and consider that everything that is said are mainly symptoms, not necessarily concrete problems. That is especially true when the tester expresses something weird, we have to dig everything that has been said, so that we do not take them too literally. Each scenario will be then followed with a questionnaire.

Finally, a debriefing session of 15 min with a questionnaire and an interview will close the test. This moment will be precious for us to collect insights regarding problems and recommendations. One of our favorite things to ask then is "now that you have played this game, if tomorrow one of your best friends tells you that he wishes to buy it and ask you what you think about it, what are going to tell him ?", players are now open to criticize the game and we can go on with the questions regarding the "what are the 3 worst points of the game, and the three best ?". If we see that testers are not willing to say bad things about our game we thus encourage him to focus on bad point, saying that the game probably has problems and that we need to know them to correct them.

We will then organize and prioritize all collected data and produce a document explaining all the problems one by one, each time exposing a report of the problem, the consequence of it on the game and what we have to do to go over it, this report will be exposed and communicated to our team. As we don't have a room with tinted glass nor the possibility to send video to a computer outside the room we will not be able to invite team members to assist the sessions, we don't want them to be in the same room as the tester in order not to impress him and to keep "ecological conditions".

If useful we will take 30 seconds videos of a tester meeting some problems to show it to our wonderful programmers and producer. As said, the final document will report all problems, their gravity regarding the core gameplay and the intuitivity of the interface, and then grouped by main patterns of our game. In conclusion and after a first discussion with all the team we will resume every datas by actions to be taken to correct our mock up and continue making a nice game on a solid basis.

Finally, at the end of those painful sessions we will probably have our game designers and programmers take a week of vacation on a breakdown specialized establishment, after that we will be able to have some times discussing about prior problems, how to correct them while keeping focused on our core gameplay. Team will then have to work on those corrections, and then... we will have another playtest session !

Thanks for reading guys, next update in a few of weeks! Bisous Bisous !