What is the scope of this project?

[apsz3]

I'm interested in this project -- I saw it linked on one of the GitHub Issues for the roguelike tutorial. What is the scope / goal, and where is the progress currently at? I've poked around the code a bit, but would appreciate a high-level description of the project goals for the engine.

[HexDecimal]

Everything I have labeled as engine is meant to be something I (or anyone else) can make a fork of to start a new project with. In practice it usually ends up being something I use to experiment before I discover something new try out. I also wanted something I could use as an example to create a new Python tutorial.

I did end up using this project to discover reusable code which I separated with their own modules such as tcod-camera and I've considered turning the keybinding code into its own module. There are things which I end up writing the exactly the same way every time I implement them.

[apsz3]

I see, thanks. Would you say this engine is stable / complete enough to fork? Or are there necessary implementations that aren't fully formed?

Also, I'm wondering -- why use the attrs lib, over dataclasses?

[HexDecimal]

Would you say this engine is stable / complete enough to fork? Or are there necessary implementations that aren't fully formed?

I've been rather conservative when developing this so there shouldn't be too much technical debt when creating a new project. This might be one of my first projects making use of ECS though, so I may need to update that area. I've been figuring out better ways to handle referencing maps and handing tile data and these areas might need more work.

why use the attrs lib, over dataclasses?

attrs is more modern/powerful and doesn't rely on the Python version like dataclass does. It's generally what I'm already used to.

[apsz3]

Thanks for the context. I appreciate the work you're doing, and am learning a lot about fluent Python from your code!

[apsz3]

So I'm doing the roguelike tutorial, and am wanting to use the tcod-ecs module in that context. I'm looking to your usage here as some guidelines as to how to use that system effectively.

I've been figuring out better ways to handle referencing maps and handing tile data and these areas might need more work.

So when you say this -- do you mind sharing the conceptual changes you've made to your approach?

[HexDecimal]

Referencing maps

The simple way is to have an object as a label, something like ("dungeon", 1) for the 1st floor of a dungeon. It's easy to setup but I felt like over complicating things and making this something fully dynamic. Instead of a string key that'd be passed to a function to tell which generator to use I could have the generator itself be the key with any extra data as the parameters. Which is how I ended up with this MapKey:

python-tcod-engine-2023/game/map.py

Lines 67 to 79 in 9efe029

	@attrs.define(frozen=True, init=False)
	class MapKey:
	"""A unique hashable map key defined as a generator function with the provided parameters."""
	generator: Callable[..., Entity]
	kwargs: frozenset[tuple[str, Any]]
	def __init__(self, generator: Callable[Concatenate[Entity, P], Entity], *args: P.args, **kwargs: P.kwargs) -> None:
	"""Initialize a map key with a generator function and all arguments rebound to keywords."""
	signature = inspect.signature(generator)
	signature = signature.replace(parameters=list(signature.parameters.values())[1:])
	bound_kwargs = signature.bind(*args, **kwargs).arguments
	self.__attrs_init__(generator, frozenset(bound_kwargs.items()))

This is probably too much. I might've been able to do the same thing with less boilerplate by making a Protocol instead. I probably didn't need more than this:

class MapKey(Protocol):
    __slots__ = ()

    def __call__() -> Entity:
        ...

Either way the end result is that you use this key as a destination attribute of a stairway component and the level will be generated on demand as the player traverses the entity.

Tile data

In all of my recent projects I always have map entities hold a whole chunk of map data. This is useful because contiguous chunks of array data are much faster to work with, especially in Python.

I have a system setup where tiles are stored in a database and the main tile layer indexes into that database. I tried to design this to be extendable and stable. There's a named lookup table which lets you use readable names for tile indexes and this table is supposed to conserve the index of tiles even when the data changes. Otherwise this is the typical flyweight pattern.

In theory it'd be easy to add more layers for data that's dynamic such as tile-damage or an on-fire state but I haven't needed this yet.