Game Ramblings

3 of 2: Game Design Role Models

Okay, so I’m going overboard a bit here, so this post will definitely be shorter than the other two, but I couldn’t talk about my game design role models without talking about Fumito Ueda, the game designer behind the pioneering, critically acclaimed games Shadow of the Colossus and Ico. I wanted to present Ken Levine and Jenova Chen as two very distinct influences on my game design, but regretted leaving out Fumito immediately, so here he is. His games are beautiful and minimalist, and touch the player in ways that no game had done before and very few games have done since. Fumito takes a reductionist approach to game design - game mechanics are stripped out of the design in order to make room for what is at the core of the game’s emotional mission.

2 of 2: Game Design Role Models

Jenova Chen is a more recent influence of mine, but his influence can’t be understated. I love this man’s approach to game design, and the games that have come out of his philosophy have astounded me. He was born in Shanghai, China in 1981 and moved to the United States in 2003 after completing a degree in computer science with a minor in digital art and design. Once in the states, he completed a masters in University of Southern California’s Interactive Media Division. After a brief stint working for Maxis, he founded Thatgamecompany, with which he would go on to create and publish Flow, Flower, and Journey on Playstation.

While in college, he developed a game called Cloud, which “focuses on a young hospital patient who soars in his mind despite being trapped indoors” in an attempt to “expand the spectrum of emotions video games evoke.” He’d take this philosophy through to this day in developing Flower and Journey.

Flower was a game that he created to bring nature and serenity into the living room. He describes it as “an emotional shelter,” and “an interactive poem exploring the tension between urban and nature”. Jenova claims that the emotional breadth of most games is very limited, and that most games tend to explore the same few emotions- excitement, fear, tension, etc. Using Flower, and subsequently Journey, he seeks to mature video games as a medium and create works of art that mature video games to a level comparable to film, all the while exploring themes that are universal, rather than culturally specific.

Journey was an exploration of communication and social interaction in video games, that only gives the player their actions to communicate with the player. This includes movement, jumping, and “calling”. These barebones means of communication worked together with a gorgeous, awe-spiring setting and universally understandable journey to create a game that touched the hearts of many people, reaching critical acclaim. This is the game that has inspired me the most, personally, though Jenova Chen’s entire game design philosophy is something I carry with myself whenever designing a game.

I’ll end this blog post with a quote from Wikipedia that concisely sums up his approach to game design that I have adopted myself in playing and observing his games:

1 of 2: My Game Design Role Models

Ken Levine is a big name in the game industry, and the first game designer I ever really looked up to. He’s definitely most well known for his contributions to the Bioshock franchise – he was the lead director and writer for the original Bioshock, a game critically acclaimed for its storytelling and philosophical/sociological themes, as well as the creative lead, director, and writer of Bioshock Infinite. As a co-founder of Irrational Games, he’s also well known for his work on System Shock 2, on which he also was lead director, designer, and writer.

Ken Levine started his professional career studying drama in college, after which he attempted to pursue a film career. The tides quickly changed, however, as he entered Looking Glass Studios and began working on Thief: The Dark Project. After this project, he left Looking Glass to co-found Irrational Games, where he made the games he is now most famous for.

Nowadays, he is working with a stripped-down team of only 11 or 12 other people, focusing on narrative-driven games for Take Two, between his script writing for film and television. It has not been announced what exactly he is working on in the realm of games, however, he has given talks about his vision for a responsive, procedural game narratives. His vision for these narratives, according to his talk(s) at GDC, is that the player can form and break relationships dynamically throughout a game with multiple characters and factions, which drastically alter how the game’s story unfolds. This sounds a lot like the recent Shadow of Mordor game, but is much more technically in depth and narrative-driven, rather than simply having characters/factions remember the player and react to them in ways that don’t significantly alter the course of the game’s story.

Well it’s about that time. After pumping out a few game prototypes, it’s time to take some of them a bit further. One that I’ll be working on over the next couple of weeks is this game. It’s come pretty far since I made that post, but there’s still a lot of work to be done on it.

So far, I’ve made a “complete”, if lacking, experience. The game starts and ends and has a story arc. Something that I want to refine about that, though, is its pacing. The game’s climax comes way too quick, quicker than the player has a chance to get attached to the affected parts of the game, and the ending leaves the second player totally uninvolved. The latter was an artistic choice I now regret. The way I’ll be approaching solving this is creating another level before the game’s climax. I’ll also totally redesign/extend the game’s ending so that the second player can get involved in the largely first-player-centric ending.

Another tweak I need to make is balancing. The first player tends to finish their level long after the second player finishes theirs. This is difficult to balance because of the extreme asymmetry in gameplay between the two players, but I have some solutions in mind.

I also need to polish the game’s visuals. The game’s art style is less than coherent and not very attractive or stylized. I’ve never made 2D game art that wasn’t pixel art, so this is just something I need to practice. I don’t expect it to come out looking gorgeous, but refinement is needed, even if it just benefits my own skill more than the game itself.

Debugging in Unity is often done by logging some variables and strings into the Console to track what’s going on in-game. This is an indispensable tool for programming games, but as I found out today, they come with a price.

Believe it or not, Unity’s Debug.Log can come with a huge performance hit if you’re logging in the Update() or FixedUpdate() functions (or any other function that updates regularly at comparable rates). I just commented out two Debug.Log function calls, and my game’s performance skyrocketed from a barely-30FPS to rock-solid 60FPS, with Unity’s Performance Profiler suggesting that framerates exceeding 200FPS can be achieved if I were to lift the 60FPS frame cap.

