Code Monkey home page Code Monkey logo

Comments (6)

santiweight avatar santiweight commented on August 16, 2024 1

Something I forgot to mention:

There appears to be a build failure on HEAD. Not sure what's up with that, but for the meantime I went with undefined calls :)

~/poker/maison/server/src/Socket/Table.hs:143:9: error:
    • Couldn't match expected type ‘Consumer Game IO () -> IO b0’
                  with actual type ‘[[Char]]’
    • In the first argument of ‘runBots’, namely ‘["bot1", "bot2"]’
      In the second argument of ‘($)’, namely ‘runBots ["bot1", "bot2"]’
      In the second argument of ‘($)’, namely
        ‘when (botCount > 0) $ runBots ["bot1", "bot2"]’
    |
143 |         ["bot1", "bot2"]

from poker-maison.

therewillbecode avatar therewillbecode commented on August 16, 2024

Hey @santiweight, great to hear from you!

I really like your suggestions, especially the one about integration tests with real hand histories.

I feel as though if we extracted the holdem game logic from this library then there wouldn't be much left, as you would be left with simply the networking logic and authentication.

What do you think?

from poker-maison.

santiweight avatar santiweight commented on August 16, 2024

Hmm. That wasn't my impression as I was writing the code to migrate, but I certainly see your point. Much of your logic is to do with seating, blind posting, whether someone can time out - stuff like that. All that logic would remain the same. But I do see your concern - I'll think about that. Ultimately, you would still have heaps of logic, such as bots, the UI, a lot of non-game specific logic. But it's certainly up to you whether you want to lessen the code in your library, I don't want to push you to remove your code :)

Let me try to motivate a little more why I think the extraction is a win for everyone, not just us.

A lot of decisions to do with setting up a game of poker are arbitrary, such as how blind are posted, whether someone can post, whether there are antes, whether someone can straddle how time outs work. These questions make up a poker site/poker game, since you can make plenty of different decisions, but once the cards are dealt - from preflop to showdown - there is only one set of rules, even across different poker games. This would a no-limit (easily extendable to limit) poker betting-logic library, not a holdem library. The new library wouldn't include players' hands, which would mean that integrating with omaha or stud would be trivial, and correct for free, as-it-were.

I think either way, if your site were to support omaha and mixed games, that logic would want to be extracted out, and then if you want to add tournament support, you just changed the pre-deal logic, and don't touch the betting logic. Plus if someone else wants to code their own completely logic on top of the new poker library, they can do so. That in particular is my reasoning - I am using the game logic to get available actions to do stuff relating to game tree construction, but my players don't have hands in my use-case, there are no timeouts etc. so I sadly can't integrate with your code! Similarly, if someone wants to write a website with slightly different time out logic than yours, then they would be hard pressed to do so, and would need to copy-and-paste your entire code, committing to a sad fracture in the ecosystem :(

I'm not in love with my code, and I would be happy to just use your code (maybe refactoring players to in maps lol), but since there is a lot of actual-poker-game related logic, such as sat-out players, I can't manage integrating :( So in that way, if we want to unify the ecosystem, we have to go towards smaller logical pieces.

I think the extraction therefore is good to do for a bunch of reasons:

  • You'll get an extra developer on your core poker logic, with a (hopefully helpful) refactoring for free from me :) and more tests
  • Other people will be able to write libraries based on the new poker logic including us
  • It makes it very pleasant to add different logic for tournaments as well as different games besides omaha
  • Tests based on other websites could be integrated. I think this is the kind of step that we could separately - perhaps you could generate tests for your specific game structure from my parsed output. I'll link you to the libraries hopefully at some point this week to give you an idea of how to integrate the pokerstars/bovada tests with your game logic. But at the very least, we would want to unify our core types, otherwise integrating would be a little too grating...
  • There has been a good amount of interest, as far as I can see, regarding poker in haskell. I think unifying the ecosystem is a good_thing since we can get people working together. I already to one other person who would be interested in the unification for their library. I think right now there are around 4 libraries on hackage that each define Rank and Suit, for example.

from poker-maison.

santiweight avatar santiweight commented on August 16, 2024

I realise in hindsight that I didn't directly address your question, hopefully what I wrote isn't a waste of time though...

In direct answer: the code that would be left over would still be quite substantial imo. There would still be anything related to a player and their username: depositing, sitting down at a table, wait-lists, sitting out, time outs, min/max buy-ins.

I personally find that to be quite a substantial amount of logic, so I think your code would get simpler but certainly not trivial.

The specific code that would get extracted would be:

  • most of Poker.Poker
  • a lot of Poker.ActionValidation minus any logic do with time outs and the like
  • hopefully all of Poker.Types
  • Some of Poker.Game would be extracted, but not that much in the short term. Much of that extraction would happen later down the line if we extracted code for handling blinds, which is not on my immediate radar.

from poker-maison.

therewillbecode avatar therewillbecode commented on August 16, 2024

I really appreciate this. However I am not seeing enough value in extracting out the logic you mention from the library.

It is just my opinion but the logic you are talking about extracting forms the core of this library, and I don't feel comfortable removing it.

Did you have any other ideas about ways we could collaborate as you are also working on poker libraries?

from poker-maison.

santiweight avatar santiweight commented on August 16, 2024

I won't argue with any of that - I totally get that.

Let's still ensure that we merge the underlying representation of Rank, Suit, Card etc.

Some great work was done here to get that uber-fast representation of Cards. I think it would be good to combine that with types like Range. Again - at the very least let's unify the types. At least then we can work off the same basis and allow people to use these libraries together.

The main thing I'd need is for poker-maison to compile fully, that is if you would prefer that I do the PR. The PR would mostly be a minus-diff that removes types like Rank, Suit etc. and importing them instead. It would be quite a non-invasive change. The biggest change might be deciding whether Card should be represented as:

data Card = Card !Rank !Suit
--- or:
newtype Card = Card Word8

I've always used the former, but the fast representation of Cards does generally seem like a good thing and workable with pattern synonyms.

from poker-maison.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.