I think a comment on the email subject is worthwhile, too.
I generally find functions less friendly for use cases that require a
complex state to be stored.
For example, the state of keys that are pressed and then held down:
which is a different matter than the events generated by the act of
pressing and releasing a key. It treats what happens in the interim game
loops between the time a key was pressed and later released. I expect
most learn this distinction early on, so it provides a good example of
higher abstractions becoming your friend.
Gumm
On 10/6/2015 4:49 PM, bw wrote:
Hi, Bob,
As Noel said, there are many ways to do what you want.
The attached program uses a class abstraction to handle events, and
two sprite types for the game objects. These are extremely basic. They
may not fit all your use cases. But the more general purpose you try
to get, the more elaborate your abstractions must become--and less
ideal for instructing. I hope you find a balance that helps your class.
Collision detection is easy enough for folks to grasp. Collision
handling, I think, is an approach that must be grasped in concept
because it must accommodate a number of factors that reduce to one
simple question: When a couple things collide, then what should happen?
- What are the elements colliding: blobs, bullets, lasers, etc.
- Is there one moving object, or multiple to consider in each time slice?
- In what order should they be checked?
- Should they be allowed to overlap?
- Do you need to know which edges hit?
- Should the one moving be blocked; or should they both bump back and
how much?
- For more complex logic, sometimes you might want an arbiter to
determine the outcome of a collision.
This is the part that often is custom coded for a game, unless two
games can use the same collision system. Even a nice physics library
doesn't handle all your cases "out of the box".
The attached program uses a very basic approach to collision handling:
the moving and stationary things are blobs, and the moving thing is
blocked; also the moving thing is kept within screen bounds. I usually
find it undesirable to simply stop movement, though, as if hung up on
a sticky surface. Unless it really is a sticky surface, it is "nicer"
to slide along an available path. You'll see what I mean when you
interact with the program. I decided to include the slightly more
complex logic because I found it instructional, myself, to understand
how a dumb sprite needs to discover its vicinity and decide how to get
around in it.
If you had different questions in mind than were answered so far,
please feel free to clarify.
Enjoy,
Gumm
On 10/6/2015 1:12 PM, Bob Irving wrote:
Hi folks,
We're introducing Python for 9th grade this year and moving from
Blitz Basic for game programming. Just wondering if anyone has come
up with a way to hide the complexity for keyboard movement..... it's
one of those things that makes sense to more advanced programmers but
not to beginners. We've experimented with making a few functions to
detect collisions, mouse clicks....
TIA,
Bob Irving
Porter-Gaud School
Charleston, SC
--
Twitter: @birv2
www.bob-irving.com <http://www.bob-irving.com>
http://www.scoop.it/t/on-the-digital-frontier