My game has had a *ton* of lag, because I wanted to use animated textures for static (kind of like this). In order to do this in a way that was convincing, as well as have a gradient of different static textures depending on the game's state, I made a *ton* of textures (27) be loaded into each object. I used this many so then the 9 different states of the object will each have 3 frames of animation. This made my game slow to a crawl, as you could imagine, but I fixed it by using something that is probably only helpful situationally, but it has helped my game’s performance immensely.

First off, I got rid of 2/3 of those textures. Instead, I am animating my textures by using a continuous offset. This essentially just moves my textures down the mesh, according to its UVs. I set up my UVs so that this would work (each tree only has 2 different sections, so I put one on the left and one on the right so that vertical movement of my texture would keep everything in the right place).

So, that solved my animation problem, since I could simply use offset instead of replacing the image. But I still had lag, because all of those textures were always still loaded into each object. That's a lot of overhead.

What I did next was set my arrays of textures to only load the static textures once when they were needed, and dump them as soon as they were not.

Perceptive Shift (Working Title)

This is a prototype of a game I’ve been working on for about a month now (playable here). The primary game mechanic has been fully programmed and implemented, which includes swinging your axe at trees that are switching between dead and alive according to the rhythm of accompanying music. The game mechanic is a bit bizarre and seemingly pointless, but that’s because it’s just a prototype. More on that later.

My design had a number of changes during its development. The game was always intended to be infused with rhythms. At first , I had individual sound files sounding off at regular intervals depending on various states of the game in order to ensure that the game is in time with the game’s sound. Beneath these sounds would be the game’s ever-present auditory ambiance. That foresight actually ended up causing the exact problems I tried to avoid, though. There were often delays in the execution of these individual small audio files, so I opted for a different route. Now, a full music track plays when engaging in these rhythm challenges, and the game’s rhythm syncs with this music by operating depending on the game’s current position in the musical track. If I had started programming the game doing that, it would have been a much smoother experience. Oh well, you live and you learn.

I’ve also had to make changes in auditory feedback and direction the game gives the player in order to help the game’s usability. My ultimate goal is to remove directions from the game (almost) entirely and allow the game to teach the player how to play it itself, but that wasn’t quite in scope of this prototype.

Going forward with developing this game, it will be all about framing the game mechanic thematically. This game mechanic wasn’t just pulled out of thin air. It’s bizarre and clunky on its own without any thematic framework. So my priority now is sculpting this game prototype into a full somewhat-narrative work, that makes its themes and subject matter clear and gives meaning to the player’s actions. This game will have multiple levels, as well as multiple objects to interact with. I also need to adjust how the player handles the axe, because as it stands it feels unresponsive and delayed.

I’ve been taking a peak into the Grim Fandango puzzle design document and found that there’s a lot that I can take away from it and implement into my own design planning.

The design document begins with a Puzzle Structure, which outlines the general flow of puzzles in the game’s first year. It elaborates on the game’s puzzle structure, stating how it begins with linear puzzles coming one after another, and then progresses further with each successive batch of puzzles into non-linearity. The design document shows this best with a chart showing all of the beginning puzzles linked in a progression that branches out into a tree, re-converges, and then branches further until it all comes together again. The chart is a great way to organize a game with this kind of progressive quest structure. I think using flow charts like this can be indispensable even in other kinds of games, so long as they have both linear and non-linear segments. It creates a very clear “order” to the game’s progression that makes designing each segment much easier in that the game’s flow becomes much more digestible because of it. This is definitely something that I will be adopting in the future. I have dabbled in using things like webs (similar to page 4 of the document) to do semi-linear level design, but the directionality of this downward flow lends itself much better to sharing it in a document and being readable.

The game, being a narrative-driven point-and-click adventure game, naturally lends itself to a verbose, narrative driven design document, and that’s exactly what the puzzle document is. Since the puzzles are inextricably tied to the story, it’s best to include as much narrative detail as is necessary to best communicate these puzzles. I think this kind of design format isn’t just useful in this context, though.

One of the coolest things about this design document is that the majority of it is written as a story (which you might have been able to deduce from what I said before). It describes the player’s actions and their consequence in the game world and how the resulting puzzles are solved in narrative form. Perhaps this is only necessitated by the game’s design structure, but my takeaway from this is that that can (and maybe should) be used for a plethora of different game types. Textual markup of the intended player experience can be really valuable in the development of a game, for the individual creators and collaborating teams working towards a common goal for the player’s experience.

Here are the levels of my game when zoomed reaaally far out. Level 3 is currently being white-boxed.

It’s so beautiful :’) Photos by Michael de la Paz, which I found through ArchAtlas (easily one of my favorite blogs)

Apparently this is a pool, which is amazing to me. 

This is an untitled networked game I made. Very rough, no actual graphics that aren’t generated by code (I made this in Processing 3). The host (right) guides the client (left) through a world they are only shown for a few seconds each turn. The difficult part for the host, however, is that the map view changes slightly each turn, but the actual map does not.

For the player, landing on the black means death, while the green is safe. Gold is the key needed to win the game, which is accomplished by reaching the blue at the top of the screen. Throughout the game, the host’s view of the map covers some of the previously black tiles with a green tile, forcing both the host and the client players to rely on memory as well as the other player’s judgement to win the game. If you can’t reach the end by turn limit, that is loss. Death is simply a metric to measure your performance.

I’m not particularly proud of the design, because I regrettably put off the design of it until the day it was due (it was a class project). So the design wasn’t really something I was passionate about or really felt great about, and code-wise it was more complex than anything I’ve managed to program in just a week.