13 Mar 2017

In the development of our game, we’re working with some very talented artists. Over a few weeks, we’ll be featuring some of their great character and background designs here on the blog. This week, we’re featuring Shelley Topping, a student at Ulster University.

Check out Shelley’s work below, and visit her website to see more.

Posted by Nigel Robb

03 Mar 2017

In the development of our game, we’re working with some very talented artists. Over a few weeks, we’ll be featuring some of their great character and background designs here on the blog. This week, we’re featuring Tyler Carrigan, an Animation student at Edinburgh College of Art.

Check out Tyler’s work below, and don’t forget to visit his blog to see more.

Posted by Nigel Robb

06 Feb 2017

In the development of our game, we’re working with some very talented artists. Over a few weeks, we’ll be featuring some of their great character and background designs here on the blog. This week, we’re featuring Amy Bruning.

Check out Amy’s work below. You can see more here and here.

Posted by Nigel Robb

26 Jan 2017

In the development of our game, we’re working with some very talented artists. Over a few weeks, we’ll be featuring some of their great character and background designs here on the blog. This week, we’re featuring Eleonore Dambre, an Animation student at Edinburgh College of Art.

Check out Eleonore’s work below, and don’t forget to visit her website to see more.

Posted by Nigel Robb

20 Jan 2017

In the development of our game, we’re working with some very talented artists. Over a few weeks, we’ll be featuring some of their great character and background designs here on the blog. This week, we’re featuring Francesca Kennedy, a 3rd year Animation student at Edinburgh College of Art.

Check out Francesca’s work below, and don’t forget to visit her blog to see more.

Posted by Nigel Robb

10 Mar 2016

Below is some information on a new project at Queen’s University Belfast, exploring non-compliance behaviour in children with developmental disorders. We’re hoping to recruit parents / caregivers of children with developmental disorders to take part in a telephone interview. For more information, contact either Luke McCann or Katherine Grady.

Posted by Nigel Robb

10 Jan 2016

Video games are hugely popular, with around 70% of Britons playing them, and the global games market expected to be worth over $100 billion by 2017. According to some sources, 20% of casual gamers have some form of disability. These numbers make it obvious that making video games accessible for people with disabilities is an important and worthwhile task.

Fortunately, guidelines exist to help game developers do just that. These guidelines offer well-founded advice for overcoming gamers’ disabilities in 4 key areas: cognitive, vision, hearing and mobility. As such guidelines make clear, the majority of these problems can be overcome through design. For example:

  • Design your game to use the simplest possible control system (cognitive, motor)
  • Allow controls to be customised so players can use different buttons other than the default (motor)
  • Allow the game to be paused at any time (cognitive)
  • Ensure that no essential information is conveyed by colour alone (visual)

However, not all mobility problems can be eradicated through game design. Consider a person who cannot use any kind of traditional game controls at all, even a simple button or touchscreen, perhaps because they can’t control any part of their body very well. In addition, many people have the cognitive, visual and auditory abilities to play more complicated video games, but simply can’t use a conventional game controller.

Special Effect is a charity, founded by Mick Donegan, which seeks to address these situations, by providing customised and novel game controllers for people with all kinds of disability. They work with people on an individual basis, assessing their needs, and providing some really ingenious solutions to their problems. This could be anything from a simple stand to keep a game controller steady, through joystick controllers with larger buttons, to games which can be controlled by eye movements, voice commands, or facial gestures.

You can see some of this really amazing technology in the video below. And most importantly, you can see just how much joy it can bring to people with disabilities to do something that so many of us take for granted – play a video game. You can find out more about the great work they do here.

Posted by Nigel Robb

17 Nov 2015

The latest version of our prototype cognitive training game has been released. It has lots more features, has been optimised for performance, and has fewer bugs. You can download it on Android devices from the Play Store, or play it in Chrome or Firefox here. To play in Chrome on iOS, use this link instead.

Some details about this latest version:

In a few previous posts, I explained how we were testing different control systems in our game. After lots of feedback from players, and observation of children playing the game, it seems very clear that simple touchscreen controls are by far the best, both in terms of how immersive the game is, and also in terms of simple usability (which is, in fact, related – becoming more immersed in a game is partly about being able to control the game without thinking too much about what you’re doing with your hands, so more usable controls are more likely to be associated with higher immersion).

