December 8, 2014
Derby Pro is a horse racing game that offers fair game play through the use of randomization. By offering a clean UI and full-screen functionality, we strive to make our game easily playable. Furthermore, Derby Pro's program files are easily expandable (through the use of Abstraction and Polymorphism) to offer diverse game-play in future adaptations.
- Data Abstraction is used to interact with the databases and functions associated with manipulating them to produce results for our game.
- Our UI implements event-driven program features, including callback functions and states.
- Polymorphism is implemented through the use of accessor functions for obtaining various results (i.e. race) and through use of library functions (i.e. shuffle-list).
- Object Oriented Programming is demonstrated in the use of classes and objects, particularly among the UI components where inheritance is used heavily.
- Randomization is achieved through the use of functions that are removed from human pre-determination, such as the programmatic shuffling of lists.
- Anonymous Functions (lambda statements) were used to implement single-instances of objects (i.e. button events in the UI).
- Databases (PS4) created and altered through the use of lists and list manipulations (car, cdr, etc.) were used to create and manipulate lists of objects.
External Technology and Libraries
- Racket GUI Toolkit (racket/gui) was used extensively to create windows, buttons, canvases, keyboard events, etc. This library is the core for everything visible to the user at program run time.
- Card Library (games/cards) was used primarily for its shuffle function, which allowed us to randomly shuffle lists of objects (horse databases and stat modifier list)
- Image Library (2htdp/image) was used in order to import .png images as bitmaps for use with our UI
- SRFI Library (srfi/1) was used for list manipulation functions (take, drop, etc.)
Favorite Lines of Code
Each partner should identify a favorite line of code, Scheme expression, or entire procedure written by himself / herself in the entire project, and explain what it does. E.g.:
(define/override (on-paint) (send (get-dc) draw-bitmap bitmap (* winWidth 0.25) (* winHeight 0.1)) (send (get-dc) draw-text "And the Winner is..." (* winWidth 0.45)(* winHeight 0.1)) (send (get-dc) draw-text (race) (* winWidth 0.45)(* winHeight 0.3)) (send (get-dc) draw-text "Press Any Key to Exit" (* winWidth 0.45) (* winHeight 0.5)))
This block of code was the result of days of coding attempts, research, and struggle in trying to include images within canvas frames. By overriding the on-paint callback, which occurs when a canvas is drawn, we can draw a bitmap to the canvas space. This block of code also demonstrates that we successfully preserved abstraction, the only calls to non-gui code are made through a limited number of accessor functions, such as (race). We also took account of the fact that all displays are not equal in size, the winWidth and winHeight variables were defined after obtaining the display size at program run time.
;; Picks two horses (define (pick-racers) ;; Original - pick-racers (set! rDB (take (shuffle-list hDB 7) 2))) (display-horses rDB)
This block of code demonstrates the use of shuffle-list, which allows us to implement randomization by altering the order of a list with drastically limited human predetermination.
There was once some beautiful code Where a list of horses would be given to load It would shuffle the list And do magic in a gist Then give us the A+ because it showed
Technology Used Block Diagram
We coded most of our infrastructure from scratch, creating object databases and a custom interface. In the initial proposal, our program was supposed to allow the user to have a choice in which horse to race against the computer, as well as the ability to boost that horse's stats from accumulated training points. We fell short on time, and were unable to implement these features. That being said, they can easily be implemented due to the preservation of our abstraction barrier, and through the use of polymorphic code.
Training: a global variable (trainPts) should start at 0 and increment by 2 for each user "win". A message box would appear when the race gui is called, after a horse is chosen to race with, in which the user could click a '+' button to add training points (thus decrementing the global variable and incrementing the speed of the chosen horse).
Choice: We needed to identify which horses were the owners, and which were the computer's. Then, when the race gui is called, the user is presented with the first horse from the shuffled user's list. If they say 'no' to the presented horse (first(hDB)), they automatically get the next horse (second(hDB)). The selected horse is inserted into the race db as a contestant.
We also have an incomplete Stable window. We ran out of time creating filter/search functions with which to return horse data (as strings) for the UI to use. We left commented-out place holder code in the UI to outline how this was supposed to happen.