Brianna Rainey's Blog

My PixiJS game template has keyboard support now, including the ability to temporarily disable the keyboard during scene transitions like the old game template... So you can pause by pressing P. Now I need to decide how scenes are going to handle adding/removing their actors from the stage in a consistent understandable way. Probably move all actor management into mount() and unmount() or something. Scenes can individually decide if they need to unmount the previous scene before mounting themselves (sometimes you want to add onto a scene rather than replace it, which is why the previous scene isn't destroyed when changing scenes in the first place).

I'm still trying to decide what game I'm going to make when I'm satisfied with the new template. I want it to be relatively simple so I can complete it within a week or two, like my old games. Currently considering Snake but it'd require a virtual keyboard for mobile support (like Rodent's Revenge has) so if I can think of something more touch-oriented then I'll probably change my mind.

I tried to make a video where I read PEP 3333, but it felt too boring so I edited the video into an explanation of what WSGI is: youtu.be/6fU36-_HHrI

If I practice more and edit some diagrams into the videos then maybe they'll be better in the future. It's hard to follow the details in this one, which is why I put "ramble" in the title 🤭

Python having an instance (self) as the first argument to the instance's methods is so logical. It helps highlight what is happening implicitly (instance is an argument to a function) and in my opinion this small reduction in implicit behaviour is helpful when forming a mental model of how the code works.

(It also makes it easy to move a function into a class by naming "self" whatever you named the instance in the original function, but that's a temporary convenience. You should still rename the param to "self" eventually, to match convention.)

This design isn't always helpful once you're more experienced with OOP, but Python does a good job teaching the idea in the first place. Explicit is better than implicit, as long as it increases clarity (by not introducing boilerplate).

Some languages (like Java) take it the other direction and allow `x` to mean `this.x` when it's unambiguous in context. Ambiguity is more common in Python due to dynamic typing and identical syntax between new and pre-existing values (i.e., there is no keyword like "new" or "const") -- so, although omitting the explicit "this"/"self" seems scarily implicit, it might make sense depending on the language design.

I'm working on redoing my "html5 canvas game template" into a "PixiJS game template". Pixi is not really a game engine on its own; it's a rendering system that uses WebGL and also handles event-progagation of mouse/touch events. Feels like the logical next step for my webgames, so I can keep making my own game loop but have prettier graphics and a layering/masking system.

older posts

7
6
5
[4]
3
2
1