Print

Please login or register.

1 Hour 1 Day 1 Week 1 Month Forever

Login with username, password and session length

[Igor Savin]

What is the difference between TNode and TSystem? As far as I can tell from the sources, TSystem is generally TNode with a little bit of logging attached. Is there any particular reason I should use it instead of TNode? Is a creature or an item a TSystem too? Or TSystem is a special kind of TNode designed for under-the-hood system things (input, output, etc), and I should tailor my own hierarchy with some TNode being a parent (World) and all other TNodes being connected to it? But documentation states that
"<Systems>'s the only TNode that should be allowed not to have a parent"
Does that mean that World is a System that is connected to the Systems (since you can't connect TNode to Systems)?

[Kornel Kisielewicz]

Havn't you seen this article?

http://valkyrie.chaosforge.org/index.php?sect=docshow&file=base

[Igor Savin]

Yes, I have read it.

"TNode is great as a base for objects in a game. Elements of a game usualy form a natural tree structure, for example -- Games have Worlds, Worlds have Areas, Areas have Maps, Maps have Items, Maps have Monsters, Maps have Players".

Yet it's not clear, how such a structure can be formed without a primary TNode.


"Singleton TSystems (a descendand of TSystem) in te form of the variable Systems, is the root of the whole Valkyrie program tree. It's the only TNode that should be allowed not to have a parent. TSystems' children should be TSystems. The uniqueness of Systems is that it is autoinitialized at runtime, and autodisposed at program end -- meaning, that any child of it is also disposed. So as long as all classes in the program form a tree with the root Systems, you need not to dispose anything manualy."

Maybe I have misunderstood something, but isn't statement
"So as long as all classes in the program form a tree with the root Systems, you need not to dispose anything manualy."
a clear suggestion to connect every used class into Systems?
And TNodes cannot be passed into Systems, since Systems only accepts TSystem to be added.

is Systems supposed to be completely separated from TNode

Systems->Input
           \->Output
--------------------------------------------
World->Level->Monster-Inventory

or it should look like

Systems->World->Level->Monster?
           \->Input
            ->Output

If the second case, then World has to be TSystem. If the first - we have 2 TNodes without parents, Systems and World. Both of cases contradict the documentation...

Or I am completely lost somewhere.

[Igor Savin]

This article (http://valkyrie.chaosforge.org/index.php?sect=docshow&file=vrl)
suggests organizing game in the following way:

S - TSystem.
N - TNode.

Systems(S)->Game(S)->Map(N)->etc.

Map is added using the following code:

\\\
  Map := TMap.Init;
  Add(Map);
\\\

How can we add TNode "Map" to TSystem "Game"?

[Kornel Kisielewicz]

Remember that TSystem is also a TNode :). You create one TSystem inheriting class called TBerserk (or whatever the name of the game is) and then add anything to it -- like TWorld(TNode)... etc. Like the second example you wrote. The good thing about it is that calling Berserk.Done will free everything.

I usualy do it like this:

Systems -> TNameOfGame -> TWorld -> TLevel --- more...
            -> TInput
            -> TOutput
             etc...

And game is a TSystem! And it can carry nodes, because it's a node too :D.

[Igor Savin]

\Remember that TSystem is also a TNode :).\

Weird stuff. Every Socrate is a man, not every man is Socrate. So the inherited classes are backwards-compatible when it comes to using them as procedural arguments?


Feels like sombody presented me a personal thermonuclear bomb...

[Kornel Kisielewicz]

* Kornel Kisielewicz hands Igor the thermonuclear bomb.

Here you are ^_^

* Kornel Kisielewicz runs away!