game-play


I like the term ‘Pitchers Duel’, because it describes a type of game that I enjoy thinking about.  Low score, few baserunners, many strikeouts.  Baserunning doesn’t matter much in these games, because rarely does a runner get on base.  The consistency of out-getting makes the contest look like a pure contest between pitchers:  Which pitcher will slip up first, and allow a run to score?

Most baseball fans, to the contrary, like high scoring games.  Baseball game attendence has increased in eras with high-scoring and dropped in low-scoring eras.   So I am considering alternative names for this computer game, that will appeal more to baseball fans.

The pitcher – catcher combo is known as the ‘battery’:

      Battery plus

Various phrases that emphasise the hitting aspect of the game:

       Bat and Ball / Ball and Bat

       Batter Up

       Ball and Stick

A more balanced title that includes both sides of the contest: 

        Hit and Pitch

This title represents the ‘moment of truth’ in each at-bat, where you know you may get only one more pitch. 

        Strike Two

Both batters and pitchers are very concerned about the strikezone, its extents, whether a given pitch is in or out, and how the player fares in the balance of strikes vs balls.

       Strike Zone

       Balls and Strikes

      Ahead of the Count

      Full Count

A facetious, but sorta mean-spirited, option: 

      NOT Barry Bonds

Let me know what you feel is a good choice.

APRESS.COM : Beginning Game Development with Python and Pygame: From Novice to Professional

by Will McGugan

This book seems well fitted for a beginner, as it starts with a basic Python tutorial, and steps up gradually to more sophisticated material. The book is more useful as a tutorial, describing a tank game with increasing complexity, from interactive text to 2D animation, to 3D in OpenGL, than as a reference.

The chapter titles are meaningful, but task oriented, ‘making things move’, ‘user input’, …. ‘making things go boom’. Once you’ve identified the chapter that might answer your question, you have to skim to find the material, though the material does have abundant subheadings, at least one per page, to help you in skimming. There is a nice index of 20 pages, which seemed thorough, in that the half dozen items I looked up were all there.

Will covers a pretty good range of topics, including packaging, sound, openGL, artificial intelligence, and inputs. The only section that surprised me in its presence was the ‘Moving into the third dimension’, in that he discusses the calculations involved in mapping 3D space to the 2D display. Most 3D programmers, I suspect, just offload that calculation burden onto the OpenGL (or DirectX) engine, and do not do such translations ourselves. Maybe the skills might be useful for people who want 3D effects in straight pygame, and the chapter may serve as a transition from the 2D material presented prior, to the OpenGL material to follow. I just skimmed through briefly, as I was already familiar with OpenGL.

The only substantial omission I found was that networking was not addressed. He may consider the networking options too unsettled at this point to be able to recommend a specific approach.

I was disappointed to not find any advice on determining which joystick button or mouse button is which. Pygame recognizes buttons 1, 2, 3, etc.., but there is no firm rule on which number belongs to a given button on the input device. The right mouse button is button 2, or button 3, depending on whether scroll-wheel is present, and I don’t know a systematic way to determine what buttons the user’s mouse has, and what numbers thy hold. Maybe this problem doesn’t have a clear resolution.

I cant complete a review of a book on game programming in python without a comparison with the other book on the topic. Sean Riley’s ‘Game Programming with Python’. GPwP is a bigger, more involved work, that is less tied to Pygame, and less approachable for beginners. If you are a beginner looking to ease your learning curve, get BGDwP. If your question isn’t answered by BGDwP, it might be by GPwP. For what it’s worth, ‘Game Programming with Python’ does discuss networking, but did not help me with my joystick button interpretation.

The batter and the pitcher demos have been improved, again, and released.  This time they are both released in the same file. 

 pduel_setup.0.8.1.exe This release is a Windows self-installer, which installs both demos, and includes an uninstaller.

http://downloads.sourceforge.net/pduel/pduel_setup.0.8.1.exe?modtime=1194898820&big_mirror=0

Improvements to the batter include:

  • Bat magnetism, pulls the bat closer to the ‘ideal’ contact position, than your input would have accomplished.  This means more contact with the ball, and more hits.
  • Improvements to the swing timing, so that hits are possible to all parts of the field.
  • A GUI that supports batter-position adjustments, as well as replay and ‘nearest-contact’ inspection.

Improvements to the pitching demo include:

  • A GUI that allows selecting the level of play (MLB, College, HS), as well as the style, intensity, and location of the pitch;  also allows for replays and strike-zone path inspection.
  • Multiple different pitchers, with different arm motions such as overhead and sidearm.
  • Three different pitches, fastball, curveball, slider.

 This game is designed to be a ‘twitch’ skill game, minimizing the influence of random chance in the outcome of each action.  The batters stroke is entirey consequent to how the player ‘aims’, with no random component whatsoever.  The pitcher’s pitch placement interface jitters or flutters, adding some ‘noise’ to the location.  However, at the moment the mouse button is clicked, the pointer points precisely at the pitch destination, so the precision of placement is dependent on your reflexes.

Good things happened this weekend!

