Module: AG0982A - Creative Research

This blog documents my 3rd year research project at Abertay University. The focus of my research is on video game progression, tutorial design, and how to teach the player. My vision statement could be stated as such:

A game often needs to gradually introduce its mechanics and skills to the player. This needs to be done at such a pace that the player is neither anxious nor bored, and needs to be clear without sacrificing challenge. How can this balance be achieved? To investigate this, I've created a simple puzzle game, and released it to a sample of players. I can use data from their feedback to improve my game.

This issue came to my interest when I noticed that many games do a superb job of gradually teaching a player how to master a complicated system (such as Portal), while many other - often more complicated - games are lacking in comfortable and effective tutorship (such as Crusader Kings II), forcing players to resort to online wiki reading, and YouTube guides.

Saturday 27 February 2016

Designing a Puzzle Game

To continue investigating how to design progression, difficulty, and tutorialship into a video game, I've decided to take my creative research into practice; I'm going to design and program a game, then send it out to testers, where back-end scripts can gather some data. I can use this data to look at areas such as flow, interest curves, and learning curves.

Creating a Game
In any case, creating a game isn't easy. But I've created a few small prototypes over the last few years, and I think I'm capable of quickly designing a game that's fun, simple, and ideal for my research. Note that, rather than simply designing a fun game and then programming it, my actual area of research is using this game to learn more about difficulty progression.

What kind of game should I make? Whatever I make, it needs to be;
- Simple, and easy to build (time is limited).
- Easy to create new levels or content with. Making new levels will be my primary way of improving the game as I gather data. I'll need to look at how hard each level is, and what systems it introduces.
- Easy to extend. The game may require new features.

Given these criteria, a Puzzle game seems ideal. Puzzle games already heavily incorporate the principles of difficulty progression. They represent very logical, definite examples of problem solving. In The Art of Game Design, Jesse Schell defines puzzles as a game where the objective is to find the dominant strategy, whereas in most games a dominant strategy should be avoided. For this reason, puzzle games generally have a one-time replay value, since once the solution is known, the puzzle is no longer fun.

And, of course, Portal, mentioned in the previous post, is a great example of a puzzle game.

Puzzle Game Design
Puzzle games are abstract, and often involve mechanics that depend on problem solving, hidden information, and sequences. Quiet often, they can be (and are) solved by applied mathematics.

After doing some sketches and brainstorming, I came to a concept where overlapping circles - with moving 'slices' on the overlap areas - can be rotated, in order to move the slices to the correct location.



The principle is quite similar to a Rubik's cube; it's a self-influencing geometry problem. Solving the puzzle is difficult because trying to move one slice often moves other slices. The puzzles aren't always automatically fun; they need to be designed to be fun. I need to create the levels manually. But it seems to be a pretty easy process.

Programming and Building
I used Unity to create the game. I'm very familiar with Unity, and with programming in C#. I hoped that creating this game would be quite easy; it features simple, easily defined mechanics. However, writing the scripts to handle the puzzle pieces and the game's logic actually proved to be pretty difficult.

The first time I scripted everything, I was met with dozens and dozens of errors - I'd solve one and face another. It started to become clear that a lot of these errors were down to script-execution. I was attempting to keep my game's programming neat and concise by keeping everything modular; puzzle pieces were their own classes, they inherited from a parent class, etc. I thought this was good practice, but it seems I've misunderstood how to properly use Object Oriented Programming.

In the end, I had to overhaul everything twice, and the endeavor took me more than a week of non-stop tinkering. I'm an aspiring designer, but I also love to code and want to get better at it. It's becoming pretty clear that I need to read some of the literature on the issues surrounding manageable code. Code Complete seems like a good place to start.

But, finally, I got the game to work. My final architecture looked something like this;



There's probably a name for this kind of design pattern; I've seen it in Civilization V's map generation script. Anyway, in the end, it wasn't very Object Oriented, and probably terribly inefficient, but it's neat and it works.



So, with this game, I'm ready to start building levels, setting up back-end scripts to gather data, and sending it out to test players.









2 comments:

  1. Excellent article. Very interesting to read. I really love to read such a nice article. Thanks! keep rocking. Flow water fountain game

    ReplyDelete
  2. Thanks for a very interesting blog. What else may I get that kind of info written in such a perfect approach? I’ve a undertaking that I am simply now operating on, and I have been at the look out for such info. chess cheat

    ReplyDelete