Re: new here, my lang project...

From: cr88192 (cr88192_at_NOSPAM.hotmail.com)
Date: 01/20/05 

Date: Thu, 20 Jan 2005 01:34:30 GMT

"H. S. Lahman" <h.lahman@verizon.net> wrote in message
news:5NxHd.15938$Vn2.3076@trndny06...
> Responding to Cr88192...
>
>>>>>>eg: an "order-0" association could probably only really associate
>>>>>>being hungry with eating. this could be helpful, eg, if it is atop a
>>>>>>scripted ai that knows to go twards any food and eat it if it is
>>>>>>getting an eat impulse. an "order-1" association would be needed to
>>>>>>associate, eg, the presence of food, being hungry, and the impulse of
>>>>>>eating, or choosing what to eat, ...
>>>>>
>>>>>...this seems to me to be several different interactions are involved.
>>>>>
>>>>>hungry -> look for food.
>>>>>food sighted -> chase
>>>>>food caught -> eat
>>>>>satiated -> sleep
>>>>>
>>>>>The behavior responsibilities for looking for food, chasing it, and
>>>>>eating it are likely to be largely unrelated (i.e., they are
>>>>>self-contained and logically indivisible). So each activity is
>>>>>triggered by a very specific change to the state of the application
>>>>>that maps to a postcondition of some other <self-contained and
>>>>>logically indivisible> activity. So events like 'hungry' reflect a
>>>>>very specific result of some particular activity.
>>>>>
>>>>
>>>>a lot of associative power would probably be needed for something like
>>>>that...
>>>>
>>>>this would not be a system of accurate or developed thought, my
>>>>expectation (as an upper limit) would be something roughly emulating
>>>>basic behaviors (maybe even if not very reliably or only approximately).
>>>>
>>>>humans seem to have an almost arbitrary-order associative ability afaik.
>>>
>>>Actually, this sort of thing tends to Just Work when one uses state
>>>machines to describe behavior (particularly object state machines for
>>>individual objects). That's because one can apply design-by-contract
>>>(DbC) to rigorously sort out where the events should go.
>>>
>>>Before any behavior (state action), X, can execute, some precondition in
>>>the overall algorithm must prevail. That may be as simple as having
>>>behavior Y execute first in an algorithmic sequence. Or it can be more
>>>complicated and include conditions on certain data being updated in a
>>>timely fashion. However, the precondition is usually fairly easy to
>>>identify.
>>>
>>>That precondition will always be the postcondition of executing some
>>>other behavior. That's because only behaviors can change the state of
>>>the application, so some behavior must execute to produce the
>>>precondition state for executing X. Therefore one has a rigorous
>>>technique for determining who cares about announcement events. One takes
>>>a given behavior, X, and determines the precondition. One finds the
>>>behavior, Y, whose postcondition matches that precondition. Then it is
>>>Y's announcement event that X cares about, so one sends the event to X
>>>when Y executes.
>>>
>>>The point here is that the sender/receiver associations aren't arbitrary.
>>>They are rigorously defined by the overall problem solution. [Of course
>>>there is a catch. This only works if behaviors are logically indivisible
>>>and self-contained. It is also very convenient if behaviors access the
>>>data that they need directly rather than having it passed to them. The
>>>reason is that one just needs to look at the behavior to know what state
>>>variables must be properly updated as part of its precondition. That
>>>allows one to daisy-chain behaviors to ensure the data is good when the
>>>behavior generating the event is good. (One can ensure data integrity
>>>for data that is passed around, but it becomes a major pain in a
>>>concurrent implementation.)]
>>>
>>
>> err, but I don't get how this really applies to human thought processes
>> and learning though (or emulating them).
>
> Actually, I was just referring to your comment about my treatment of
> events to the effect that, "a lot of associative power would probably be
> needed for something like that...". My point was simply that DbC provides
> a simple but rigorous technique for matching up announcement events with
> behaviors that care in order to connect the dots of the overall solution
> sequence.
>
ok, so I guess that explains the confusion some, I had been talking about an
associative/log-based ai that would use events as a way of percieving the
world, and actions/feedback as a way to interact and learn about it.

> It's not really about human thought. (One only gets into emulating human
> thought if the subject matter is the AI itself, as we got into later in
> the message.) It is more about encapsulating self-contained, logically
> indivisible behaviors and letting them interact to solve the problem. In
> theory in an OO development one could define all the objects and their
> behaviors by simply abstracting intrinsic behaviors of problem space
> entities that seem necessary to solving the problem. One could even write
> the object methods and unit test them prior to including any event
> generation or procedure calls for collaborations with other objects. Then
> one could then go to a higher level of abstraction (e.g., a UML
> Interaction Diagram) and apply DbC to determine the solution flow of
> control. Then one could backfill the methods with event generation or
> procedure calls from the Interaction Diagram to capture the overall
> solution flow of control.
>
ok.

