Лучший дизайн фреймворка для C # Poker? - PullRequest
Новая
       9

Лучший дизайн фреймворка для C # Poker?

6 голосов
/ 20 августа 2010

Я пишу покерный фреймворк на C #, и мне не нравится дизайн, который у меня сейчас есть. Моя цель состоит в том, чтобы иметь игровой движок, который может очень быстро играть несколькими агентами ИИ друг против друга в пакетном режиме и играть несколькими агентами ИИ против нескольких людей (вероятно, через клиента Silverlight). Я хотел бы поддерживать высокую эффективность, но сохранять гибкость - например, он должен уметь играть в такие игры, как лимитный холдем, безлимитный холдем, лимитный 7-карточный стад и т. Д.

Мой текущий дизайн довольно неуклюжий и негибкий:

  • HandHistory: содержит всю информацию о текущей руке (игроки, сделанные ставки и т. Д.)
  • IPlayer: каждый игрок определяет метод GetAction (история HandHistory).
  • GameEngine: определяет метод Play (информация о HandInfo), который возвращает объект HandHistory.
  • PotManager: управляет банком и определяет, сколько должен сделать колл каждого игрока и сколько он может выиграть (например, если у него неравные стеки и олл-ин).
  • BetManager: управляет ставками и определяет, когда заканчивается круг торговли.

Класс HandInfo содержит всю информацию о том, как настроить руку. Тогда метод Play выглядит примерно так: 

HandHistory Play(HandInfo info)
{
    PotManager pots = new PotManager(info);
    BetManager bets = new BetManager(info);
    HandHistory history = CreateHistory(info);

    bets.CollectBlinds();
    if(!bets.GameOver)
    {
        DealHoleCards();
        if(bets.PlayersThatCanStillBet > 1)
            bets.CollectBets();
        if(!bets.GameOver)
        {
            DealFlop();
            ... and on and on
        }
    }

    return history;
}

Проблемы возникают из-за того, что нужно учесть множество мелочей, таких как сбор блайндов и т. Д. Классы менеджеров банка и пари становятся кошмаром и неизменно пронизаны ошибками. Кроме того, мой дизайн движка поддерживает только один тип игры (Холдем) в отличие от других.

Мой главный рейтинг - в первую очередь по эффективности, поскольку движок используется в основном в качестве симулятора искусственного интеллекта на миллиардах рук. Однако я хотел бы подумать, что есть более элегантный способ сделать это.

Ответы [ 3 ]

3 голосов
/ 20 августа 2010

Моя первая мысль - сначала создать код для удобочитаемости и отсутствия избыточности, а затем оптимизировать для повышения производительности (что, я полагаю, означает то, что вы подразумеваете под эффективностью). Обычно трудно предугадать, где будут узкие места производительности, и немного более медленное приложение лучше, чем глючная или неисправная система. Легко использовать продукт, такой как dotTrace , когда вы будете готовы к оптимизации, если вы обнаружите, что он недостаточно быстр.

Что касается вашего желания добавить функциональность, я рекомендую стать лучше в рефакторинг . Это один из основных принципов TDD: напишите наименьшее количество кода, чтобы завершить часть функциональности, а затем переработать любой запах кода. А используя TDD, вы можете быть уверены, что когда вы реализуете, скажем, Stud, ваш Холдем все еще работает.

Хорошее место для начала с вашего рефакторинга, поскольку, похоже, вы уже столкнулись с проблемами сопровождения, это попытаться убедиться, что каждый класс несет единую ответственность (первое из SOLID ценностей ). У вашего метода-примера много обязанностей: ставки, сделки, история игр и т. Д.

1 голос
/ 20 августа 2010

Мне очень понравился интерфейс IOpponent, который был написан John Gietzen для турнира Battleship AI.Я бы взглянул на его каркас для вдохновения.

Какой лучший линкор ИИ?

О, и я недавно видел это: http://visualstudiogallery.msdn.microsoft.com/en-us/ba4638ad-a2d2-49e5-ae46-94e0f747cae0?SRC=VSIDE

0 голосов
/ 24 марта 2011

Пример готового Техасского Холдема с 7- и 5-карточным оценщиком можно найти здесь и более подробно объяснить здесь .Это может помочь вам с производительностью.Все отзывы приветствуются по адресу электронной почты, найденному в нем.

...