To introduce the writing I’ve done for this project, I will say that video games are a hobby of mine, with Nintendo as my favorite game company. I enjoy playing games as well as writing about them. My love of video games and preference for centering essays and projects on the things I care about is what led me to the <canvas> element for this project. I also consider myself to be above an average skill level when playing the games I play regularly, and I enjoy looking into and understanding the underlying mechanics of a game and how they create a unique experience.

For all this time I spend playing games, I had never done much thinking about the subject from the perspective of the game developer, the ones who conceptualize and create these games that I love so much. If I ever thought about the methods and practices a game developer would follow to create a game, I only considered the concepts and ideas that affected the user’s experience with the game. I thought of vague ideals that the developers writes line after line of code to achieve, such as “never leave the player stuck in a level with no way to escape” or “use collectible items to guide the player.” My familiarity with usability and user-centered design through my major in Technical Writing certainly reinforced this line of thinking.

What I had never really considered until embarking on this project is that in the realm of game development, especially within the growing scene of game development within <canvas>, far more discussion takes place on how to write that code in the first place. Pursuing an ideal game design, it seems, doesn’t work very well if you can’t design a game in the first place. Techniques for optimizing written code and the proper ways to implement common game elements like gravity and collision detection make up the bulk of my findings on <canvas> game development discussion. Game developers working in <canvas> discuss the ways they can get these older, accepted elements of game design into this new environment.

Using Christina Haas’s extension of Vygotsky’s historical-genetic method onto technology as a framework to examine <canvas> and game design, the difference in my prior views on gaming and what I found as I delved into the development scene have a clear explanation. Vygotsky’s method argued that in order to understand an artifact, you had to study the context surrounding the artifact and the history that led up to it. Haas builds off this concept and applies it to understanding technology and literacy in the 20th century by arguing that understanding literacy requires understanding the technologies that support it in the past, present and future as well as how its media are similar to and different from the media that came before.

More importantly for my work here, Haas makes the assertion that a technology’s uses are closely tied to the other things we humans do, and our views of a technology are shaped by how we use it. A person’s knowledge of and needs from a technology form a context that informs how that person engages with it. This was critical for my understanding of video games, <canvas> and the discourse around them that I researched for this project. I primarily play games, so I think of practices that affect the player’s experience. A game developer primarily creates games, so he or she would think of practices that affect the creator’s experience. This can be extrapolated to how different groups use <canvas> as well; a video game developer’s uses <canvas> for different kinds of work compared to a web developer, so each group’s views about what aspects of the element are important differ as well.

Overview: What is the <canvas> element?

The <canvas> element creates a rectangluar space on a web page for a developer to manipulate JavaScript to draw graphs and animations as well as handle photo compositions and video processing. The element itself is easy to form in an HTML document. The only code needed to build a canvas is a call for the element and settings for the width and height. Once formed, a developer calls the canvas from the Document Object Model (DOM). This creates the canvas's drawing context, where the drawing methods and properties used for the canvas itself are defined. Now, JavaScript code and even CSS properties like fileStyle can manipulate the canvas.

The <canvas> element actually can be used to create video games to be played in a web browser. JavaScript code is used to build the game elements, such as a player character, an image background and game rules such as win conditions and collision detection, which display to the player through the canvas. As one could imagine, browser games built in <canvas> are quite the different experience compared to more traditional video games played on a PC or a dedicated game console. <canvas>-based browser games are normally the domain of smaller, independent “indie” publishers in today’s video game scene.

Check out a simple game scenario written using <canvas> and JavaScript here.

History and Significance of <canvas>

The story of <canvas>'s development begins in 2004, with Apple developing the tag for use with their own Safari browser and OSX WebKit component to operate Dashboard items. According to WHATWG specification writer Ian Hickson, Apple developed and introduced <canvas> to the Web "without going through any sort of standardization first (not even unofficial standardization like the WHATWG)..." (Hixie, 2004), though WHATWG eventually did standardize the element. By bringing in JavaScript, <canvas> greatly expanded what kinds of graphics web developers could use for their pages. Yet, even before <canvas>, web developers have already been building graphics features into websites. Web developers at Apple built this element as a way to streamline and facilitate this work already being done.

As relatively new as <canvas> is among web technologies, using it for game development is an even newer idea still. Game developers who would use <canvas> to do their work have only recently joined in the conversation about the element’s development, and because of this they don’t have much power in how <canvas> will continue to develop. Discussions saved on the W3C mailing-lists support this observation, with features that function fine for web development and other web work being preferred by the well-established web developers, even if those features interfere with video game functionality.

