I’ve long held the belief that quality is far more important than quantity, at least as far as media goes. I only have time for a few media experiences, so I want those to be the best they can be. But I’m now thinking that this general rule breaks down when I am the author rather than the audience.
I’ve noticed something with content on the web. While 90% of everything may be crap, when enough crap gets put into the same place and follows the same themes, it stops being crap. Long running web comics may start out terrible, but somehow they transform into something worthwhile. I may still look at the end result and be dissatisfied, but every web comic that has passed a thousand strips has a fan base. I think this has to do with quality being found in depth, and the indirect relationship between quantity (within a common frame) and depth.
I define depth as the number of connections in a system, while complexity is the number of individual nodes. While it is possible to have a very deep system that is not complex, it is much harder to have a very complex system that is not also deep. If a system has only a handful of nodes but they are all connected to everything else we have a non-complex system that is very deep. Conversely, if we have a system that has only one connection per node, but has lots of nodes, then there may not be much depth per node but the total complexity level still leads to some depth overall. Depth is desirable for creating meaning, and while it is often preferable to have depth without complexity, this is not a hard rule. Depth through complexity is better than no depth at all.
Now complexity is interesting. Systems that are constantly modified tend towards complexity. When modifying a system, more time is usually spent adding to it than removing from it. This is especially true of narrative frameworks that exist in the mind of a reader. Even telling the reader that “it was all a dream” doesn’t remove complexity. In other words, any narrative system that is extended over a long period of time will grow in complexity. And as a narrative system grows in complexity, so does its increase in depth.
In other words quantity seems to trump quality. Here it’s not that quantity is better than quality. Quality is certainly more important. Rather, we can see that quantity often leads to some degree of quality. The inverse cannot be said to be true; quality doesn’t create quantity. Further, in most cases having both quality and quantity is more desirable than just having quality. This suggests that focusing on quantity first is far more important – even if quality is the long term goal.
This property of narrative contexts doesn’t necessarily extend to non-narrative contexts, such as this present essay. However, I believe there is another fundamental way that quantity is more important than quality in any work in which one plays the role of author. I will examine what this way is in Part II.
Saturday, 30 April 2011
Friday, 29 April 2011
Cut from my Dissertation
Preface
I find that I can fairly easily write a thousand words on any subject that interests me, though sometimes (and I have no way to tell this before writing) I’ll only be able to write a few hundred words while other times I’ll write two thousand. But writing more than three or four thousand words is really hard.
My Masters dissertation needed to be 12 to 18 thousand words long.
When presented with needing to write a longer essay I chop the task into several interconnected pieces. While I effectively did the same thing with my dissertation, three or four interconnected pieces just wasn’t going to cut it. However, almost everything I write gives me ideas for other things I would like to write (creativity is not a limited resource). So, having written several interconnected sections, I was able to find new things to write that were connected to one or two of the pieces already written.
At first, I chose each next thing to write as I sat down to write it, based only on what most interested me in that moment. As I got closer to my target I realised that some of my sections were becoming very divergent, so I started trying to ensure that I wrote towards connecting the various ideas and creating a flow through the whole. Still, in the end I was left with one major tangent... but by that time I was already just over 18 thousand words. So I cut the tangent and polished what was left.
But I still like the tangent. So I’m presenting it here.
The context of this tangent is that I have defined games as ‘play within a finite system’ and a finite system as being able to be wholly described as a list of possible states (though this list may be impractically long). I also made the claim that goals are inherent to play; play is active, as opposed to reactive or passive, and all actions are directed towards an intention. In other words, by being active, play encompasses intentions – and goals are just a particular ‘look’ at intentions.
The Cut
Before moving on to other values to compare my new definition with, I would like to touch on one possible objection to what I’ve outlined above. When we speak of goals within the context of a game, we generally refer to ‘the’ goal, not ‘one of many’ goals. Considering a game as ‘play within a finite system’ there is no insistence within the game that players have a particular goal – they are welcome to bring any goal they want to play with in order to join this notion of a game. Surely all players within a game must have the same goal in order for the game to be a game and not many different games? Further, if a player is within a finite system and accomplishes one goal only to adopt another, then they must be playing a different game than the one they initially sat down to play? Where do these differences exist within my definition?
In this case, rather than find the singular goal within my definition, I will step back and contend that it is only certain types of games that must have singular goals. For instance, in our discussion of Myers’ definition we have already seen that different players have different goals when playing a role playing game. While this can cause break down in the successful play of the game, in the cases where all players are able to pursue their individual goals within the game the game works well; more importantly, it certainly is a game. In addition, something not mentioned in our discussion before is that the goals of a role player are mutable – in different situations the same player may be pursuing different goals. But even though the player is changing goals, they are still playing the same game.
Which begs the question, if not all games are necessarily single goaled, what is the type of game that must have the same goal for all players and how does my definition contend with those games? Almost all contests fall into the category of having the same goals between players. The reason they need to have the same goals is because the challenge of a contest is to beat the other players – in order for the play to have the possibility of failure, the other players must be trying to attain the same results you are. While there are some contest like games that have different goals between players, these are the exception... and even then, the differing goals will be predictably similar between instances of the same game. In all these games the goals are codified by rules and failure to try to attain the goal means that the other players will not be appropriately challenged. Upon finding out that their opponent has not been following this rule they will feel cheated. How is it that the goal of these games has moved from ‘play’ to ‘rules’ and how does ‘finite system’ embody the rule of trying to achieve a goal?
First of all, it is important to observe that not following this rule is not necessarily the same as not following other rules. If I am not trying to win, you will only feel cheated if you feel that you are no longer having an appropriate challenge from your play. If ten people are racing, but one of them is pursuing a different goal that does not interfere, then the other nine will still be challenged by each other. All (including the differently goaled player) are still in the race. Likewise, if we are only playing a two player game, and my different goal does interfere with your attempt to win, but the interference neither makes your attempt too hard nor too easy, then it is likely that you will not feel cheated and that the game will go on. Whether or not it is still the same game is a point of contention, but I’m fairly certain that the resolution of this question must be subjective.
Secondly, while the goal may exist within the rules, its pursuit must still exist solely in the play. A rule may tell a player that in order to play a game they must attempt to change the state of the game to a particular condition, but the rules cannot be responsible for enforcing the intent of the player. Not only are the rules inert but intent is ultimately unknowable by any but the intender. It is only the player who can be unrealistic in their optimism or who acknowledges failure that can choose their intended outcomes. In other words, while goals may be found within rules, they are only ever pursued within play.
In terms of locating the rule coding for a goal within a finite system, I would like to suggest that any game that includes a rule of a particular goal contains a global state within which that goal is active. For instance, in a race, there is a state which describes a player as trying to win the race. However, the alternative state of not trying to win the race does not exist within the finite system – the finite system may refer to the state but it does not contain the state. At first, this may seem objectionable. Surely any state the finite system observes must be contained within the finite system?
To help with understanding how this can be, let me propose a simple game and then list the states that are contained within the game. The rules of the game are that you roll a dice until you roll any number other than a six. No goal within these rules. (Though note that in order to play you will need to have a goal – you can’t help but have a goal if you are going to be within the emotion of play. You can try to trick the system by trying to not having a goal while playing this game, but you will quickly observe that your optimism that you can do that is highly unrealistic.)
Now let me list the states of this simple game:
1) You are rolling the die
2) The die is showing a six
And that is it. There are no states within the game that include any of the other values that could be shown on the die. Each of the other values that could be shown are states that the die could be in, and the game certainly references the state of the die, but the only state of the die that is contained within the game is the one where it shows a six. From this it is not a stretch to see that one of the states that could be tracked within a game is the intent of the player, even if the only valid state for the players’ intent was trying to win the game.
I find that I can fairly easily write a thousand words on any subject that interests me, though sometimes (and I have no way to tell this before writing) I’ll only be able to write a few hundred words while other times I’ll write two thousand. But writing more than three or four thousand words is really hard.
My Masters dissertation needed to be 12 to 18 thousand words long.
When presented with needing to write a longer essay I chop the task into several interconnected pieces. While I effectively did the same thing with my dissertation, three or four interconnected pieces just wasn’t going to cut it. However, almost everything I write gives me ideas for other things I would like to write (creativity is not a limited resource). So, having written several interconnected sections, I was able to find new things to write that were connected to one or two of the pieces already written.
At first, I chose each next thing to write as I sat down to write it, based only on what most interested me in that moment. As I got closer to my target I realised that some of my sections were becoming very divergent, so I started trying to ensure that I wrote towards connecting the various ideas and creating a flow through the whole. Still, in the end I was left with one major tangent... but by that time I was already just over 18 thousand words. So I cut the tangent and polished what was left.
But I still like the tangent. So I’m presenting it here.
The context of this tangent is that I have defined games as ‘play within a finite system’ and a finite system as being able to be wholly described as a list of possible states (though this list may be impractically long). I also made the claim that goals are inherent to play; play is active, as opposed to reactive or passive, and all actions are directed towards an intention. In other words, by being active, play encompasses intentions – and goals are just a particular ‘look’ at intentions.
The Cut
Before moving on to other values to compare my new definition with, I would like to touch on one possible objection to what I’ve outlined above. When we speak of goals within the context of a game, we generally refer to ‘the’ goal, not ‘one of many’ goals. Considering a game as ‘play within a finite system’ there is no insistence within the game that players have a particular goal – they are welcome to bring any goal they want to play with in order to join this notion of a game. Surely all players within a game must have the same goal in order for the game to be a game and not many different games? Further, if a player is within a finite system and accomplishes one goal only to adopt another, then they must be playing a different game than the one they initially sat down to play? Where do these differences exist within my definition?
In this case, rather than find the singular goal within my definition, I will step back and contend that it is only certain types of games that must have singular goals. For instance, in our discussion of Myers’ definition we have already seen that different players have different goals when playing a role playing game. While this can cause break down in the successful play of the game, in the cases where all players are able to pursue their individual goals within the game the game works well; more importantly, it certainly is a game. In addition, something not mentioned in our discussion before is that the goals of a role player are mutable – in different situations the same player may be pursuing different goals. But even though the player is changing goals, they are still playing the same game.
Which begs the question, if not all games are necessarily single goaled, what is the type of game that must have the same goal for all players and how does my definition contend with those games? Almost all contests fall into the category of having the same goals between players. The reason they need to have the same goals is because the challenge of a contest is to beat the other players – in order for the play to have the possibility of failure, the other players must be trying to attain the same results you are. While there are some contest like games that have different goals between players, these are the exception... and even then, the differing goals will be predictably similar between instances of the same game. In all these games the goals are codified by rules and failure to try to attain the goal means that the other players will not be appropriately challenged. Upon finding out that their opponent has not been following this rule they will feel cheated. How is it that the goal of these games has moved from ‘play’ to ‘rules’ and how does ‘finite system’ embody the rule of trying to achieve a goal?
First of all, it is important to observe that not following this rule is not necessarily the same as not following other rules. If I am not trying to win, you will only feel cheated if you feel that you are no longer having an appropriate challenge from your play. If ten people are racing, but one of them is pursuing a different goal that does not interfere, then the other nine will still be challenged by each other. All (including the differently goaled player) are still in the race. Likewise, if we are only playing a two player game, and my different goal does interfere with your attempt to win, but the interference neither makes your attempt too hard nor too easy, then it is likely that you will not feel cheated and that the game will go on. Whether or not it is still the same game is a point of contention, but I’m fairly certain that the resolution of this question must be subjective.
Secondly, while the goal may exist within the rules, its pursuit must still exist solely in the play. A rule may tell a player that in order to play a game they must attempt to change the state of the game to a particular condition, but the rules cannot be responsible for enforcing the intent of the player. Not only are the rules inert but intent is ultimately unknowable by any but the intender. It is only the player who can be unrealistic in their optimism or who acknowledges failure that can choose their intended outcomes. In other words, while goals may be found within rules, they are only ever pursued within play.
In terms of locating the rule coding for a goal within a finite system, I would like to suggest that any game that includes a rule of a particular goal contains a global state within which that goal is active. For instance, in a race, there is a state which describes a player as trying to win the race. However, the alternative state of not trying to win the race does not exist within the finite system – the finite system may refer to the state but it does not contain the state. At first, this may seem objectionable. Surely any state the finite system observes must be contained within the finite system?
To help with understanding how this can be, let me propose a simple game and then list the states that are contained within the game. The rules of the game are that you roll a dice until you roll any number other than a six. No goal within these rules. (Though note that in order to play you will need to have a goal – you can’t help but have a goal if you are going to be within the emotion of play. You can try to trick the system by trying to not having a goal while playing this game, but you will quickly observe that your optimism that you can do that is highly unrealistic.)
Now let me list the states of this simple game:
1) You are rolling the die
2) The die is showing a six
And that is it. There are no states within the game that include any of the other values that could be shown on the die. Each of the other values that could be shown are states that the die could be in, and the game certainly references the state of the die, but the only state of the die that is contained within the game is the one where it shows a six. From this it is not a stretch to see that one of the states that could be tracked within a game is the intent of the player, even if the only valid state for the players’ intent was trying to win the game.
Thursday, 28 April 2011
Author Astray
Preface
I recently finished my Masters degree in ‘Digital Games Theory and Practice’. While I found the Theory part far more enjoyable (the Practice section was far too similar to my day job working at Lionhead) I am still happy with most of the work I put into the Practice sections. One of these assignments was writing a ‘review’ or a ‘post-mortem’ of a previous assignment – a short design doc. While I think I may still use the design doc for a future project, the post-mortem itself has likely seen the totality of its use. However, after reading it my mother told me that she found it relevant for her own creative process independent of the design document itself. Now, I’m not sure a mother’s praise can be taken at face value, but I still thought the least I should do was to self-publish the post-mortem online. So, here it is.
Introduction
Creating the ‘Auto de Fé’ design document has been an interesting journey. It was meant to take only a couple of months to write, but the process was interrupted several times. On the one hand, these interruptions have broken my concentration and constricted my schedule. On the other hand, they have given me more time to reflect. Because these reflections came mid-project they had a direct effect on the results of the ‘Auto de Fé’ project. For this I am grateful. I do not think the game design would have been as good without this mid-project chance for reflection. This document is a brief sketch of the key thoughts I’ve had, how they changed what I was creating and what (I hope) I’ve learned.
Missing the Forest Fire for the Falling Tree
When I started work on ‘Auto de Fé’ I started with a blank slate. My intention was to use experimental prototyping to explore a unique set of game mechanics in order to invent a new genre. However, I quickly hit a snag; I found it difficult to work experimentally within the provided prototyping environment. My initial reaction was to fight against the constraint placed upon me; a fight which I would ultimately lose. While I don’t consider picking that particular fight to be a bad call on my part, my reaction to losing it was. I continued harassing the issue long after I knew that I was stuck with the tools provided. Worse, I didn’t adapt my work practice to the designated tool set. I kept trying to work in the way I would have given my tools of choice. Needless to say, I didn’t make much progress with either strategy. If it wasn’t for the sudden interruption of serious crunch on Fable III, I don’t know where I would have ended up.
The long break away from working on ‘Auto de Fé’ gave me perspective. When I returned, I saw my mistake. Continuing to attempt a programmer’s approach of experimental prototyping in a context in which I was unfamiliar was madness. With perspective, I was able to revaluate what I needed to be working on. This is the first important lesson I learned working on this project; when things stop working the way I ‘need’ them to, step back and reconsider where my ‘needs’ are coming from. If a change in the way I work enables me to continue forward progress, even if it means changing my vision, then such a change is a good idea.
Starting Out of Time
Unfortunately, crunch on Fable III took a lot longer than I expected it to. Just when I thought I had finished, I was given a new set of responsibilities. When I finally came back to ‘Auto de Fé’, while I had a fresh perspective on how not to proceed, I was also out of time. I knew that an experimental prototype wouldn’t be easy given my tools and my now tight schedule, but I still needed some form of prototype. I just didn’t know how to proceed. So I went back to the project requirements and realised that the prototype portion of the work was not necessarily the ‘core’ task.
Over the years I’ve worked on a variety of projects in my spare time. One thing I’ve found over and over again is that projects will often have hard problem and easy problems. When I focus on only the hard problems, I sometimes get stuck and unable to make further progress. On the other hand, if I focus on the easy problems, I can end up going in a direction that makes the hard problems harder. While I don’t think I know yet where the best middle ground lies, I came to a new realisation from reflecting on what I needed to do next. When pressed for time, solve the biggest problems first. In the case of ‘Auto de Fé’, the design document was the big problem – the prototypes were meant to support the document, not the other way around. So I put my prototyping problems to the side and focused on the design and writing.
An Imperfect Match
At its core, ‘Auto de Fé’ is the combination of two ideas; creating a serious world where standard platform mechanics make sense and telling a story about Columbus as a privateer before he became famous. Both are ideas I’ve had for a long time, but I’d never really considered them together. The ‘serious platform game’ was an idea looking for a story while ‘Columbus as a Privateer’ was a story with no mechanics. I decided to try to fit the two together.
At first, everything went well. I found interesting ways to make jumping around an environment approachable and 15th Century Spain proved to be an interesting source for conflicts far beyond Columbus and privateers. However, as I got into the writing, I found that I continuously had to justify the two ideas to each other. These two ideas, having grown in wonderful ways as I worked with them, weren’t working well together. I either needed to make them mesh together or to drop one of the ideas.
So I started playing with my two ideas from a number of different perspectives, seeing what was important about them. What I found was that from the perspective of the world, it wasn’t particularly important why I’d crafted it the way I had. It didn’t matter that the world was made up of winged amphibians in order to justify the platform mechanics. It didn’t matter that the world had strong influences taken from the true history of Spain. What mattered was the end result; a world of medieval anthropomorphic swamp creatures. I didn’t need to explain that amphibians were Jewish and reptiles Christian. The conflict remained without the explanation and the explanation got in the way of the end result. Taking the time to explain why the world was the way it was did not further the end goal – writing a quality game design document. The lesson here is simple. It doesn’t matter where an idea comes from. It only matters where it is going.
The Perfect Curse
I now had a clear idea of where I was going, and only several thousand more words to write in order to get there. But these words – they weren’t coming. I knew what I wanted to say, I just couldn’t find the right way to say it. And every start I made just seemed to make the final product worse. This led to low motivation, and low motivation led to low productivity. Not a good thing when I was already running short on time.
But this is a lesson I’ve been taught before. Maybe one day it will stick. Perfection is impossible. As soon as I begin judging my work while I work on it, I will find myriad flaws. Trying to fix these flaws on the go is always a mistake; I have no scope to see which problems are the big ones. It is better to finish first, flaws included, and then make incremental changes that approach my ideals. The lesson; done is better than perfect.
A Different Type of Prototype
At the same time as I was solving the problems involved with getting the document finished, I began to look back in the other direction. I needed to figure out what I wanted to do for the prototypes. A discussion I’d had several months before suddenly clicked for me. What the prototypes showed was more important than how exhaustively they showed it. They were not being created for me, but for another audience.
When I think of prototyping, I think of experimental prototypes. When creating a set of mechanics I am unfamiliar with, I like to ‘feel out’ the possibility space of those mechanics. I do this by writing a prototype in a programming language I am comfortable with and then playing with the results. I push the resulting game mechanics both in directions towards my initial set of inspirations, but also in whichever direction maximises fun.
But experimental prototypes are not the only type of prototype that can be made. Specifically, for the purposes of presenting a work to others, it is more important that a prototype communicates an idea than that it explores a set of mechanics. In both cases, the prototype is exploring unfamiliar territory. In both cases, the prototype is meant as a proof of concept. But changing the audience of the prototype fundamentally changes the nature of the prototype. With an experimental prototype, I am exploring territory unfamiliar to myself in order to discover which set of mechanics are the most fun; a disproof is as important as a proof. With a prototype meant for an external audience, I need to elucidate territory that is familiar to me, but unfamiliar to them. The purpose of this type of prototype is to prove to my audience that I know what I am talking about. A disproof will just make me look bad.
In the end, the prototypes I made for ‘Auto de Fé’ are somewhere between these two... but the realisation of this difference is perhaps one of the most important discoveries I made during this process. It shines new light on previous conversations I’ve had throughout my career in the games industry.
Conclusion
It is surprisingly difficult to make things, whether full games or just designs for games. But with each making, whether success or failure, I learn something new. While a failure is a definite lesson, it is those projects that I finish that I learn the most from. I need to finish more projects in order to learn, not only those projects that have a framework of external expectation. A finished project doesn’t need to be perfect, but it needs to be done. It doesn’t need to solve all the problems before me; finishing something is more important than being truly innovative. When I get stuck, I need to find ways to push through, whether by forgiving my imperfections, concentrating on the most important tasks first or by focusing on the end product rather than all my cool ideas. And lastly, I need to learn to communicate my ideas to others if I’m ever going to get their help.
This last one scares me the most; while I am very precise in what I say, precision isn’t always the best path to understanding. And the discipline of design is, far more than I would like, about getting other people to understand ideas. I suspect learning these communication skills will be my major focus for the next several years.
I recently finished my Masters degree in ‘Digital Games Theory and Practice’. While I found the Theory part far more enjoyable (the Practice section was far too similar to my day job working at Lionhead) I am still happy with most of the work I put into the Practice sections. One of these assignments was writing a ‘review’ or a ‘post-mortem’ of a previous assignment – a short design doc. While I think I may still use the design doc for a future project, the post-mortem itself has likely seen the totality of its use. However, after reading it my mother told me that she found it relevant for her own creative process independent of the design document itself. Now, I’m not sure a mother’s praise can be taken at face value, but I still thought the least I should do was to self-publish the post-mortem online. So, here it is.
Introduction
Creating the ‘Auto de Fé’ design document has been an interesting journey. It was meant to take only a couple of months to write, but the process was interrupted several times. On the one hand, these interruptions have broken my concentration and constricted my schedule. On the other hand, they have given me more time to reflect. Because these reflections came mid-project they had a direct effect on the results of the ‘Auto de Fé’ project. For this I am grateful. I do not think the game design would have been as good without this mid-project chance for reflection. This document is a brief sketch of the key thoughts I’ve had, how they changed what I was creating and what (I hope) I’ve learned.
Missing the Forest Fire for the Falling Tree
When I started work on ‘Auto de Fé’ I started with a blank slate. My intention was to use experimental prototyping to explore a unique set of game mechanics in order to invent a new genre. However, I quickly hit a snag; I found it difficult to work experimentally within the provided prototyping environment. My initial reaction was to fight against the constraint placed upon me; a fight which I would ultimately lose. While I don’t consider picking that particular fight to be a bad call on my part, my reaction to losing it was. I continued harassing the issue long after I knew that I was stuck with the tools provided. Worse, I didn’t adapt my work practice to the designated tool set. I kept trying to work in the way I would have given my tools of choice. Needless to say, I didn’t make much progress with either strategy. If it wasn’t for the sudden interruption of serious crunch on Fable III, I don’t know where I would have ended up.
The long break away from working on ‘Auto de Fé’ gave me perspective. When I returned, I saw my mistake. Continuing to attempt a programmer’s approach of experimental prototyping in a context in which I was unfamiliar was madness. With perspective, I was able to revaluate what I needed to be working on. This is the first important lesson I learned working on this project; when things stop working the way I ‘need’ them to, step back and reconsider where my ‘needs’ are coming from. If a change in the way I work enables me to continue forward progress, even if it means changing my vision, then such a change is a good idea.
Starting Out of Time
Unfortunately, crunch on Fable III took a lot longer than I expected it to. Just when I thought I had finished, I was given a new set of responsibilities. When I finally came back to ‘Auto de Fé’, while I had a fresh perspective on how not to proceed, I was also out of time. I knew that an experimental prototype wouldn’t be easy given my tools and my now tight schedule, but I still needed some form of prototype. I just didn’t know how to proceed. So I went back to the project requirements and realised that the prototype portion of the work was not necessarily the ‘core’ task.
Over the years I’ve worked on a variety of projects in my spare time. One thing I’ve found over and over again is that projects will often have hard problem and easy problems. When I focus on only the hard problems, I sometimes get stuck and unable to make further progress. On the other hand, if I focus on the easy problems, I can end up going in a direction that makes the hard problems harder. While I don’t think I know yet where the best middle ground lies, I came to a new realisation from reflecting on what I needed to do next. When pressed for time, solve the biggest problems first. In the case of ‘Auto de Fé’, the design document was the big problem – the prototypes were meant to support the document, not the other way around. So I put my prototyping problems to the side and focused on the design and writing.
An Imperfect Match
At its core, ‘Auto de Fé’ is the combination of two ideas; creating a serious world where standard platform mechanics make sense and telling a story about Columbus as a privateer before he became famous. Both are ideas I’ve had for a long time, but I’d never really considered them together. The ‘serious platform game’ was an idea looking for a story while ‘Columbus as a Privateer’ was a story with no mechanics. I decided to try to fit the two together.
At first, everything went well. I found interesting ways to make jumping around an environment approachable and 15th Century Spain proved to be an interesting source for conflicts far beyond Columbus and privateers. However, as I got into the writing, I found that I continuously had to justify the two ideas to each other. These two ideas, having grown in wonderful ways as I worked with them, weren’t working well together. I either needed to make them mesh together or to drop one of the ideas.
So I started playing with my two ideas from a number of different perspectives, seeing what was important about them. What I found was that from the perspective of the world, it wasn’t particularly important why I’d crafted it the way I had. It didn’t matter that the world was made up of winged amphibians in order to justify the platform mechanics. It didn’t matter that the world had strong influences taken from the true history of Spain. What mattered was the end result; a world of medieval anthropomorphic swamp creatures. I didn’t need to explain that amphibians were Jewish and reptiles Christian. The conflict remained without the explanation and the explanation got in the way of the end result. Taking the time to explain why the world was the way it was did not further the end goal – writing a quality game design document. The lesson here is simple. It doesn’t matter where an idea comes from. It only matters where it is going.
The Perfect Curse
I now had a clear idea of where I was going, and only several thousand more words to write in order to get there. But these words – they weren’t coming. I knew what I wanted to say, I just couldn’t find the right way to say it. And every start I made just seemed to make the final product worse. This led to low motivation, and low motivation led to low productivity. Not a good thing when I was already running short on time.
But this is a lesson I’ve been taught before. Maybe one day it will stick. Perfection is impossible. As soon as I begin judging my work while I work on it, I will find myriad flaws. Trying to fix these flaws on the go is always a mistake; I have no scope to see which problems are the big ones. It is better to finish first, flaws included, and then make incremental changes that approach my ideals. The lesson; done is better than perfect.
A Different Type of Prototype
At the same time as I was solving the problems involved with getting the document finished, I began to look back in the other direction. I needed to figure out what I wanted to do for the prototypes. A discussion I’d had several months before suddenly clicked for me. What the prototypes showed was more important than how exhaustively they showed it. They were not being created for me, but for another audience.
When I think of prototyping, I think of experimental prototypes. When creating a set of mechanics I am unfamiliar with, I like to ‘feel out’ the possibility space of those mechanics. I do this by writing a prototype in a programming language I am comfortable with and then playing with the results. I push the resulting game mechanics both in directions towards my initial set of inspirations, but also in whichever direction maximises fun.
But experimental prototypes are not the only type of prototype that can be made. Specifically, for the purposes of presenting a work to others, it is more important that a prototype communicates an idea than that it explores a set of mechanics. In both cases, the prototype is exploring unfamiliar territory. In both cases, the prototype is meant as a proof of concept. But changing the audience of the prototype fundamentally changes the nature of the prototype. With an experimental prototype, I am exploring territory unfamiliar to myself in order to discover which set of mechanics are the most fun; a disproof is as important as a proof. With a prototype meant for an external audience, I need to elucidate territory that is familiar to me, but unfamiliar to them. The purpose of this type of prototype is to prove to my audience that I know what I am talking about. A disproof will just make me look bad.
In the end, the prototypes I made for ‘Auto de Fé’ are somewhere between these two... but the realisation of this difference is perhaps one of the most important discoveries I made during this process. It shines new light on previous conversations I’ve had throughout my career in the games industry.
Conclusion
It is surprisingly difficult to make things, whether full games or just designs for games. But with each making, whether success or failure, I learn something new. While a failure is a definite lesson, it is those projects that I finish that I learn the most from. I need to finish more projects in order to learn, not only those projects that have a framework of external expectation. A finished project doesn’t need to be perfect, but it needs to be done. It doesn’t need to solve all the problems before me; finishing something is more important than being truly innovative. When I get stuck, I need to find ways to push through, whether by forgiving my imperfections, concentrating on the most important tasks first or by focusing on the end product rather than all my cool ideas. And lastly, I need to learn to communicate my ideas to others if I’m ever going to get their help.
This last one scares me the most; while I am very precise in what I say, precision isn’t always the best path to understanding. And the discipline of design is, far more than I would like, about getting other people to understand ideas. I suspect learning these communication skills will be my major focus for the next several years.
Subscribe to:
Posts (Atom)