http://webusers.npl.uiuc.edu/~a-nathan/pob/AJP-Aug2008.pdf

When I was testing the batter demo on pitcher’s duel, I observed some behaviour that seemed very odd.  The ball when hit sharply up, would seem to wander around.  Tracking it via its shadow directly below the ball, it would move back and forth over the foul line.  I thought at first this must be a bug, but the realized that is how popups behave.  The ball leaving the bat is severely undercut, and has a lot of backspin; the ball with backspin curves back toward the backstop as it rises.  When it  reaches its apex, though, it reverses direction without reversing spin.  As it falls, what was backspin is  now topspin, and pushes the ball towards the pitchers mound.  The path is thus a loop, and the shadow moves backward, then forward.  Follow the link for a much more detailed explanation.

The ball behaviour explains the way fielders, observed in MLB games, seem to wander back and forth tracking a pop fly.  They aren’t lost, they are just tracking the ball.

David

Nate Robins – OpenGL – Tutors

 These are ‘Tutors’, not ‘Tutorials’.  More accurately, they are little laboratories for experimenting with OpenGL parameters.  Each laboratory has a graphic pane showing an object, and a pane showing the key functions for that aspect of OpenGL.  You can change the parameter values by dragging, and see immediately what is the visual effect of a parameter value change.

I just yesterday found the fog tutor very helpful in understanding why my own fog generation was not looking as it should (and in making it right).   Take a look.

 David

Home runs can be as slow as 90 mph off the bat.   This suprised me, at first, as that is the speed of a pitched fastball, and we do not imagine that someone can throw a baseball over the outfield fence from home plate.  However, a good strong arm can reach home plate on a throw from mid center field, and the nearest fence portions, of small ballparks such as Fenway, are as close as 325 ft.

There were two home runs at under 89.5 mph off the bat, but both were in-the-park home runs.  

The fastest home runs were slightly over 122 mph, off the bat.

HitTracker :: Home run tracking and distance measurement 

This weekend was mildly productive.  I resolved the memory leak in Pitchers Duel, which was actually a memory leak in Lamina.   So I put a corrected version of Lamina in subversion; I also updated the demos to fail more politely in the absence of necessary GUI libraries.

I will try to get a new release packaged up and put on Pypi this week, but the current code is available at the link below.

/branches/Lamina/Pitchers Duel

David

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.

This subclass of Twisted’s selectreactor has methods to yield control of the reactor to its caller, and resume control later.

The guts of mainLoop have been moved to a generator method, and mainLoop instantiates the generator and calls .next() on it.

There are new methods for new functionality.

.release() causes the mainLoop to yield at the end of its current iteration.

.resume() transfers control back into the reactor. A .resume call is like .run, in that it does not yield control until the next .release or .stop.

.isRunning() tells you whether the reactor is running.

from twisted.python import log, failure, util
from twisted.internet.selectreactor import SelectReactor

class PausingReactor(SelectReactor):
    """Implement selectreactor that can be exited and resumed. """

    def __init__(self, *args):
        SelectReactor.__init__(self, *args)
        self._releaseRequested = False
        self._mainLoopGen = None

    def _mainLoopGenerater(self):
        """Generater that acts as mainLoop, but yields when
        requested.
        """
        while self.running:
            try:
                while self.running:
                    # Advance simulation time in delayed event
                    # processors.
                    self.runUntilCurrent()
                    t2 = self.timeout()
                    t = self.running and t2
                    self.doIteration(t)

                    if self._releaseRequested:
                        self._releaseRequested = False
                        yield None
            except:
                log.msg("Unexpected error in main loop.")
                log.deferr()
            else:
                log.msg('Main loop terminated.')

    def mainLoop(self):
        """Setup mainLoop generater, and initiate looping. """
        self._mainLoopGen = self._mainLoopGenerater()
        self.resume()

    def resume(self):
        """Resume mainLoop looping after interruption. """
        try:
            self._mainLoopGen.next()
        except StopIteration:
            pass

    def release(self):
        """Request main loop pause and reacter yield to caller. """
        self._releaseRequested = True

    def isRunning(self):
        """Is reactor running? """
        return self.running

def install():
    """Configure the twisted mainloop to be run using the pausingreactor.
    """
    reactor = PausingReactor()
    from twisted.internet.main import installReactor
    installReactor(reactor)

__all__ = ['install']

To use the module,
import pausingreactor; pausingreactor.install()

The pausingreactor module, and a couple of files to test it, are linked. The stresstest.py sends increasing long strings to an echo type server ‘uppercaser_ns.py’, reads them back and checks them for intactness. It also pauses a couple times per second for a fraction of a second.

pausingreactor.py

stresstest.py

uppercaser_ns.py

Enjoy.

I have been considering networking options for months, and over the last couple of weeks have had time to explore specific options. I initially made exploratory forays into two disparate implementations: One approach was to write the game logic in ‘inside-out’ form so that everything could be done by callback; the other approach was to put the network code into another process, and pipe data to and from it via os pipes.

The ‘inside-out’ approach would add significant burden to coding the game logic, and was abandoned after an evenings work. The separate process approach was making some headway, but I have put it aside as well, for yet another approach.

