Ludus
Chris Ochap
CS 470
System Overview
• Goal
– Develop a scalable system to assist / automate game play within
selected online gaming rooms.
– Client is CustomCPU.
• Why
– To assist in evaluating / executing game play based on
probabilities of a given hand, along with some other less important
heuristics, governed by play profiles.
– Client plays multiple games at once manually, an automated
system can assist with play decisions & execute play on clients
behalf if option is selected.
System Design
• Ludus has five services that perform distinct roles.
– SnapShot Service
• Is responsible for broadcasting accurate state of any games being monitored to other
services while filtering out massive amounts of redundant game state information.
Receivers pick and choose what elements they want to keep track of based on
message object type & other identifying characteristics. Also resizes game client
windows to correct, or mapped, size so relative window element XY’s remain valid.
– Probability Service
• Is responsible for calculating the pre & post flop rank of a hand within a monitored
game which could be used to make a recommendation to the user or automate play.
– Logic Service
• Is responsible for making a recommendation or play decision based on hand rankings
calculated by the “Probability Service” and heuristics defined by play profile applied
for a given game.
– Delegate Service
• Is responsible for executing a play decision that has been made by the “Logic
Service” within a chosen game window, playing audible alerts & broadcasting
heartbeats used to populate the user console with current game monitoring state, when
it is opened, are it’s primary roles.
– Channels Service
• Responsible for facilitating communication between the other four services. All IPC is
layer 3 routable, so only SnapShot & Delegate services need to be installed locally on
PC for Ludus to function. At least 100Mb LAN recommended.
Service Configuration (All Services)
• All Ludus services use common XML parsing library to load operational
settings. None of these settings are of any concern to user, but are adjustable.
– Polling intervals
• Completely event based would be nice, however, some things like the photograph
module currently just poll a given game window at a definable interval for the
appearance / disappearance of cards.
– IPC / RPC addresses
• All services communicate via layer 3 addresses, whether localhost or remote PC.
– Remoting URL
• IPC / RPC needs path for remoted object (Channels service) to join Ludus services
“Chat Room” or application layer broadcast domain.
– Event log ID / error nums
• Not really needed anymore, but code is still present in all services from early
development for troubleshooting purposes.
Game Collections (All Services)
• A structured hierarchy of hashtables is created to make a virtual
representation of any games being monitored within each service (except
Channels). Each service picks certain game elements to keep track of when
they are broadcasted by the SnapShot service. Although SnapShot service is
the “noisiest” service in system, all services (except Channels) send
broadcasts out.
– Processes (All services except Channels)
• Indexed by PID. What game rooms are we monitoring?
– Games (All services except Channels)
• Indexed by window handle. How many game windows are we monitoring within in a
given PID?
– Table & Player Cards (Probability service)
• Indexed by hash of relative XY coordinate. What cards are on the table and what
cards are in my hand?
– Other players (Probability & Logic service)
• Indexed by hash of relative XY coordinate. How many players are at the table??
– Controls (Logic & Delegate service)
• Indexed by hash of relative XY coordinate. What actions can I take?
Game State Broadcasting (SnapShot Service)
• Three primary methods are used for monitoring game window activity.
These methods work together to keep the collection of games, represented in
memory within each service, as up to date as possible.
– SnapShot Module
• Uses native API’s to enumerate processes, threads, visible windows & child windows
(controls) within a parent window. This module provides / updates the blueprint for
what processes & windows are currently running. However, we still cannot access any
player bankroll amounts, pot amounts or identify what cards are on the table.
– Trampoline Module
• Uses core pieces of a library written by Microsoft Research that allows an actively
running process to have chosen API’s trampolined & their arguments reported back to
Ludus. Text output API’s, such as “DrawText()” & “TextOut()” contain the needed
string data drawn to game window elements like player bankroll and pot amounts.
– Photograph Module
• 52 different bitmaps that are drawn to the screen over and over at specific XY
coordinates. Doing a screen capture of specific game window XY’s and adding up all
pixel RGB values whos total is used as a key in a lookup hashtable for each game
client type. RGB tally is faster than math based hashing algorithm & in this case, just
as unique.
Attribute Maps (SnapShot Service)
• Areas of interest, defined by relative XY’s, within any game window include
available controls, cards, number of players, pot amounts & player bankrolls.
These coordinate definitions are parsed from an XML file when the system
starts. New gaming software with different layouts can be added for
monitring & play by creating an attribute map for it. Mapping process can be
lengthy (2 <-> 4 hours) depending on how much Red Bull is available.
– Process
• Defined by process name as it is loaded into memory.
– Game Layout
• Defined by type of game (Texas Hold’Em, Omaha, etc) & number of players.
– Players
• Defined by relative XY coordinates.
– Cards
• Defined by relative XY coordinates. (Finding correct XY’s for Photograph module to
take snapshots of within game window is by far the most time consuming part of
attribute mapping process)
– Controls
• Defined by relative XY coordinates.
Play Profiles (Logic Service)
• Define simple heuristics that are used when determining a recommended
play or automated action.
– Allowed actions
• Visible buttons, or play actions, is what Ludus uses to make a decision whether it’s
a recommendation or executed action (post sb, post bb, fold, check, call, bet, raise,
all-in). If fold, call, bet, raise & all-in are not selected for a given play profile,
Ludus will only post sb, post bb & check. If one of those actions is not available in
the game window, an annoying audible alarm will sound for user intervention.
– Allowed amounts
• Ceiling for dollar amounts Ludus is allowed to wager on users behalf. If play profile
allows check & call up to $10 & the game window actions available are fold, call
$20 & raise $40, Ludus will sound the same annoying audible alarm for user
intervention.
– Hand probability
• Floor for pre-flop chances that have been calculated using number of players at
table & pocket cards.
• Floor for post-flop chances that have been calculated using number of players at
table, pocket cards & table cards (flop, turn & river).
Console Init
Console
Console Processes Available
Console Process Init
Console Actions Menu
Console Actions Context Menu
Console Actions Context Menu (Disabled)
Console Profile Editor
Console Profile Selection
Console Profile Apply
ConsoleDebugger Init
System Specifications
• User interface allows automated play to be started & stopped at users
discretion.
• User interface allows monitoring of a game window to be started & stopped
at users discretion.
• Must support playing at least four games at once. Screen space & enough
system resources are all that is needed to scale up to dozens of games being
monitored / played at once.
• Audit trail of play decisions made or suggested must be kept in ASCII debug
file, for now.
Conclusion
• Prototyping had to be used because of the large number of unknowns when
implimenting the software. Disassembly of gaming software was required to
discover the most common API’s that are used to render elements on the
client screen. Lots of vetting after much trial and error.
• Addressed many of the UI issues present during the in class demo last
month.
• Successfully delivered system to customer. His requirements were exceeded
with the addition of play profiles to the system, however, the audit trail for
plays made was not very helpful to him because of it’s verbosity and
formating.
• I learned…
– Learned more, the hard way, about about .Net remoting & multiple application domains
within a single process.
– Integration techniques between libraries, services & applications written in C, C++ & C#
(i.e. unicast delegates, interop & marshalling).
– Many gaming sites spy on my computer via the same API’s I use to spy on their software
(i.e. process / thread enumeration & screen capture).