#templating

Sometimes when defining very similar objects, it can make sense to generate them all at once. For example here is how 3 classes of similar functions can be generated from an array and a single class definitions:

const classTypes = ['A', 'B', 'C']; for (let type of classTypes) { global[`class${type}`] = class { [`describe${type}`]() { return `A class of type ${type}`; }; } } const objA = new classA(); console.log(objA.describeA()); // A class of type A const objB = new classB(); console.log(objB.describeB()); // A class of type B const objC = new classC(); console.log(objC.describeC()); // A class of type C

global should be whatever the top level value (or object) that you want to attach the classes too. So window for browsers. In most cases, method names would remain the same across all classes, but I wanted to demonstrate that like everything else, those can have a unique name directly input.

I could not find a direct compatibility table of the support for those dynamic method names, only general support tables](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Method_definitions#Browser_compatibility). So instead I verified the above works manually with window in the latest Chrome, Firefox, Safari and MS Edge in addition to Node 10+ with global.

Yes, as long as nothing has changed its creature types.

Goblin Warchief is a Goblin and it gives all Goblins you control haste, so it gives itself haste.

Goblin Warchief is a reprint from an earlier time in Magic’s history where these sorts of abilities were common. Were the card being printed for the first time today, it would likely have “Haste” and “Other Goblins you control have haste.”

Using Prefabs in Cogmind’s Map Generation

Josh Ge, the developer of the roguelike Cogmind (and X@Com) posted a writeup about the use of prefabs in Cogmind’s map generator, and I thought it would be a great springboard to talk about the use of prefabs in general.

I’ve mentioned them before in Dungeon Crawl, but ADOM, Angband, Spelunky, and other roguelikes also make heavy use of vaults/prefab elements. It’s one way to make stuff stand out from the oatmeal and introduce statistical spikes to break things up.

Josh gives us an in-depth look at how you can implement a generator that incorporates prefabs. It includes big level-defining anchors added at the start and room-defining presets applied after the basic layout is in place for more interesting encounters. Note that the prefab templates allow for a lot of variation (like Spelunky’s rooms) including rotating and mirroring.

Cogmind uses the prefabs to implement encounters and tactical challenges, which is a smart application of the technique. Using prefabs in this way can be thought of as a generalization of action set-pieces in more conventional level design. Rather than laying out the specifics of one unique encounter, you can describe the general parameters of the challenge and let the player encounter many variations. (Spelunky uses this to great effect.)

Prefabs are also a way to add landmarks. It’s difficult to make a map generator that has unique content that stands out enough to avoid being lost in the mush, but otherwise bland content makes for excellent connective tissue between the more unique landmarks that grab attention.

Another way to get unique landmarks is to have multiple generators, with a few being rarely invoked, as with biome generator. But prefabs are cheaper and can be combined with other techniques. Particularly if your prefabs can have other generators nested inside them.

The encounter system also touches on something else I’ve been thinking about lately: generating abstract systems. Games and simulations usually have a lot of invisible systems that aren’t directly reflected in the visible map space: tech trees, combat rock-paper-scissors relationships, economic systems, and so on. But, with a few exceptions, these are not things that procedural generation is commonly used to make.

But there’s no reason not to use procedural generation to make them. Indeed, many of the biggest procedural generation games have precisely the weakness that their generation is visible and physical, but that the gameplay systems aren’t subject to the same variation. Procedurally-generated gameplay is an under-explored area.

Heart-Piercer Manticore’s triggered ability is one of those cases and my previous post about it here was incorrect. (It has since been deleted.)

So, Heart-Piercer Manticore’s triggered ability is a new style of template where a triggered ability can can set up another triggered ability based on a choice that’s made. (This has never been the case before, and that’s why I was caught out.)

When Heart-Piercer Manticore enters the battlefield, its ability triggers and goes on the stack. You don’t make any choices at the time you put the ability on the stack. When the ability resolves, you have the option to sacrifice another creature. If you do sacrifice a creature, then the nested trigger triggers and you choose a target creature or player for the nested trigger when it goes on the stack. The creature has already been sacrificed at this time and thus your opponents will know how much damage the trigger will deal to its target when it resolves.

You can actually target zones, but only one card (Circu, Dimir Lobotomist) has ever done it.

The most basic description of metaprogramming is code that writes code.

Anytime you write a program that outputs code you are metaprogramming, and this is, actually, a lot more common than you might think if you're new to the concept.

Metaprogramming is useful when you realize that what you are doing could be parameterized if only you could pass the name of a function you want to call as a string. Or, to use terminology from a post by Vedant Agarwala, any time you realize that you need to use parts of your program as data.

From personal experience, metaprogramming is dead useful for Object-Relational Mapping (ORM). If you use metaprogramming in certain circumstances when you are dealing with code generated by an object relational mapper you won’t need to frequently hand write additional, remove, or alter code every time you add, change, or remove some object or attribute in your database.

Metaprogramming is also what’s used to generate ORM code in the first place.

In addition, if you have ever used any kind of templating engine, for example, to server-render HTML that’s then sent to a browser—that’s metaprogramming.

Actually, that’s what a compiler is too. You write code in a high level language and the compiler writes machine code.

The important thing to remember is that you never want to metaprogram as a replacement for writing DRY code. If you’re metaprogramming because you got tired of copying and pasting, you need to rethink your strategy.

Here are a few articles others have written on the subject:

Meta Programming — the most memorable code I’ve written

Behind the Scenes of the 'Has Many' Active Record Association

The Magic of Metaprogramming

Before it was Java, PHP was a templating language. Which is just as well, since working on legacy system often means that instead of Blade or Twig or Pug or whatever, the only thing you'll have to put your views together is PHP itself. Great! Maybe?

Anyway, if you're using an IDE to make the refactoring work easier, you'll want to make sure you let it know when you're using entities in your views.

/** @var $boomer Acme\Dynamite\BoomStick */