[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Function for keyboard movement



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