Firstly, the Philadelphia Phillies (the local team) qualified for the playoffs by winning the NL East Division, and qualified without the one game tie-breaker. This team does not have the best pitching staff in the league, but complemented by their extraordinary offense, the team is good enough to win the World Series.

Secondly, another major milestone was reached in the development of Pitcher’s Duel. The pitching demo was rereleased. A prior release (in 2005 !) was just an animation demonstration, and did not have an interface to speak of. This release has a GUI and the ability to choose and throw pitches, some retrospection features, and is better looking.

The batter demo is almost done; in fact it was done, but I somehow overlooked releasing it, and now it needs a little sprucing up to match the pitcher demo.   There were a few releases months ago, but without the GUI and some features designed to aid hitting.  This week, I will get it fixed up, and then I will release it as well. I hope to get some good feedback on each, and I may well release an upgrade or two for each, to test any improvements we come up with.

Those are the two largest components of the game. After getting the batter demo online, I will be working on the network library (I have discussed various considerations on this blog before), and then assemble the three components into a playable inter-player game.

Anyway, enough chicken counting….

The demo (version 0.3) is at:

http://sourceforge.net/project/showfiles.php?group_id=110483&package_id=119360

Some description and background is at http://pitchersduel.python-hosting.com .

 

The demo is available as a self-contained Windows installer, and as a source zip.

The source zip needs pygame, pyopengl, and ocemp gui 0.1x preinstalled.

 

If you are a baseball fan, or a sports-game fan, give it a try.

 

DavidScreenshot

Greg Ewing has released his GUI for Pygame, under the name ‘Albow’.

It includes a demo, which shows it off quite well.  It is an attractive GUI package.

I set out to add it to my comparative review of pygame GUIs, but was disappointed that there was no readily apparent way to integrate it into a foreign main loop.   The documentation describes using it as the event loop.   I spent a few minutes looking at the RootWidget run method, thinking I might subclass a ‘callable’ root widget, but backed off from the complexity.

So I am not providing you a demo, but since I spent a few minutes looking it over, I will share my impressions with you.

The code is rather scant on docstrings, but the included html documentation seems complete and is clear.   Hopefully, he will put the documentation online somewhere where the curious can preview it.

The GUI in the demo is rather attractive, and has a theming system where you can change the look-and-feel to suit your game.

The range of input widgets is rather limited, with no checkbox, radio button or slider widget; it does have a set of input boxes, text buttons and image buttons. There are a few high-level widgets as well, including a file dialog, grid and palette widgets.

If your game can accomodate the GUI owning the main loop, give this kit a look.

http://www.cosc.canterbury.ac.nz/greg.ewing/python/Albow/

pduel_playtest1.jpg 

Play-testers needed.

The Pitcher’s Duel project has released a demonstration of its batter interface, and we need people to play with it and report how it works for you.

Pitcher’s Duel is a baseball simulation game that relies on player hand-eye coordination to determine the batting outcomes, not on randomness. Once the pitch leaves the pitcher’s hand, there is no randomness involved, and whether the batting player even makes contact depends entirely on the skill of the gamer. Whether the batter gets a ‘hit’ depends not only on the gamers skill, but also on in-game qualities of the batter-avatar, such as strength, stance, and bat-speed.

For now, the product is nothing more than batting practice; the pitcher throws an unending series of pitches, all strikes, and you swing away at them. The last few months have gone into improving this interface so that pitches are hittable. It turns out that a pure true-scale, real-time
simulation is impossible to hit in, so various visual aids and timing corrections have been designed in.

I, myself, can get contact rates over 70%, but I have a fair amount of practice at this, with all the in-house testing I do, and I need a few other people to test it and report.

A good batter interface is critical to the success of the game, and I need to know that it works acceptably well before I continue on to building the rest of the game around it. Your assistance is appreciated.
The demo file is for Windows (tested under XP Pro) only, and includes an installer and an uninstaller. It can be downloaded from Sourceforge. Please email dkeeney@travelbyroad.net with a report of how well, or how badly, it played for you.

For more details about the project, see Here or the Wiki.

Thanks in advance.

David Keeney

An enlightening post by the Baseball Analyst in his blog yesterday revealed to me that MLB batters make contact with about 82% of swings. The best contact hitters make contact with over 98% of swings. This knowledge has given cause to reevaluating Pitcher’s Duel’s play.

I recalled that in my various play testing sessions with Pitchers Duel, I seemed to get about a 70% contact rate, batting with the mouse in the batterdemo script.

For a new session last night, I paid attention to the statistics, and observed a contact rate under 50%, for a couple dozen pitches. The ‘SurRound’ feature, intended to aid batting, seemed to be a distraction. Newbies to the game are going to do substantially worse than I do, and I am not doing very well. It is ‘back to the drawing board’ for now, and my plans to release the updated batter demo is postponed for a while.

My first try at improvement will be to make the surRound ring much more subtle, so that it is observable while ceasing to be a distraction. The next step will be to make the pitch trajectory more pronounced somehow. Sometime back, I tried artificially slowing the pitch timing (by 0.7 ratio, more-or-less), and did not observe any hitting improvement. I may revisit that,(Unfortunately, that was before going Subversion, so I may not have the code to reuse) more carefully.

Next Page »