Royal Game of Ur!

Royal Game of Ur!


Hail, mortals!

Just a very quick blog here to explain the Royal Game of Ur, and some possible iterations of it. Because apparently most of us aren't including enough content from Critical Games Studies in our blogs.

The Royal Game of Ur originates from the ancient era of th Middle East, with the earliest boards discovered in Iraq, and being dated before 2600 BC. This game involves an oddly shaped board, seven counters per player, and a number of dice. The game is designed for two players, and is played using four four-sided dice (4D4), or four-sided throwing sticks. These dice or sticks operate on a binary system; so two of the four sides are marked, and each of these marks counts as one when the die lands on it. Thus, the maximum number of moves is four, and the lowest number of moves is zero.

This is how the game plays (by one set of rules; the true rules of the ancient Egypt version are unknown):

The first player (decided by highest roll) rolls his dice and can move that number of spaces this turn. The start and end spaces of the board are on either side of the narrow "bridge" near the centre. Each players starts and ends his pieces on his own side of the board, but must move up the middle of the board to get to the end spaces from the starting spaces. In this centre of the board, passing or landing on an enemy piece will destroy it, returning it to it's owner's control, where they have to start the piece again from the start. The first player to get all of his pieces through the board wins. The Rosetta squares you can see every four spaces on the board are special squares; these give the piece immunity to attack, and allows the player another roll of the dice for another move on his turn.

The game has evolved over the millennia, and a modified version involving only five pieces per player, and where the end of the board in "unravelled", making the game faster and more exciting by extending the area of combat.

That's all for now, mortals, I may update this later when I have a little more time to research.

For now, Hail the Emperor, and never, NEVER download Babylon onto your computer.

A Very Brief Set of Notes

A Very Brief Set of Notes

Hey there, mortals, how go things?

So, I just wanted to make a quick blog, partly to get some notes about the week's reading from Rob, but mostly to kill time while I wait for my Steam sale purchases to download.

First of all is Space of Possibility and Pacing in Casual Game Design by Marcos Venturelli. I wonder if this link will work?

https://learn.ucs.ac.uk/bbcswebdav/pid-195672-dt-content-rid-353466_1/courses/IMDCGD110-12YRD/Week%20By%20Week%20Module%20Readings/Week%20By%20Week%20Readings%20Readings%20for%20week%207%20Space%20of%20Possibility%20and%20Pacing%20in%20Casual%20Game%20Design_A%20PopCap%20Case%20Study/Space%20of%20Possilbility%20and%20Pacing%20in%20Casual%20Game%20Design%20_%20A%20Popcamp%20Case%20Study.pdf


Venturelli first defines a casual game as a game which you can "pick up and play", which can be enjoyed in small bursts, and can be put down with little to no penalty. He also mentions that the complexity of the game is less important than how the complexity is presented to (or hidden from) the player, as well as noting their general family-friendliness and accessibility.

Next, he defines Pacing as the overall rhythm of the game, the relative speed at which different parts of the system are introduced. For example, how often one receives a new plant in Popcap's Plants Vs Zombies.

