Nathan's Final Reflection
Nathan Wu
Professor Elena Bertozzi, Professor Sarah Stevens-Morling
Art of the Game
Final Reflections Essay
It’s currently 6:08 a.m., Wednesday May 9, 2018, but despite the time I feel great –
because my game has reached its final stages!
Designing a game from scratch was a truly one of a kind experience that I would not have gotten to experience had I not just whimsically signed up for this class. Actually to be honest, I initially wasn’t going to take this class because I was interested in taking more traditional courses towards my major, but then my Freshman Counselor pointed out to me that this was my only opportunity to take a freshman seminar, so under his suggestion, I picked one. Initially, my first choice was “The Science and Politics of Cancer”, but at the very last day of preregistration, I decided to switch my number one preference to Art of the Game. And it was one of the best decisions of my life!
The process of creating this game was truly a journey. I didn’t really have a concrete idea of what sort of game I should create going into this class, but I clearly remember the starting point for my character came from Chapter 1 Character Shapes and Poses of Chris Solarski’s Interactive Stories and Video Game Art. In this chapter, he mentions many aspects of how shapes can influence people, such as describing characteristics that we almost intrinsically associate to shapes. For example, he attributes the circle with innocence and the triangle with aggressiveness, and he explores how different combinations of these shapes in different settings play pivotal roles in defining a character, environment or mood (Solarski, 2017, p. 3). This idea was especially important to me because as someone who is generally lacking in artistic ability, capitalizing on any intrinsic associations we might have as people would be beneficial to me in making my game compelling. Even in the final product, I wound up keeping extremely simple art design (although to be honest, even the art featured in my game was really complex art for me). Solarski’s chapter on dialog got me thinking about what sort of things I would need to do to communicate effectively with the player. Should I make a dialog-based game, or even a narrative/story-based game in general? Solarski’s chapter on dialogue covered a wide variety of ways that game creators and the players communicate, besides just traditional player-NPC dialogue. He discusses specifically the two cases of Minecraft and The Witcher 3 as examples of games where communication is not driven by dialog as much as it is by gameplay expression (Solarski, 2017, p. 47). To clarify, the amount of freedom given to the players in these two games allows the player to express themselves in a wide variety of different ways, and the point is that it isn’t necessary for there to be an explicit dialog-based story driving the action behind a game. This point was really inspiring to me, because while I felt story/narrative is a compelling part of any game, I had my doubts about me personally having the ability to come up with a compelling dialogue-driven narrative. Thus, my biggest takeaways from the chapter readings that we had to do throughout the semester was to seek other ways of engaging the player if I wasn’t going to be able to do that through exceptional art or exceptional storylines.
I eventually decided on game mechanics to be how I would “sell” my game. I didn’t believe I could draw well enough or tell interesting enough stories to compel the player, but maybe the mechanics that I would implement would be sufficient to capture the reader’s attention. This sort of thinking was especially encouraged after I played Universal Paperclips, where the storyline was secondary, and the art was minimal, but the game mechanics and game design made this game addicting. It illustrated to me that it’s possible to build a game around a simple game mechanic (i.e. click buttons!) and have it be compelling. Getting Over It was similar in terms of having relatively simple mechanics, and Her Story if anything solidified my belief that a story-based game was not the way I wanted to go. I thought that Her Story was not a great game, and it just illustrated to me that storylines can be hit-or-miss, but everyone loves a great game mechanic.
Throughout this essay so far, I’ve mentioned a lot about game mechanics and gameplay and whatnot. As is unsurprising, creating good gameplay mechanics often involves a lot of coding (and this proved to be true), but coming into this class my computer science background was almost zero. I was concurrently taking the intro cs class here at Yale, and Art of the Game really pushed me to the limits of self-studying code, which I thought was fantastic. Although it was super frustrating at times when code doesn’t work or you don’t know how to implement something, I think Art of the Game taught me that it’s important to go out and learn for yourselves the things you don’t know, rather than waiting for someone to teach you. I have a love-hate relationship with the Unity API’s now, but I definitely think the CS experience was extremely rewarding, especially as code started to come together. Some of the code specifically that I implemented that I thought were the most challenging were sprite changing, passive health healing, and projectile damage. The common theme between all these codes is that the concept sounded a lot easier than the implementation turned out to be, which was extremely frustrating! However, I believe that having to deal with these constant setbacks and frustrations really helped me become a better problem solver, and definitely a lot calmer when it comes to failure as a person.
Something surprising to me that I learned about myself over the course of this project was just how much I enjoy drawing! I always knew that I wasn’t terribly adept at drawing, and even after taking this course unfortunately, I wouldn’t say my drawing skills have improved substantially. However, the actual process of drawing on photoshop, on paper, etc. I thought was very calming and very enjoyable, definitely very different from the more hectic problem sets that I usually deal with for other classes.
Going a little bit more in-depth to the choices I made in the creation of this game, I chose to focus on relatively cartoonish art (because that was the best I could personally do), and because of the cartoonish style, I felt the need to throw in a little bit of humor somewhere. That’s why during the course of the game, you might find somethings that aren’t super logical (e.g. colored clouds, some walls are actually not solid and you can walk through them). I felt at the time that these choices contributed aesthetically/positively towards the game in keeping with a light-hearted theme. However, I think based on the end message of the game that I decided on (e.g. strength isn’t what’s on the outside, it’s what’s on the inside) wasn’t very consistent with this idea. If I had to do it again, I would choose to either go full whimsical or full inspiring/serious because I think trying to accomplish both just resulted in mediocrity for both aspects. Furthermore, in terms of coding choices, I definitely would have taken more time to plan out my code, because there were many times while I was coding that I wished I had separated these functions into a different class, or that I wish I had a separate object that encapsulated these variables, and that led to a lot of inefficient and inflexible code.
Although those are choices that I might have changed given another chance, I did change some aspects of the game (actually a lot of the game) in response to the feedback from teachers and students. The most obvious feedback was that art was lacking in my presentation, but that was a relatively straightforward fix. Noah mentioned that the game seemed a little bit, as in he didn’t know where he was going, and Tucker suggested I zoom out the camera view, which I did, which improved the clarity of the game a lot because you could see more of where you were going. I think the most important criticism that I received and personally observed was that my game just seemed to lack direction. Initially, my idea was to have a speed run and the player’s desire to complete the game as fast as possible would be the impetus for the player to play, but after playtesting it, after asking friends to playtest it, I discovered that the speed run idea just wasn’t compelling enough. Because of that, I added two major things to increase the “direction” of the game. One was adding in enemies, namely cartoon triangles and rock-looking figures who threw some unnamed projectile at you (and you fired back at them). This gave the game some added depth by adding a sense of “agency” in that you are fighting against someone/something, which makes the game feel more engaging (i.e. no longer just passively wandering around the world). This simple combat aspect also allowed me to introduce my interesting mechanic with regards to health, in which you wouldn’t actually die if you had no health, but your speed and jumping abilities would be severely affected (lower health = less speed and jump force). There’s also a visual cue of a green health bar that shrinks as you get hurt and increases when you (passively) heal. Furthermore, the addition of passive healing to the game ensured that you wouldn’t ever just be crawling around the game at a snail’s pace or be unable to complete it (the course was designed in a way such that with your base run speed and jump force, you could complete the game). This was such a pivotal design choice for me because it allowed me to preserve the idea of trying to complete the game as fast as possible (I really like speed runs!) but also introducing an extremely engaging element towards the game with some interesting mechanics.
The second major element I introduced to address the issue of design was adding a little bit of a backstory to the game. It’s definitely very bare, but I felt it helped because it gave you some context as to why you’re in this world fighting enemies (you’re training to stand up to a bully) and then there is a payoff to completing the course (you get to fight the bully and beat him up). I threw in a little bit of whimsical humor there in terms of the progression of the bullying as well to add in a tinge of extra spice to the game (although as I discussed earlier, it may have been misplaced).
I also want to thank a lot of people who helped inspire me. Watching Alan’s combat system made me realize that combat is really engaging and that I wanted to incorporate that. Bryan and Tucker’s infinite spawner mechanism turned out to be something I would also use for shooting projectiles (although I never looked at their implementation for that and just came up with my own), and Patrick for his ice mechanism, which for some reason I really just liked (I have my own ice platform in the game). Tucker’s discussion of audio for his bees also reminded me to implement audio in my game (although unfortunately I never could get my own self-composed audio to work because I could never correctly convert the MIDI files).
In summary, I think producing this game from scratch gave me a lot of insight into many different things, from game design to programming to art, and I think most of all, it definitely stimulated my intellectual curiosity, and I found every moment working on the game to be enjoyable!
As a short summary of all the game mechanics that I used:
Sprite Changing, Color Changing, Fall Damage, Moving Platforms, Projectiles, Health, Visual Health Bar, Damage, Infinite Spawners, Audio (background music and play on clip), Scene Changes/Buttons, Passive Healing, Stopwatch.
As you can see from the list above, I definitely learned a lot of different techniques on the coding side (and no less on the art side, I just don’t know what to call them). I also would just like to explicitly state some lessons I learned from this game:
1) Always draw art in the highest resolution possible because you don’t know if you may have to resize your sprites
2) Plan your code!
3) Everything always takes way longer than expected
4) The Unity Game Engine has a lot of shortcuts for certain types of code
5) Don’t use filler art for too long, because when you import in your real art, it messes up a lot of your animations/sizing, etc.
6) Debug.Log statements are your friend
7) Ask other people for their opinion on your ideas
8) Ask yourself hard questions about your game design (is it compelling?)
early rather than later
And there are many many more!
Finally, I just would like to say thank you to Professor Elena and Professor Sarah for teaching this class—it was a pleasure! One suggestion that I might have for the course is to allow the students more time for self-exploration in class/work on their games because I think a lot of the Unity Engine can be learned through self-discovery and for art, you don’t really know what you don’t know until you try to implement the art techniques yourself. But overall it was a fantastic class!
Citations:
Solarski, C. (2017). Interactive stories and video game art: A storytelling framework for game design. Boca Raton: CRC Press.
Special credits to the following for music from freesound.org:
amrboghdady
Mrthenoronha