Once upon a Time, Software happened
When you do code for a indie game, there are ton of useful things that can… derail you.
Learning to deal with the frustrations is part of the development experience and learning path.
Lets get down to it:
🌀 Braniac work — it’s the slow burn of deep thinking, the kind of effort that eats up hours, not for immediate gratification but for the promise of future clarity. Building something like an encapsulated widget system is exactly that: a lure into a mental labyrinth where every turn is a decision.
🔍 You could throw together spaghetti code — hardcoded widgets, each with their own static logic — and it’d work. For a while. But then you’ll blink, and suddenly your codebase is a house of cards. Every new feature feels like a Jenga pull, one wrong move from collapse.
I was doing a troubleshooting (temporary) kind of “Trace” button for my Overlook Hotel inspired point-and-click tactics game.
How do you make a good switch button, and bind a keypress event to it as well?
Stumbled upon some of PyGame internals — and how widgets like a Switch (has 2 states) are done in PyGame.
I loathe bloated code.
One of the reasons I have never done a lot of Java (code) — beyond the amount of Java I have done, is that I feel it is an absolutely bloated language.
Which is tainted, human, and biased view.
I should know better; one of the bigger memorable hobbyist projects I did was a text entry accelerator on Pascal. I tasked myself to enter 11000 article headings for my own database of computer magazines, and of course that veered into first making a proper time saving turbo editor, which would keep me from repeating the tedious long phrase snippets that would eventually keep repeating in the data. It saved a lot of time. You simply use keyboard to accelerate the most commonly occurring snippet entries, and it dynamically detected and added to a codebook these snippets.
Key Principles for elegant widget creation in PyGame
- Encapsulation:
- All widget-related logic, including key bindings and state management, should be handled internally by a factory.
- The caller should not need to know how events are processed or widgets are updated.
Let’s see if this is doable!