> In practice experienced OO developers don't do this because it is usually
> pretty obvious who cares about the postcondition of the method in hand
> that is being coded. (When one abstracts properties that seem necessary
> to solve the problem, one needs a megathinker anticipation of the overall
> solution.) But they do resort to DbC when things aren't so clear (e.g.,
> when the receiver of the event needs data to have been updated
> consistently in different parts of the program).
>
ok.

>>>>>In this case it seems like BigCat is the single object doing
>>>>>everything; it looks for food, it chases food, it eats food, and it
>>>>>sleeps. But in practice the actual activities are likely to be
>>>>>delegated to other objects or even subsystems. Thus the "behavior" of
>>>>>looking for food may really just involve sending a message to somebody
>>>>>who knows where all the critters are relative to the local map. They
>>>>>do the actual looking and respond with a "food sighted" message. Maybe
>>>>>the chase behavior makes an evaluation: if the candidate food is not
>>>>>acceptable, it sends the "keep looking" message back; otherwise it
>>>>>sends a message to whoever manages chases over the terrain announcing
>>>>>that this Big Cat is chasing that Food. And so on...
>>>>>
>>>>
>>>>
>>>>well, the problem is that the ai is not all that well structured.
>>>
>>>I suspect there may be another problem. (More precisely, there is a
>>>special form of being unstructured.) Ideally the game elements should do
>>>their thing independently of whether they are player controlled or AI
>>>controlled. That is, the AI should be just as externalized as the
>>>player. The player communicates with the game via a UI, which is usually
>>>isolated in its own subsystem or layer. The same thing should apply to
>>>the AI; it should be encapsulated in its own subsystem or layer. In
>>>addition, the AI should issue exactly the same messages that the UI does
>>>to control the game artifacts. [The AI, though, needs to do a lot more
>>>accessing of data for the state of the game than the player, though,
>>>because it doesn't have a "free" display. So it may need a different
>>>interface than the UI for that sort of <synchronous> data access. But
>>>that is a one-way, synchronous data access.]
>>>
>>>IOW, the AI should be an application unto itself that encapsulates all
>>>the smarts that the player provides and it should be completely
>>>substitutable with the player UI for controlling any given game artifact.
>>>I'll bet that isn't the case.
>>>
>>
>> dunno.
>
> In the code you have, is the code different in any way for, say, moving a
> Soldier depending on whether it is the player or the AI initiating the
> moving (e.g., does it matter if the Soldier is German or US in
> Wolfenstein)? Are the player's "pieces" different than the AI's "pieces"
> in any significant way in what they know or do? Are the player and AI
> "pieces" dedicated to them (e.g., certain "pieces" are only used by the
> player and there is a hard-wired link to the UI in their implementation)?
> If the answers to any of these questions are Yes, then the AI has not been
> properly decoupled from the manipulation of game artifacts.
>
ok.

an ai would likely recieve events, and a player would likely have things
rendered. possibly a lot of what the ai would get would be the kind of info
sent to the player for rendering though.

