[racket] universal Pong question

From: Matthias Felleisen (matthias at ccs.neu.edu)
Date: Sun Jul 25 19:13:09 EDT 2010

The key to Universe programs is to allocate knowledge in the
right places. That's called protocol design in the Docs. Once 
you have decided what goes where you can do two things: 

 -- make up data definitions for the local state 
 -- decide what messages you need to send back and forth 
	and make up data definitions for those 

Since you believe that there are several related and possibly 
equivalent paths, let me recommend a bit of an exercise for
your class: 

  have the students jointly discuss the two ideas above
  have them come up with two or three different choices 
  and set up some pairs/teams that implement all three of them 

When done, have the students demonstrate how the choices affect
the implementation of the local client and the server. 

You may also wish to discuss the results in terms of security
then. What happens when a bad client joins? What happens when 
a client sees too much about some other client? It's less relevant 
for pong but for many games (battleship is wonderful here, Shriram 
has an implementation, I have an old one from during the design) 
these are obviously interesting questions. 






On Jul 25, 2010, at 3:26 PM, Todd O'Bryan wrote:

> In the three-week intro course I'm teaching, the students have
> expressed a desire to program Pong played over the network, so that
> they can play against each other when they get home from camp.
> 
> I've never done universe programming before, so I'm not sure what kind
> of messages the worlds should send back and forth.
> 
> Obviously, each world needs to report on the position of the paddle
> (left or right) that its player controls, but what about the ball?
> Should I just let the worlds handle that with on-tick, or should I
> check that the ball is in the same spot on both worlds every so often,
> or should I have the universe server control the ball and tell the
> world everything except their own paddle position each time something
> changes?
> 
> I think all of these are reasonable choices, but I'm pretty sure some
> will be more or less nice in terms of performance, so I'd like not to
> head down a blind alley.
> 
> Todd
> _________________________________________________
>  For list-related administrative tasks:
>  http://lists.racket-lang.org/listinfo/users



Posted on the users mailing list.