Further analysis of action video games has given me lots of great ideas for features to include in our cognitive training game. The latest prototype has particle effects (see below left), power-ups (see below right), screen-shake effects, information displayed on screen, unexpected changes to the current task, and more besides. All these features are there for a specific reason: to recreate the kind of fast-paced, hectic, messy, complex learning environments that entertainment games (especially action games) provide, because I think that this messiness is important in creating learning that transfers beyond the training environment.

The latest version of the game also has music and more sound effects, which we found were important for increasing player arousal in an earlier playtest.

Another major change has been made behind the scenes. Previously, the game relied heavily on the State Design Pattern. This was ok, but I was experiencing some unusual bugs and had performance issues. I had been meaning to switch to an Entity-Component System at some point, and I decided now was the time to do it. The system I’ve implemented isn’t perfect (software never is), but I’m finding the game is running a lot better and the unusual bugs have disappeared, so I think the switch has paid off.

Posted by Nigel Robb

06 Oct 2015

In September I was able to attend two conferences, to learn more about relevant research and also to present our work so far.

The first conference was organised by the Society for the study for behavioural phenotypes (SSBP). The purpose of the SSBP is to study the learning and behavioural problems of individuals with genetic disorders, so the TASTER project fitted in very well. I presented a poster on our progress so far, and was able to show some encouraging data from our playtests.

The second conference was on ‘Virtual worlds and games for serious applications (VS-Games).’ This was more focused on serious games, that is, games designed for a purpose other than just entertainment. This time I was able to give a short oral presentation. Since the focus of this conference was different, I spent more time talking about the design and development process I’ve been using. A really important part of this process has been the involvement of children with PWS throughout development, and this involvement is on several levels. Obviously, children have informed on the design of the game, both by telling us directly what their preferences are, and through behavioural and physiological measures of how engaged they are with the prototypes. But in a more abstract sense, children are involved in virtue of the fact that our decision to make a game that trains cognitive flexibility is based on scientific research that has linked a deficit in this area (in children with PWS) to temper outbursts.

Both conferences were really informative, with a great range of interesting research on display, and I learned a lot by attending them.

Posted by Nigel Robb

10 Jul 2015

The current version of TASTER has been set up to trial different control systems, so that I can find out which system children find easiest to use.

The first new control system uses a virtual joystick. Use your finger or thumb to move the joystick in any direction, and your character will move in the same direction:

The second new control system uses two buttons drawn on the screen. Your character moves forward continuously with this control system; use the buttons to steer them to the left or right:

The original controls are still there too: simply touch the screen at the location you want the character to move to.

The current version of the game will automatically switch between these control systems at specific times and in a specific order.

Posted by Nigel Robb

30 Jun 2015

Recently, I’ve been looking into a variety of ways that we can collect data about a person while they are playing a video game. Of course, the idea of saving player data has been around (almost) as long as video games themselves – Space Invaders (1978) was perhaps the first major game that saved a list of high scores, and modern games save an enormous amount of data about players.

Because TASTER is a cognitive training game, we’re interested in data that can tell us how engaged and immersed players are as they play it. This is because research has suggested that by increasing engagement and immersion, we can increase the effect of the training. At the moment, we’re planning to record things like heart rate and video of players’ facial expressions as they play the game.

This data will be extremely useful during the research and development phase, as it will help us refine the game and give an early indication of how effective it might be in terms of cognitive training. But both these techniques aren’t very practical. This is either because of the equipment required (e.g. heart monitors and a separate video camera) or, if we use the camera built into the tablet, there are issues with sending and storing large video files.

So I’m continually on the lookout for other ways to find out about players’ emotions during gameplay. One interesting possibility is explored in this paper, which demonstrates how analysis of the touch gestures people make as they play a video game can be used to determine their emotional state.

The researchers had participants play a game (a version of Fruit Ninja) on a touchscreen device, while recording things like pressure and stroke length as they touched the screen. Players also reported their emotional state at various points during gameplay. The researchers were then able to use machine learning algorithms to distinguish between four emotional states: excited, relaxed, frustrated and bored. This approach is promising because it requires no special equipment (like a heart monitor) to be paired with the game, but also because analysing the gestures does not require a large amount of memory or processor power, which makes it easy to implement on mobile devices.

Posted by Nigel Robb

29 May 2015

The development of TASTER is continuing, and more play tests will be conducted in the coming months.

In order to get a clear indicator of how different game features can optimise conditions for learning transfer, we need to compare versions of the game which differ in one particular feature, with all other aspects of the versions exactly the same. This way, if players show behavioural and physiological states that we know suggest a higher level of engagement and arousal when playing one version of the game, we can assume that we have identified the right way to implement the variable feature. At the moment, I’m working on the control system. This is because I can quite radically alter the gameplay experience by simply altering the way in which the player controls their character. In addition, the control system was one feature that I identified needed improvement from the first play testing session.

