Hacker News Reader

Experienced modern game programmers would never write a "Duck" class though. For instance, in Unity, it would be a set of small components representing narrow behaviors attached to a generic scene graph object. So the "Duck" would only exist as a data object that happens to have maybe a unique Quack component, along with a lot of common non-duck components like MeshRenderer, AudioSource, Collider, RigidBody, etc. You would see similar things in something like Unreal, or even in-house engines. The implementation is likely also to be way more interested in acting on aggregate data streams rather than enforcing strict encapsulation and object boundaries and such.

It's still very OOP, but not in the sense of representing real-world taxonomies.

I know there's an argument that this real-world metaphor is good for beginners, but at least in my personal experience I don't think that's the case. I remember when I was a kid, my dad tried to teach me coding with a lot of object oriented examples with like Cats and Dogs and stuff. He was really well meaning, but it never really made sense to me. I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global. Awful code, but 10 year old me was able to reason about that a lot easier than polymorphism/encapsulation/scoping/etc.

> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place and practically everything being a global.

An aside: It's okay to learn that way, when you're 10.

A lot of my own big programming revelations have come from ignoring best practices and accidentally trying to implement or construct them from first principles once my problem becomes unmanageable.

"Doing it wrong" is an even better teacher than "doing it right all of the time", because the mistakes you make can lead you to a deeper understanding of why things are done a certain way.

Totally agree. I think we make a mistake trying to harp on doing things "right" too much for new programmers, because they end up with analysis paralysis.

That's my current approach to teaching people programming concepts. I try to provide an example of not using that concept, point out the quickly growing complexity of the code, and then show how that complexity can be reduced with the new concept I'm introducing.

