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.