I don't have an educational background in the programming-world; however, I've been working on a programm in my spare time for the last two years.

I'm currently struggling with how to decouple the GUI (or the drawing-logic in general) from the internals. More precisely, how to retrieve the data that's needed to display all information on screen.
For example: There is a collection of items that I want to display in some sort of inventory.
Should there be a copy of the collection in both the modules that use these items and the GUI-module or should all of them referece to the same container?
Should the implementation already provide methods that are needed in the UI logic? (e.g. the game only needs to check if you can use an item, the UI would show why you cannot use it - should several functions be provided in the logic, even though the game doesnt care for which reason?)

I have been reading up on MVC and MVP but the problem hasnt really been adressed: How does the View retrieve the data needed to display the model?

I'm not using any frameworks, engines, etc. Just plain code - I'm more focused in the design than finishing the project.


There a a number of ways to do this, but I will go into the way I solve this in my own games.

Firstly, the Icons/UI elements are a visual manifestation of the status of the item. Just a representation, but you need something to glue that to your items. In this case a container that contains a object that references both the GUI elements and the inventory items. I do stress REFERENCE, not copy because if you copy,then you have to manage status updates across multiple copies of the same object.

For container design, this should be a baseclass, with functions that are overridden based on the item there in. For example, you may want to show a cooldown on a sword or item in game, your container class could have an inherited class to deal with that AND also manage how that is displayed in your UI component, say with a colour or timer overlay. Another could be a potion, that is represented as full or empty. That can be a separate inherited class to do the logic for that also (single use instead of cooldown).

What i'm basically getting at is, that firstly address the loose coupling of UI to game object through a class that manages the logic of displaying on screen. Functions such as game logic are in the referenced object class and you don't need to pull that up into the container class, its taken care of where it should be.

You then wrap the container class up within a collection class, that container class could also be an abstracted class, Say Bag, Chest, Safe, etc that itself organises how it is displayed on screen.

Each layer then takes care of itself, is extensible. base class design is the key here, and ensuring that everything is in a logical place in your object hierarchy.

Hope that is a a start


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .