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).