PhD Log 25/11/2016

Concentration on the game continues for the next few days before I return to the thesis. I had a meeting with a subject matter expert (education and physical education), which was really useful – got some good directions to go in terms of theory, etc. and she also gave me the confidence that I am on the right track.

In terms of game development, I continue to concentrate on what is probably the key game mechanic: the gathering of clues and making deductions, which is really a game dynamic because it dictates most of the gameplay and further builds the aesthetics of challenge and discovery. I have now completed the basic mechanics of the deductions user interface – gathered clues and red herrings relevant to each question are displayed and these can be dragged into deduction slots; when a clue is dragged into a deduction slot it disappears from its clue slot; if when all the deduction slots for a question are filled the deduction has not been solved, the player can drag the clue out of the deduction slot, release the mouse button, and the clue will be placed back in a clue slot. The image below shows the player in the middle of solving a question:


The tutorials on drag and drop from Unreal / Epic Games were very useful as a starting point, but there needed to be customization and refactoring, and a lot of additional development. The refactoring has really cut down the amount of code and I can see there are ways to really slim it down further. One major change from the tutorials was to create an interface to apply to all objects containing clue information. All the objects are gathered as they are and later, when they need to be interrogated, the interface is used to ask for the clue data (currently just an image and the clue description). This means that any object in the game can become a clue – I cast the generic object to a clue as required; I store in the underlying data structures as the generic object.

The next step is to give feedback on when a deduction has been made, i.e. the correct clues have been dropped into all of the deduction slots. I also want to have a cascading mechanic whereby only the questions that need to be answered now are enabled and / or visible; some questions will be locked until a prerequisite question has been answered. In addition, it may not have been possible to discover clues for a question yet (it may be in a future room) and so questions should be locked until all the clues are available.

PhD Log 22/11/2016

Busy, busy, busy. I’ve been working every spare hour the past few days on getting the important deduction interface working. It’s getting quite close now to a first fully-working prototype (of that deduction interface, not the full game!). At that point, I can start thinking more about game content, the lesson plans, in effect.


As you can see from the image above, a number of deductions are to be made in the level. Right now, I envisage each deduction requiring 2 to 4 clues to solve it. In the top row of clues will be the clues that solve the question, plus a small number of red herrings, e.g. if 3 clues are required, I might include 2 red herrings. The idea here is to acknowledge who will be playing (not hardcore game players, for the most part) and how to keep them in the zone between frustration and boredom (in the flow channel – based on Csíkszentmihályi‘s theory of flow). If there were too many permutations, e.g. 3 deduction slots to be filled from 10 clues, then it might take too long to solve the deduction if the player is reduced to guessing. On the other hand, if there were 3 deductions slots, but only 4 clues to choose from, then a very quick trial and error process would solve the deduction. Right now, I would tend towards about 50% extra “red herring” clues, but initial play testing will help determine the best ratio (even before a pilot study designed to test transfer of learning, etc.). Red herrings could be clues that are relevant to other deductions, or clues that are not applied to any deductions.

Right now, the player can click on a question to solve (i.e. to make a deduction). This will make visible 2 to 4 deduction slots in the lower row. The player can drag clues from the upper row (clue slots) into the deduction slots. The player can click through the questions and the clues that were dragged into the deduction slots will still be there when the player clicks on a question again. Currently the clue slots don’t change when you click on a question – however, I have an underlying data structure that links clues and red herrings to deductions to be made and a bit of scripting will make that work too. The next step after that will be to give feedback to the player when a correct clue is in a deduction slot (e.g. green border around the image) and then to let the player know when a clue has been solved, and perhaps what has been unlocked as a result. A final step will be to apply some stylish graphics.

PhD Log 17/11/2016

The pace is definitely picking up now. I have a bit more free time away from teaching and other duties as the semester draws to a close (though I must correct 30 game essays and a number of game group projects, nearly 40 Spring framework assignments and a number of group Spring web / database projects by early January!).

Today I made some progress on the clues / deductions drag and drop user interface. You can now walk around and right-click on objects and those that are clues will add an image to a free clue slot in the UI. Right now I have a maximum of 10 clue slots – maybe I ensure that some deductions are made and clues cleared before moving on to the next section and 10 will be enough. These clues can now be dragged around within the clue slots, dropped into a free slot or swapped with an existing clue image. This might be useful if the player wants to group what he/she thinks might be related clues. The solution involves scripting the drag and drop behaviour of the clue slots in the UI, while maintaining a parallel array of clues; all very old fashioned programming / scripting in some parts. Here is what I have so far:


It’s a bit rough yet, but with some prettifying it will look just fine. In the background, I have scripted the beginnings of the deduction data structure and the management of it. I have decided that in each level, I will create an array of object references (i.e. reference the actual 3D object that was dropped into the level, which will have embedded clue metadata – clue text, clue image, etc.). This is a 2D structure with an array of deductions, each of which has an array of associated clue object references.

To allow for flexibility as to what a clue object is, I created a ClueInterface, which each type of interactive clue object will implement (it simply has a get method that returns clue text and clue image). This means that my base interactive object, and by extension any more specific objects that inherit from it (e.g. newspaper articles, notes, etc.), as well as any other objects like non-player characters or anything else, can be a clue – it just implements the interface and the get method, returning clue text and clue image property values. This avoids the bad cast-fail-cast pattern because you never need to cast to a specific type of object, you just cast to the generic one-size-fits-all ClueInterface type.

Next step is the drag and drop to the deduction slots below, plus being able to select which deduction you are working on.


