Critiquing a Book’s Paragraphs

When was the last time you heard or saw people arguing about how a book’s paragraphs could be formatted? What about camera maintenance for this movie? How to make the high-hats better on a music track? What type of brush a painter should use to finish off their latest project?

… and how about people arguing over how to code something in a game?


It might just be sampling bias, but I see more people argue about how to code a thing in a game than I see argue about minutiae of producing all of the other things put together. Moreso, these arguments are more often carried out by people with limited experience in coding / game making than relevant critique in other fields. I think this is something we need to work on.

Last night I was reading a suggestion on the Heroes of the Storm Reddit, where suggestions and “solutions” are tuppence a bag; an argument started about whether and how a change to one of the maps should be made. The argument discusses the map Haunted Mines, which is unique in the game for having two halves of the map (“upper” and “lower”) which don’t have direct paths between: only interactable portals which teleport the players.


The minimap on Haunted Mines, showing both halves of the map. The yellow huts show locations of the portals between halves.

The argument consists mostly of the following statements repeated with varying intensity and nuance:

  • On the map Haunted Mines, if I click into the lower half of the map from the top half, my character won’t path there automatically.
  • Hey, wouldn’t it be great if we could click on the minimap to automatically path to the portals which take you to the other half.
  • That’s easy, you just have to make the game check whether you’re going there and redirect you to the portals.
  • Hey, that’s not easy because modifying the game engine is hard!
  • No, it’s easy, look here’s a list of requirements.
  • No, it’s hard, because game engines are complicated.
  • Et cetera.

It’s rather typical of discourse around games that it’s devolved into little more than gainsaying. Some friends of mine (I’m looking at you, Alt!) have chosen to see this as an example of the gaming community being so entitled that they want to tell Blizzard how to code their game. Knowing the recent history of the gaming community, I sympathize with the position, but there’s more to it than that.

One of the interesting questions I’ve seen raised in one of the more eloquent regions of gaming critique recently is that even many highly experienced gamers aren’t actually very literate in the details of what games are and how they work. While I’d expect someone who goes to the cinema thrice a week to know something about shots, framing, or whatever, I wouldn’t expect a “hardcore” gamer to know much about what a collider is or how object-oriented programming works.

I think this means that gaming discourse tends to draw from whatever little the writers do know about games and coding, which is often more to do with marketing than with actual technical stuff. There’s a feedback loop between lack of participation in the medium, lack of honest coherent critique of it, and lack of interest in coherent critique. The latter is the lynchpin; when people don’t see value in learning from honestly desconstructing ideas and learning from their mistakes, fewer critiques are taken seriously and thus less is made.

Screenshot2017-03-29 10_27_18

WTB friends for pictures next time.

Let’s return to the argument at hand, shall we? I made a suggestion, aiming to think about the problem more critically. Firstly, we have to accept that it’s unlikely that an engine-level change will be made for a small quality of life change. Those pointing out how much work (and how many knock-on effects) this would require are correct. But here is where limited literacy is important, because the point misses something: you don’t have to change the engine to change the map. As an exercise of interest, I started thinking about how one might change map-specific code to get around the problem.

(1) Why doesn’t the player path to the other half of the map? – Because there’s no nav mesh joining the two regions. So join the nav mesh up. Now players can path between map halves, and the engine will already automatically find the fastest route.

(2) Now players will just walk over “nothingness” to the other half of the map. – Okay, so we need to introduce colliders around the new navmesh which block movement but don’t interfere with the nav mesh. I presume that this can be done without causing too many problems with other mechanics in the game, given judicious choice of previously implemented code.

(3) Now there’s no way to actually get there automatically. – A script can be added to the portal which does the following: “IF there’s a player in range AND they’re pathing to the other half of the map THEN automatically start the portal channel“.

(4) This requires the portal to know where the player is trying to get to. – I would assume that this is accessible through a suitable method call on the player object. Something like player.Get(‘”destination”).

So, as a person entirely unqualified to program a major AAA game I have used my critical thinking to come up with a solution. At this point, it’s important to recognize that it is; (a) probably wrong, and; (b) probably naive. By thinking about how my solution breaks and why it is difficult to bring to Live (hint: requires a lot of testing!), I learn more about games. The important step that makes this useful is recognizing that I probably won’t get it right, and being humble enough to learn from that. This comes directly from my appreciation of what value critical thinking has, which in turn I’ve gained from many years as a scientist.

I don’t think the problem here is a lack of entitlement, rather than a lack of the humility to allow oneself to be wrong and still do the thinking. Society could do with more of that [cough, cough, cough].

It is the mark of an educated mind to be able to entertain a thought without accepting it.

–  Aristotle

Screenshot2017-03-29 10_30_09.jpg

About stoove

A physicist, researcher, and gamesman. Likes to think about the mathematics and mechanics behind all sorts of different things, and writing up the thoughts for you to read. A competent programmer, enjoys public speaking and mechanical keyboards. Has opinions which might even change from time to time.
This entry was posted in Game Design. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s