What I want(1) is a twisted reactor that can be exited and reentered. I could then use the substantial asset of proven twisted code for various high and low level operations, but use a conventional subroutine-oriented code structure. When an engine needs to exit, it can have the reactor yield to its caller; the caller then follows game logic to set up another engine, which resumes the reactor operation. The timing constraints would be the same as for a call-back, (ie: don’t delay the reactor more than necessary), but the game logic would be more readable and more writable without having to put everything in callbacks.

The usage would be like:

class Engine()
   def iterate(self):
       # do per frame stuff
       if self._done:  reactor.release() # yield to engine's caller
       else:   reactor.callLater(0, self.iterate)
   def run(self):
       # init stuff
       reactor.callLater(0, self.iterate)
       if reactor.isRunning(): reactor.resume()
       else:  reactor.run()    

def intro():
   # set up intro pages
   eng = Engine()
   eng.add(intro_pages)
   eng.run()   

def room(room_context):
   eng = Engine()
   eng.add(room_context)
   eng.run()
   return eng.retval   

def main():
   intro()
   # set up lobby context
   next = room(lobby_context)
   while next != GAME_EXIT:
        # set up context for next room
        next = room(room_context)           

The code is fairly readable, with more specialized function in specialized subroutines.  Calls to the engine can be from main(),  or from a subroutine a few calls deep.  

See my next post for the reactor subclass itself.

1)
OK, what I really want is a file-like connection object:
con = Connection(‘gameserver.org’)
con.write(‘game update data’, game_data)
news = con.read()
check = con.read_non_blocking()
But I am not going to find (or write) that, so I’ll settle for an pause-able reactor.

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 sequence above was flat, not involving any subroutines. Any significant game is going to make a *very* long main generator, without subroutines. However, any subroutine called from the generator cannot chain to an engine or other functionality via the reactor. Returning control to the reactor is done by yielding. If the sub-generator yields, it yields to its caller, which needs in turn to yield, recursively all the way to the reactor.

The code can be subdivided for organizational purposes, but not necessarily by functions. A sub-generator can provide encapsulation to local variables, while maintaining the ability to yield to the reactor repeatedly for different stages.

def intro(engine):  # generator
    res = 0
    engine.interface = intro_iface
    while res != 'quit':
        if res == 0:
            engine.objects = [intro_pic0]
            engine.interface.buttons = (None,1)
        elif res == 1:
            engine.objects = [intro_pic1]
            engine.interface.buttons = (0,2)
        elif res == 2:
            engine.objects = [intro_pic2]
            engine.interface.buttons = (1,None)
        yield None
        reactor.callLater(0, engine.go)
        res = engine.retval  

def main():  # generator
    engine = Engine()
    # iterate over intro, while intro shows
    #    its various page pics
    for i in intro(engine):
         yield i    

    # execution resumes here after intro
    # set up stage 1
    engine.interface = stage1_iface
    .....
    # done
    reactor.stop()
    yield None    

continue_main = main().next   # creates iterator  

continue_main()   # runs to first yield, installing first engine (via first .callLater) in reactor
reactor.run()

As you see, isolating the multiple stages of introduction into a generator makes the main a bit simpler, but the calling syntax: for i in intro(engine): yield i; is ugly.

This post was originally posted to a mailing list, but it summarizes my recent thought on the question, so it is copied here.

The python sockets library is probably *not* the place to start.  It is very primitive,  and most references you will read will recommend using a  higher level library such as asyncore or (higher yet) asynchat.  Unfortunately, these higher level libraries share the same weakness as Twisted, in that that they expect to own the main loop.  I have identified five general approaches to integrating networking with a pygame application.  I have not fully implemented a game with any of them, .. but soon.

1. Use the iterate method of the Twisted reactor.  This is the easiest approach, and the one that Mr Wittber’s library uses.  Use of reactor.iterate is unfortunately deprecated by the Twisted developers, and will, presumably, be removed from Twisted in some future release.
2. Use the Twisted reactor *as* your main loop, and implement all game logic as call-backs from there.  This is the approach that the Twisted people will recommend.   This approach is quite burdensome, in that structuring your game into a series of callbacks can be difficult.  Using generators as coroutines provides some relief, in that you can pass the generators ‘next’ method as a callback to Twisted, and maintain game state within the generator.  Using subroutines or nested generators involve their own awkwardnesses.
3. Run the Twisted reactor in its own thread, and use ThreadedSelectReactor to move data to the pygame event queue.  Bob Ippolito has blogged on how to use this with Pygame (GIYF).  Unfortunately, ThreadedSelectReactor is unmaintained and deprecated.
4. Run the Twisted reactor in its own thread, and use thread-safe queues to move data to and from the main thread.  Alternatively, if you wish to use the perspective-broker features or use Twisted code beyond mere message passing, there are tools in Twisted for safely invoking methods in other threads.  Hmm. maybe these were deprecated with the TSR?
5. Run the Twisted reactor in its own process, and use pipes or sockets to pass data between it and the main loop/process.  This has the merit of using the OS’s CPU allocation management rather than that of Python’s thread manager.

Most of these approaches could use asyncore/asynchat as an alternative to Twisted. My own efforts lately have been along approaches 2 and 5.   My engine ‘Spyre’ will run under Twisted’s reactor now, but the getting the whole multi-engine game logic sequence working in the ’inside-out’ callback style is an imposing prospect.