Some related concepts to pacing include Movement Impetus (the player's will or desire to move forward with the game), Threat (perceived danger overcoming real danger), Conflict (contest of powers), and Tempo (time between each significant decision made by the player, setting the intensity of play).

Next, possibility means all the possible actions and outcomes within the game system; all of the available moves in a game of Chess, for example, or position choices in Tic-Tac-Toe (Noughts and Crosses). Patterns of gameplay are created through a series of different possibilities being selected for their outcomes, which is where strategies of gameplay come from. By instinctively identifying patterns of gameplay, the player increases their overall chance of winning.

Possibilities directly affect the pacing of the game, and therefore the Player Impetus; by restricting the number of possibilities, the player has to think less, and will make choices more quickly, reducing any frustration and making the gameplay generally smoother.

However, reducing the Scope of Possibility too much leads to a game which is too easy to master, and which will consequently become boring faster; a good example is Tic-Tac-Toe; Tic-Tac-Toe has so few choices, the game became masterable by most children.

On the other hand, Chess has far more choices, an almost infinite amount of patterns and possibilities are available to each player. Of course, this does not mean that more possibilities make a game better, especially in the case of casual games; as previously stated, too much Scope of Possibility forces the player to stop and think, which takes away their momentum, and therefore reduces their Player Impetus.

The solution to levels of possibility is to take the problem from the "Lower Arch of Pacing" to the "Upper Arch of Pacing", or to take the learning curve and curve of the Scope of Possibility from a single or a few levels to the majority of the overall game. Again, Plants Vs Zombies is an excellent example of this; rather than having all of the Plants to play with, with all of their possibilities, the game gives them to you over the course of the entire game, so that you have time to learn about them before being given another one.

I think that's all I'll write about for now. I really like the way this article is written, with all of the terms (such as "Scope of Possibility") making a great deal of sense to me. I might have even enjoyed reading it if it didn't take me so long, and I wasn't so damnably tired at the time. Looking back now, it all makes good sense, and can be fairly easily applied from a design standpoint.

Praise be to the Emperor, I'll talk at you again next week or so.

Notes on Creating Drama

Notes on Creating Drama


Hey, how's it going? Mortals.

I'm not gonna stop calling you that soon, I'm afraid; I want this to be a casual blog, and if that means insulting, then I will insult you to your face!

Well, I was gonna try and make a "funny" title about being on top of the most recently updated blogs list in the lesson on Tuesday, but I've decided that I'm probably not gonna publish this until after the lesson. Look, it's late right now, and I don't really feel like going through the long notes I took so that I can refine it down into this post, OK? I'm tired!

So, I literally just finished reading "Tools for Creating Dramatic Game Dynamics" by Marc LeBlanc. In fact, I've so only just finished reading it, I haven't actually read the last paragraphs!

Aaaaaand done!

Now, I'm really liking Marc LeBlanc from what I've seen of his work so far; he has extremely well conceptualised and refined ideas about video games, which he demonstrates beautifully in his Taxonomy of Game Pleasures. This article also shows his obvious intelligence, and thus makes for an enlightening read.

First of all, LeBlanc outlines the MDA theory of designing and playing games:

Mechanics - what is required to play the game at it's most basic form, including rules and equipment.

Dynamics - the behaviour of the game as it is played, such as popular tactics used by the players, which emerge from the mechanics.

Aesthetics - the desirable emotional reactions of the player or players.


Next, LeBlanc introduces us to the aesthetic of dramatic tension; he first defines what dramatic tension is:

"our level of emotional investment in the story's conflict; the sense of concern, apprehension, and urgency with which we await the story's outcome."

Finally, he gives us the dramatic arc as an example of how drama should build within a narrative:

Here, as you can see, the drama of the narative builds towards the climax, whereupon it suddenly  changes direction and fades away.

Now LeBlanc tells us how levels of drama are affected in games. It is important to understand that, unlike traditional narrative forms (such as movies or books), the game designer doesn't have total control over the aesthetics of the story as it plays out.

First, he splits drama into Uncertainty and Inevitability:

Uncertainty: the sense that the outcome of the conflict is still unknown.

Inevitability: the sense that the content is moving forward toward toward it's resolution.

Dramatic tension requires a combination of both of these factors; one alone is insufficient. If the game has uncertainty without inevitability, then the end seems far off and doesn't really matter. If the game has inevitability but no uncertainty, then there's no reason to be invested in the conflict, as the outcome has already been decided. It's worth noting that the narrative climax of the game occurs when the uncertainty and inevitability "intersect", and the outcome is realized by the player or players; the gameplay climax occurs just before this.

So, now that we know how to identify dramatic tension, how can we produce it in the design process? Well, dramatic tension (or at least the uncertainty part of it) is an aesthetic that emerges from dynamics that make the game feel close during the "contest" in the game. Closeness can be achieved in one of two types of dynamicss: force and illusion.

• Force - by manipulating the state of the contest itself, we can alter the level of a player's advantage or disadvantage.
• Illusion - it is possible to make the player believe the contest is closer than it really is by manipulating their perception of it.

A good way of employing these from a mechanics standpoint is through feedback systems; these take the current status of the game, works out how well each player is doing, and alters the game in some way (either through force or illusion dynamics) to make the game closer, or appear closer. For example, in a racing game, if one player is doing less well than another, the game might give the loser a speed boost to keep the game more even, and therefore less uncertain. 

Feedback systems can also be used in a number of different ways, to cause different effects. A negative feedback system will give the losing player an advantage, such as in the above example, or give the winning player a disadvantage. A positive feedback system will do the opposite, giving the winner an advantage, or the loser a disadvantage. The purpose for this is to give the game denouement, to let the players know the game is coming to an end, and this player has won; the dramatic climax where the outcome is decided is over.

So, we've covered uncertainty, but what about inevitability? Some good mechanics for increasing the sense of inevitability are "ticking clock" mechanics; these remind the players that the game won't go on forever, and that the end of the game is drawing closer and closer. A literal clock doesn't need to be invloved, as other mechanics can act just as well, if not better; the number of cards in a deck, the number of pieces left on the board, and so on. If a ticking clock is to be effective, it must be visible to the players; inevitability is entirely percieved, and to add to dramatic tension, it has to be percieved.

Once the climax has been reached, it can be argued that a game should end as soon as possible; once the outcome has been decided, the players become little more than spectators, which very quickly becomes boring. However, it is also arguable that there should be a period of denouement for the game, to let the players unwind, stop the game from ending too abruptly, and to let the winner celebrate their victory. This time should be kept fairly short, but it does need to be there. One way of doing this is a post-mortem of the game, such as a statistics screen, or an after-game discussion between the players.

Well, I'm pretty damned tired, I've learnt that I don't like Monster energy drink, and I need to catch a bus in under five hours. I think I'm done here.

Praise the Emperor.

Chance and Skill

Chance and Skill

Ah, mortals, it's been too long!

I think.

Actually, you probably didn't miss me too much; I didn't miss you at all.

Well, I'm contacting you today to tell you about the reading I performed this week. I read chapters five and six from Challenges for Game Designers by Brenda Brathwaite and Ian Schreiber, which cover the use of chance and skill in games from a design standpoint.

Chance first, if that's OK with you. I don't really care if it's OK with you, it's the order that my notes are in, and that's the order I'm going to address them in this post.

"Why is chance an important component in games, and what tools does the designer have at their disposal to deploy this element?"

(I should not that chance is not an overlly important component in games; many games have gotten on just fine without it. Chess, for example.)

In games which are based purely on skill, rather than chance, allow the stronger player to win everytime the game is played; if you're better than your opponent at Chess, you'll beat them nine times out of ten (unless you let them win, which I applaud you for doing; on the other hand, where is your Saiyan Human Pride?). While making the better player win may seem like a good idea, it isn't suitable for a long-lasting game; if someone is better than you at Chess, then the game becomes a dull sequence of defeat after defeat after defeat until you lose the game. Adding an element of chance, however, increases the interest of the game immensely.

With chance in a game, the uncertainty of the outcome is increased, and the game becomes more dramatic as a result. The game also becomes difficult or impossible to solve (Noughts and Crosses is an example of a game which has been solved; with two players who know how to solve it, the game becomes a draw every time), and has increased variety, making it more interesting to play again and again.

Chance can be mechanically implemented in one of two ways, I think; as with the dramatic tension (I'll post the blog on this tonight or tomorrow, if I remember), one can use either force or illusion:

• Force: the chance factor actively changes the state of the game, such as when dice rolls decide the number of moves a player can make.
• Illusion: doesn't directly affect the game state, but changes what the player can percieve, such as a fog of war mechanic, or being unable to see your opponent's cards.

"Why is skill an important component in games, and what tools does the designer have at their disposal to deploy this element?"

(Again, skill isn't absolutely necessary, but it is perhaps a little more important to have than chance; Chess is a better game than Snakes and Ladders.)

When a game is based purely on chance, there is actually very little user-input at all. What decisions does one make when playing Snakes and Ladders, or Roullette (without the gambling part), or any other game where the outcome is decided randomly? As a result of not affecting the outcome, the victory of such a game is less fullfilling than when one has earned their victory through skill. I feel great when I win at Chess; I feel less great when I win at chance-based games. Chance games also lack the pleasure of learning and mastering patterns found in skill games.

Implementing skill into a game is fairly easy in some cases; skill can be broken down to decision-making, meaning that all a designer has to do is give the player opportunities to make decisions. The requirements of these decisions are that the decision musn't be:

• Obvious: if every player would make the same choice every time, under every reasonable circumstance, then it shouldn't be a choice; it should happen anyway.
• Meaningless: the choice has to change something in the game state, otherwise, the choice doesn't have any meaning, or therefore need to be present.
• Blind: give players enough information to know what they're choosing and what some of the consequences might be; don't punish or reward them for not knowing any better.

That's it for now, mortals. I'll maybe post the dramatic tension notes tomorrow.

Praise the Emperor!

Notes on MDA

Notes on MDA


Can I even bother to be the rude nerd I usually am on this blog today?

YES! Greetings, mortals! A very good evening to you!

So, the other day I did a bit of reading in the form of an article written by Robin Hunicke, Marc LeBlanc, and Robert Zubek, entitled "MDA: A Formal Approach to Game Design and Game Research".

So, what does MDA stand for? Short answer: Mechanics, Dynamics, Aesthetics. I don't have a long answer.

Mechanics covers the solid rules of the game; "This can happen, this can happen, and this can happen. This cannot happen. " Mechanics are the only things game designers really have any control over in the development process.

Dynamics are the run-time behaviour of the mechanics acting on player inputs and each others' outputs. These are influenced by the mechanics and the player's input into the game.

Aesthetics are the desirable emotional reactions evoked in the player as they play the game. These are also uncontrollable directly by the designer, but are influenced by the mechanics. For example, if a game's desired emotion is fear (or a similar emotional reaction), then the aesthetic would be intended to be one of fear, through the mechanics and dynamics (a monster charging toward the player gives a great aesthetic of impending threat).

So, we know what MDA stands for, but what's it's purpose? Basically, it is an attempt to bridge the gap between the design process and the creation process of game development. Using this method, a game designer can analyse and refine the process of game creation and improve it next time; this can be done in two ways:

• analysing the end result to refine implementation.
• analyse implementation to refine the end result.

The process of designing and creation is clearly described it the format of MDA, going from Mechanics to Dynamics to Aesthetics in the same order as the designer does. After this, we can apply certain parts of a game's design, such as an aesthetic, and objectively ascertain the process by which we attain that aesthetic from a design standpoint, which can be done prespectively or retrospectively.

For example, if we use fear as an aesthetical goal, we need to find some mechanics and emergent dynamics which will result in the player feeling afraid when they play the game. A fine example of a game which does this well is "Amnesia: The Dark Descent", created by Frictional Games in 2011. So what makes Amnesia a frightening game to play? One of the most powerful things about this game is it's atmosphere. Atmosphere can be described as a dynamic, emerging from a number of mechanics working together: certain, pre-scripted events occur in the game, such as music, unsettling noises, light levels, the way the level is designed so you just can't see around that corner, come together to form this overall trait which progresses as the player does, and results in the emotional reaction of fear and apprehension.

Let's use another example from the same game; the "Gatherers" of Amnesia. The cold, hard enemies of the game, who show up every so often to terrify the player senseless, and give the main character a bad day. Now, why do they terrify the player senseless? A number of interesting dynamics are related to the appearance of the Gatherers, which are themselves comprised of a number of mechanics (or lack thereof) working together. A very good mechanics choice (in my opinion) is the player's inability to fight; you can't stop the Gatherers, it just doesn't happen, there's no way to hurt them.

Because you can't fight them, the only thing you can do is hide, and hope they don't find you. The hiding dynamic of this game is born out of the mechanics which mean the Gatherer can't see you when you're behind another object, such as when hiding in a wardrobe. Hiding in a wardrobe while you hear a monster outside completely trashing the room, desperate to peek out to see what's happening, but terrified it'll see you is an incredibly powerful aesthetic which, in my opinion, can be related back to when you were a child playing hide and seek; the person hiding, knowing the seeker is close, is thrillingly terrifying, and this is perfectly recreated in Amnesia.

So, for example, I could use this method of looking at an aesthetic and tracing it back into mechanics to build a more frightening game than Amnesia, which will evoke a more powerful or well-balanced emotional reaction from ther player. I could look at the hiding mechanic and say

"This is good, but it would also be good if you could hide in other places than wardrobes. Maybe if the player could hide under the bed in some rooms, and only see the Gatherer's feet shuffling around as it searches?"

This is the process of refinement, which can be reached by using the method of MDA.

I really liked this article; seeing the process these guys suggested and then trying it out for myself like that really feels encouraging that this is the way to make design advance the way other formats (such as hardware) advance.

That's it for now, mortals. Apologies that this was so very, very late. It was just sitting in my blog list as a draft for over a week, and I literally just noticed it and decided to pick it up. I really need to get the next post done soon.

Praise the Emperor, and a very good night to you!

Generic Weekend Title

Generic Weekend Title


Good evening, mortals.

Now, I don't know if you know this, but I'm on a course for Computer Games Design.

One of the major parts of this course is learning how to use a little-known coding program called Flash Professional. I joke, of course, you've all heard of Flash, it's used all over the damn place.

Flash, however, is hard. It is annoyingly hard, needlessly so, in my opinion. I also think that 3D modelling software is awkward, but I can understand that it's the easiest method I can think of. With Flash, however, things are just unnessecarilly difficult.

I've used a version of GameMaker before (the free version), and that was so easy; you know what the icons do and where to put them, and you're fine. Everything's very easilly laid out and labelled, so you know exactly what's going on all the time, and you can pick it up and know what you're doing within five minutes. Flash, on the other hand; I have no idea what's going on with it. The tutor (a gentleman named Chris Janes ("Hi, Chris!")) has been trying to make us understand by walking us through making a basic game with Flash, and two things stick out about those lectures:

• Why isn't any of this going in, where is he, how did he get so far ahead of me, why can't I just listen?
• I could do what's taken him an hour in Flash, in about ten minutes in GameMaker.

I understand that drag-and-drop tools such as GameMaker are more limited, but holy Hell, why does Flash need to be THIS complex?

Here's an example; I was reading a book and doing some tutorials about Flash today to try and catch up, and this is the code required to display the words "Hello World!" onto a screen (a relatively simple task, I think you'll agree):

package  {

import flash.display.*;

import flash.text.*;

public class HelloWorld extends MovieClip {

public function HelloWorld() {

// constructor code

var myText:TextField = new TextField();

myText.text = "Hello World!";

addChild(myText)

}

}

}

THAT'S JUST TO MAKE "Hello World!" APPEAR ON THE SCREEN!!! What even?

But yeah, that's been my Sunday today. Learning to do that.

Otherwise, it's been another slow weekend for work; tomorrow I have the day pretty much off; I'll get some work done then, probably more stuff toward the group project, and maybe more Flash (fun!). I will also be reading and postng notes about Rob's reading for the week.

Tonight, if I remember, I'll try to get some dialogue done for the characters I'm creating for the Introduction to Design Methods lectures. Phil Jackson, my previous personal tutor and tutor for this and the 3D modelling lectures, is leaving us. Apparently Sony has something we don't. Nah, but we're sorry to see him go. Looking forward to meeting Mike Green, our new Design Methods tutor.

Well, I think that's it for now. I know I was going to mention something else in here, but whatever, I'm doing another blog tomorrow, and I can always edit this one.

And, of course, Hail Emperor.

Formal Design Abstract Tools

Formal Design Abstract Tools


Evening, mortals.

Straight onto the primary matter today, I think; I'm tired and I have other things I want to do. I have little time for dry wit or humorous monologue that no-ones going to read.

I have just finished reading the Gamasutra article, "Formal Design Abstract Tools", which attempts to convey the fact that a comprehensive language for game design doesn't exist, and suggests ways in which one could be created, and some examples of potentially good additions.

Before I began reading, I was given a quote from the end of the article and was asked to explain it once I had finished reading.

"Games are not books, games are not movies. In those media, the tools used... are used to manipulate the viewers or readers, to make them feel or react exactly the way the director or author wants them to. I believe the challenge of computer games design is that our most important tools are the ones that empower players to make their own decisions."

The tools that Doug Church (the author of the article) mentions are the "tools" which are available to a designer, and both metaphorically and in the form of similes relates them to the tools that might be used in science or construction. For example, he says that not every tool should be used for every game, and should rather stay in the "toolbox" waiting to be needed. These tools should be identified across a wide range of games and game types. For example, one should be able to take a tool used in a Real-Time Strategy game and utilise it in a Role-Playing Game.

The tools Doug offers as examples which could be used in a video games design language are:

• Intention - "Making an implementable plan of ones own creation in response to the current situation in the game world and ones understanding of the gameplay options."
• Perceivable Consequence - "A clear reaction from the game world to the action of a player."
• Story - "A narrative thread, whether designer-driven or player-driven, that binds events together and drives the player forward toward the completion of the game."

Church explains that some of these and other such tools work well with others, while others don't. For example, Intention and Perceivable Consequence work very well together when the player knows what they want to do, and can anticipate one or more outcome of this. Say, for example, that a player is attempting to cross a pit; they attempt to jump across, taking the game's physics and their character's abilities into account. If they fall into the pit, the game is telling them that that strategy doesn't work here; the player can see why it doesn't work, and that they should try a different tactic.

However, if Consequence is used without Intention, it can have a negative effect on the player's experience. For example, if the player makes an arbitrary decision without being warned of the outcome, and the consequence is a negative one, then the player will become frustrated because they had no way of knowing that would happen.

Therefore, Perceivable Consequence is most effective when used in tandem with Intention, as this adds depth to the player's decisions, and can make them feel more integrated into the game world.

In my opinion, this article offers a very interesting point. While it seems to take game design as a science rather than an art, it also offers many insights into what can be made into good game design. It's very true that consequences without the player's intentions aren't very good design, while consequences based upon intention can improve a player's experience. Overall, this is an article worth reading, and actually makes a lot of things clear which were previously difficult for me to understand. Formulating something like game design into identifiable qualities can be a big help, though I have to wonder what kind of an impact this would have on a game when put into practise.


NOTE: I've literally JUST noticed this wasn't published; this blog was written on Thursday 1st November. My apologies.