Yet, therein lies the great thing about <canvas>; game developers and gamers are now a part of the web development scene. Thanks to the capabilities of <canvas>, a group that was external to web development in the past has now been invited to join in, to have an influence on its present form and a stake in its future. In addition, game developers bring new ideals and practices on how web development work should be done, which will take <canvas>’s development in a new direction, perhaps different from its original intent, yet just as important and valuable for the element’s history and context.

The scenario surrounding <canvas> serves as a demonstration of a larger phenomenon; HTML as a whole has changed based on the people and groups that have entered the web development scene, who have brought their own ideas of how it should be into the discussion and have done the work to implement them.

Trends & Practices

As a part of this project, I conducted research on sources on web browser and <canvas>-based video games to determine what some best practices were for three key aspects of games: the visuals, player movement (specifically jumping) and enemy behavior. I decided to focus on game practices within the context of games in the platformer genre.

Practice 1: Visuals

Practice 2: Jumping

Practice 3: Enemies

Summary: A Connection to Older Video Game Forms

As I’ve said before, game developers have only recently been invited into the web development scene, and most of the work to develop standards and practices for video game development has already taken place in older game and game forms. In my view, no discussion on how to build a platformer game is complete without a mention to one of the most influential platformer games, and arguably video games in general, of all time: Nintendo’s Super Mario Bros., released for the Nintendo Entertainment System (Famicom in Japan) in 1985. The game that established Nintendo as a dominant player in the North American video game market for years to come and kicked off one of the most successful game franchises ever, Super Mario Bros. also introduced many concepts and practices that endure in platform games even today.

In a recent interview with gaming website Eurogamer, lead designer and creator of Super Mario Bros. Shigeru Miyamoto and fellow designer Takashi Tezuka shared some insights into how they and the design team created Super Mario Bros., pointing out some practices they followed as they created the game’s levels. Most of the practices and ideas they discuss here don’t relate to how to literally write and code a game, but rather how to create an experience for the player. While these are kinds of practices I expected to see based on my perspective that I detailed earlier, it’s still different from the literal-writing perspective I came to expect from game developers as I conducted my research. This may have an explanation, however. Given that writing code for the 30-year-old NES isn’t very relevant today and their audience is likely not familiar with the inner workings of that console, Miyamoto and Tezuka may have avoided talking about the code writing itself, favoring the design ideas that went into the game instead.

Miyamoto and Tezuka discussed the design of the first level of Super Mario Bros., World 1-1, for a majority of the interview. In particular, they demonstrated how the very first section of the level functions as a tutorial for how to engage with the rest of the game. They simulated what the player would do and placed items and elements based on those observations. A suspicious enemy, the Goomba, approaches quickly, so the player must jump on it or above it. Then the player sees the ? Block hanging in the sky. They jump from below to try to tap it, and a coin appears. This is pleasing, so the player tries again on the next ? Block nearby and a Super Mushroom appears. The player touches it and Mario grows from his small form to his big form, and that’s even more pleasing. Even in this small section, the player engages with enemies, power-ups and the many uses of jumping.

Speaking of enemies, Miyamoto and Tezuka reveal how they designed some of Super Mario Bros.’s enemies in the context of World 1-1. Early in development, the most basic enemy was the Koopa Troopa, a turtle that needed to be jumped on and then ran into from the side to be defeated. As the basic enemy, Koopa Troopa was the enemy that originally appeared at the beginning of World 1-1. However, Miyamoto and his team “thought it might be a little too difficult for the player to jump on and then kick it.” (Eurogamer, 2015) To address this, they created the Goomba, a simpler mushroom-like creature that only needed to be jumped on to be defeated. The Goomba came to be because of a user issue that Miyamoto and the rest of the Super Mario Bros. design team foresaw. In my interpretation, the Goomba serves as a useful introduction to the Koopa Troopa itself, as the player will be familiar with jumping on other characters to defeat them through their interactions with Goombas by the time they encounter a Koopa Troopa.

Mario’s jumping in this game is really distinct in this game with the way his momentum influences it, and Miyamoto and Tezuka discuss why they designed Mario’s jumping that way and how they built the environment of World 1-1 to introduce it to the player. In Super Mario Bros., the player can hold the B button to make Mario run, and Mario jumps higher when he jumps during a run. Mario also slides quite a bit when landing after a jump performed this way, even if the player stops inputting on the Control Pad. Miyamoto explains why they implemented this ‘slippage:’

Super Mario Bros.‘s designers felt that preserving some of Mario’s momentum when he lands from a jump would convey that feeling of weight they were going for, with Miyamoto adding, “Even with this one flat-surfaced image, adding weight helps the player believe it’s a real character.”(Eurogamer, 2015) And to introduce this concept to the player through World 1-1, the level has a gap that requires Mario to gain a bit of speed in order to clear. That gap has solid ground beneath it, allowing the player to try again even if they fail. With this, the player can master the jumping concept in a safe environment before moving on to the next similar gap that has no safety net.

These kinds of practices are not the kind that I saw shared throughout discussions and showings of game development in <canvas>. Yet, they do appear one way or another in many of the <canvas> games I encountered during my research. Preservation of momentum after a run and a jump and a natural progression of more and more complex enemies are the kinds of practices that aren’t discussed by the <canvas> game development community but still show up in their games. Perhaps they and other similar practices aren’t discussed because, after their success in Super Mario Bros. and many games after, they had become best practices by the time game development in <canvas> became possible. They became the kinds of practices game developers agree upon and bring with them as they enter the web development scene.

Conclusion

Throughout this project I have endeavored to show how game developers have done their work prior to <canvas>, how they’ve entered web development through <canvas> and how they adapt the work and practices they’ve done before into their new space. The final point to consider about game developers and HTML is the effect the former has on the latter. I think it’s too early to tell what impact game developers will have on HTML’s development. The big effect that I predict game developers will have is proposing changes to <canvas>’s functionality in ways that facilitate gaming and starting more discussion on <canvas>’s features and specifications that already do that. But, I also think that game developers need to spend a few more years working with HTML and web writers before they can step up as prominent voices in this community. Until then, the current prominent voices and the already established implementations of <canvas> will dominate the discussion. Conversations saved in the W3C mailing-lists support my hypothesis, as seen in this discussion on <canvas> GPU acceleration: (W3C, 2012)

"It seems to me that one way or another we have to break something. Canvases drawn into once with no animation loop may go blank with GL-based hardware acceleration, whereas most video games will not function properly without it. I much prefer the former to the latter."

"No, we can't break the current implementation. It's perfectly reasonable for an author to draw into a canvas once and expect that the browser will manage it properly.”

One very important thing to remember about HTML and even technology and tools in general is that all of our knowledge on how to use it and how it should be used isn’t naturally formed. This stuff doesn’t just come to us out of nowhere and already figured out; humans had to create these tools and technologies, and they had to figure them out through using them and learning from other humans. Similar to the claims of Vygotsky and Haas, there is no one true way to write HTML; the context that the writer operates within determines the best practices to use. When a group of people enter the HTML and web development scene and begin doing their work with current HTML, as game developers have done, a new writing context is born, and with it a new vision on what HTML is and should be. Thanks to changes like this, the context that HTML now exists in is very different from when it was originally developed. For game developers, the <canvas> element bridges the gap from the environment back then to the current day, from a context that didn’t represent game developers to one that does.

Similar to the efforts of game developers working in <canvas> to gain prominence in the HTML scene, they also strive to succeed in the realm of gaming. Games developed for the web are relative newcomers here, having only gained a foothold aided by <canvas> in the mid-2000's while industry giants like Nintendo and Sony have been operating with dedicated consoles for decades already. The majority of discourse in gaming revolves around these few big names, with "indie" developers off to the side.

Still, it seems to me that browser games have grown very quickly in terms of what they are capable of, and have a few advantages to tout over more traditional forms of gaming. While not developed with <canvas>, the browser game Pokémon Showdown! uses JavaScript to faithfully recreate the battle gameplay of the Pokémon games, while adding a ladder-based random matchmaking system that lets a player battle with other players on the site. Feats like this show that browser games are capable of matching up with even the most popular console titles of today.

Geoff Blair, co-founder of web-based game company Lost Decade Games, describes ease of access as an advantage for web-based games; "People can just play your game right away..."(Intel, 2014) as opposed to needing to purchase a physical copy from a retail vendor that requires the proper game console to play it. Yet, being a web-based independent game company in the current gaming realm has struggles as well, and perhaps a reason why newer web-based developers aren't in the main spotlight; Blair states that smaller companies "have to bring a lot of their own traffic" (Intel, 2014) because they aren't already in the public eye, and that "just having a game that plays in a web browser is not enough to build a product on." HTML5 and <canvas> make it easier than ever to develop a game and distribute it to others, but one small game will have difficulty standing out amongst multitudes of browser games like it, let alone the biggest releases from a company like Nintendo.

In summary, the <canvas> element represents an exciting new development for video games, both by bringing game developers into the HTML scene and, incidentally, HTML into the video game scene. This one element brings two previously unrelated groups together, and the practices they each abide by now influence the development of the other.

A Blank <canvas> to Play With: A Historically-Grounded Examination of the <canvas> Element

By: Andrew Burke

What is this project?