So the next time I test the game, the play testers will have to adapt to several different control systems, using buttons, gestures, and maybe even a virtual joystick. At the moment, I have three different systems implemented, but I need to do some more work to make the transitions between them clear and intuitive for the players.

I’ve also been doing some work to develop a system for automatically collecting player data from the game. This way, I can gather much more information, at a much greater level of detail, than previously, all sent automatically to a secure server as the children are playing the game. (Don’t worry though, I won’t be gathering any data that could be used to identify the players by a third party, and everything will be transmitted using a secure connection.)

Posted by Nigel Robb

08 May 2015

The aim of the TASTER game is to improve the task switching ability of the children who play it. This is because a deficit in task switching in individuals with Prader-Willi syndrome has been linked to temper outbursts associated with changes to plans or routines.

Task switching – also sometimes called ‘shifting’ – is an executive function. Executive functions are general control processes that regulate human cognition; for example, when we resist the urge to eat a lot of cake, our executive functioning is involved.

There have been several models of executive functions proposed, but the most widely-accepted identifies three such functions:

  • Shifting: allows us to move flexibly from one mental set or task to another.
  • Inhibition: allows us to override dominant responses or impulses.
  • Updating: allows us to constantly add/delete working memory contents.

It is important to note that, according to this model, the three functions both share a common core (i.e. they involve a common underlying ability) but also show some diversity (i.e. there are some extra abilities specific to some executive functions).

In recent years, a number of studies have suggested that playing action video games can lead to improved executive functioning. This research is not without critics, but ongoing work will hopefully address some of these criticisms.

Meanwhile, I’ve found it extremely useful to look at typical action video games and analyse the features they offer which seem most likely to be responsible for this improvement in executive functioning. In other words, what exactly is it about these games that might give people who play them superior executive functioning?

I’ve then tried to include some of these features in TASTER. One way to think of this is that I’m trying to extract from the action video games the features that improve executive functioning, but leave behind the features that make them unsuitable for children (both in terms of mature content and difficulty). In addition, I’d like to try and concentrate the former features, to make TASTER a really intensive executive function workout.

Posted by Nigel Robb

16 Apr 2015

Our first prototype game is currently being play tested, and we have some encouraging initial feedback:

Children found the prototype enjoyable, and showed good levels of comprehension of the overall gameplay. Also, we found that the children had a good level of understanding of the specific switching tasks within the game: when the target indicating which creature they should collect changed, children were generally able to make the switch to the new target easily.

Parent’s reports of children’s behaviour when playing the game were also positive: children exhibited behaviour which was previously associated with high levels of enjoyment (e.g. talking to themselves and others, smiling, making non-speech noises). In general, children seemed motivated to play the game and get a higher score. We did have one report that the game was a little frustrating, although this frustration eased as the child came to understand the gameplay better.

Overall, these initial results show that players achieve a high level of satisfaction from the game, and find the interface and gameplay easy to understand. This is enough to confirm that we’re at least on the right track with this prototype, so the best course of action seems to be to develop this game further.

To help with this development, we also got some great suggestions about how to improve the game, including having more variety in the gameplay, better controls and more backstory and character development to help players engage with the main character.

Posted by Nigel Robb

23 Mar 2015

Our first prototype is now ready for play testing.

The children who took part in the design of the game expressed preferences for games in which they controlled an animated character, and games in which they had to collect items. So the first game I’ve developed incorporates these two features.

The game presents the player with a screen full of creatures. Here’s what they look like:

You’ll notice that there are two distinguishing features: each creature has a colour and a shape. This is the key to the task switching in the game – sometimes the player has to collect creatures based on their colour (i.e. ignore the red and collect the blue), while at other times they have to focus on the shape (i.e. ignore the cuboids and collect the pyramids). So the game forces the player to constantly switch how they conceptualise the creatures.

On top of that, every so often a rock appears and rolls towards the player’s character. When this happens, the player has to stop thinking about collecting creatures and run away, because if the rock hits them they lose points.

The game adapts its difficulty depending on how well the player is doing. Getting the difficulty just right is one of the hardest parts of game development, so hopefully the play testing will help me to tweak these settings.

You can play the game in a web browser at this link.

You can also download it from Google Play.

Posted by Nigel Robb

06 Mar 2015

