Hacker News Reader

Comment by hprotagonist | Hacker News Reader

Making the item system polymorphic was ultimately a mistake, but that was a big one.
Q: Why was this was a mistake?
A: When you declare a class that’s a kind of item, it locks you into that structure much more tightly than if you just have member elements. It’s nice to be able to use virtual functions and that kind of thing, but the tradeoffs are just too much. I started using a “tool” item in the hierarchy, which started to get various functionality, and can now support anything from a stepladder to a beehive to a mortar (and pestle, separately, ha ha), and it just feels more flexible, and I wish every crafted item in the game were under that umbrella.

We do a lot of procedural generation, and if we wanted to, say, generate an item that acts partially like one thing and partially like another, it’s just way harder to do that when you are locked down in a class hierarchy.

Preach:

https://ericlippert.com/2015/04/27/wizards-and-warriors-part...

https://ericlippert.com/2015/04/30/wizards-and-warriors-part...

https://ericlippert.com/2015/05/04/wizards-and-warriors-part...

https://ericlippert.com/2015/05/07/wizards-and-warriors-part...

https://ericlippert.com/2015/05/11/wizards-and-warriors-part...

I have certainly committed all of these sins, too.

View on HN

"Tool" is still a class, with perhaps very generic polymorphic methods (e.g. do_default_action() ). The problem is not polymorphism per se, but rather about having a deep class hierarchy aka lasagna code.

My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.

Funny thing, it's just the object model in play that causes the problem. Something more similar to Smalltalk (or Objective-C) works pretty well for things this dynamical, though you do need to factor out the properties and messages reasonably well still.

The trouble is C++ and similar object models poor support for composition and implicitly penalizing uniform object structure.

(E.g. call multiple base methods in a subclass - pain ensues. Add virtual calls to the mix, it gets really iffy.)

Even Python and Ruby with explicit mixins but the old model get hairy.

This is one of the things I like about Go. Just structs with methods. You can embed them but it seems to hedge against deep nesting and creates simple code

Then how would you model composing behaviors in Go. Say for example I have a representation of Food and a representation of Animal. I then want an ability that will "animate" things, so I can animate Food to give it the behaviors of Animal.

I'm not being critical either, I'm seriously curious how somebody would implement this behavior in Go. Like you say, just struct with methods is a very appealing mental model since you have fewer moving parts, but how does it deal with a scenario like this which is very common in game dev?

Go has interfaces, but not inheritence.

I'm slightly confused about what you're trying to describe, but maybe it's something like this?

https://play.golang.org/p/smPyWvBvWWp

We can make both Food and Animal statisfy the "Animateable" interface.

Go also has a syntactic shortcut which is similar to inheritence, but more explicit. If you include a field in a struct without any name, it is considered "embedded", and you can call methods on the field directly, without referencing its name, which ends up looking the same, at the call site, as inheritence.

https://play.golang.org/p/cIMqQqE0eVc

But everything is still explicitly laid out in the struct -- it's just a simple struct, no inheritence shenanigans.

I think interheritence is a mistake, but interfaces are the bees-knees. Even in C# (which is my main language these days, 'cuz that's what you use if you're making a game in unity), I just use interfaces, not implementation inheritence.

