Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


GDC = AI_Fest; while(GDC == AI_Fest) {CheerWildly();}


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
71 replies to this topic

#41 BrianL   Members   -  Reputation: 530

Like
Likes
Like

Posted 16 March 2004 - 05:03 AM

I think we are arguing sematics; specifically, the definitions of reactive and deliberative are. One of your comments though jumped out at me:

quote:

In one case, you have a decision available immediately (reactive) in the other case you have to search for a decision (deliberative).



Is that the difference, for you, between an agent based on an deliberative and reactive behaviors? Any time a search is involved, the agent is deliberative? If there is no search, it is reactive?

In the end, it seems like the fuzzy area between strictly deliberative and strictly reactive agents will be the best solution for most problems. It seems like SPA itself could be implemented as a reactive system though, so am unsure if the elements in this argument are even lined up against each other.

For instance:

Sense: Find the nearest wall
Plan: Apply the ruleset for combining destination and wall
Act: Move

Would this be a S-P-A that is reactive? What change would be required to make it reactive?

(...and I am glad I am not the only person continuously messing up tags! )

Sponsor:

#42 alexjc   Members   -  Reputation: 450

Like
Likes
Like

Posted 16 March 2004 - 05:47 AM

quote:
Original post by BrianL
Is that the difference, for you, between an agent based on an deliberative and reactive behaviors?

Any time a search is involved, the agent is deliberative? If there is no search, it is reactive?



Reactive behaviours are generally local. But an agent based on reactive techniques uses immediate lookup instead of search. Finally, a reactive architecture is event driven rather than query based.


quote:

Would this be a S-P-A that is reactive? What change would be required to make it reactive?



That''s a reactive technique because it seems you''re not planning. I wouldn''t call that an S-P-A for the same reason.

But doing the sense-plan-act in that order means your architecture is not event driven (not a reactive architecture).



What''s the tag to get smaller fonts for my footer?


AiGameDev.com

#43 BrianL   Members   -  Reputation: 530

Like
Likes
Like

Posted 16 March 2004 - 06:11 AM

quote:

But doing the sense-plan-act in that order means your architecture is not event driven (not a reactive architecture).


Something has to generate those events; an external to the AI system can generate them, or the AI can monitor the world and generates events internally.

External events (agent took damage) are nice and easy to treat as events which potentially trigger a state change in an reactive system.

Other events seem more problematic; how would you handle ''AI just received line of sight to an enemy because the enemy turned the corner''? Something like this would have to be monitored by ''something''. It may be a system internal to the AI, or the AI could issue a request an event when this occurs from a shared visibility system. Either way, something is in a sense loop at this point, checking for this visibility continuously.

In the context of event driven vs query driven agents, any deliberative system could be converted to a reactive system by moving all of the sensing to exterior systems, provided the exterior systems provided arbitrarily complex queries themselves which an AI could request, and which were translated into events sent to the AI who then reacted to them.

Is that correct? If so, how is this an advantage over allowing each AI to do this on its own?

#44 alexjc   Members   -  Reputation: 450

Like
Likes
Like

Posted 16 March 2004 - 11:43 AM

quote:
Original post by BrianL
Other events seem more problematic; how would you handle 'AI just received line of sight to an enemy because the enemy turned the corner'? Something like this would have to be monitored by 'something'.



I'm glad you brought that up. I think it's a very important issue.

Having the AI query for that information is like an annoying user; it just requires a small amount of information for itself, and is oblivious to the rest of the system. It's innefficient because the queries are dispatched at the convenience of the AI, and require immediate attention.

On the other hand, an AI that deals with data when it is provided is like a patient user that understands that there's an entire game to be run on the same processor. This is more efficient because the game engine can decide when it's most convenient to compute the information and pass it to the AI.


Who would generate the events? It could be the physics engine, or possibly during the game logic update. But it doesn't matter; decide that along with the engine programmers. If they decide how to do it, it'll be more efficient as a batch process -- instead of one off queries. And all it takes is for you to design your AI as a reactive architecture...


quote:

In the context of event driven vs query driven agents, any deliberative system could be converted to a reactive system by moving all of the sensing to exterior systems, provided the exterior systems provided arbitrarily complex queries themselves which an AI could request, and which were translated into events sent to the AI who then reacted to them.



