Retro Games

New Blog post after what could be considered to be my first 'proper' lecture and possibly one of the only ones of its kind. Today I'm gonna talk about our lecture on Retro games and gameplay 'Segmentation' as well as which game that I have chosen to review as my first assessment of the year.

The Retro Games lecture was based on the article 'Rounds, Levels, and Waves : The Early Evolution of Gameplay Segmentation' by José P. Zagal, Clara Fernández-Vara and Michael Mateas and basically covered the concept that games nowadays take things for granted that were developed as a result of the existence of retro games, the key aspects of which can be covered with segmentation.

Gameplay segmentation can be basically broken down into three different types all with their own areas of a game that they cover. These segments are the following:-

• Temporal Segmentation - This covers gameplay elements relating to limiting factors, synchronising and/or co-ordinating player activity over time.

• Spacial Segmentation - Covers all aspects relating to 'virtual space', e.g levels.

• Challenge Segmentation - Self-explanatory; covers areas relating to challenges within the game.

Temporal Segmentation
There are two main aspects covered in this area which are temporal co-ordination and temporal resource.

Temporal co-ordination is about turn-taking, rounds, etc, basically it is talking about how time progresses and flows in a game. Temporal resources are about gameplay elements that are restrictive of game flow, such as time limits or time trials.

Temporal Segmentation is generally quite simple to comprehend, however, without retro game development the term wouldn't even exist - generally speaking, most board games aren't time restrictive (though they do have rounds/turns) so these had to be developed on their own when video games were made.


Spatial Segmentation
As explained, Spatial Segmentation covers the game world itself and its elements such as levels and possibly things such as checkpoints within those levels. Other than this there isn't much to say about spatial segmentation (in my opinion) - it is quite a broad topic but ultimately stems down to the way the level has been made; even the components of it aren't necessarily included (obstacles, etc) aren't included as they are a part of Challenge segmentation.

The easiest comparison to make with spatial segmentation is level structure, aesthetic design, and the type of background (static with a moving player or the player progressing along a moving path). As before, these things had to be developed in retro games - in board games the only level was the game board itself but in a video game there may well be more; hence we owe retro games for this.

Challenge Segmentation
Out of all the segments challenge is the one that I personally feel retro games have had the biggest impact on in modern game development. There are so many elements that appear in challenge segmentation that couldn't have been developed from board games - waves, bosses and bonus stages all owe the retro game thier existence.

Challenge segmentation boils down to 4 main areas: Waves, Puzzles, Bosses and Bonus Stages. All these things are parts of a level that may or may not appear but when they do they add challenge to the game which makes players strive to pass them and win. They are all quite self-explanatory so I won't bother to go in-depth about them.

In a board game you don't get bosses, waves or bonus stages - there may be puzzles though - and as a result these were developed specifically for retro games and as a result is the reason I consider them to be crucial to the development of games today.

Retro Game Review
Anyways, that's the main things that I personally got from today's lecture - more critical games vocabulary and ways to look at game development and design so now to finish up with I will briefly talk about the game that I have chosen to review for my assessment.

The game in question is Ice Climber made by Nintendo for the NES console in 1985. In essence it is a very basic platformer with a slight twist to the norm in that it is a vertical platformer as opposed to the traditional horizontal ones. At this stage I haven't looked or started reviewing it yet but basically I will be looking at it using the vocab and guidlines that I have gained from the first few weeks at university.

'Til next time - that's all folks!

This parrot is no more! It has ceased to be!

Random Blog Post Time!

Those of you in the know should realise where the title of this blog post comes from and those of you that don't should really learn as you are missing out on a very great piece of British comedy. I am of course talking about Monty Python's Flying Circus and more specifically the 'Dead Parrot' sketch but for the sake of this blog post I am going to be talking about Monty Python in genreal.


So why am I doing this blog post you may ask, well first it is something that is interesting and not completely irrelevant from design work and second we are required to do blog-posts from outside sources other than games. The inspiration behind this post comes from the fact that I was recently lucky enough to purchase the complete flying circus box set on DVD and, while I knew about the most famous of their sketches (Dead Parrot, Cheese Shop, Kamikaze Scotsmen, etc), there were plenty that I never knew about. This got me thinking about the Pythons as a whole and what inspiartions and ideas they must have had when working on the series, hence leading me to think about design and thus games design.