(And even interfaces I don't use much -- but when you need it, you need it!)

Thanks very much for the reply. Here's more of a clarifying example:

The idea I was going with Animateable was not animation (poor wording on my part), but effictively giving the properties of a creature to a thing, ie magically animating it. So I have an ability in-game that lets me turn anything into a creature, thus merging the Creature interface with whatever other interface this has. From what I'm getting from you, that means every single thing in the game must implement the Animateable interface.

Now lets do another one, I want a Metalic property. Say these are things that when hit by lightning will give off lightning damage. Then there's a curse called Midas that will let me turn anything metallic.

So I have a Wooden Hammer object which I midas curse mixing in metalic, then a wizard animates it so that it has the properties of a creature, and I have a creature that when I hit with lightning gives off sparks that I can also use to hammer nails.

Point being, in this world you're basically requiring every single thing to implement every single interface which sounds like a nightmare, where with more of an ECS style system, you just merge in the new behavior and call it a day.

So caveat, I've never actually used an ECS system, but I've read about the pattern, and I would say it definitely seems better suited to the kind of situation you're describing than interfaces (or inheritence).

(I would say interfaces/inheritence are useful for simple high level abstraction of basic concepts with multiple implementations (here's an interface for a compression algorithm, or a RNG, or whatever), not so useful for trying to model complex game-world relationships. And to me, the useful part is the interface, whereas inheritence mixes in two unrelated concepts: implemementation-sharing and interface.)

But you don't need either of those for ECS, right?

If I understand it correctly, ECS at its core is basically an optimization of the struct-of-arrays datastructure. E.g., something like this is a super-basic ECS:

  struct World {
    Comp1[] Comp1
    bool[] HasComp1
    Comp2[] Comp2
    bool[] HasComp2
    ...
    int NumEntities // all arrays have this length
  }

I'm a big fan in general of struct-of-arrays vs collection-disparate-structs-with-pointers. Besides being way faster, it tends to make code clearer, too. ECS seems like a more efficient and convenient evolution of that pattern.

At least from what I've read. No real experience. Take with 13 grains of salt. :-)

P.S. If you feel like it, I'd be happy to explore some concrete code (you first!). It's always very interesting to me to try to explore all possible ways to express some concept in code.

I am not a Go programmer but I would assume that each behaviour of Animal would be a struct with one or more methods. Those behaviours are added to the agent to make it an animal. Composition. If you want your Food item to walk like a duck and quack like a duck you just add Walk and Quack to it. Presumably some other system would take care of identifying those behaviours and calling them as needed.

https://en.m.wikipedia.org/wiki/Structural_type_system

By structural typing. It’s a form of satisfying an interface by composition.

Go uses duck typing. "Interfaces," such as Food or Animal, declare sets of functions that must be implemented in order to qualify as an object of that type. So a "Food" thing might need to implement "beInjested()" and "spoil()", and Animal "run()" and "die()". If, for type "Chicken", there are "beInjested(Chicken)", "spoil(Chicken)", "run(Chicken)", and "die(Chicken)", then a Chicken can be used anywhere a Food or Animal is wanted.

edit: You cannot, however, explicitly declare that a "Chicken" is supposed to be a Food and/or an Animal. And you can't directly inherit implementations; to make Chicken directly use a generic function you need to do something like implement "baseSpoil(Food)", and then have the body of "spoil(Chicken)" explicitly call "baseSpoil(self)".

As mentioned in another reply, there is a shortcut. You can declare that the Chicken structure includes (anonymous) Food and Animal fields. Then, if you call "spoil(myChicken)", Go will automatically replace it with "spoil(myChicken.Food)".

> My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.

That's been my observation as well - there's no free lunch and DRY isn't free either, certainly not if you use inheritance chains to achieve it.

I'm starting to think that the only programming axiom that will survive in the end is KISS.

KISS and YAGNI are like yin and yang for me.

they are yin and yin for me.

Perhaps yeah, I just meant two different sayings that are the same vibe. Yin and yang probably was the wrong choice of term haha

Well, YAGNI does have both yin and yang in it...

A few weeks ago some commenter here said they ascribe to WET - Write Everything Twice. Basically worry about abstraction when you get to number three.

And what an acronym given the context!

I've also heard "We Enjoy Typing"

That’s great, and jives with my experience. You probably don’t know the problem well enough to come up with the right abstraction until at least example #3.

I've never heard this as an acronym, but I use it in practice! For me, it's an extension of "three or more, use a for" that made sense for all repetition and not just loops.

Or to paraphrase some sayings / one-liners, "a little copying is better than the wrong abstraction".

I love this. And I like it's also consistant with the findings of the natural semantic Metalanguage.

NSM would be the minimum element set of concepts shared by all human cultures, which can be used to derive the rest of concepts, and it's heavily based on anthropological field studies.

And it includes the numbers one, two and many, (also few, some & all). So that indicates some special meaningful distinction for us in that jump from two repetitions to start abstracting away.

KISS is universal, not only to programming.

But the single responsibility principle and the idea that you should divide your code in components where the lower components should be abstract by the point of view of the higher ones are almost never wrong.

Not by coincidence, those last two are consequences of how people think. While KISS is kind of a physics law.

"I only allow a single inheritance layer"

I would agree to that as a goal, but not as a dogma. It depends what you build, I guess.

My policy is OOP is like Heroin. Don't even start.

Never write GUI code then.

Yeah that's the one downside of not doing OOP. OOP is the only way to do GUI stuff.

Nobody on the face of the earth has ever used Functional Reactive Programming. It's a made up concept. In fact it's also definitely not one of the concepts that inspired the most popular pattern in React.

I am unaware of a single functional reactive UI library or framework that does not rely on other people's, most often object-oriented (or even *gasp* procedural) libraries to actually put anything on the screen.

Of course it's relatively easy to build shiny clean wrappers around the dirty work that others have had to do on your behalf.

You're right you are unaware. This is not an insult and I'm not trying to offend you. This is a factual statement. You truly are unaware as you stated yourself, and I can prove it to you.

First off FRP is actually a term. Functional Reactive Programming. It is 100% a functional paradigm that gasp by DEFINITION cannot be procedural. So you truly didn't know what you were talking about here: https://en.wikipedia.org/wiki/Functional_reactive_programmin...

Second there are many languages/frameworks that use this paradigm. React partially uses this paradigm. But I will list two popular ones that strictly follow it... just note that there are more. Much more.

Take a look at elm. Elm is a fully functional UI library and language that is 100% pure, functional and has no OOP. Believe it or not ELM is not some toy, it is production ready and actually measurably faster than react. This language is what popularized the FRP pattern which is partially used by React today. See here: https://elm-lang.org/examples/mario

Note the load time and latency on the mario game. React doing the same thing will be slower.

Another language is ReasonML. ReasonML is essentially a language that compiles to the browser and has one to one correspondence with another functional language... OCaml.

ReasonML is Created by the creator of React, Jordan Walke. Coupled with React as framework, ReasonML is essentially the ideal GUI paradigm that Jordan would recommend everyone to use in the ideal world. However due to the fact that everyone is use to javascript, Jordan instead as a first step, ported FRP concepts over to a language called JSX (essentially JavaScript mixed with html) and is slowly nudging the world in the direction of GUI programming using the functional style: https://reasonml.github.io/

Make no mistake the creator, of the most popular GUI framework in the world is a supporter of the pure functional paradigm, and he is heavily and successfully pushing the functional style programming of GUIs into the mainstream.

OOPs being the dominant paradigm for GUIs has, in the past five years, become a false statement.

You're right on the wrapper part though. Assembly language is essentially a procedural language so every functional thing that exists on top of it, is a wrapper. But I mean this is a pointless observation.

Ah so ReasonML doesn't transpile to JavaScript, an OOP language?

How does it run on the browser?

You mention React and Elm, which - as I said previously - both rely on other people's actual GUI work (the various browsers' rendering engines + DOM, the various platform-specific UI SDKs, etc) to actually put anything on the screen.

I can't speak to ReasonML, as I have not used it, but my impression also is that it takes advantage of other people's GUI libraries considering that I've heard Revery compared to Flutter (and Flutter outsources its rendering to Skia as well as relies on rather imperative RenderObjects beneath the functional reactive layers). Please correct me if I'm wrong.

I would be very interested indeed to see a GUI framework built from the actual ground level up in an entirely functional reactive manner. Do you know of any?

Actually there is NuclearJS a Flux (React) implementation in JS designed around immutability, FP and also reactive programming. As anything pure FP, it's ridiculously difficult/awkward to get started but it really shines in some areas. Namely complex UIs, state transitions and interrelated data "objects". The first 2 can be solved with proper OOP (it's obviously not nice but it solves the problem), but I've never seen a framework ironing out the nastiness of relational data so well. The idea is to combine multiple data objects using lambdas. It's incredibly elegant and so general concept is supposed to be the "Functional Lens".

Unfortunately it's discontinued, probably rightly because it's definitely not for teamwork. But really, it doesn't depend on anything OOP in the strict sense.

I try really hard not to. So far it's worked!

MVU doesn't need OOP though.

Yeah, assuming you are using something like C.

Are you by chance thinking of MVC?

MVU is more towards functional rather than imperative programming.

Not when using an OOP language like JavaScript, you are by definition using OOP constructs exposed as language fundamental types.

Another good rule for OOP: Objects are fine, object graphs are a killer. Graphs are what get you into "all I wanted was a banana" territory. Objects should either be atomic, agrigated by simpler structures like maps and arrays, or if you absolutely must have objects pointing to objects, be sure that they form a tree and not a graph such that each object need only know about the things below them which can be encapsulated at a single point.

I guess the exception would be when you’re modeling a graph.

Hah, that's actually a good point.

You still don't necessarily need to model the graph at the object level though. You could model your graph as a set of pairs, ie edges. If performance was more of a concern you could do it as a map where each object was a key and the values were a list of the connected objects. You could also separate out the value from the graph behavior and have a GraphNode object that wraps each value object.

The bigger point though is when you have networks of objects that are relying on each other to perform functions, that's where the problem is, and where you start to rely on mocks and stubs for testing, which really should be considered a smell in its own right. Your better off making the interface between objects values rather than having hard references between objects as described in this talk: https://www.destroyallsoftware.com/talks/boundaries. Once the interfaces between your objects are values instead of references you're free to connect your objects together in any way you need and are not stuck with the fixed graph as originally designed.

Oh yes that is certainly sane.

> Once the interfaces between your objects are values instead of references you're free to connect your objects together in any way you need and are not stuck with the fixed graph as originally designed.

Absolutely, same can be said about relational data representation for example.

Even a single object gets you into the "all I wanted was a banana territory. "

I have a gorilla class and a banana method on the class, can I ever use banana without the gorilla? No. The simple act of having a class screws it all up.

Make the banana a pure function, or one that is defined in terms of a polymorphic parameter that it mutates.

  func banana(x: animal){...}

  banana(gorilla);

The way to do it via OOP is base class methods and importing the method to all children via inheritance which is just bad and universally reviled among even practitioners of OOP.

  class Animal() 
  {
      banana()
  }

  class Gorilla() : Animal {
  
  }

Technically there are slight fair advantages and disadvantages to the OOP way when you don't account for inheritance and polymorphism but all that is gone once you do account for them.

Nah, the problem is OOP polymorphism that conflates too many separate things. If you have a language that can actually express "implements this interface", "has this member", and "delegates this interface to this member", then you don't need traditional "extends" inheritance at all; sometimes you want to do the exact equivalent (and you can), but most of the time you want to do something narrower.

Is that an example of decorator pattern?

I'd say that that's an example of structural or duck typing (as opposed to nominal typing).

In my experience it is nigh impossible to design-pattern your way out of a language simply being unable to express what you need it to express without incurring a severe performance penalty (anathema for game development) or resorting to code generation (which is itself prone to ending up as a Gordian knot).

> I'd say that that's an example of structural or duck typing (as opposed to nominal typing).

No it's not. I'm talking about having nominal typing but easy support for delegation (e.g. look at how Kotlin does it).

Kinda - an instance of an OO subclass is a decorator around an instance of its superclass, so if you're using a language which has a good way of expressing decoration then that's usually better than using inheritance.

But as the other reply said, patterns are a language smell - the language needs to support that style and make it idiomatic. Otherwise, if you give people the choice between doing it right but verbosely and doing it wrong but more quickly, guess which one they'll choose. https://www.haskellforall.com/2016/04/worst-practices-should...

Object programming is MUCH better than object oriented IME.

This is something I've struggled with in the past as well.

I have a player, NPCs, enemies, and wild animals. Should they have any class hierarchy at all? If my code matches the game world, what happens when I was to add golems and let mages turn castle's into entities that act just like an NPC would? Should my class design be so tightly coupled with the elements of my world? I don't think so but what alternative works best?

Can you create a base class for all living things and derive from there? The base class owns a bunch of common components such as HP, Animation, Sound, etc, and each subclass has components that are specific for itself (for example, you cannot "Use" a player, but should be able to "Use" a wild animal, so here goes a component for that action).

That's very interesting, because I had observed exactly the same when I tried to implement a rogue-like in Java some years ago. For example, I had to decide whether there should be different subclasses for spell books, the different weapon types (e.g bows vs swords), drinks, etc. or just one big Item class. Closely related to that, another decision I had to make was whether object or character properties should be implemented as class members or as entries in a hashmap (where the latter is a class member). At the end, I had the feeling that I was implementing my own class/object system on top of Java's one. I guess in other languages, like lisp, this is not really an issue.

IIRC I already wrote that here on HN, but I think implementing a simple rogue-like is an excellent exercise to get familiar with any programming language.

Mattias Johansson uses basically this example in his argument for composition over inheritance. You have humans, robots, and dogs all fitting into your nice class hierarchy. But now you need a robot dog that breaks everything.

https://www.youtube.com/watch?v=wfMtDGfHWpA

I think inheritance makes the most sense when your problem domain has been known for decades - like airline reservations. But for new blue sky projects - you always seem to wind up in these snafus that break your rigid class hierarchy.

> You have humans, robots, and dogs all fitting into your nice class hierarchy. But now you need a robot dog that breaks everything.

I like the way you put that. Though humans and dogs are 85% similar at a DNA level, so makes sense for them to inherit from a common parent. And my guess is robots and robot dogs would be ~85% similar at a building block level, so dog would inherit from robot.

I think go easy on levels of inheritance but have really strong root classes that most things inherit from.

Heh, I actually had that wrong. I probably should have watched the video instead of going by my recollection. He has a mix of robots and animals. Same concept.

Robot dogs inherit from robot and dog. Mammalian dogs inherit from mammal and dog.

In a multiple inheritance world yes. But I think most C++ devs decides that led to a big mess in large systems. Supposedly one of the best things about Java was no multiple inheritance.

Except it happens that there are architecture scenarions where multiple inheritance makes sense, so all major languages have it in some form anyway.

In what concerns Java you have multiple inheritance of interfaces, and as of Java 8, traits.

Windows C++ frameworks, from Microsoft and Borland/Embarcadero make use of multiple inheritance.

The Codeless Code #83 - Consequences http://thecodelesscode.com/case/83

is a good read on that... or rather, its a spot to start thinking from.

It ends with:

> A nun of the temple whispered to Jinyu: “This problem has several solutions, but I dislike all of them.”

> “Therein lies its value,” whispered the abbess in reply. “For we are all of us doomed in this profession: our designs may aspire to celestial purity, yet all requirements are born in the muck of a pig-sty. I trust that this monk can succeed when the stars align in his favor, but when they do not, how will he choose to fail? By cowardly surrender? By costly victory? By erroneous compromise? For it is not he alone but the temple that must bear the consequences.”

There are also a set of "topics" hidden with a mouseover at the bottom that can waste a day away without difficulty.

Definitely components are the way to go. These have gotten very well known recently in the game dev world thanks to entity component systems, which is what I would call "heavy components," but you can also do "light components." Meaning, you don't need to organize your entire system around an ECS in order to take advantage of some of their benefits.

They make changing behavior dynamically extremely simple. Instead of needing to hardcode classes for each different type of thing players may want to create in your world, you just assign and unassign components. Give a rock the Moveable component and now it moves. Remove the PlayerControl component from the player and put it on, I don't know, an orc -- now you've implemented body swapping. They're even more useful in a game like traditional roguelikes, where you don't have to worry about animating all these dynamic states.

I've actually never thought about how a component system might fit into a more traditional business application; it's an interesting thought experiment but I'm not quite sure it would be a strong benefit.

Database modeling comes to mind, especially EAV.

> We no longer have the problem of trying to fit “a wizard can only use a staff or dagger” into the type system of the C# language. We have no reason to believe that the C# type system was designed to have sufficient generality to encode the rules of Dungeons & Dragons, so why are we even trying?

Good point! Skimmed the blog posts, seemed to have useful enumeration of techniques with considerations.

Hickey nails this one in his talks. When you make something a class, that's NOT an abstraction, that's a concretion. You make a Tool class, you haven't abstracted what a tool is, you've made a fixed decision about what it is. For games that want this level of complex interaction between components, entity component systems are the way to go.

I’d love a reference to this talk.

"Maybe Not" talks about these compositional ideas: https://www.youtube.com/watch?v=YR5WdGrpoug

https://youtu.be/2V1FtfBDsLU?t=2268

Goes until 43:25.

The whole talk is worth watching. It's basically about the higher level problems of business app development, how to address them, and how Clojure does address them.

I would argue that if you have a "Item" class then it is the set of all concretions/specializations.

By creating a tool class you haven't extended the set, you've instantiated a subset of the set of items that contains the items that are tools but nothing else. It's obvious why it is so difficult to represent a tool that is also e.g. a consumable item. The set of items that are both tools and consumables is a superset of the set of tools and set of items. You can't represent it through a second layer of inheritance because it only lets you create a subset of the items that are tools. You obviously have to use multiple inheritance for something like this because it will let you form the set of items that are both tools and consumables. Of course, multiple inheritance is very messy so you should try to avoid it.

> For games that want this level of complex interaction between components, entity component systems are the way to go.

Entity component systems are still in a half-baked state, with everyone rolling their own slightly different conceptual model. They're solving a problem, but not solving it well.

One promising direction is getting rid of entities. Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components. Old writeup (not mine): https://github.com/kvark/froggy/wiki/Component-Graph-System

I think this is more of a language paradigm problem. Game programming is very much tied up in C++ and C# for historical and performance reasons, ECS is a way to try and graft what is entirely natural in a more value-based language into OOP mechanics and C++/C# type systems.

ECS is so common and easy in lisps that it doesn't even warrant its own name.

Rust game engines are all based on ECS too.

Ironically, the ECS advocates kind of miss the part that ECS models are based on OOP literature.

https://en.wikipedia.org/wiki/Component-based_software_engin...

"Component Software: Beyond Object-Oriented Programming"

https://www.amazon.com/Component-Software-Beyond-Object-Orie...

> One promising direction is getting rid of entities. > > Components need to link to entities and other components anyway, so one may as well treat entities as zero-size components

You are essentially describing ECS here. In ECS, entities are nothing but a "handle" without any additional data, normally just an integer used to link common components together.

What op links actually describes a different issue than what is in the post. What I got from the article, instead, is the following:

If entities could be IDs to which components are connected, or containers holding components. Either case has disadvantages.

If entities hold components, then iterating over components means iterating over entities, which slows down all systems. A rare type of component still degrades with adding entities.

If instead components link to entities, and you want multiple components to interact, then these interactions slow down the system because of multiple lookups that need to be done.

Author proposes to use a graph structure between components, getting rid of entities-component duality. Proposes to use pointers which allows calling into any component and process then all required components.

I am not entirely sure if this would solve all problems, but this seems to be the proposal. It seems setting up the graph dynamically would be quite the task, though. For example, I don't immediately see how to guard against cyclic behavior and too many calls into a single component etc.

> Author proposes to use a graph structure between components, getting rid of entities-component duality. Proposes to use pointers which allows calling into any component and process then all required components.

This is far from ideal, and is equivalent to a very naive implementation of ECS. Having the user have to use pointers is not ergonomic, and the random access of secondary components via those pointers destroys the caching benefits of data-oriented design. Having a memory pool don't automatically give optimal cache usage, only if you have very little data.

Most modern ECS frameworks solve the issues you mention by allowing systems that "query" more than one component at a time, not requiring a lookup. For example:

    system<Position, Velocity>().each([](auto p, auto v) {
        p.x += v.x;
        p.y += v.y;
    });

This is supported by lots of mainstream ECS libraries already. It doesn't require lookups inside the System's hot loop, doesn't require random memory access via pointers, and also doesn't require managing/cleaning up those pointers.

The nice thing about keeping Entities as opaque handlers is that a "System Iterator" is able to abstract away the issues mentioned and implementation becomes a mere detail. An ECS library could even use the implementation the GitHub wiki link suggested, since ECS is currently abstract enough to allow it, because of the opaque handlers.

Good to know. Just to be clear, I was not endorsing the article. As mentioned, I have doubts about using a graph structure of pointers for related reasons, most of all because I think handling relational paths will amount to more overhead than any ECS structure.

Nevertheless, I wanted to highlight that the quoted article clearly states that the proposal is not an ECS and is in fact superior to it.

> Good to know. Just to be clear, I was not endorsing the article. As mentioned, I have doubts about using a graph structure of pointers for related reasons, most of all because I think handling relational paths will amount to more overhead than any ECS structure.

Got it! Yeah, I totally agree with you.

Prefer delegation over inheritance was one of the first OOP lessons I learnt. I read it in a C++ blog around 2004, it was explained very well with geometric shapes examples.

The only time I used inheritance was while implementing a job execution framework. It fit the pattern nicely.

this is a pretty good series of posts but I was rather surprised at where the series ended, with more (hypothetical) OOP abstraction instead of less. trying to fit game rules into a language's type system is a common thing for novice programmers to attempt, because it seems like the perfect logical application of these type system rules you just learned about when learning the language you're using. I kept expecting the article series to get around to reducing the system down to something like a Player class with a PlayerClass enum and member (and ditto for Weapon), then branching logic based on that, instead of trying to pack it into the type system.

composition over inheritance...

Its the fragility of large inheritance hierarchies. They work well for very rigidly defined real world structures but not so well in most real-world usages.

I came to the comments to say exactly this. I think like any ideological stance, it's extreme and there are exceptions to the rule, but for games it's great for a lot of reasons.

Tarn was wrong about this though:

> Using a single object with different allocated subobjects is almost certainly worse for cache misses

It depends a little on the context, but having object pools is exactly the right thing to do when you're trying to scale. It allows you to group together similar data, reducing cache misses when batch processing. You can even cache-align your primitives, or even run SIMD and multi-core jobs to batch update an entire set of attributes that belong to multiple objects.

Thanks for that great series! It reminded me a lot of this demo for O'Doyle Rules, a Clojure rules engine library, wherein the author demos a dungeon crawler style video game written top to bottom using only the rules engine for logic https://youtu.be/XONRaJJAhpA?t=1577

He also goes on to show a text editor written entirely in the rules engine (which he uses to develop the game in), really cool stuff!

The Baader-Meinhof phenomenon has hit me hard. I read an excellent blog post yesterday on this exact subject. Well worth a read, even if Rust isn't your thing:

https://kyren.github.io/2018/09/14/rustconf-talk.html

This took half an hour to read so I don't know how the author expected it to be a half an hour talk! Thanks for sharing.

In the LPMud LPC language objects could inherit from multiple other objects, so they could combine behaviors. I haven’t really seen that in other languages.

The "about inheritance in LPC" - https://www.mars.org/home/rob/docs/IntermediateLPC/chapter6....

and a bit about multiple inheritance in LPC - http://graphcomp.com/info/mud/mudos/lpc/constructs/inherit.h...

And another bit - http://www.geas.de/tutorial/lpc_57.html

As to seeing it in other languages... this gets into a mixing - https://en.wikipedia.org/wiki/Mixin

An example of that in Scala - https://docs.scala-lang.org/tour/mixin-class-composition.htm... or https://www.baeldung.com/scala/class-composition-mixins

The issue is that for most situations, the additional conceptual load of multiple inheritance gets difficult.

like C++?

For some reason I actually did not know this!

Sorry but a lot of the complaints from the article and what you linked are... well weird. Look, I'm no grand ninja guru wizard programmer, but after a decade of programming on and off as a job... wtf are you all smoking? Theres nothing to preach but to check your hubris. A majority of problems stem not from OOP or whatever language being used, it's from over abstracting. This is mostly due to trying to pre-build for a scale that will 99.8% never happen or to account for some wild potential esoteric function in the ether that'll never happen as well. There's some weird dick measuring contest out there on the internet that I wasn't invited to where everyone is trying to out over complicate each other. They never stopped to properly learn any real design patterns, so their classes end up all over the place. "Its OOP's fault!" And hell, sometimes you used a hammer when a screwdriver was more appropriate. No big deal, we all make mistakes in lines of design logic. It ain't OOP's fault you made an oops.

Let's just say that there's a reason game dev has tended towards ECS/data-oriented design.

A program that puts a handful of form widgets, consumes a bunch of text or spends most of its time waiting for I/O is far from the same domain.

Exactly ! Apart from the "Mental model" and "superior ?" organisation of your "objects erm entities", there is a definite "cpu execution" advantage as well. Having the different system "execute" over items which is basically just data, helps keeping the data local and in the cache.

Reply on news.ycombinator.com