Tuesday, 24 August 2010

An Open Book

I'm not sure this is the right thing to do. I don't know what is. Here are my journal and technical design notes:

At least it should help save some blog time. It's quite a lot to absorb, but dig in, let me know what you think, ask questions.


  1. Thoughts, as I come to them:

    "Components and their connections can be arrayed, or collected such that individual circuits can operate in parallel"

    But isn't everything already operating in parallel?

  2. Thoughts, as I come to them:

    "Where a circuit developed to control a single entity (e.g. a game object), it should be easy to instance this object multiple times and it’s control circuit within the game"

    I'm not sure that instanciating the same circut multiple times is really the best paradigm. I would have thought that having one circut operate on multiple 'objects' in parallel would make more sense.

  3. Also, still can't figure out what you mean by a component being arrayed. Components are circuts, not objects, right?

  4. Arraying is needed to allow for dynamically sized systems. Yes, multiple circuits do operate in parallel, and you can set this up manually placing down and wiring up each one individually, or you can use arrays to automatically create how ever many are needed.

    You do have the choice to have:
    (a) many (arrayed) circuits controlling an entity each (in parallel).
    (b) one circuit controlling many entities (in parallel) with multiple circuits internally.
    (c) one circuit controlling many entities one-at-a-time with a single control path.

    However, it's far easier to maintain state for each entity with multiple circuits, and a and b are almost identical anyway.

    Does that help?

  5. I think so. I guess I just have trouble wrapping my mind around the state of an object being not just 'data' but more 'data at several positions in a circut, which can change the way the circut works'. There's a certain organic autopoiesis to this approach, which is really good... but it's still different enough from procedural OOP that I have trouble thinking in this model.