On Wed, 2005-03-02 at 11:23 +0200, Alexander Whaley wrote: > This may be a "naive/stupid" thing to ask but here goes anyway: > > Can't dual processor chips be used to up the AI? > > By this I mean: > A game has to do a certain amount of work to get the image to the > screen, the sound just right and player actions must be dealt with. This > happens nicely with current games. However, if an AI could be set up on > a different thread, which is not framerate dependent, then the game > could appear more intelligent. New orders might be sent to the "main" > thread every 1/2 second - 1 second based on the tactical info and the > game would be smarter. Theoretically (and I am learning still), the AI > thread, running on its own CPU, could have access to a different set of > data, thus clashes on resources may be minimised. > > Is this a crazy idea? IT is not crazy at all, it is a great idea. What I am really trying to focus on is the mechanisms that need to be added to programming languages to make it easy to do what you are suggesting. But, it really helps to have some solid examples to work from. What kind of programming mechanisms do you need to make it easy for an AI to interact with the other parts of the game? For example, the AI may need to examine the state of the game. The trouble is that even if the AI only reads the data and never changes the data, it has a hard time determining when the state of the game is stable so that it can get an undistorted view. Who do the AI and the main loop of the game interact to make sure the AI gets an up to date, stable, view of the game, how does it send commands back, and what language or library features would make that easy to do? Bob Pendleton > > > --------------------- > To unsubscribe go to http://gameprogrammer.com/mailinglist.html > > > --------------------- To unsubscribe go to http://gameprogrammer.com/mailinglist.html