During these weeks we have discussed how to evaluate games and what a game design document should contain to name two of many things. But what I have learned from these past weeks is to look at games from a different point of view where I can identify different objects and elements in a game and thereby also see what makes the game good or bad.
Let’s take one of the exercises from the last week’s were we should evaluate the game play. I chose Grow Cube and there are some things missing in the game that you now can see that it would have been nice features to have in the game like a skip or undo button. You can now identify certain things in the game to like different objects as the people, the ball and the water, all of which you can integrate in the environment during certain times in the game. So now you can pinpoint different things and say that this is the things that makes the game bad and this are the things that makes it a good game instead of saying that the whole game is good or bad. That was of course possible before this course too but then it was more like that the graphic or artificial intelligence was bad even though things like that still is important and can make a game good or bad.
One part that I enjoyed was the design document exercise where we had to come up with a game that we had redesigned from an older game. We, the people in my group, chose to redesign Outrun from Sega. I got an idea of a game when we decided what game to redesign, we was supposed to redesign Off Road but I came with the idea to redesign Outrun instead which is a better game. I got an opening to develop this idea into a rather short design document which was really fun and gave me big dreams of the future. But I have learned during this week’s that there isn’t only good ideas and that even ideas has to be evaluated but I still think that Spacerace is a good game with a lot of good ideas. But with the past couple of weeks in my mind I would take some things a bit further and develop them a bit more so the game fits more people than those who have played games for a long time and knows how it all works, to reach a wider audience in the end so too say. Some of the things I think we missed in the design document were to show some sketches of the environments and track layouts of the game but we didn’t have the time to fix it.
During the course we have had a couple of workshops which is a great way of learning things. Aki Järvinen presented us to his analysis tool which was a good way of analyze a game quickly and it showed that even simple games can be very complex with a lot of different things that you normally wouldn’t see or care about or at least think about as a normal player. Aki’s method was divided into nine different elements that the game contains; components, environment, information, theme, game mechanics, rule sets, players and contexts and then there were three types of ownership, self, other or system. At the first look at it, it sounded quite complex and massive with a lot of different elements that all should be in the game. But when he started to explain it all it turned out to be a very easy way of analyzing a game. I analyzed Zookeeper at that workshop and I hope that when I have more time I will analyze other games with his method to practice on analyzing games.
We learned about other analyzing methods that week with MDA being the most interesting one in my opinion. MDA stands for Mechanical, Dynamics and Aesthetics and is a way of how to develop a game with you starting on the aesthetics on the game idea, then forming the dynamics around it and in the end develop the mechanics. What it means is that you start with setting a theme of the game and get a feel to the game, should it be a scary game or a soft game. The dynamics then is about what the game should be about; how to win or lose, how the characters will behave and will there be any power ups. You finish up with the mechanics which are the rules of the game, what you can and can’t do and how and when do you die in the game. Another thing with MDA is that a person who play a game gets the MDA the other way then the developer, he first meet the mechanics, what can I do and what rules are there in this world then he wonders what to do to win the game and what the character he or she plays can do.
When I came up with Spacerace I wanted a racing game in space that would let you race in both space and on planets. I wanted the game to have a grown up, cartoony look over it, it shouldn’t be childish but still colorful and living. That was a bit of the aesthetics part of the game and then the dynamics of the game should be decided. Spacerace should be about getting to a finish line before the time runs out and you get more time at each checkpoint. The boost system came up here as a power up that you achieve when traveling close to objects like rocks and trees. In the end decisions was made on how different things would work, like multiplayer and what you should be able to do within the screen. I think that the MDA method of developing game ideas is a good way because you always have to think of something that could be fun playing and what theme the game should have and then take the more advanced elements and develop them into something playable.
The other methods we were showed was the Game Ontology Project and Game Design Patterns but none of them would be a standardized way for me to develop a game. Game Ontology Project is a wiki like page with games put in different categories and under categories depending on what they contain. If I would use it for a game like World of Warcraft it would first be put in the multiplayer page, then role playing and in the end fantasy but it would be as a good example of a multiplayer role playing game in a fantasy world. It might work when it is all done but for the moment there is too few games represented there to get something useful out of it. Game Design Patterns was also undone with nearly no fact at all to present.
Another workshop we had were the redesign workshop were we redesigned old games into new ones with varying result. The new game idea I liked the most at that workshop was when we took Taito’s Bust-a-Move game and redesigned it to Turbine Turret Turbo, a puzzle game with a lot in common with Bust-a-Move but with a circular playing field and a different control method. It was a giving workshop that I learned a lot from. To spot and pick out different rules from a game and that if you change one rule, the game won’t be the same is a good knowledge to have in the future. If you would take Assassins Creed and change the rule that makes it possible for Altair, the main character and the one the player controls, to climb walls so that he isn’t able to do it any more then the whole game would change. The game is built for you to climb walls and with that rule taken away you would be stranded on the roads and limited to ladders if you want to climb the houses and that would also make the game impossible to finish because you are required to climb up to certain high buildings to see where you can get information about your target. I haven’t thought of these things before but I have now learnt that it is crucial not to change something that could affect the rest of the game if it isn’t something I want, at least when developing a game, if you are redesigning a game then you should change the rules to make the game your own but you have to watch out and see what happens with the game when the rules changes.
The three types of rules; operational rules, constitutive rules and implicit rules, wasn’t something new really but nothing that I have been thinking about either but there have always been more to a game then showed . The three different types of rules are rules on different levels. In a game of football the operational rules are that you should get the ball in to the other team’s goal and not letting them getting the ball in your goal, the first things that you hear when joining a football game. The constitutive rules are that the game should be played with a ball. The implicit rules are, depending on where and when you play, things like if the ball crosses the side line then it is either a kick in if playing with friends or if playing a league you throw in the ball. Operational rules are the rules that you can be told if it is the first time trying something out or when joining a game, constitutive rules are the underlying rules like you have to play with something that roll, whether it is a football or a handball or just a piece of paper. The implicit rules are the rules that those you play with have decided to use, they can be the normal rules of the game or there can be some changes like kick inns instead of throw inns, they are unwritten rules.
The second week on this course we had a lecture about the history of games; we went through the history of arcade, console, pc and handheld games. Very interesting but I wrote a paper on it at upper secondary school and held a presentation about it so I knew most of the stuff already.
This course have made me more aware of what a game designer does and what the work is about, before I knew that I should design games, come up with new game ideas and make something out of it. I have learned a lot and I’ve read a lot of extra materials, like when I wrote the final assignment on the different analyze methods I spent a day reading about the MDA method on different sites, one of them was LeBlanc’s own site 8 kinds of fun. I have spent a lot of time and many late hours to get stuff done and making them as good as possible. To summarize the summary, I have learnt a lot of new things and methods which I think will come in handy when working with games in the future. The lectures have been good and inspiring with some nice conversations and new ways of having lectures on, first time for me to have a distance lectures and taped lecture. I will end this text and course with a thank you to all the teachers who have been teaching us this period and hope to meet you all next year. Thank you and happy New Year.
