Today’s dev news is about pygamelib/hac-game-lib and more specifically about complex items.
It’s been something I wanted to implement for a long time: complex items. Understand: items that are represented over more than 1 cell on the game board.
I did some proof of concept a while ago, and the “demo” is still available on the related GitHub issue. At that time I thought it was going to be an easy one… Key part: “at that time”. It was a nightmare to implement!
To be fair it’s not all about the specific feature, it is everything that it triggered in my brain.
There’s two main reasons for me to implement that feature:
- Have bigger and more complex characters models.
- Be able to use colors and Unicode glyphs to render complex graphics in the terminal (complex for the terminal).
In theory that feature is easy to add: a complex item is nothing more than a collection of items bound by the same movement. With that in mind it’s easy to move, because we can move items individually with Board.move() and all the things that move() does are auto-magically going to be done with complex items too. All the logic exists for complex items to exist.
Well. To a point, it’s partially potentially eventually true. To a point.
Moving is not really the real problem, adapting everything to complex items is what takes times. And if it is sometimes fun, it is mostly menial tasks that require little to no thinking. And that is what hell looks like: going through the entire library making sure that every single piece still works and that it does not change a thing for people that are using it.
On the other hand, it created the need for better graphical capacities and led to real sprite implementation (you could almost call them terminal textures), that in turn led to a new notion in the library: the sprixel (I’ll explain later) and all together a brand new GFX module that include a console particle system.
1.2.0 is going to be a big update…
I’m fairly happy with the current state of the complex item system, it allow for that kind of stuff:
