A Blank <canvas> to Play With

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

Enemies

In platform games, enemies are antagonistic characters controlled by code patterns or artificial intelligence that exist to impede the player’s progress. They accomplish this in a few different ways. They may be simple pawns for the player to pummel on their way to the end of the level, a very threatening presence that must be removed to proceed or even the key to solving puzzles. They can serve as distractions to complicate difficult jumps or resources needed to defeat other enemies. Usually, enemies are the primary obstacles the player interacts with as he or she progresses through a level, occupying the terrain the player needs to traverse.

Once again, my perspective as a gamer and not a game developer informs the practices I thought should be applied to designing enemies in platform games. When I think of enemy design, I think of practices like “only have a few enemies on screen at a time” and “don’t make the more difficult enemies just faster or stronger clones of basic enemies.” I also find the actual appearance of the enemies to be important; having multiple enemy types that are just recolored versions of one another isn’t interesting.

However, over the course of working on this project I feel that I have a slightly better understanding of how to write game elements in code. Thinking about the kinds of code writing practices I would expect to see, I’d expect that the same code and variables that determine the player’s position on the canvas and how they move also works to position an enemy. Also, I’d expect that a best practice for writing the collision detection of an enemy would be to write separate code methods for different types of collisions. (For instance, running into an enemy from the side hurts the player but falling onto the enemy from above defeats the enemy.)

Some of the code writing practices I expected to see did turn up in my research; variables for components like velocity and gravity that move the player also move enemies. One particular practice that I noted was the use of a technique used for instances of many enemies being on screen at once called spatial partitioning. This technique "involves partitioning a game's space ino cells, so that only sprites in the same cell can possibly collide." (Geary, 2015) This optimizes the game's collision detection when it has many sprites to manage at once, like the presence of many enemies on the sceen. The presence of a practice like this defied my expectations; I thought game developers would prefer to avoid having that many enemies on screen in the first place. The fact that game developers in <canvas> have adopted spatial partitioning to facilitate having a lot of enemies on screen may mean that a high quantity of enemies isn’t seen as the bad practice I see it as.

Click here to return to the home page.