a lot of the lower-level stuff (moving, aiming, attacking, ...) would
probably be hard coded, leaving the ai mostly to make decisions or such (in
quake, this was largely done by functions like 'findtarget' and such, and by
altering these functions one could somewhat effect the monster's behavior).

in quake, there was a fairly strong distinction between the players and
monsters/other objects. the players had special entity numbers, and special
functions, ...

> That sort of coupling is a manifestation of poor modularization. (Or poor
> structuring, if you will.) Ideally it shouldn't matter whether a Soldier
> is US or German; that is just a matter of what uniform is assigned for the
> graphics at startup. (An oversimplification, of course; a whole set of
> <data> properties is probably parameterized.) It should make no
> difference whether the control of movement, etc. comes from the player or
> the AI.
>

yes, but typically this is not the case in the games I have looked at.
in mine, it is sort of the case, eg: player movement is currently pulled off
by a set of kludges in the main loop, and monster movement isn't currently
implemented (unless of course I want to move them like a door or
platform...).

>>>>largely it just that different aspects of state generate messages, which
>>>>can trigger actions, ...
>>>>what actions are triggered by what events has to be "learned", ...
>>>>
>>>>of course, divulging from just coding up what is supposed to happen is
>>>>itself dubious, but if the algo is sound, and it allows sufficiently
>>>>complex associations, then it should be possible to learn basic
>>>>behaviors, possibly near that of what can currently be done with
>>>>hard-coded ai's (possibly, though, at the cost of a lot more
>>>>processing).
>>>>
>>>>an interesting test could be combining something like this with
>>>>something like genetic algorithms to try to come up with a fairly good
>>>>model of the ai (eg: you have a number of ai's competing with each other
>>>>and possibly humans). those that do best live on, and the rest are
>>>>replaced by combinations of those that did best, ...
>>>>
>>>>assuming a sufficiently good model, this may eventually result in
>>>>something that could compete effectively.
>>>>
>>>>maybe, maybe not.
>>>>
>>>>there are so many things that were not explained, or at least I haven't
>>>>got to them yet.
>>>>
>>>>something else like this should sensibly exist, but I don't know.
>>>>of course, the whole idea could be worth nothing as well...
>>>
>>>Carrying the point above further, I would expect the subsystem that
>>>encapsulates AI strategy to be a unique problem space that is exclusively
>>>devoted to emulating high level human thought. That is a daunting
>>>undertaking and I would expect the AI to have a complex scope. Thus I
>>>would actually expect it to be composed of multiple subsystems, each
>>>devoted to a particular aspect of that emulation (e.g., strategic vs.
>>>tactical algorithms; economic vs. military goals; etc.).
>>>
>>
>> this is a conventional ai, where the ai is coded to do something or think
>> some way.
>> I am talking about exhibiting abstract learning behavior.
>>
>> in the case of a learning ai, it is not as easy to divide.
>
> I think I have to disagree with that. Whether the AI uses hard rules,
> heuristics, or some sort of neural net learning, the AI mechanism needs to
> be encapsulated. I believe that regardless of the AI mechanism, there
> will actually be several quite different categories of things it will have
> to think about and each of those categories will involve a unique set of
> details. That means one is likely to have a different set of rules,
> heuristics, or neural net configuration for each category.
>
maybe.

I guess that is different than throwing everything at a single point and
expecting it to sort it out itself.

> It should be possible to encapsulate those separate AI mechanism contexts
> via subsystem encapsulation. In the end they all algorithms that operate
> on data. That data comes from the various game artifacts. All one should
> need is a set of interfaces that update the AI when something changes or
> an interface that the AI can use to obtain the latest data that it needs.
> One would probably use the first strategy for a continuous learning AI
> while the second strategy might be better for hard rules or heuristics.
>
ok.

> [Note that modularization allows one to apply the best AI approach for the
> context. Finding the shortest path for a point-to-point movement is
> probably a rules based thing. OTOH, determining how aggressive the player
> is would probably be a learning thing (though maybe not as exotic as a
> neural net).]
>
yes, finding paths will be left to scripts (since I can then leverage the A*
algo or such).

choosing things like attacking and running, or determining when to search
for cover or needed items would likely be left to the ai.

>> I appologize if my responses aren't that great, right now I am lacking in
>> time.
>
> So you have a Day Job? B-)
>
no, college classes have started, and right now things haven't really
stabilized again yet.

I was writing that just before about having to leave for classes.

Relevant Pages

  • Re: My Top Ten wish on Bynum
    ... Keep hands up under the basket ... Keep Learning ... restriction in the pros, more resources, and more coaching, access to ... Staying in for a junior or senior season puts a player in a position of authority on the floor, much sooner than it takes for them to become veterans in the NBA. ...
    (alt.sports.basketball.nba.la-lakers)
  • Re: Monte Carlo computer go methods
    ... players are not going to become professionals. ... learning "bad habits" becomes a detriment, ... level play. ... Each game between a stronger and weaker player verifies ...
    (rec.games.go)
  • Re: R&R Hall of Fame - Metallica, Jeff Beck, and Run-DMC?
    ... only player here to have spent hundreds of hours learning that stuff ... Try learning to play. ... Then you'll be better qualified to judge whether Jeff Beck ...
    (alt.guitar)
  • Re: Learning the notes on the Fret board
    ... Memorizing the playbook from a football team ... does nothing to make you a football player. ... make you a football player, but I have never seen a football player ... You cant criticise someone for learning. ...
    (alt.guitar.beginner)
  • Re: hello?
    ... even blanker as it wouldn't need what few innate behaviors ... I just see that as multiple layers of learning on top of one another. ... another layer of evolution learning systems on top of other evolution ... Take the example I've used a lot where you reward a robot for charging it's ...
    (comp.ai.philosophy)