That's probably a good move anyway, though if there is any chance that you could upgrade your OS to something less than 10 years old, that would probably help your cause enormously also :)

With respect to rewriting your perl code, probably not.

For the most part, anything that runs on 5.6.1 should run on 5.8.x with minimal changes. That's a risky generalisation to make without having seen the code in question, but based on my own usage of both, it's not too wild a guess. Of course, my memory could be playing tricks on me again.

The harder question is how much effort will be required to make your current single threaded code run multi-threaded. On that, I will not even hazard a guess.

From the little information I have, your app is basically a big loop that get user input, uses it to modify the state of the current player, takes the opportunity to update the state of your NPC's and loops back for input.

Your desire is for the NPC's to run independantly of the user input. In theory, sharing the variables that contain their state with a background thread that loops over a sleep and modifies their behaviour is pretty trivial, but the devil is in the detail.

If your NPC's are OO-modelled, or if their state is maintained in nested hashes, or any number of other standard perl techniques, then the modifications could be awkward.

It may make more sense to simple use a timeout on your user input (using Term::ReadKey or similar), and just allow the NPC's to continue their state changes whilst the user thinks about his input.

How much effort would be involved, and whether multithreading would be beneficial relative to the other options available, will depend highly upon how your code is currently structured and how you want to modify it.

Yes, the NPC's are OO-modelled and their state is indeed maintained in nested hashes (if that means the $dude->{hitpoints} thing). Altough the Object Model will have to be revised (don't know if you care, but whatever)

The current system indeed gets user input, executes the user command, lets the NPC do their moves (some kind of AS - Artifial Stupidity - they're not quite intelligent yet :) ) and then gets user input again. Term::ReadKey seems to be an attractive solution, thanks for the hint. But that also seems not to work on Windows systems. That is, it never worked for me.

But I'll have a look at it!

You say it'll depend on how my code is currently structured, but that's no important issue. Some procedures that should/could be part of the Classes, are still stored in the main part of the code (non-OO style), while others are stored in the class files. Some procedures that should be a method of class X that inherets from class Y, are stored in the file of class Y. So the current structure is Bad and really needs to be revised, as stated before.

But that also seems not to work on Windows systems. That is, it never worked for me. But that also seems not to work on Windows systems. That is, it never worked for me.

Again, my best guess is that the reason it doesn't work for you is because you are using '98. It works for me on NT & XP.

You say it'll depend on how my code is currently structured, but that's no important issue.

Why it is important is that you cannot call objects across threads using Perl's iThreads implementation. You can share data, but not code pointers, ie. methods. That makes utilising objects with threads awkward.

You could use a thread to interact with the user and queue the input to the main thread that manipulates the objects. That is pretty easy to do, but actually only achieves the same as putting a timeout on the IO, hence teh mention of ReadKey().

If you thought is to make each NPC a separate thread running around on it's own and interacting when they come into contact, the problem is need to share the environment between threads. If the environment is also represented using objects, the problem of sharing those objects between threads returns.

---

Examine what is said, not who speaks.

"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail