Re: new here, my lang project...

• Previous message: Ilja Preuß: "Re: Singletons"
• In reply to: H. S. Lahman: "Re: new here, my lang project..."
• Next in thread: H. S. Lahman: "Re: new here, my lang project..."
• Reply: H. S. Lahman: "Re: new here, my lang project..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

Date: Sun, 23 Jan 2005 01:18:06 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:VExId.9709$Dz2.5395@trndny09...
> Responding to Cr88192...
>
>>>But those interactions should be independent of who (player or AI)
>>>provides the instructions. If the game artifact needs to know whether it
>>>is controlled by player or AI, then there is <very likely> a cohesion
>>>problem in the way the UI and/or AI is encapsulated.
>>>
>>
>> actually, this is fairly common, eg, in quake.
>> if(other.classname!="player")return;
>> type stuff...
>
> IMO, that is not good design. Whatever the 'other' artifact does depends
> upon context. If that context is changed, there will always be a risk
> that 'other' needs to be changed as well.
>
yes, however, the engine usually changed other on its own.
quake had a system of "mystery globals" that changed on their own, other was
one of them (along with time, self, ...).

I was not arguing it as good design however, eg, I tend to pass 'other' as
an explicit argument at least. as for other things, it depends.

in my code, time tends to be a function (for when needed), or time is
removed from many of the places where it was.

eg:
in quake one would be like:
self.thinktime=time+1;

wheras, mine is just like:
self.thinktime=1;
and self.thinktime rapidly decreases and the think event is generated once
it hits 0.

>>
>> of course, quake also did things like:
>> do some stuff...
>> self=other;
>> do some more stuff from the point-of-view of another object.
>>
>> this is imo something I find particularly ugly...
>
> I agree.
>
yes.

>>>I would expect the AI to need to be up to date on what game artifacts are
>>>around, where they are relative to each other, what they are doing,
>>>context information (e.g., a state of war exists), etc.. But I would not
>>>expect the AI to need to know a lot about display rendering. That is,
>>>the AI cares about the game logic, not the display logic. (Though the
>>>game logic may inform both the AI and the rendering systems when some
>>>change is made.) So I would expect the AI to talk to the game logic and
>>>the game logic would talk to the display rendering subsystems.
>>>
>>
>> yes.
>> the general properties of origin, angles, velocity, and bounds are needed
>> by most subsystems, things like the model, skin, ... may be needed by
>> rendering, and things like the classname, various state data, ... may be
>> needed by scripts. the physics though, primarily wants the classname,
>> movetype, solidtype, model, ...
>> however, the sequencer only really cares much about the model and current
>> anim sequences.
>>
>> ...
>>
>> everything is wrapped up in the general package known as an entity, which
>> is shared between many subsystems (and takes the form of a bag of slots).
>
> Ah, yes. The old one-size-fits-all trick. I now see where your
> predilection to pointer indirection came from. In a word: Yech!
>
> This approach leads to monolithic god objects that lurk in the center of
> the application with tendrils touching every activity. Their behaviors
> tend to have lots of IF decisions about context like the your example
> above. Usually any change in peripheral objects also needs a change in
> this critter. Better yet, a change to it to accommodate one subject
> matter will often break interactions in another subject matter that seems
> completely unrelated.
>
yes, however, at least the scope is limited "a little".
ammusing is that the nature of these objects feels pulls even from other
engines, eg, to match their specific conventions.
what breaks there have been thus far (eg: calibrating space in meters vs.
carpentry or standard inches) have resulted in endless annoying troubles.

> When one encapsulates subject matters one can implement their view of the
> world independently from other subject matters. That simplifies the
> subject matter implementation, allowing one to focus only on the
> requirements for the subject matter. It also allows one to recognize
> invariants unique to the subject matter much more easily. It will also
> tend to isolate changes to particular subsystems when requirements change.
> All those things combine to make the application more reliable and
> maintainable.
>
yes.

> The main reason is that each subsystem has its own functionality that is
> unique to the subject matter. If that functionality is properly isolated
> and decoupled from other functionalities via a pure data transfer
> interface, then one has a much more robust design than passing around
> monolithic objects that any context can trash.
>
however, the monolithic objects aproach is sort of forced by the
predecessors I have inherited some formats, tools, ... from.
in some cases, I can do little really wrt fundamental issues.

> Of course, there is no free lunch and there is one cost. Different
> functionalities can do different things when operating on the same data.
> Some some data needs to be shared across those "independent" subsystems.
> That requires synchronization when the data changes so that all the
> subsystems "see" the right data values. Fortunately, that is relatively
> easy to do with data transfer interfaces. When somebody changes data it
> sends a message to everyone who might care, which includes any subsystems
> that operate on that same data.
>
> In fact, that synchronization substantially changes the way one approaches
> the problem solution. Quite commonly the precondition for executing a
> behavior is that the data state has changed somewhere else. So those
> "synchronization" messages actually become the overall flow of control of
> the application. Thus Fred changing X triggers Harvey to do something
> that changes Y, which triggers Fred to do Z, and so on.
>
ok.

> Note that you don't need to be doing OO to design this way (though
> abstraction makes it easier). In C one keeps local structs in each
> subsystem that are organized explicitly to that subsystem's needs. They
> will have only the necessary subset of all the data associated with the
> entity that they need to resolve the subject matter's responsibilities.
> Some of that data will appear in structs in other subsystems, so when it
> is changed, those subsystems are informed via their subsystem API. The API
> function understands which structs within the subsystem the data goes into
> so they are updated. The API also knows if that change should trigger any
> behaviors within the subsystem and, if so, dispatches to them.
>
yes.

