Re: pyglet audiogame examples
no. You don't want threads here. What you do want is to pass on events as soon as you see them, at least if that's possible. Even if it's not, you don't want to expose it this way. It might be later, and it's best not to introduce lag.
Right now, what you would do is have an if statement that moves stuff if a key is down. A smarter way is to give everything a velocity. In the on_key_down function, look for the arrow keys and set the velocity on the player. On the on_key_up function, clear it. Then, everything is happily handled by the movement code. By looking at the movement code, I understand everything about movement. By looking at the keyboard functions, I understand everything about the keyboard. But these concepts are separate: I can work on one without even seeing the other.
But more generally, by combining stuff like this in tick, you're treating the keys and the mouse as special.
The keys and the mouse aren't special. The keys and the mouse are indicating to my game that something should happen, but the actual code that makes things happen can and should be as separate as possible. The code that does things can then be shared between the player (keyboard and mouse), the AI code (everything else), and the network (maybe, it's a little more complicated than that, but the general point stands). My current project takes this to an extreme you don't need to go to; it's possible to make all display and input completely separate from all logic.
This is called the model view controller pattern, and the more you look like the model view controller pattern the better. In the model view controller pattern, there are three things. The model is the world and all the code to do things to the model. The view is the code dealing with screen, sound and text to speech. The controller is the keyboard, mouse or
network code. The more these are separate the happier you're going to be later when your game gets upwards of, say, 2000 lines. How they communicates varies. I like publish subscribe frameworks like blinker and the Queue module, and my current project pretends there's a network even though there's not.
But more seriously, if you've not done a game of Shades of Doom complexity in Python, please do so now. You're trying to set precedent potentially for a very long time, and I've never seen a game from you. This is part of the reason I'd not do this project myself: I have nothing completed and released, though I do have a number of failed and successful but I don't care projects. Making game engines for everyone is not something I feel comfortable doing, not because I can't. You're solving problems for everyone, not just for yourself, and you will never, ever, ever be able to back out and
say "I was wrong". I'd usually just shrug and go "yes, this works" and it does, for a reasonably simple and possibly even an intermediate game. But you're not making a game.
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