The Python's work is regarded as some of the most random, extravagant and nonsensical comedy ever made but also some of the most funny comedy ever made. At the time that it was being thought up I'm sure that there were certain BBC executives that thought it couldn't work, people wouldn't take to it and the series would fail - how wrong they were.

When the series first aired in 1969 it was a huge hit and the Python's style of comedy became renowned world-wide, even being know to this day as being 'Pythonesque' - yes, the style of comedy has it's own word. Now, this got me thinking about games design and how there are games that come from a similar situation as the flying circus series - I'm sure there were, are and will-be games and game series that the publishers don't think will sell or get picked up but they soon become shining gems.

There isn't much to look into on that statement, I am merely saying that I personally believe that and I guess, in some ways, it is what keeps me going in games design - some of the more radical and unlikely ideas can become best-selling works and those ideas have to come from somewhere - why not my ideas, or the ideas of anyone I know.

In essence, this blog post is doing 2 things, it is both praising the Python's for the brilliant series (seriously, if you've only seen the films go on youtube and look for Dead Parrot, Lumberjack Song, Kamikaze Scotsman, Cheese Shop, Argument Clinic, Self-Defence with Fruit, Dennis Moore and Upperclass Twit of the Year - you won't be disappointed) and showing that there is always hope for people with ideas and a vision.

'Til next time - that's all folks!

The Bibliography Task

Today's blog post isn't specifically related to games - it comes from something we learnt in one of the lectures.

So without further delay, let's begin. This week we learnt how to assemble and write a bibliography. Why you may ask would we need to learn to do that, however, it is in-fact a very crucial tool and something that not just Games Designers but in-fact everyone should take the time to learn how to do properly. Citing people's work and research when writing an essay is crucial as it shows that you actually aren't some form of super-genius who is able to do everything on their own with no outside help whatsoever and it also shows that you are deeply analysing and looking at what it is that you are writing about.

Part of making sure that this citing is done correctly is learning how to actually style a bibliography and as it turns out there is more than one way of doing such a thing and there are different ways to do it depending on what you are citing - for example, citing a book is different from citing a magazine entry. The most common way to cite (and the way in which I do) is the Havard way - this in my opinion is the clearest and easiest way to see where exactly the work is coming from, below are the ways in which Havard cites different sources.

Books
Author or Editor Surname, Initial., [Subsequent author(s) or editors] Year of publication. The full title of the book: italicised or underlined to indicate it is the title. Publisher: city of publication.

Contribution to a Book
Author Surname, Initial., [Subsequent author(s)], year of publication. The full title of the article, without inverted commas. In Editor Surname, Initial., [Subsequent editor(s),] The full title of the containing work: italicised to indicate it is the title. City of publication: Publisher. page span of the work cited.

Journal/Magazine Article
Author Surname, Initial., [Subsequent author(s)], year of publication. The full title of the article without inverted commas. The full title of the journal: italicised to indicate it is the title [volume and part if given and/or] Month, or Season, or volume/part number.


TV Programme
Episode title: Series Title. Year. [TV], Channel, Date.

So there we go... it's not that difficult, especially if you are properly using the source to it's full extent and should have full access to all the required elements to properly cite the material. As a part of a task we had to undertake I have made 6 bibliography citations, 2 for each type of written source, on games design books and articles. Below are the books that I found as proof that I looked up these various books and have cited them correctly.

Bibliography

Books

Perkins, T., 2008. Nintendo Wii Flash Game Creator's Guide Design, Develop and Share Your Games Online, New york: McGraw Hill.

Van der Spuy, R., 2009. Foundation Game Design with Flash, Berkeley (Ca.): Friends of ED.

Articles

Chun, R., 2004. Design Simple Flash Games. , Macworld, Vol. 21, Issue 4, pp 62-65.

Stevens, C., 2004. Custom-build your own flash game: dip a toe into the ocean of Flash possibilities--without getting out of your depth.(flash games). , Internet Magazine, Vol. 118, pp 72.

Contribution to a Book

