Sunday 6 November 2011

Managing Games and some other stuff

Right, here I am back for the bi-weekly blog post on the readings that we've undertaken at Uni. As the title suggests, the readings that I am going to be talking about are related to managing games and some other stuff... I say some other stuff because the readings that we had this week were about Games Design in general rather than a specific type of game. There were 2 readings relating to managing for one week and a reading based around the layers of Games Design and another about rules of play in Games Design for the 2nd week. So let's dive right into this thing and kick off with the managing games.
-----------------------------------------------------------------------------------------
Managing Games
Right well, I said there were 2 readings for managing games... and there were but... the 2nd was a bit... meh (or at least I thought it was - I got 1 note from it which was 'Interaction in management games fuels narrative simply')... so I'm only going to talk about the other reading which comes from Trefry's book on Casual Games Design as many of the other readings have and more specifically it is chapter 7 of Trefry's book.

In this chapter, Trefry goes on to explain what makes a managing game, what they are and why we find them fun and all the usual stuff - yet again backing up all his work with a plethora of examples to get his point across. I know it may seem like I keep having a go about it and well, that's because I am, but seriously, the guy needs to learn to shorten the amount that he talks about specific game examples. Anyways, back on topic, Trefry states that games often walk a fine line between work and play - at their core, with games we as the player need to put in effort to see outcomes which is much like work. Managing games in particular though are almost exactly like work though rather than walking the fine line between work and play, this is because, for the most part, managing games tend to be simulations of a job.

While only a couple of examples, Cake-Mania and Diner Dash illustrate the idea that managing games simulate work. Cake-Mania puts the player in charge of a cake shop and it is their duty to make cakes to the customer's specifications and Diner Dash makes the player a waitress in a, well, diner, and has them takes orders, etc. This shows that these games merely simulate an actual existing job and for that reason the games are literally a means of work - of course they are not the same as doing the job yourself but they are the closest you can come to doing the job without actually doing it. Trefry alludes to this himself, stating that he believes that this is part of the appeal of managing games (despite being work) as it allows people to experience different jobs that they otherwise would not be able to do.

Trefry then does on to explain in-depth about what it is that makes Cake-Mania and Diner Dash work for them, the bits that you can take and apply to managing games in general however though are management games are essentially keeping track of multiple variables, in Diner Dash it is merely multiple timers whereas in Cake Mania it is remembering different ingredients. He even makes a link to RTS (Real-Time Strategy) games an how they are partially management games as they are keeping track of multiple units parameters, etc.

Trefry then goes on to use a couple more examples but there's nothing worth mentioning from them in particular. In summary, with managing games, as they are just keeping track of various variables you have to remember not to overwhelm your player as they boil down to the ability to keep focus more than anything else - at the same time however they must be demanding as this is where the fun of these games comes from.
------------------------------------------------------------------------------------------
Layers of Games Design
The next reading that I am going to talk about is an article by Tony Vetrice called 'The Four Perspectives of Games Design'. The article basically talks about thing that we discussed last year about how Designers see games in a different way to how the consumer ultimately sees them, how they all link together and so on, but despite this I actually found it an interesting articles to read.

Vetrice breaks up the 4 layers into Concept, Paradigm, Mechanics and Features, and Interface and says how the only thing that is truly inventive and created is the concept - everything else may be added as and when it is needed but these needs stem from the concept; the same is true with the 3 other perspectives. Basically, the concept leads to the paradigm which leads to the mechanics which leads to the interface but these things can all flow through and affect each other - all stemming from the concept. Concept is basically the idea, paradigm is the frame of mind the player (unknowingly) uses, mechanics support the paradigm/enables the player to do it and finally the interface is how the player sees and uses the mechanics.

There isn't much to say on concept as it is self-explanatory so I'll move on paradigm... Paradigm is something the player knows about the game or what to expect from it just from what type of game it is - Genre is a good way of exemplifying paradigm; from the genre of FPS or Strategy the player will know exactly what type of game it is but the specific mechanics and features of that game will (or rather, should) be different to other games. Mechanics is what the designers and programmers work on and understand more than the consumer, the mechanics are added to make the game work, they add or remove mechanics as they are needed and shape them into what makes the game unique. Finally, Interface is how the player sees all this stuff that the designer has made - the player doesn't need to necessarily see EVERY mechanic but the mechanics are still there working nonetheless; they need to see only what they need to and not be overwhelmed.

So that is basically it, it's a good read and re-affirmed stuff we knew but in a different and interesting way.
------------------------------------------------------------------------------------
Rules of Play
Finally, the last reading comes from Eric Zimmermann and Katie Salen entitled 'Rules of Play: Games Design Fundamentals' and... well... it is a good read but it was difficult to read and take notes on... I don't know why... I just did... The article talked about conflict in games, how it leads to goals, how it stems from rules, and so on and was generally very in-depth about it but, to be honest, none of it was anything new - it was stuff we had looked at and read last year and it is very much imprinted into my brain now... maybe that was why I found it hard to take notes, I don't know.

Anyways, to sum the article up, Conflict takes many forms individual conflict the game's AI or co-operative conflict against the AI or conflict against each other, this conflict is defined by the internal rules of the game world and the conflict in turn leads to the goals of the game. The player goes through this conflict as a competition to reach the goal and finds fun in this, however, the game must be fair and balanced otherwise the player will just think it is unfair and quit.
------------------------------------------------------------------------------------------
So there we have it - the readings from this week. 'Til next time - that's all folks!