I spent most of my time this week refining my concept. At the end of last week I had a lot of ideas of what I would like to build but I didn't know what the final form would be. I spent a lot of my time over the summer looking at games that let the player derive meaning from the system. I had an understanding of how these precedents would guide my project but not the form my project would take. I spent this week finding those conclusions.
This week I build several simple games with the intent to improve my Actionscript programming skills, In an attempt to refine and prove the validity of the concept of dynamically generating varied and interesting results from a simple set of rules I used processing to create an experiment on creating complexity. In order to refine my concept and inform what I was building as I moved forward I wrote on the topics of variety in games and methods of procedurally generating levels. Each of these prototypes centered on the goals of Concept Verification and Implementation/Production.
I built simple games in Flash with my main focus on learning how a game is structured. My current programming skills afford me the ability to create functionality but I don't have the experience necessary to structure a complex program such that games are. A software program does more than execute functionality; it provides the user with a framework to operate in; within the context of a game this structure is called the "Game Loop". The game loop accounts for any interaction that occurs after the game has been initialized, including functionality, scoring, win conditions etc, and finally the ending screen that feeds the player back into the pre-game interaction. The games I produced were an exercise in creating the components of this loop and structuring them in such a way that they could be extended.
I found a new major resource in Katie Salen and Eric Zimmerman's "Rules of Play". This week I read the "Systems" chapter and the "Emergent Games" chapter. This reading effected my prototyping and informed my writing by giving me depth of understanding in complexity and games as systems. I did experiments in complexity in an effort to begin thinking about the algorithms that would eventually produce levels. The complexity experiments were of limited success I wasn't able to create even an analogy of the algorithms that would produce levels however the experiments are something I plan on continuing to help progress my thinking.
I have included my writing below:
I have realized that I should describe my project from a different point of view. I plan to make a 2D side scrolling platforming game with levels that generate dynamically based on player performance and decisions. Traditionally Platformers have simple narratives that play themselves out through world themes and simple cut scenes. The game I make will follow in this tradition however the level themes and the cut scenes will be generated dynamically based on user performance and decisions. The main focus of this thesis is technical. Randomly generated level design is always a dicey proposition. Without the hand of a designer guiding the production levels can become monotonous and disorganized, lacking flow and an organized structure. I can see several ways to solve these problems. The first comes through research the second comes through untested assumption.
1. randomly generate levels from terrain chunks and features. This is the method utilized in Dino Run and to a less successful degree in Infinite Mario. Part of the reason this method works so well in Dino Run is the nature of the game play experience. Dino Run is a fast paced game, you must save your Dino from the apocalypse by running as fast as possible, to the right. The game play does not promote lingering or wandering. This provides a forgiving canvas for the random level generator.
Another reason Dino Run works is that the terrain features are well designed. Each level has it's own distinct set of features. For instance a particular level might have a brontosaurus bridge or a tar pit with scattered rocks. These features are not made of discreet objects they are large chucks of designed terrain. They provide a designed experience for the player to navigate. These features are placed randomly in a level amongst smaller more generic terrain pieces.
The benefits of the approach of using terrain chunks is that it is easy to control...
2. Other method is similar but leaves more up to the engine. In this version I would provide the engine with granular level elements; platforms, enemies, items, in combination with distinct rules. Platforms maybe no further than X pixels apart, there may be no more than X number of items and they should be spaced X distance from one another. This is similar to the method employed by "Infinite Mario." Here the results are incredibly varied but also completely random. Random is often uninteresting, this is proven in "Infinite Mario." After only a few levels of play, the game becomes tedious and boring, there is very little variation from one level to the next because there is no pacing, no guiding hand. To remedy this I would need to develop an algorithm that would guide the pacing of each level. The
benefit of this approach is more variation.
This lead me to think further about my project and it gave me a new direction. I wrote this paragraph as a result:
I propose to create a game with a built in editor that will sit inside of a dynamic and ever expanding narrative. The editor will initially be built as a tool for me to use to develop a game concept that I have been developing for some time. The editor will allow users to add chapters to an ever growing story. The story is flexible and may branch in myriad directions. The editor will allow players to add to the story line, inset pieces of the story to provide finer detail or branch off in a completely new direction.
My writing expanded the possibilities of what I the final form my thesis project might take. I will continue