(And yes, as a kid, I was hurt by all those "Cat : public Animal" examples too. It took me many years before I figured out why they didn't work in practice for me.)

I think this is why you often see people reinvent GOTO. Everyone who started with BASIC (and moved on) knows why you won't do that any more. But someone today starting with python might not understand. [replace GOTO with any bad example]

Both Unity and COM use aggregation instead of implementation inheritance to compose bunches of small sub-objects together.

Unity has the notion of components (inheriting from MonoBehaviour => Behaviour => Component => Object), which can be multiply attached to GameObjects (inheriting from Object), that you can switch between with gameObject.GetComponent<ComponentClass>().

COM has the notion of multiple interfaces to the same "controlling unknown" object (analogous to GameObject), that you can switch between with QueryInterface.

https://docs.microsoft.com/en-us/windows/win32/com/aggregati...

https://flylib.com/books/en/3.357.1.89/1/

http://www.369o.com/data/books/atl/0321159624/ch06lev1sec5.h...

https://en.wikipedia.org/wiki/Object_composition#Aggregation

They're basically the same idea, but slightly different in the details and implementation.

COM is essentially C++ pure virtual interfaces implemented by one or more concrete classes using multiple inheritance (like the way Java lets you multiply inherit interfaces, but only singly inherit classes). Different COM interfaces can refer to the same shared C++ implementation object, or separate delegate objects, and "tear off" objects created on demand.

Unity's component model is implemented in C#, but isn't an essential language feature of C#, just a way of using it to implement aggregation.

From your point of view, are GameObjects in Unity an implementation of entities from the entity–component–system pattern, or is there a difference?

There are some abstract similarities, but neither COM nor Unity GameObjects/Components are an "implementation" of that pattern, since they were both invented a long time before 2007 when Adam Martin defined ECS in "Entity Systems are the future of MMOG development":

http://t-machine.org/index.php/2007/09/03/entity-systems-are...

ECS builds on top of some of the ideas of COM and GameObject/Component, but loses much of the baggage, takes it much further in a different direction, and has a lot of other advantages, like storing the data in separate contiguous cache-friendly buffers.

https://en.wikipedia.org/wiki/Entity_component_system

>In naïve ECS implementations, every system iterates through the complete list of all entities, and selects only those entities that are needed. The total iteration cost for all systems becomes too costly if the number of systems grows or the number of entities is large. In other ECS architectures, every component type is stored in a separate list, so whatever systems operate on a given type of component are only iterating over objects they care about by default. In this common ECS architecture, the described disadvantage actually becomes a major performance advantage, by more efficiently leveraging the CPU instruction and data caches.

http://t-machine.org/index.php/2014/03/08/data-structures-fo...

>Net effect: Contiguous memory is King

>If you store your data contiguously in RAM, it’ll be fast onto the Bus, the CPU will pre-fetch it, and it’ll remain in cache long enough for the CPU(s) to use it with no extra delays.

>NB: this is independent of the programming-language you’re using. In C/C++ you can directly control the data flow, and manually optimize CPU-caching – but whatever language you use, it’ll be compiled down to something similar. Careful selection and use of data-structures will improve CPU/cache performance in almost all languages

Also:

Entity–component–system (ECS) back and forth (skypjack.github.io):

https://news.ycombinator.com/item?id=19166910

Entity Component System Framework that is CPU cache friendly:

https://stackoverflow.com/questions/23473783/entity-componen...

Designing a cache-friendly entity component system:

https://cerulean-skies.com/index.php?article=1

Unity is rolling out a new officially supported entity component system that's a totally different stack than GameObject/Component. (But they interoperate, of course.)

https://docs.unity3d.com/Packages/com.unity.entities@0.1/man...

One (but not the only) fundamental difference between COM and GameObject/Component, is that you query for COM interfaces with an interface GUID, so you can only have one interface on an object for each GUID. But Unity lets you slap as many of the same component class on an object as you like. The singular Component GetComponent<ComponentClass>() method will just return the first one, but the plural Component[] gameObject.GetComponents<ComponentClass>() returns an array of all the components of the given class.

For example, it is useful to attach several different Colliders to the same GameObject (each with its own position/size/shape/etc). They all just work together as you would expect. A RaycastHit will identify which Collider was hit, as well as the sibling Transform of the GameObject it was attached to.

Another fundamental difference is that with GameObject/Component, each GameObject and component is always a completely separate independent object, but COM allows the implementation class to implement any number of different interfaces with the same instance (using C++ multiple inheritance, so each interface implementation has its own vtable pointing back to the same implementation class's different methods), or delegate to other sub-objects using "aggregation", or even make sub-objects lazily on demand with "tear-off interfaces".

TBH, I haven't written any real games, and the simulation work I do is in finance, so if we have an account, it's really just an account. But securities and accounts and such are all well-defined abstractions that lend themselves very well to direct representation in code, so my experience is not representative.

Maybe it's possible to be less misleading, but I still think it's a mistake to try to write a tutorial that tries to present basic concepts in the fashion that production code is written. There's just so much stuff you do in prod that is not relevant to the concepts you're trying to convey.

> I only kind of "got it" when I did something nobody would recommend anymore, and learned QBasic, and wrote a bunch of ghastly code with goto's all over the place...

I learned on a C64 when I was a kid, too. I'd absolutely recommend learning structured imperative programming before OOP.

> It's still very OOP, but not in the sense of representing real-world taxonomies.

1. OOP was never about "representing real-world taxonomies."

2. Real-world taxonomies are often not very good at representing real-word taxonomies.

Programmers are highly susceptible to scientism, and it's ruined whatever chance OOP had of being a tool rather than an ideology.

> In the context of a game or simulation, such classes can absolutely do all these things

Sure, but the point of TFA is that even then it still doesn't (necessarily) make sense to give them an OO hierarchy similar to their real-world taxonomy.

It might make sense of course, but it might not - you can't tell without looking at the code. The point here is that duck/bird analogies imply that the real-world relationship between ducks and birds tells you something about whether your Duck class should inherit from a Bird class, when in fact it doesn't.

I think my broader criticism of this complaint is that they aren't considering the pre-requisite mastery problem.

> Here’s an example that I think would be better to use instead: the `Visible` hierarchy in [Pygmusic][], which is a kind of software drum machine. A `Timer` is a horizontal strip on the screen with a stripe racing across it. A `NumericHalo` is a spreading ripple on the screen that fades.

That's how someone experienced in OOP is going to do it. The problem is that this depends on experience and knowledge of how such a system works.

I don't think this would be significantly better than the Vehicle-Car examples, because your target audience is seeing this odd layout and you aren't likely able to give them reasons why it should be that way.

To fully explain yourself would require information you can't reasonably impart in a tutorial. You know why it's done that way, but the underlying rules are obvious and intuitive to you because you worked on them long enough.

These rules manifest in a trained developer as an intuition that is developed by the feedback of doing things and failing or succeeding. Maybe they could be expressed mathematically, but it'd probably be very specialized math like advanced linguistics.

> In good OO programming, we don’t make class hierarchies in order to satisfy our inner Linnaeus. We make class hierarchies in order to simplify the code by allowing different parts of it to be changed independently of each other, and to eliminate duplication

Maybe we should really stop talking about "objects" and "classes" entirely?

Non-OOP structured programming doesn't have this problem; it's hard to grasp exactly when two subroutines are overly coupled, but it's easy to explain that sharing state and having action at a distance is a bad idea. And, generally, it's just not claiming any subroutine represents a real life "object". The only hierarchy imposed is the hierarchy of control flow.

The thing OO tutorials steeped in real world hierarchies are missing, though, is that understanding the concept of a hierarchy is not the hard part. Understanding what hierarchies are interesting in factoring a problem into code is the hard part that the student needs to understand.

And the key part of the problem is understanding that hierarchies and categories are completely arbitrary, and their value is determined by how useful they are. There's no one holy taxonomy.

Real-world examples can be used to point that out. Whales are mammals to biologists, but they're essentially fish to the economy. A bat is a mammal and an airplane is a vehicle, but both of them go into the same bag as birds if your main concern is "things that can fly" vs. "things that can't". Square is a special form of rectangle to mathematicians, but it's the other way around if your main concern is how much information you need to draw it. "Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad." Etc.

Once you crack the student's belief in there being one proper taxonomy for everything (a belief that strangely seems common even in adults in general population), you can then effectively show them that one of the main tasks of a programmer is finding the most useful way of categorizing things they're dealing with - and once that's done, the programming languages tend to have tools that let the programmer exploit such categorizations to minimize complexity.

> It's odd he makes these complaints, because the comment he's responding has this caveat:

> > unless they are talking about writing a clone of The Sims or something

Although I formatted it as a quote, I wasn't quoting or responding to somebody else in that part. That part about the Sims was part of the somewhat flippant principle I was proposing. The litany about ducks was just to explain the reasons for it. It wasn't a rebuttal.

We regret the inconvenience.

Even though I disagree with it, I think it was still a valuable point.

And everyone should deliver a litany about ducks at some point in their life.

I'm glad I've passed that point now.

The Sims actually uses "subject oriented programming", and it even personalizes objects and objectifies people! ;)

It's actually implemented in C++ of course, but it has a virtual machine that executes a noodly visual programming language called "SimAntics". And by noodly, I mean optimized for spaghetti code, containing intertwined loops, floppy, and droopy...

https://medium.com/@donhopkins/the-sims-pie-menus-49ca02a74d...

Subject Oriented Programming

This is described by some people as object — not Object Oriented Programming, but Subject Oriented Programming.

Objectifying People

People are objects, so when you click on another person, the items that you get in the menu depend on your mood, and your relationship with that person.

(From the transcript of this demo video:)

https://www.youtube.com/watch?v=-exdu4ETscs

The Sims, Pie Menus, Edith Editing, and SimAntics Visual Programming Demo

This is a demonstration of the pie menus, architectural editing tools, and Edith visual programming tools that I developed for The Sims with Will Wright at Maxis and Electronic Arts.

http://radar.oreilly.com/2009/03/interview-will-wright-sims-...

Will Wright: Well, one of the first challenges was could we develop a really robust model of human behavior test so that we could put these little characters in the elements in any situation they would behave reasonably. A Sims user is kind of controlling the environment. They can put the Sims in a wide variety of potential environments and then the Sims have to act reasonable. So we kind of had to develop a very — well, on the surface, it looks like an object-oriented programming model, but in fact, it’s what’s technically called a subject-oriented programming model. But I won’t get into that detail. So developing this robust kind of behavior system — in fact, it was environmentally distributed intelligence is the way we solved it.

But on the design side, there was a lot of thought about how much autonomy do these characters have versus how much reliance do they have on the player directing their actions. And there was also a whole dimension of thought around how much are we going to let the player read in to the simulation. In other words, how much of the simulation are we going to offer them to play of imagination versus make very clear and overt?

https://www.gamedev.net/forums/topic/697362-need-some-advice...

All8Up Moderator

Posted June 15, 2018

From the way the embedded code is shown, I would say the first thing to do is reverse the logic. What I mean is that what you posted suggests that the code is along the lines of "I'm trying to interact with you" and "I need to figure out what you are and what I can do to you". Conceptually of course is the most sensible solution, unfortunately in practice it is also the solution which fails the most often. Rather than this, I've always used subject oriented programming for interactions. This reverses the logic such that rather than the 'doer' figuring things out the subject of the interaction performs the work. Basically this means that the input system would simply set a flag on the input component saying "this entity wishes to interact". The interaction system can then do pre-cull for subject entities which are in range, which ones can be used from the doer's position, etc. Finally, you end up with a door that runs the rule checks: "You are in range, you have my key, it is Monday after noon, you are wearing a purple shirt... Ok, guess I will open now."

As to how you implement these things in the ECS itself, I suspect everyone does it differently. Personally I use a handle based approach where the interaction component simply contains a handle which refers to usually a script which checks the interaction rules. The script gets the doer and subject ID's so it can check states and make the decision. Then, likely in another script, an action is performed.

Overall this probably sounds ass backwards but it is a well proven solution to removing massive 'if/else' checks. It is also great for expansion packs and such since all the new logic is contained in the subject and you don't have to patch the doer code to understand the new interaction. Just as an example, The Sims used(still uses I assume) this subject oriented approach which allows DLC to be dropped in and mostly just work.

Hope this makes sense.

http://ivizlab.sfu.ca/arya/Papers/SW/SOP.pdf

Subject-Oriented Programming (A Critique of Pure Objects). William Harrison and Harold Ossher.

Abstract

Object-Oriented technology is often described in terms of an interwoven troika of themes: encapsulation, polymorphism, and inheritance. But these themes are firmly tied with the concept of identity. If object-oriented technology is to be successfully scaled from the development of independent applications to development of integrated suites of applications, it must relax its emphasis on the object. The technology must recognize more directly that a multiplicity of subjective views delocalizes the concept of object, and must emphasize more the binding concept of identity to tie them together.

This paper explores this shift to a style of object oriented technology that emphasizes the subjective views: Subject-Oriented Programming.

https://en.wikipedia.org/wiki/Subject-oriented_programming

In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions (“subjects”) of the objects. The term and concepts were first published in September 1993 in a conference paper[1] which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of “real” objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird’s nor the tax-assessor’s additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant’s analysis, the same may be true even of characteristics we think of as intrinsic.

SOP sounds a lot like ECS, with the subjects being the components, but I guess I kind of said that in a different comment.

The Kantian thing is kind of a mindfuck. I may need to think about that for a while. It reminds me of the work Phil Agre did on literary criticism of AI.

One weird aspect of how Subject Oriented Programming worked in The Sims is that the "SimAntics" virtual machine context had both a "me" object (like "this" but more subjective), and also a "stack object" that you were operating on (like "that"). So when you were executing a method of any object (either inanimate objects or other people), you implicitly knew what object the method came from (the "stack object") and which person was interacting with it ("me").

Kind of like JavaScript with "this" and "that", or like the subject and predicate of a sentence.

There was also a sparse "relationship matrix" where you could associate data with pairs of objects and numeric keys, so it could remember that a person had a "slept in" relationship with a bed that increases every time they sleep in it, which affects how much they are attracted to the bed's "sleep in" action advertisement, so after they sleep in one bed a few times, when they become tired, that bed becomes more attractive than the couch and other people's beds, so they learn to sleep in the same bed every night.

Wow cool, do you have a link to Phil Agre's AI LitCrit please?

Have you read Chip Morningstar's "How To Deconstruct Almost Anything: My Postmodern Adventure"? "Academics get paid for being clever, not for being right." -- Donald Norman

http://www.fudco.com/chip/deconstr.html