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
|