So I am using an entity component system for the first time and while I like how it organizes the code, I am having issue understanding how to go about 1 thing at the moment. In case this matters, the game in a 2D turn based rogue like game.

So with the ECS, the player is just like any other entity and right now it does not have any component on it that is unique to the player. The issue is that I find that there are multiple use cases where I want to have access to the player's specific entity either outside of the ECS or within the context of a system that works on different entities. I will try to give a couple of concrete examples.

For example I have an inventory UI screen that is outside of the ECS but needs access to the player's inventory (to show the items). Another example would be the enemy path finding system which would need access to the player's locations (in order to both know if the player is within aggro range and to know the location to path find to). Another would be a world loot system that needs access to the players location (as only items within a certain range of the player should be rendered). 

Most generic stuff I have read says that Entities should just hold components and nothing else. Now I generally don't apply patterns dogmatically if I think there is a valid use case to diverge slightly and this is one of those cases to me. What I am leaning towards is having a unique label that can be placed on the entity or have it null if not needed. This seems to be an edge as the only thing I think I am going to need this unique label for is the entity of the player (but who knows, other use cases might show up later).

Does this seem like an unreasonable way to implement an ECS? I am open to the idea that there might be other ways to handle the use cases where I need access to the player's specific entity but I can't think of one right now.

Quote

For example I have an inventory UI screen that is outside of the ECS but needs access to the player's inventory 

In my 1/5 done UI system, the player entity is the only one with inputs and input mappings. Those mappings handle a key button press, that can grab it's owner entity, check if it has the ui view it wants to show (because the ui view group is another component), and display it. The ui view, depending on what it does, can fetch components from its owner entity (say, like the inventory component) and do its magic. All inside the ECS, no concept of "player" needed for that.

In any case, you can just have a tagging system. Entities can have Tag components, and the system keeps a tag -> entity map around. You can request the tagging system for a specific entity that way (this can work for other use cases, like say, tagging enemies, or movable objects, or quest items, or whatever). 

I think what you want to do is get the entity from the ECS and pass its location to the world loot system's function you're calling. The ECS should have an ID or string key for the entity you can probably keep in an array/linked-list. I'm assuming the ECS is like the warehouse for entities and you don't want to duplicate any data. Getting a pointer to the entities from the ECS with an ID or string key should be O(1). But don't store the pointer in the world loot system. Just use it to pass it the parameters it needs to do its job. I could be way off idk.

In general, you should make the player entity not special (except for principled features, like connecting it to inputs and outputs) and assumed singletons one of an unspecified number of entities, components or other objects.

The inventory screen should be able to render any character's inventory (maybe one day magic could allow the player to look into a monster's pockets); the enemy pathfinding system should reason about on a set of enemy characters within range (and be applicable to any group of hostiles and monster infighting situations); culling treasure rendering should ignore characters because centering the view on the player location is incidental and compare the location of the item with the extent of visible map regions. 

You could create a "player" component that has anything specific to a Player controlled character (as opposed to NPC), and use it as a reference to which entity is the player entity.