PoignardAzur

DIP - Unique pointers

Rationale

The use case for unique semantics is pretty common:

struct SmartPtr {

PoignardAzur

22 - Wrappers
35 - API
39 - Naming
60 - Security
73+74 - Logs
91 - Brevity
98 - Anti-patterns teaching
100 - 10.000 mistakes
104 - Guard rails
109 - Generic solutions

PoignardAzur

Critical hits

Two types of hits: normal and critical.

Every weapon has a "edge", a different way of making crits. (see also Dead Cells)

Edges are related to mechanics of the combat system, eg:

• Parrying,
• Backstabs,
• Dodging,

PoignardAzur

Inspired by the board game "Scotland Yard".

The player is invisible, but leaves clues/breadcrumbs that let NPCs guess its path.

The IA can follow simple patterns (eg straigt lines, the player disappearing next to a ventilation duct) to anticipate the player and lay ambushes.

PoignardAzur

See Pocket

The main semantic interest (beside performance benefits) is the ability to write

if (entity.hasComponent!Foobar)
  entity.component!(Foobar).doThing(...);

Also, apply a system only to entities with the relevant components (example?)

PoignardAzur

Object-oriented smells

Object-oriented programming is widespread in industrial codebases.

This is in part because of inertia: OOP has been the dominant paradigm for decades; an entire generation of programmers has been taught from the onset that OOP was The Right Way To Program.

There are also strong reasons to do OOP: objects are somewhat intuitive abstractions, and encapsulation is a convenient way to separate responsibilities so that a very large team can work on the same code without bumping into each other; inheritance and abstract classes add modularity and reusability to the mix.

But OOP also has strong flaws, which I rarely see discussed. People who criticize OOP tend to do so from the perspective of performance: OOP leads to vtables, heterogenous collections, and sprawling object graphs which put a lot of pressure on CPU caches. But people rarely discuss what I see as the main problem with object-oriented codebases:

PoignardAzur

• For every feature, lay out at least one accidental "path" through which the user can stumble on this feature organically.

  • Express this path in a data structure that can be checked in CI.

• When browsing a hierarchy, make it really easy to quickly see the list of all parents

• Do not make the user make changes that they don't know how to cancel. (even without ctrl-Z)

  • Cancelling should generally be as easy as "Remove object I just created"

• Make "git diff" visible in object hierarchy

PoignardAzur

Start the Separatist playthrough in an Obviously Doomed Hometown.

Have really trivial tutorial quests, while dropping hints that the village is about to be attacked by the Empire. At the end, the Empire attacks, but is quickly repelled. The game plays on the player's expectation that the village will be destroyed for drama points.

PoignardAzur

At the risk of being “that guy”, this isn’t actually true. Encapsulation does not mean that other objects can’t change the states of an object, just that they can’t do so DIRECTLY. They always have to ask the object to do it for them. So, in this case, there’s nothing in OO rules that says that a bank transaction can’t, as a side effect, change the name of the customer. It only can’t do so by reaching into the instance of the account and setting the “customerName” instance variable itself. It would have to call something like “setCustomerName” or, more reasonably for the sorts of cases you’re talking about, call the “changeCustomerName” method.

This sort of thing is, in fact, what a system with a lot of varied and strange events that can impact a lot of different objects wants to do. First, you don’t want to have to have all of these varied objects actually have to know what the actual logic of changing a customer name is. Not only does this add complexity to them, but it also is a royal pain if you eve

PoignardAzur

CONTENT WARNING - SHORT DESCRIPTIONS OF UNETHICAL HUMAN EXPERIMENTS - CHILD ABUSE - MENTIONS OF SEXUAL ASSAULT

Warning - this fic broaches heavy subjects. If you've finished Twig, this shouldn't faze you. Otherwise, heed the trigger warnings. Also, major spoiler for the entire story of Twig.

Notes

Theme: Happens ~10 years after the events of Twig. The Academy is being demolished, press reports on it as a symbol of the new world. Ex-actors from Professor Ferres's show come together and share their perspective. They disagree on how traumatic the experience was.