Is your feature request related to a problem? Please describe.GameArea instances currently hold data about the world (GameBlock collection) as well as the view. (Scrollable) This means that if you need to change the view, you need to copy whole object with the complete GameBlock data.
Describe the solution you'd like
I propose to separate GameArea from the Scrollable implementation:
Add a GameAreaView or GameAreaCamera, that handles the Scrollable logic, but does not hold any world data and only points to an existing GameArea
Either remove the Scrollable interface from GameArea, or give each GameArea a default view/camera to preserve backwards compatibility
Let GameAreaComponentRenderer take a view/camera instead of a GameArea
Describe alternatives you've considered
Making the visible part of a GameArea dynamically resizable would also mean that the world data does not have to be copied, but this would miss out on the cool features listed below. While making the views/cameras resizable would also not hurt, the decoupling makes it fairly easy to create a new view/camera, so the actual resizing support can go down in priority.
Additional context
This separation would enable a lot of cool picture-in-picture game features, for example:
Item description panels can include an extra 5by5 view of the item and its surroundings, that also updates the same way as the main view.
Follow-cams for characters. Surveillance simulator, anyone?
Dialogue boxes showing the character you speak to, maybe even using a different projectionMode than the main view.
Is your feature request related to a problem? Please describe.
GameAreainstances currently hold data about the world (GameBlockcollection) as well as the view. (Scrollable) This means that if you need to change the view, you need to copy whole object with the completeGameBlockdata.Describe the solution you'd like I propose to separate
GameAreafrom theScrollableimplementation:GameAreaVieworGameAreaCamera, that handles theScrollablelogic, but does not hold any world data and only points to an existingGameAreaScrollableinterface fromGameArea, or give eachGameAreaa default view/camera to preserve backwards compatibilityGameAreaComponentRenderertake a view/camera instead of aGameAreaDescribe alternatives you've considered Making the visible part of a
GameAreadynamically resizable would also mean that the world data does not have to be copied, but this would miss out on the cool features listed below. While making the views/cameras resizable would also not hurt, the decoupling makes it fairly easy to create a new view/camera, so the actual resizing support can go down in priority.Additional context This separation would enable a lot of cool picture-in-picture game features, for example:
projectionModethan the main view.