Skip to main content

Context

Easel has a powerful feature called context which, when used right, allows your code to be more succinct and easier to read. When overused howver, it can introduce unintended bugs. Because context has implicit effects in your code that you cannot immediately see, these bugs can be difficult to track down and fix. Good practice around context is needed to avoid these issues.

Choose a limited set​

In your project, you should have a small set of context variable names that you use everywhere. Outside of this set, you should not use context at all. This way, you know what to expect, and you can avoid unintended bugs.

Here are some examples of common context variable names:

  • Roles: unit, projectile, scene, dialog, owner, body, ui, camera, space
  • Common parameters: radius, color, luminous, sharp

As you can see above, context variables tend to come into two sets. Roles are used to describe the role of an entity in your game. This is a topic in itself, see Roles for a more in-depth discussion of this topic. Common parameters refers to simple values like color that can be accepted by many different functions in your game.

Deciding what to include​

What criteria you should use to consider whether to include a variable in your limited set of context variables? To answer this question, we will look at the luminous parameter as an example. If you are unfamiliar with it, the luminous parameter is used to turn on additive blending for graphics, which makes it look like they are made of light, rather than paint.

Here are some reasons why luminous makes a good candidate for context:

  • Same meaning everywhere it is used: The luminous parameter is accepted by most graphical functions in Easel, including ImageSprite, Spark and Streak. In all cases, it always turns on additive blending. There are no alternative meanings of the parameter. So if we make luminous a context variable, it is clear what it does because it always does the same thing.

  • Same value for entire entity: If something is luminous (say for example, a Laser), then normally every sprite, spark or streak that comes from it should use additive blending. The entire laser is made of light, so if you forget to set luminous for one spark, it would look out of place. It does not have different values for some parts of the entity versus others.

  • Commonly used throughout the project: In addition, luminous is a parameter which would be used by many entities in a game. For example, a single spellcasting game might have a Laser, Lightning Bolt, and Fireball, all of which are luminous. It is a parameter that would be used so often that we are unlikely to forget it exists. That means, when we encounter bugs, we are likely to remember that luminous is a context variable, and so we are likely to check it when debugging.

If you follow these criteria, you will end up with a small, manageable set of context variables that are used throughout your project. This will help improve your code's readability and iteration speed, while avoiding unintended bugs.