Re: Earwax
I have been thinking on this and asked myself... why not make your game board a List[List[Any]]? You can remove that third layer, or at least give an illusion of making it appear as such. This way, I can do boards of integers, or boards of stacks, or board of properties like in monopolies (represented as objects). Your get tile function would then ensure that x and y are in bounds and return the current object at said position, and the user would handle it from there. Alternatively, you can allow for them to pass in a custom tile_handle function which would take the retrieved object, run its magic on it, and pass it back to get_tile, which would then return it to the user. That would have do be optional if you implement it, though. If I have a board of integers, there is no extra processing magic I need to do and feeding the class with lambda p: p seems redundant and pointless.
I'm assuming you mean List[Any]. I'd rather have it be List[T], where T is a TypeVar instance. This has the added benefit of not breaking the typing system.
As Lucky 13 already relies on the current method, and every time I think of board games, the current solution seems fine, why not implement a SimpleGameBoard class or something? You can put in whatever you like, and the old functionality is still available.
I have an actual question. If I pass in custom data to my level, will __attrs_post_init__ be able to access it? Consider:
l = MyLevel(foo="bar", a="b", pi=3.14159) #in __attrs_post_init__: self.magic_number = pi ** 2 / ord(a)Obviously this is is nonsense, but I hope you can get the gist. If we are not able to pass in custom parameters, could that be added?
So no, and sort of. Earwax is using Attrs for all its classes, so you can subclass, and add in your own attributes, as long as the class is decorated with @attrs. Then the _-attrs_post_init__ method will absolutely have access to the new attributes.
Looking at your door class, could you add a generic boxlike object which you could attach as a component to something else and be able to override its interaction and collision methods? I've been told you have most of the framework within your door object, you just need to make it more general. As you can probably infer, this is not my own request.
Tell whoever it is to just subclass earwax.Box, and add their methods there, then create instances of their class, rather than earwax.Box. BoxLevel.add_box doesn't really care, although mypy might.
I also have an interesting dilemma. If I am building a space invader type of game, I can obviously schedule the interval at which a specific enemy moves. Here is the question: Would I do this for all objects as a collective union, or should I do this on an individual basis? I'm asking because I come from Pygame and needing to write my own game loop.
I'd actually use tasks for this. Every time you create an enemy, add an earwax.Task to do stuff with them. That way, they'll move independently, rather than in a hoard. Unless you want them to swarm of course. #HereComeTheInhibitors.
How bout different action. Let's say that the aliens can move and shoot at the player independent from their movement. How would one go about carrying out checks which determine if the player is in range? Do I just schedule whatever I need to run at a certain interval? What is the limit on doing so? Is there a better way of doing this?
Again, earwax tasks are probably the one. Unlike schedule_interval, they let you specify a random time each round, so things don't feel as static. I feel like the range question is game-specific, and one I don't feel particularly well-equipped to handle ATM, as I'm still only just graduating from for-looping everything.
Eventually I'll include Camlorn's collision tutorial, then you can use methods in there, but I have an extensive to do list.
-- Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