Even though there are still some children completing the game evaluations, the iterative nature of my development process means that I can begin working on a first prototype game, as future design changes can be incorporated at a later stage.

So a first prototype game is currently in progress. The initial feedback from the evaluations showed that children enjoyed a variety of gameplay features. One of these was collecting items (like coins or LEGO pieces). I’ve decided to focus on this initially, as it was extremely obvious how to incorporate task switching into this kind of gameplay: we start off with a several groups of different objects, and switch which groups the player has to collect.

So I’m currently working on a top-down collecting game. As if changing the target collectibles wasn’t enough, I’ve also implemented two control systems, which will randomly switch during gameplay, and I’ve added obstacles which randomly appear and block the player’s current path.

I haven’t created original graphics yet, so I can’t really post any screenshots at the moment, but the game is playable, with most of the features implemented. I expect to get the assets started over the weekend, so look out for some screenshots on this blog early next week.

Posted by Nigel Robb

13 Feb 2015

I’ve chosen to develop the TASTER game using HTML5. HTML5 includes a new canvas element, which is a container for graphics and is perfect for games. I’ve chosen HTML5 for a few reasons:

  1. HTML5 games are actually programmed in JavaScript, which is the programming langauge I have most experience with (it’s also my favourite).
  2. Since webpages are also made from HTML5 and JavaScript, an HTML5 game can easily be hosted as a web app. This is great, because it means that people can play the game immediately in their web browser, without having to download any software.
  3. A variety of platforms exist (e.g. CocoonJS) which can deploy HTML5 applications on mobile devices, meaning that an HTML5 game can easily be converted into an almost native application for iOS or Android.

Currently, I’m developing the game using the Phaser framework. A framework provides generic functions that will be used over and over again. This is particularly useful in game development, because most games share a common structure. Almost every game involves the following:

  1. Drawing animated graphics on screen.
  2. Playing music and sound effects.
  3. Getting input from the player.
  4. Continually updating the state of the game world (in what’s known as a game loop).

So rather than every game developer having to start from scratch by programming these functions, why not make use of tried and tested frameworks that already do these things? This isn’t cheating; it’s good software engineering practice. Phaser, for example, has a team of contributors who are continually developing and testing these core functions, leaving game developers like me free to concentrate on what makes my own game unique: the graphics, sounds, gameplay, characters and so on; in a word, the design of the game. Since the TASTER project involves adapting the design of the game to suit the very specific needs of our players, this freedom to concentrate almost entirely on design is extremely important.

Posted by Nigel Robb

30 Jan 2015

In another post, I discussed the human-centred design process being used in the TASTER project. The idea is simple: we use the preferences and needs of the people who’ll be playing our game to dictate what the game will actually be like. As part of this process, we’ll have play testing sessions in which kids with PWS try out a prototype of the game. Now it’s highly unlikely that every kid will absolutely love the first prototype I produce. In a sense, I expect the prototypes to (partially) fail. Actually, I want them to fail (again, only partially!), because that’s the quickest way to learn what I need to change in the next phase of development.

What I’m doing, then, is accepting that design changes will occur even after I’ve started to program the game. And this is what makes my approach to software development agile.

Agile software development refers to a group of methodologies that share some common features. Primarily, agile methods aim to produce working software quickly (like the prototypes I mentioned above), to maximise customer collaboration, and to embrace changes to the design of the software, even after development is underway.

I don’t subscribe to one particular style of agile development, but I tend to use quite a few techniques from the agile methodology known as Extreme Programming. These are:

  1. Simple, continuous design. I think of myself as designing right through the development process. Even at the final stages, I’m prepared to make changes to the design of the game.
  2. Test-driven development (TDD). A computer program is usually made up of a large number of small, self-contained modules or units. For each of these units, you can write a test (called a unit test) to check that that module works. TDD involves writing these tests first, before you’ve written the module being tested. Initially, the test will obviously fail (because the module being tested doesn’t exist). The programmer’s job is then to write just enough code to make the test pass.
  3. Continuous integration. In large software companies, this can be quite a complex process, but with a one-person team, it’s really simple. For me, continuous integration just means that every time I add something new, I build the program and check that it still works.
  4. Regular, small releases. Rather than spend a very long time producing a feature-rich program (and then possibly finding out that your customers don’t like it), it’s better to release a feature-lean program earlier. Again, this is about involving the users of your software in the development. The best way to find out what’s wrong with your game is to release it and have the players tell you.