Barrett, K., Harley, J., Hilmer, R., Posner, D., Snyder, G., Wu, D., 2003, Pseudo Interactive’s Cel Damage, Grossman, A., Post-mortems from Game Developer: Insights from the Developers of Unreal Tournament, Black & White, Age of Empire, and Other Top-Selling Games, San Francisco, CA, pp 41-50.

Caillois, R., 1962, The Definition of Play: The Classification of Games, Salen, K., The Game Design Reader: A Rules of Play Anthology, Cambridge (Mass.): MIT Press, pp 122-155

So there we go, this ends this blog entry. 'Til next time - that's all folks!

Paper Based Group Game

Another Blog Post Begins

Not going to be a lengthy blog post this one, just explaining stuff that I've (we've) been doing and why. Basically, now that I'm several weeks into the course the main group project is starting to pick-up and influence certain aspects of other lessons so, as a part of this, we have started iterating and looking at a paper based version of the game we are making.


The game that we are making is called Circuitry Absurdity which is going to be a flash game that helps children to understand certain aspects of the science curriculum by assembling circuits for various appliances. As a starting point I believe that this is good as our game doesn't include 'quiz' elements that have appeared in other game ideas and makes our game more unique - i don't like to just say 'it's good' but at this stage there isn't much to say...

Anyways, the paper based version of our game is slightly different to how we envision the final flash game to look but it does show us the basic concept of what we hope to create. As I mentioned in my Iteration blog post, iterating the game this early on using paper is very helpful and helps us separate the good ideas from the bad before we get too far in.

At the moment we are still very early on in development so expect more in-depth posts about the game as time goes on.

But for now, that's all folks!

Design Tools... wait, two posts in one day - yep I'm on form this weekend

Blog Post Number 5 is about to begin...

More notes about various articles and seeing what we can take from them in this blog post. This time there are two articles in question 'Space of Possibility and Pacing in Casual Game Design - A PopCap Case Study' by Marcos Venturelli and 'Formal Abstract Design Tools' by Doug Church. Both of them talk about a vocabulary for talking about the ways in which we should design and things that we think about designing, however, Venturelli focuses on the emerging 'Casual Game' market whereas Church talks about games design in general. So without further delay, here we go.


Doug Church's Article
To be perfectly honest, a lot of Doug Church's 17 page article was waffle - he went into a lot of detail explaining certain things that he didn't really need to and ultimately we can't take anything from. However, the key design tools that he mentions are very important and very interesting - these are 'Perceivable Consequence', 'Intention' and 'Story'.


Perceivable Consequence
Perceivable Consequence is the player's understanding that their actions in the real world will ultimately effect how they play the game and it's outcomes. An example of this would be in a platformer, when the player comes across a hole that they must clear they realise that they must press the jump button to clear the hole, else they will fall into it and die - in laymen's terms, perceivable consequence is realising how the game works and what dangers there are; this leads onto the next design tool 'Intention' that will be discussed shortly.