PhD Log 16/11/2016

General musing

One of the most crucial phases in a thesis is arguably settling on a structure and the chapters within that structure. Put simply, it’s the stage when you know what the hell you are doing. I seem to be at that stage now, meaning that there is a marriage now between project plan and thesis, and thus more focus. And a focal point: getting done in 18 months.

I spent so long settling on a topic … 2.5 years, to be precise: an initial 6 months settling into the PhD, then 2 years working towards a thesis on how publicly-available (released into the wild) cultural heritage metadata was being used in a myriad of ways from the analytical to the artistic. I was going to build a case study around how the Tate Britain metadata had been used. I had the Serious Leisure theoretic framework ready to roll by way of methodological development. The topic is actually a really good, viable one for a PhD, and if anyone ever wants to pursue it, I’ll gladly hand over what I have. Maybe strike that … let me get my PhD finished and then I’ll supervise whoever wants to do it 🙂

The bottom line was that my heart just wasn’t in that topic and I feel I would have drifted for several years before maybe giving up. Sometimes the best course of action is to go back to square zero and start again – be dispassionate about it by answering one question: will whatever I do get me to the end of the PhD faster, even if it means starting all over again?

Now I have confidence in being done in 18 months (but I won’t panic if it takes 6 months longer than that).

Work done since the last post?

Not much that’s functioning in the game – my next focus is on getting a clues / deductions interface working. I think once I have that interface working that I’ll be ready to implement a story containing little lesson plans, e.g. talk to an athlete, look around his/her home as a little case study in choices and their consequences – oh, there’s a newspaper with the guy in the headline winning a gold medal… oh, there another one with the guy in the headline being called a drug cheat… oh, there’s a leaflet about a kids/drugs outreach programme… deduction: successful guy gets caught and is trying to make amends (I’ll actually have more fine-grained clues and deductions than that). Now a line of conversation opens up about the consequences of being caught, or ways that amends can be made, what it’s like trying to make ends meet while banned, etc.

There isn’t much choice in terms of Unreal Engine 4 tutorials on the subject. The main one, which is a series of 3 recorded live streams by an Epic Games employee, are quite detailed and easy to follow, but what is being developed is a rather more complicated inventory systems with two floating widgets, with icons being dragged and dropped between them. What I need is there, but in the midst of dragging and dropping entire widgets, which make s it more difficult to pick out what is relevant. What I have right now merely does the following: displays available clues slots and deduction slots to drag them into; you can drag a clue image over a deduction slot, but it won’t drop in there yet. Very rough and not dynamic, but I’m only half way through the tutorials. I’ll need to add a lot more to the GUI, like clue descriptions, deduction text, make it all dynamic based on what is discovered in the game, etc. The following image doesn’t say much:


On the writing side, did a bit more on serious games, MDA framework. Next step is to try and complete the Lit Review (at least the first full draft of it). This will include some fundamentals on education / pedagogy – the kind of stuff that is foundational to any thesis featuring education of some kind; also some foundational stuff on games and game design. That’ll lay the groundwork for when I get more specific in later chapters.

PhD Log 03/11/2016

Over the past 4 weeks I’ve worked on the design of the game and written maybe 1,500 words towards the thesis.

With regard to the game design, I have made a fairly big shift away from first-person perspective as can be seen on this previous post. I spent some time playing games, waiting for inspiration to hit me. I’ve been hoping to achieve a detective feel to the game. I experimented with third-person, over the shoulder perspective, but was never satisfied with the results. Then I played Agatha Christie – The ABC Murders and I knew the perspective had to be from a spectator / fixed rotating camera point of view. Each room will have a camera set up which constantly looks at the player character. The mouse is used to point and click at a destination (click on the floor and the protagonist walks there) and to point and right-click on objects to view / interact with. I also threw out the dialogue plugin I was using – it did not seem to be supported any more by the developer and I did not have source code to allow me to continue upgrading Unreal Engine. I had spent many hours integrating that plugin into my project, but I don’t regret switching to a new dialogue plugin which is future proofed as I have access to all code / components. Below is a screenshot showing the new point of view.


Note the speech bubble above the non-player character, which is a nice little touch that I coded. Also, when the mouse hovers over an object that can be examined, a magnifying glass icon is superimposed, with a similar icon for articles / notes. These suggest affordances that I will document briefly in the thesis. The dialogue has a new look too:20161103b

That smiley face will be replaced by a headshot of the non-player character. The headshot will be particularly useful when my protagonist is talking on the phone to someone.

Another addition is obviously the protagonist 3D model. If you get a close look at him, you’ll see he is at least 50 years old and looks like he’s been around the block a bit, maybe reported on a war or two.

In terms of game design and development, I need to develop some kind of clues and deduction mechanism. The Agatha Christie and Sherlock Holmes (Crime and Punishments) games have good solutions that I can draw inspiration from (there is a newer Sherlock Holmes game, but I can’t justify forking out €45 for it). I want my protagonist to be able to examine objects, read notes, etc. and then allow the player to combine these clues together to make deductions – some clues will be red herrings and won’t combine with other clues. When a deduction is made, some action will be unlocked, such as a line of questioning through dialogue. There is a bit of GUI work to do in the game to allow the player to drag and drop, combining clues, but it’s very doable.

Once I test that out in the one scene I have, it will be time to begin the implementation of the first fully functioning prototype, with more scenes and characters, for initial user testing.

I need to write up all of these design decisions to get some word count into my thesis, though.