I’ve heard some software developers say that it’s difficult to integrate the design process with the development process in the way I’m describing. Personally, I disagree. I think that it’s difficult to integrate designers and developers. But since I’m both the sole designer and sole developer on the TASTER project, this obviously isn’t an issue.

Posted by Nigel Robb

21 Jan 2015

When thinking about gameplay design, one important issue to consider is how difficult the game is. For the TASTER project, this is particularly important, for two reasons:

  1. In order to maximise the training our game provides, players must be highly motivated to do the training (i.e. play the game). And the difficulty level of a game is a factor in whether or not people are motivated to play it. For example, I haven’t spent much time playing either Geometry Dash or LEGO Juniors Quest, the former because it’s too difficult, and the latter because it’s too easy.
  2. Some research suggests that computerised cognitive training works best when the difficulty of the training is adapted to suit the individual requirements of the person doing the training. For example, this article by Torkel Klingberg refers to some studies on working memory training that found specific effects in adaptive, as opposed to non-adaptive training.

The problem for the game designer, then, is to produce a game that is exactly as difficult as it needs to be to challenge the player. This means that the difficulty of the game needs to vary as the game is played, with the difficulty level being set by the player’s skill level.

This can be achieved by programming a system that generates some features of the gameplay on the fly - an artificial intelligence that controls the gameplay. This is known as procedural generation.

Fortunately, I have some experience with this, having created a level generator called UrbGen. While I won’t be using these kinds of 3D environments in our task-switching game, the idea - that some feature of the game can be generated during the game by a computer program - is the same.

Posted by Nigel Robb

09 Jan 2015

While the design of our game is still in the very early stages, one thing we’re sure of is that the game must feature a high level of task switching. To maximise the effect of the training the game offers, we’ll try to have several levels of task switching. For example, in addition to having some event in the gameplay that involves a task switch, we might also have a change in the control system of the game.

Because the game will most likely run on touchscreen devices, this has led me to think about different control systems for touchscreen gaming.

I’ve never really liked it when touchscreen games try to emulate a traditional game controller by drawing it on the screen. I’ve never played a game with a virtual directional pad that I felt worked well. One of the games I selected to have children with PWS evaluate has a virtual D-pad: Gravity Duck. I found it straightforward enough to use (although still not ideal). But I’ve observed some young children play the game before, and they all had problems controlling the character. (This might be partly due to the disorientating change in gravity that happens in the game - another level of task switching, incidentally).

As this article by game developer Tim Rogers puts it, drawing a virtual controller on the screen often comes across as an admission that touchscreen gaming is somehow inferior: “[Sigh.] It sure would be cool if we were making a game with buttons.”

One of the great things about mobile devices is the multitude of ways you can interact with them: tapping, pressing, swiping, pinching, shaking / moving the device. And if you’ve ever watched a very young child play with a tablet, you’ll know just how intuitive these gestures can be.

Our human-centred design process will confirm or deny my suspicions about virtual D-pads. In the meantime, I’ll try to come up with as many different ways to interact with a touchscreen device as I can.

Posted by Nigel Robb

23 Dec 2014

Designing a great game is a difficult process. But when the game is targeted at players with very unique needs, it’s even harder. The best way to overcome this problem is to treat the design as an iterative process and to involve the end-users throughout.

For that reason, we’re currently working with a group of children with PWS. We’re getting them to play a carefully chosen selection of games, and to provide feedback about their preferences.

We’ll be looking out for a range of information, not just about the kinds of games they enjoy, but also which games they understand best, which platform they prefer to play games on, and what kinds of controls they find easiest to use.

This is important because for any training program to work, people need to be highly motivated to engage in it. In other words, the more enjoyable our game is to play, the more children will play it, and the more effective the training it offers will be.

Posted by Nigel Robb

22 Dec 2014

Over the next 12 months, researchers at Queen’s University Belfast will be developing a video game to help children with Prader-Willi Syndrome improve their task switching abilities. In turn, we hope that this will help to reduce the temper tantrums that often accompany a deficit in task swtiching in PWS populations.

Put simply, we think that by training the cognitive ability to switch between multiple tasks, we can help children with PWS cope better with unexpected changes to plans or routines. And we think that the best way to make cognitive training effective is to incorporate it in a really great game.

This blog will be primarily a development blog, where I document progress on the game as I create it. I’m the sole developer on the project, responsible for, not just the programming, but the art, animation and music too. So there will be something for everyone here, from character sketches and game design ideas to code snippets and technical issues.

Posted by Nigel Robb