As a designer, we need to think about perceivable consequence, we need to make sure that the player knows that something they do will have an outcome of some sorts, whether it is good or bad or even, in some aspects, obvious - as a gamer you should know that falling down a hole is a bad thing but that is because the designer makes it so. An example given to me of a case where perceivable consequence isn't given is if the player has to go through a choice of 2 doors not knowing that going through the left one will instantly kill them - the player needs to know that there will be good and bad consequences for their choice but in this case there isn't. It is due to this that 'Perceivable consequence' (I'll call it Peco from now on) is a crucial design tool.


Intention
Intention is very closely linked with Peco, intention is the player planning ahead and thinking about their actions and the outcomes and therefore planning how to overcome obstacles, etc. Using the same example as before, the player knows that they will die by falling down the hole and therefore they plan to run and jump over it to avoid this outcome.


As a designer, intention is something we should think about and help to implement but ultimately it is the player that makes their own intention, we cannot affect how they plan to overcome issues - if the player wishes to repeatedly fall into the hole and die, that is their choice and their intent. As designers, what I think we do is give the player the choice to make their decisions regardless of how much they control the rest of the game - this leads to the next tool 'Story'.


Story
Story is exactly what it says on the tin, it is the narrative thread of the game. Whether this narrative thread is directed by the designer and the player is merely progressing along a pre-determined path or the player has more direct influence on the story, the story is the main thing that drives the game forward and gives then player a goal to reach.


In my opinion, all games have a story that the designer wants the player to see or achieve but it is down to the player to follow it - even in a very linear RPG such as Final Fantasy XIII where the story will unfold how the designer wants it to as you progress, the player can choose to simply die and fail in fights and therefore not proceed and see the story. Obviously this is just stupid and no one would do it but the point is the player should be able to see that they have a choice, plan accordingly and know what will happen based on those choices - as designers it is down to us to design games that allow players to do this.


Marcos Venturelli's Article
Venturelli's article is about one specific games company, PopCap, but it generally talks about all casual games and casual game developers. PopCap is a well renowned casual game developer which is naturally why they are the subject matter for finding what makes casual games and tools we can take from them. From the article there are two key tools that we can take 'Pacing' and 'Possibility'.


Pacing
Pacing is essentially how quickly or slowly the game flows and how the game is affected as a result. The best way to describe this is is to say that casual games are quick and more mainstream games are slow - there is a reason for this though however. In casual games, there is little story, little choices for the player to make and as a result to make casual games appealing they are very fast paced, making the player make quick decisions that increases the tension and thus makes them more fun. In more mainstream games this wouldn't work as well because the story and planning would be lost, defeating the purpose of making the game detailed and in-depth.


Possibility
Possibility is the number of options that are available to the player - the more options available to the player, the slower the game pace. The two basically go hand in hand and as a result in casual games there are more limited possibilities to help keep the pace up - the reason why the pace goes down otherwise is that with more possibilities there are the more the player has to think about what they are doing and ultimately slows the game down.


Pacing and Possibility
As designers I feel that it is our duty to find the right balance between the two when we make a game, this can be affected by genre and other aspects, but ultimately once we find the balance we find the type of game we want to create and then we use Church's tools to form the basis of how the player plays our game.


Anyways, that was a LOOOOOONG post so 'til next time - that's all folks!

Iterate, Iterate, Iterate and Iterate some more

Blog Post Number 4 - Might be a little shorter than previous entries, but here we go anyway.

Basically in Tuesday's lecture we learnt what it means to iterate ideas and had a go at doing it ourselves. Iterating an idea is basically where you take your idea and make one change to it to try and improve it, test that idea with independent persons and see how it pays off - if they like it and think it works then the idea is kept, if not it is discarded as useless. Regardless, this process continues until your idea is full of changes that work towards making it a better game.

The most crucial thing to remember is that when iterating is the fact that you must change only one thing! While this may seem inefficient and you may think 'Surely I can iterate quicker if I do several things at once' this is not the case, the reason why is that if you implement 2 changes at the same time and then have them tested to see how they work you can't tell which of the changes it is that is making your idea better or worse. If you change just one idea at a time you know that it is definitely that one change that is helping or hindering your idea and not a combination of two things that on their own may be both helpful and a hinderance.

Iterating is a very useful process, it helps you to develop your ideas (sometimes at the expense of 'killing your babies') and wean out the good and the bad to make your idea as good as it can possibly be. In all fairness, iterating is one of the best and safest way to think of ideas and test them before they are taken too far into development - you don't want to make half a game only to be told that one 'tiny' thing ruins it that you should've removed earlier on in the thinking process.

Anyway, with iterating in mind we iterated our 15 minute board games - we roughly did 2-3 iterations in the time we had left and from doing so I already feel that my game has been vastly improved and had aspects removed that didn't work well. At the same time, I also feel that I helped to improve others' games by telling them how well their iterations have worked - it's a shared process of design that helps us to help each other be the best that we can be. Iteration is also a very quick process and can be done in very little time, which helps get through various ideas very quickly.

Anyway, that's all for this post on my thoughts about iteration, 'til next time - that's all folks!

Paidea, Ludus, Agon, alea, Ilinx and Mimicry - words I've never used before (well, except mimicry)

Well, in today's Critical Game Analysis lecture we learnt about a lot of what makes up a game and the way that games can be defined... some involves using the words that are in the title. The question is what do these words mean and how do I personally understand them? The best way to answer this is to take examples of games I play and compare them to the words.

So without further delay, here we go!

Paidea - Play for pleasure
In the lecture today we learnt how to separate 'game' and 'play' and paidea is playing a game purely for pleasure - there is no ultimate outcome as to why you play, no goal, no end, you play simple because you want to, "mucking about" as it were.

One of the best examples of games like this is 'The Sims', unfortunately though I don't play The Sims so I have to choose another game which has posed a bit of a challenge as most of the games I play do have a purpose (such as winning). Ultimately then I have settled on a game that you are suppossed to play for an ultimate goal but I play just for the sake of it which is the Valve game Team Fortress 2.


Team Fortress 2 is a team-based, class-based first-person shooter with various game modes, such as arena or capture the flag - it is a game with an outcome. When I play it though, I ignore the game mode and simply go around killing people because I can, I don't get anything out of it and neither does my team as I haven't contributed to ultimate goal yet it is still fun to do. This is paidea, playing for pleasure.

Ludus - Playing with rules and/or an outcome
Most games that I tend to play (and find others to play) are games that have a sense of an outcome, whether its playing to watch the story and see what happens or playing to beat our opponents, etc. This is effectively a ludus game.

The example of game that I am going to use as a Ludus game is an SRPG (Strategy-Role Playing Game) made my Nippon Ichi Software called Disgaea. I won't go into the entire mouldings of the game, but it is basically a game where you are a Demon Prince named Laharl and you are trying to take control of the Netherworld to become the Overlord.

Now, this is a game where you can't play it for the sake of it, when I play it I do it either to progress through the story, defeat strong bosses, find strong weaponry and level-up to level 9999 (and no that's not a typing error), etc. I do get pleasure from doing so (or else I wouldn't do it) but I can't just put the game on and play it for an hour killing enemies for no reason. This is ludus, playing for an outcome.

Opinions on Paidea and Ludus and how they contrast
paidea and ludus are defined almost as opposite types of games, but in my opinion I feel that I game can't work without a bit of paidea and a bit of ludus. Some games have both of them in an obvious sense, Grand Theft Auto for example where you can run around stealing cars (paidea) or do the missions and progress the story (ludus) but most are more subtle but I believe they are there.

Using my games as examples, I've already stated for Team Fortress is 'supposed' to be a ludus game but I play it otherwise and personally I feel that you are meant to look at the game that way, you can choose to muck about or try to be the best. As for Disgaea, it is a very ludus game where you wouldn't think of just playing it for fun, yet there have been times where I have loaded it up just to see some 'over-the-top' attack animations or some funny cutscenes (when you have Prinnies in a game, how can you not laugh) and then stopped playing having progressed no further, again though I feel that the game gives me that choice and allows me to choose what to make of it.

Ultimately, paidea and ludus work together and it is up to us to play the game in the way that we so wish - no matter what game it may be.

Agon, Alea, Ilnix and Mimicry - Competition, Randomness/Chance, Movement, Simulation
I have grouped these together as they are all types of game that more often than not are melded together anyway - you rarely get a game that is purely chance or purely competition. These four words often end up getting conformed to by games, by which I mean the developer will try to make sure that their games have at least one or more of these aspects and that without it they won't work.

An example game that I am going to use to illustrate these points is Street Fighter IV by Capcom - a fighting game. As is obvious with it's genre, there is a clear sense of agon trying to be achieved - a fighting game won't work if there isn't competition between other players or the AI opponent to win the fight - and that agon is what it is trying to conform to. At the same time though, there are elements of randomness (who you end up fighting (when against AI) as certain characters are better against some than others due to their fighting styles) and this will affect the game, there is the way in which you move and control the characters (what moves you use to defeat your opponent, ducking and blocking, etc) and there is an element of simulation (you get to see what it could (and I say 'could' very loosely with Street fighter) be like to be a fighter). Therefore, I feel that agon, alea, ilnix and mimicry aren't the best game defining terms.

Ultimately, these four terms are good at defining types of game and how developers conform to develop a game in a particular style, but in terms of they separate games and define them I feel that they aren't useful purely as most games contain all of the four elements.

Final Word
So there we go, 6 new words I have gained to define a type of game and I personally feel none of them are perfectly accurate. I feel that games contain elements from all over the place and ultimately they are shaped the based on which ones are more focused (fighting games being more agon, The Sims being more paidea, etc). In all honestly, the best way to define games (even though this too has problems that I may go into in another blog post) is genre.

Anyway, 'til next time, that all folks!

Goals, Structure, Struggle... what makes a game a game?

Blog Post number 2, this time I'll be talking about a BBC bitesize Key Stage 1 revision game that I'll analyse using Costikyan's definition of a game. The bitesize game in question is one that is suppossed to teach children how to recognise shapes and various aspects of them (such as lines of symmetry), not something that I would normally play but it is interesting to look and see how the game has been made and how to improve it.

In my opinion, the game was quite badly flawed and this will most likely be demonstated in the following paragraphs.

Interaction
Interaction in a game is how the player sees the game and how they change it, such as making decisions and the different outcomes from each of thier decisions. In this key stage 1 game there is a limited ammount of interaction - the player is given a choice of 3 shapes to choose from and they must choose the right one based on the description given to them by the computer - and this limited interaction is a hinderance to the quality of the game.

Goals
The goal of the game is to successfully identify 5 sets of 3 shapes, ultimately from which (in the game) a robot invention is made. The player will most likely get a sense of achievement and victory from getting 5/5 and creating the robot but ultimately there is little reward for completeing the game and fulfilling the goal - this too is a hinderance to the quality of the game.

Struggle
Struggle, in regards to a game, is about the challenge of reaching the goals or competing with others to get to the goal first. In this game however, there is almost no struggle mainly due to the fact that there is no chance of failure - even if you get the shape wrong you have an infinite ammount of tries to get it right, you will ultiamtely reach the goal. On a positive note, there are various levels of difficulty but without the chance of failure this is almost meaningless.

Structure
The structure of the game is almost non-existent, you pick the shape, you either get it wrong and have to try again or you progress to the next choice of shapes. The only rule of the game is which shape is right and which is wrong and ultimately it is a very linear path and your choices don't change this - something which in a game you would expect.

Endogenous Meaning
Endogenous meaning refers to things that have meaning in the game world but hold no significance in the real world. In this game the only thing that is endogenous is the invention that is made - the player tries to get 5/5 to get the invention made but the invention isn't real and ultimately the player gains nothing. In this regard then the game is actually how one would expect it to be (did I just put 'how one would expect it to be'..? how posh...).

My overall evauation of the game and possible improvements
Overall, I think that the game does satisfy the requirements needed to class it as such but its a different matter to say if it is any good or not. The game is flawed in almost every aspect (I don't need to say why, it's all explained above), even endogenous meaning where I praised it as ultimately it is an education game and will benefit people in the real world by teaching them. Asa result of this I think I can come up with several improvements that may not neccessarily make the game perfect, but will improve it to a suitable standard.

Interaction - The player should be given feedback on thier decisions, why are the decisions right and why are they wrong, etc. The game should do this to try and help the player learn; the KS1 pupil will never learn from thier mistakes if they aren't told why the mistake has been made.

Goal - The reward for completeing the game should be greater, even if the struggle was improved by giving an option to fail would imporve the game greatly. On an independant note though a good potential improvement would be to reward the player for getting 5/5 for playing as the invention they make or something fun like that.

Struggle - The simpleist way to improve this is simply to give the player the option to fail, give them lives that when they run out they have to try again. Or another suggestion, give them a points reward system for right or wrong answers that allows them to compete with other players for the best score.

Structure - This is a difficult area to suggest improvements to as if the structure is changed to much (such as rules) you change the concept of the game and it becomes something new. However, one improvement would be to allow progression of the game's difficulties - at the present, when you start the game you have access to all the difficulties - so that as you complete medium you unlock hard, etc.

Endogenous Meaning - This actually doesn't need improving, the player knows what is real and what isn't, they know the creation isn't real and, even though it goes against endogenous meaning, the game helps the player in the real world to further thier education.

So there we have it, my second blog post is done. Hopefully you'll see that I have a good understanding of what makes a game a game and have the ability to analyse it as such.

Til next time, that's all folks!