Exactly. You can nest a SPA within the reactive architecture by storing the data you need, and still have the advantages I listed above.


I'm glad we're on the same page! What shocked me about Brian's original rountable summary was that he separates the "phases" sense-plan-act, which implies queries rather than an event driven approach (There are no distinct phases with a reactive architecture.)



Any ideas how to print this signature with a smaller font?


AiGameDev.com
  • The Book - Synthetic Creatures with Learning and Reactive Behaviors

  • Tutorial Series - Exercises in Game AI Programming




  • (Edited by mod to adjust font size...Alex, edit this post to see how its done...)

    [edited by - Timkin on March 17, 2004 6:24:08 AM]

    #45 Timkin   Members   -  Reputation: 864

    Like
    Likes
    Like

    Posted 16 March 2004 - 11:45 PM

    Great to see other people wading into the conversation!

    Okay, Alex, I finally think I understand the issue now... I''ve been talking about reactive planning vs deliberative planning and how these differ in terms of SPA, while you''ve been talking about reactive agents (in terms of information gathering) and how these differ from SPA. There are some subtle and some glaring differences between reactive agents (by your definition) and reactive planners, the most obvious being your notion of a reactive agent: an agent that deals with stimuli when it it presented to it, rather than actively aquiring it as part of an iterative algorithm;

    This is different to a reactive agent that acquires a stimulus from the environment and reacts to that stimulus with no consideration of the global optimality of the action choice (but perhaps with local consideration). This is how the planning community would think of a reactive agent/planner. Thus, both and SPA agent and your reactive agent could be reactive planners (where the SPA agent uses a plan of length one and only local information about the domain, gleaned from the stimulus).

    So, now I might be able to talk about your notion of a reactive agent in terms of SPA and not confuse the situation by thinking that we''re talking about reactive planners!

    What''s your biggest bone of contention with SPA? That it''s iterated and involves polling the environment? I can easily envisage an agent that utilises SPA that fits into your notion of reactive (i.e., continues in its current plan/action until a stimulus is provided by the environment, at which time it evaluates the effects of the stimulus on its plan to determine whether changes to the plan are required... the plan is certainly just part of the internal state of the agent, since it represents a desire to achieve some goal, to steal from the BDI literature).

    I don''t think SPA is the antithesis of reactive (in your sense) in this problem scenario; I think that iterative polling is. However, whether that polling is done by the environment or by the agent, doesn''t mean that it''s not happening... it''s just shifted responsibility. Why is shifting responsibility for monitoring the occurance of events to the environment a better solution in terms of software engineering? You still have to do the work...

    Unless, of course, you can tell me how we get stimuli from events without a polling mechanism?

    Getting back to the SPA ''reactive'' agent... why would we want our reactive agents to NOT use global information and deliberate about the global effects of a stimulus just acquired (other than the obvious computational load)?

    Cheers,

    Timkin

    #46 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 17 March 2004 - 12:16 AM

    quote:
    Original post by Timkin
    What's your biggest bone of contention with SPA? That it's iterated and involves polling the environment?



    My problem is with the sequence:

    Sense(); Plan(); Act();

    It's ok for systems that have only one agent, but for games separating these phases is just an incredibly rigid approach... Polling doesn't help either. More below.


    quote:

    I don't think SPA is the antithesis of reactive (in your sense) in this problem scenario; I think that iterative polling is.



    I've always seen SPA linked with polling, as it originally was, and the papers I've read that fix the problem use reactive approaches and call their systems hybrid... so pure SPA is evil!



    quote:

    Why is shifting responsibility for monitoring the occurance of events to the environment a better solution in terms of software engineering? You still have to do the work...
    Unless, of course, you can tell me how we get stimuli from events without a polling mechanism?



    I contend that it's much easier to design a system using the event driven approach. Yes, many things can be expressed as events very easily with few changes in the code. In the other cases, it's just a matter of reorganizing code, but it gives you more flexibility.

    Ok, here are some reasons:


    • Fine grain control. Event handlers are coded for very specific purposes. As a consequence, functionality is divided naturally over many functions. This allows you to control execution of the AI better. Say an NPC is far outside of the range of the player, you just don't send it messages. If it's nearby, you just send it sound events. As it gets closer, you can enable more and more of the AI functionality incrementally by deciding what messages should be sent. With the SPA polling, you end up with a coarse 'if (active) Sense();' or really ugly control flow within the sensing procedure.

    • Decoupling of code. With messages, your AI doesn't depend on the engine as rigidly. During development, you can enable and disable messages, and the AI would work. You also get the advantages of hot-pluggable AI if you code it right... just more flexibility basically, but that applies to software in general.



    quote:

    Getting back to the SPA 'reactive' agent... why would we want our reactive agents to NOT use global information and deliberate about the global effects of a stimulus just acquired (other than the obvious computational load)?



    If you're going to ignore computational load, it'd have each planner consider actions globally, but within the internal world model of each NPC. So the planning would reflect beliefs (BDI) and personallity, etc. Yeah, there's nothing wrong with that.

    In fact, I've been researching this over the last few days, applying SOAR's chunking to get reactive planning within BDI... cool stuff.


    AiGameDev.com: Artificial Intelligence from Theory to Fun!


    Edit: I will get this sig. right! Font size doesn't work within lists unless you duplicate the tag...

    [edited by - alexjc on March 17, 2004 7:22:41 AM]

    #47 BrianL   Members   -  Reputation: 530

    Like
    Likes
    Like

    Posted 17 March 2004 - 04:15 AM

    The Sense state polling can operated on just as fine a level of granularity, and at times may be more efficient.

    If the sense stage can definitely be broken up into steps. For instance, there may be several independant sensors, each of which senses a single ''type'' of event (enemy, good position to attack from, heartbeat, damage, etc) and translates it into information on the AIs blackboard/working memory. (see the work by the MIT Character Group:

    http://characters.media.mit.edu/publications.html

    specifically, ''A Layered Brain Architecture for Synthetic Creatures''.

    With a system like this, the sensors may be attached and detached as needed. Each sensor may have its own polling frequency, or may even be event based. However it is implemented, I contend that a polling system, when well designed, will be just as easy to work with as an well designed event based system.

    #48 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 17 March 2004 - 04:33 AM

    quote:
    Original post by BrianL
    I contend that a polling system, when well designed, will be just as easy to work with as an well designed event based system.


    Polling and queries are efficient for chunks of data that are readily available in the world representation, or computed with trivial operations. Otherwise, it'll be more efficient to batch up the queries and dispatch the results as messages.

    You could design a modular polling based sensory system, but it wouldn't be as easy to manage. For example, you'd have to have each agent keep track of the state of the game so it knows when to hear and when to see (all the time is innefficient). You get a level-of-detail AI paradigm for free with messages. Another example, how would you notify many AI soldiers about the sound of a player knocking on the door using sensing via polling?

    If you've worked with messages before, you quickly realize their power... It's what makes Smalltalk such a flexible programming language. Sure, it takes a bit of skill to get a nice event-driven system in procedural languages like C++, but if you know what you're doing it pays off in elegance and efficiency. (Anyone can do polling )


    Also note that the C4 reference you gave relies heavily on message passing via "DataRecords."


    I'm not going to preach about this any further . Polling isn't very efficient in software generally (see Windowing Toolkits like QT), and AI is the same to me.

    Alex



    AiGameDev.com: Artificial Intelligence from Theory to Fun!

    [edited by - alexjc on March 17, 2004 12:31:51 PM]

    #49 Timkin   Members   -  Reputation: 864

    Like
    Likes
    Like

    Posted 17 March 2004 - 04:35 PM

    quote:
    Original post by alexjc
    Say an NPC is far outside of the range of the player, you just don''t send it messages. If it''s nearby, you just send it sound events. As it gets closer, you can enable more and more of the AI functionality incrementally by deciding what messages should be sent.


    This is the one problem I have with messaging systems... you STILL need an oracle watching over the environment and deciding when events occur. This oracle is going to need to run at a fine resolution to ensure that small duration transient events are not missed (like bullets ricocheting off walls and producing sound events for nearby agents). Now, instead of having agents poll their local environment, we have the environment essentially polling agent states and checking them against environmental states. I don''t see that the computational workload is improved.

    From the perspective of system design, yes I do understand the benefits of messaging systems... they do permit clean event driven architectures that are ''relatively'' easy to debug... however they don''t diminish the computational load... so they''re just shifting design difficulties into object event difficulties.

    Personally, I think we need a whole new paradigm... something along the lines of an agent-centered message system, placing the onus on agents to notice events in the environment, rather than have the environment tell them that they notice them. Such a system might be built as an interface between the environment and the agents inference system, so it looks like sense(), but works by filtering scenes of the environment (here, I mean scenes to be things that can be sensed... sounds, images, smells, etc) and passing messages to the inference engine based on the filter results. The resolution and accuracy of the filter determines whether certain things get noticed and passed into the inference engine. This places the onus of perception back on the agent, where it should belong (from an AI perspective at least).

    Such a paradigm again separated sensory action from the decision making architecture of the agent, but doesn''t remove it completely, allowing different interfaces to be designed for different classes of agent.

    Anyway, that''s just my looney idea for the day!

    Cheers,

    Timkin

    #50 IADaveMark   Moderators   -  Reputation: 2512

    Like
    Likes
    Like

    Posted 17 March 2004 - 05:07 PM

    "Events" is too broad a term anyway. A bullet hitting a player is an "event". It is the function of the bullet and should notify the player. It would be foolish for the player or any other NPC to poll all of the bullets on the screen to see if any of them happen to be hitting him.

    For that matter, "agent" and "object" are being loosely used here. The player, the NPC and the bullet are all objects. Which object should be polling the environment? Should only intelligent things "poll" the environment because only sentient things should notice stuff? We are back to the PC/NPC polling the bullets if that were the case.

    Again, we are at the point of a definition of terms that may or may not give us concrete 1:1 results. e.g. TermA always uses MethodA. It is this sort of trying to "solve the world" through definitions and theory that hems us in a little bit. The bottom line is, each situation is going to have its challenges based on the needs of the design and the needs of the AI. Solve each of those challenges individually. If you happen to reuse tools such as the ones you guys are talking about, fine... do that. However, there are going to be situations where (to oversimplify my example) having the bullet poll the world is better and others where polling for bullets would be favorable. None of that can be boiled down to an answer of "my way is better than yours".

    That''s largely why I didn''t want to even bother with this discussion... you aren''t solving anything. You aren''t designing anything. You are playing with words and theories. Real heady stuff but about as useful as trying to narrow down all of America''s political issues to a two-party system. There are just too many situation gray areas.

    When it comes to a real in-game problem, this thread could only be used as a banner stuck in the ground and forgotten. Rah-Rah-Yay-Yay-whatever... Now let''s get to work of figuring out how to do THIS particular AI problem in THIS particular genre with THIS particular design pattern and architecture with the needs of THIS particular game design.

    Dave Mark - President and Lead Designer
    Intrinsic Algorithm -
    "Reducing the world to mathematical equations!"

    #51 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 17 March 2004 - 10:27 PM

    quote:
    Original post by Timkin
    This is the one problem I have with messaging systems... you STILL need an oracle watching over the environment and deciding when events occur.



    Welcome to computer games! In games, you already have something doing that, both physics engine and the game logic. (They usually tightly integrated.)


    quote:

    This oracle is going to need to run at a fine resolution
    ...
    instead of having agents poll their local environment, we have the environment essentially polling agent states and checking them against environmental states.



    You need your oracle/game logic to run at a fine resolution anyway; your gameplay relies on it. The difference with events is that things happen lazily, you only watch the area around the player rather than getting all the agents in the world to poll. It's efficient because it's done lazily, and you can use optimizations of the physics engine (like space partitions) to find the set of applicable agents.


    In my project, there's one kind of sensing that's done by polling; line traces. These need to be computed on a custom basis, as requested by the agents. I'm trying my best to batch them up and return the results as messages, by sorting line traces according to the world-representation and processing them in a sensible order. Computation time drops down to a fraction of what it was because you've got fewer cache misses as everything is still in memory while you compute the batch results.

    Now I'd be very interested if you can name one single other thing in games that isn't suited to batch processing...


    quote:

    Personally, I think we need a whole new paradigm... something along the lines of an agent-centered message system, placing the onus on agents to notice events in the environment, rather than have the environment tell them that they notice them.



    What for?


    InnocuousFox:

    There are many thing to take from this beyond definitions:

    • Use reactive behaviors if you can get away with it

    • Use reactive techniques as much as memory allows

    • Try to design your AI as an event-driven reactive architecture


    Now maybe Timkin and the "planning community" would get upset about this (hehe ), but this is very good advice for practical game developers.

    Alex

    AiGameDev.com: Artificial Intelligence from Theory to Fun!

    [edited by - alexjc on March 18, 2004 5:35:34 AM]

    #52 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 17 March 2004 - 10:45 PM

    Timkin: Wouldn''t your latest idea also be known as a blackboard architecture? The senses post the events to the blackboard, and the brain gets to "perceive" then selectively...

    Alex

    #53 Timkin   Members   -  Reputation: 864

    Like
    Likes
    Like

    Posted 17 March 2004 - 11:26 PM

    quote:
    Original post by alexjc
    Timkin: Wouldn't your latest idea also be known as a blackboard architecture?

    No, that's not what I had in mind. Think of the sensor as a filter and translator rolled into one. It generates internal messages akin to the type you describe (which I call external messages), but it does so based on filtering incoming information. Presumably that information is available whenever the agent updates in the game loop, or at some other frequency, like when it actually looks at things, or stops and listens.

    As to Dave's comments...

    quote:

    A bullet hitting a player is an "event". It is the function of the bullet and should notify the player.



    One could argue that the player was in the way of the bullet... but your point is valid in this example. However, there are two ways to classify events with respect to agents: 1) Those caused by the agent; and, 2) those caused by the environment (anything external to the agent). Certainly, for the latter class of events, one might want to have the environment tell the agent about that event. However, for the former, one would probably want the agent to notice the affect it has on its environment (which is particularly important in learning algorithms).

    quote:

    For that matter, "agent" and "object" are being loosely used here.



    I disagree. I know exactly what I am referring to when I say agent... from the AI perspective, an agent is an entity that perceives its environment and acts in response to its perceptions. An object on the other hand is just a thing. Now, if you want to talk data structures and internal representations, sure, agents and walls are both 'objects'... but we're not talking about them in that way... at least, I know I wasn't!

    quote:

    you aren't solving anything. You aren't designing anything



    I disagree. We're discussing general design principles of agents, from which their applicability follows. Sure, we're not having a discussion about "how do I get a neural network to write my homework", or "what's a finite state machine". We are though, discussing important and fundamental issues in modelling environments that have agents embedded in them (in Alex's terminology, Emboddied Agents).

    Both theoretical and practical discussions have value. I completely disagree that the only way to tackle AI, particularly Game-AI, is to think only in terms of the practical problem in front of you (and to allow for overlap of problems ONLY in so far as the tools used to solve those problems are the same or similar). Such thinking would almost never lead to new generalised architectures or methods, only new applications of old techniques, or ad hoc , one-off solutions that are all too common in both AI and Game-AI. Having generalised architectures and design principles leads to quality standards that are taken by many developers. The architectures are tested and refined on many problem instances and lead to better designs. This is how we will one day achieve software agents with believable human behaviours. The thing to remember Dave is that not all of us are here because we're writing a game (or dreaming of it)... some of us are here for the computer science and to see the field of Game-AI develop and improve itself so that one day it lives up to the expectations of the players.

    Timkin

    [edited by - Timkin on March 18, 2004 6:32:39 AM]

    #54 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 18 March 2004 - 03:16 AM

    quote:
    Original post by Timkin
    Think of the sensor as a filter and translator rolled into one.



    So the sensor is a closure (a function with state) that is linked to the events generated, caches the data internally, gives a boolean indication to the agent as an event too, but only provides the data when the agent requests it?


    quote:

    I completely disagree that the only way to tackle AI, particularly Game-AI, is to think only in terms of the practical problem in front of you



    Indeed. The hacker culture is great, but it''s a very narrow minded attitude...

    Alex


    AiGameDev.com: Artificial Intelligence from Theory to Fun!

    #55 BrianL   Members   -  Reputation: 530

    Like
    Likes
    Like

    Posted 18 March 2004 - 03:40 AM

    I may be off here, but I think you are trying to make the definition of sensor a bit too tight Alex. That would be one way to implement a sensor.

    We could just as easily have a ''heartbeat sensor'', which every 10 seconds sends an event to the AI. This sensor does not even look outside the AI for things.

    A sensor could also be the recipient of an external event from the engine (''you bumped into a wall'') which it translates and passes on to the AI.

    A sensor could proactively scan the environment for hostiles, maintaining a list of the n most threatening enemies.

    Now, the question of how the sensor communicates with the Agent is may vary. A sensor may post information on a blackboard or another shared location (and may set a flag/send an event that this info changed). It could be implemented to post events to the Agent with processed information in a digestable form similar to your event system ideas. It could cache it and wait to be read.

    Since any of these are valid, it seems like the definition of a sensor is separate from the information flow system that handles communication between these modules. I am not saying that we shouldn''t discuss this component; only that it is outside of the sensor itself.

    #56 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 18 March 2004 - 03:45 AM

    quote:
    Original post by BrianL
    I may be off here, but I think you are trying to make the definition of sensor a bit too tight Alex.



    Oh, I wasn''t defining sensors. I was trying to understand Timkin''s approach


    I agree mostly with what you said. I see a sensor as a generic concept, which can translate into poll-based queries or event-driven messages...

    #57 BrianL   Members   -  Reputation: 530

    Like
    Likes
    Like

    Posted 18 March 2004 - 03:47 AM

    On the point of batching trace lines; this only helps if cache coherency is maintained through through the search. If your world representation is multiple megs, then it is very easy to ignore cache coherency completely as doing any trace line will result in a sequence of misses.

    I am not anti-batching, but this level of optimization may not be commonly helpful, particularly due to the complexity of a decent scheduler.

    I think it may be easier at times to optimize number of trace lines performed when the Agent can simple say ''that first trace line was a success, I don''t need to do any more''. That is easier to do when the agent is controlling the order itself instead of relying on a batch system.

    Again, I am not trying to shoot down your ideas at all, just providing a view based on my experiences. I am very open to other views on this, as I have not worked with a substantial system like the one you describe.

    #58 IADaveMark   Moderators   -  Reputation: 2512

    Like
    Likes
    Like

    Posted 18 March 2004 - 03:48 AM

    quote:
    Both theoretical and practical discussions have value. I completely disagree that the only way to tackle AI, particularly Game-AI, is to think only in terms of the practical problem in front of you


    I didn''t dispute either of these. I never claimed that it was the "only" way or that you should think "only" in those terms. However, there are times when this discussion has tended towards solving "all" problems with all-inclusive theories. That was my only contention.

    Dave Mark - President and Lead Designer
    Intrinsic Algorithm -
    "Reducing the world to mathematical equations!"

    #59 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

    Likes

    Posted 18 March 2004 - 04:12 AM

    Ack... one-hour talks in a dark room about AI just suck.

    #60 alexjc   Members   -  Reputation: 450

    Like
    Likes
    Like

    Posted 18 March 2004 - 04:24 AM

    Granted BrianL. Line traces are a challenge to handle elegantly, which is probably why I still use polling queries for some of them... However, while your agent may need custom control over some line traces, there''s a lot of stuff that''s quite common (e.g. checking for visibility of a bounding box that optionally requires multiple traces). That kind of thing is ideally suited to batching, and can be done lazily... which leaves only a few exceptions.

    Counter-examples are really welcome by the way, I''m curious what kind of things are difficult to code with messages (but are worth it), and those things that are just not suited to messages.


    I''ve not worked with a pure event-driven approach either, there are some little details that just aren''t worth it. But right now I am putting in the effort to make sure my project handles a great majority of the sensing via messages. It''s proving to be worthwhile so far.

    Alex

    AiGameDev.com: Artificial Intelligence from Theory to Fun!




    Old topic!
    Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



    PARTNERS