typically, yes, the subsystems are independent and have specialized data.

however, in my code in many cases the data is not known or managed by the
subsystems, but is instead used by others, and is either destroyed (freeing
up memory sooner) or forgotten (freeing up memory later).

> [Aside. If one uses events one can put the event queue in each subsystem
> in its own thread. Then one gets concurrent processing for the various
> subsystems in a quite robust manner almost "for free" --
> provided the subsystems' functionality's are self-contained and cohesive.
> (There are some situations where synchronization is more complicated, but
> they will usually become apparent when one designs the subsystem APIs.)]
>
yes.

I had thought about it recently, and eventually figured how one could pass
data between threads w/o locking.

oh well, it has been quite a while since I have used (system level) threads.
on current systems in many cases threads don't have a strong justification
for the extra work needed to maintain them (eg: avoiding race conditions,
securing subsystems via locks or such, ...).

>>>>in quake, there was a fairly strong distinction between the players and
>>>>monsters/other objects. the players had special entity numbers, and
>>>>special functions, ...
>>>
>>>I don't like that at all. The game has a fundamental logic for the rules
>>>and policies of the game and the game artifacts just do as they are told
>>>within that context. It shouldn't matter who is telling them to move,
>>>shoot, etc.; their actions, targets, etc. are all constrained by the game
>>>rules and policies.
>>>
>>
>> yes, but quake was not very open about this.
>> I personally did not like it much.
>
> Good for you.
>
yes.

>>>[Meier's CIV is a good example of how powerful parametric polymorphism
>>>can be. The game is designed around each artifact having a large but
>>>fixed number of characteristics that /may/ be relevant to an artifact.
>>>Those characteristics are defined in data that is initialized
>>>appropriately for the desired artifact, including an appropriate sprite
>>>icon. That allows such diverse games as CIV N and Alpha Centauri to run
>>>off exactly the same game engine with minimal time to market. Basically
>>>all one has to provide is a new set of parameter values, a new set of
>>>unit and map graphics, and a new game setup display. Everything else
>>>from the display logic to the AI Just Works. And in later editions they
>>>exposed the parameters to the player via text configuration files so that
>>>the player could design scenarios, tech trees, units, and whatnot.]
>>>
>>
>> ok.
>>
>> this is in strong contrast to the "ugly mass of scripts" approach, or the
>> need to duplicate and alter a large amount of code to make a slighlty
>> different version of a monster (eg: one with different ai, but a lot of
>> the same animations and actions).
>>
>> I had before considered that on a general scale, doing something like
>> class-based inheritence on the directory level (eg: defining directories
>> as kinds of classes that extend and override different directories) and
>> could construct general item or monster prototypes, could be quite
>> useful.
>
> You usually want to avoid subclassing when doing parametric polymorphism.
> The reason is that if the tree changes, that is a static relationship so
> one has no choice but to modify the code. Whenever possible one should
> provide the parametric changes via external configuration data so that one
> doesn't have to touch the code. [It can also reduce code size a lot.
> There have been examples where the combination of encoding invariants and
> parametric polymorphism have resulted in a 90% reduction in executable
> statements when an application was rewritten.]
>
dunno, the class model seems more straightforward though, and is an
improvement over "typical" practices in many cases.
actually, similar could be said for an anim sequencer, so the scripts no
longer have to worry about or manage the actual animations...

> I have have a fair amount of material on parametric polymorphism in the
> category for Invariants on my blog, including a sort of analysis pattern.
> So I won't repeat it here, but you should check it out. It is quite easy
> to implement parametric polymorphism in C with structs and pointers.
>
ok.

the "directory inheritence" idea was ammusingly simple to implement. some
things remain, but otherwise it was fairly simple.

of course, I did take the "path of least resistance" approach after all.

>> another misc idea has come up:
>> a tool to allow binding animations to not exactly matching skeletons.
>> eg: smd animations include a lot of info that implies the general
>> configuration of the skeleton (absolute positions, absolute angles, ...).
>>
>> however, doing things similar to what is done with skeletal animation in
>> the first place, it could be possible to use one skeleton and animation
>> (a template) to work on an existing skeleton (an instance) and create a
>> set of animations for that model (regardless of the exact configuration
>> of the models).
>> however, this does assume that the models sort of match (the same bones
>> with the same names). it could help though, eg, by allowing one to modify
>> the shape of a humanoid skeleton without fouling up the animations.
>>
>> the rough idea is:
>> using the info from the first skeleton, generate a set of vectors
>> representing the position of each bone (vs. the pos/angles system);
>> for each target frame, position the target skeleton such that it matches
>> these vectors.
>
> Unfortunately this is getting into rendering issues that are well beyond
> my ken. I haven't paid any attention to graphics techniques for a decade,
> which makes me pretty obsolete in that venue.
>
yes.

sprites have gone away. statically deformed meshes have risen and gone away.
static animations are fading, and may be replaced eventually. ...

always new systems with new data, and old tools that can no longer generate
new data or have arbitrary limitations. it is sort of like a treadmill on
this front.
there also seems to be an ever-increasing amount of ties between the
subsystems, eg, physics, scripts, and rendering appear to be getting
integrated at ever finer levels in newer games, ...

it is at least often a little easier to find info on the older approaches
than the newer ones.

of course, like the case with model formats, my geometry system is a
fragmented mess anymore...

• Previous message: Ilja Preuß: "Re: Singletons"
• In reply to: H. S. Lahman: "Re: new here, my lang project..."
• Next in thread: H. S. Lahman: "Re: new here, my lang project..."
• Reply: H. S. Lahman: "Re: new here, my lang project..."
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]