Desculpe pela necromancia do encadeamento, mas esse problema é meu projeto favorito para aprender e ensinar modelos e estruturas de simultaneidade!
A execução de cada cliente / mob em seu próprio encadeamento gera uma divisão natural, mas como vários observaram, os encadeamentos são caros quando você usa mais deles do que os núcleos da CPU. Se esse não é um motivo convincente para não usá-lo no seu MUD, ainda é um bom motivo para aprender uma maneira melhor.
A execução de todos os clientes em um único ciclo de jogo em tempo fixo, com ações executando um certo número de loops, é um método familiar do mundo dos jogos gráficos. Ele vincula tudo no mundo ao mesmo ciclo de tempo, embora fazer os loops suficientemente refinados possa mascarar isso. A principal desvantagem desse método, a meu ver, é que ele não é inerentemente paralelamente agradável. Alguém observou que você pode criar threads para descarregar a E / S de construção / análise / transcepção, executando a IA e outros para outros segmentos, mas tornar a lógica do jogo principal paralelizada exige uma mudança fundamental e muito trabalho para manter as coisas seguras.
Se você fizesse todo esse trabalho, provavelmente terminaria com algo parecido com o meu favorito atual, o modelo de ator ( http://en.wikipedia.org/wiki/Actor_model ). O modelo Actor é uma estratégia de compartilhamento de tempo que acaba elaborando bem próximo do que você estava propondo com a idéia de um thread por cliente. Ao usá-lo, você codifica seus "Atores" como se fossem threads independentes, com algumas restrições: eles devem ser controlados por eventos e só podem se comunicar com o resto do sistema passando mensagens (o que é diferente, mas simples). O bit orientado a eventos abre espaço para o seu tempo verdadeiramente independente, agendando eventos específicos do ator para serem disparados em momentos específicos, por exemplo, quando uma ação é concluída ou em alguma frequência específica do cliente.
Sob o capô, a implementação usa uma fila (ou filas) de mensagens sendo geradas por todos os atores e um conjunto de encadeamentos que correspondem ao número de núcleos da CPU. Os encadeamentos retiram as mensagens das filas e invocam os métodos de manipulação de mensagens do Ator destinatário para manipulá-los, executando no contexto desse Ator até que a mensagem seja "manipulada". Do seu ponto de vista, cada Ator obtém seu próprio encadeamento sempre que está em execução, mas, do ponto de vista do sistema, existem apenas quantos encadeamentos há CPUs para executá-los.
Existem algumas estruturas ótimas de atores por aí, como Erlang / OTP e Akka, mas a idéia básica é simples o suficiente para que você possa implementá-la em qualquer idioma sem o barulho adicional de uma estrutura.
Para ser completo, o modelo Actor é realmente apenas a combinação de passagem de mensagens para segurança de encadeamento, programação orientada a eventos para simultaneidade e um mecanismo de envio de encadeamento. Se você remover os bits de despacho de threads, ficará com um sistema "reativo", que está em voga para a escalabilidade em geral no momento (consulte http://www.reactivemanifesto.org/ ). Você pode mapear a execução para várias máquinas em uma nuvem ou o que quer que seja ... você entendeu ... o que significa dizer que seu projeto de programação MUD pode estar lhe ensinando habilidades de programação comercializáveis. Viva!