# Separating data from model and successfully visualizing it

This is a bit of a design question that I'm struggling with. I have a data model and an entity model. The data model is, of course, what is (de)serialized to represent my levels and entities within it, whereas the entity model is the run-time manifestation of the level actually being played.

In addition, I have a game editor that allows the levels to be edited and played all in the same UI. It has 2 modes, each with 2 views:

• Design-time Mode:
• a top-down, interactive view of the level. This is where the actual editing of the level takes place.
• an in-game preview of the level that updates as changes are made in the top-down view
• Run-time Mode:
• a top-down view of the level that is non-interactive but live
• an in-game, run-time view of the game that is interactive. ie. you can actually play the game.

The user switches between the modes by clicking play & stop buttons. Here's an example of my top-down view (this one is run-time):

Now, here is the problem: I want the design-time top-down view to mimic the run-time top-down view as much as possible, but certain information is unknown at design time, such as the texture dimensions and collision circle information. Therefore, I cannot render this information accurately.

I see these options for dealing with the situation:

1. don't try and mimic the run-time, top-down visualization. Instead, just render something that is as useful as I can make it given the limited information I have available.
2. hack my data model so that it also returns information that it really has no business knowing, such as the collision circles and texture dimensions. This would facilitate the visualization of that information, but at the cost of maintenance and code design.
3. since my design-time mode already has two views, one of which is a manifestation of my data model, and the other is a manifestation of my entity model, I could dynamically try to correlate that information for the purposes of my top-down visualizer. This seems like it should work, but also seems rather messy and error-prone.

This seems like it must be a fairly common problem when writing game editors, so I thought I'd try to gather some advice. Any input from the community would be much appreciated.

• Can you explain why you don't know texture sizes at runtime? You should have some idea (eg. a range0 even if you don't know the exact size. – ashes999 Aug 19 '13 at 1:00
• @ashes999: I do know the texture sizes at runtime, but not at design-time. That's why my design-time visualization currently does not look exactly like my run-time visualization. – me-- Aug 19 '13 at 1:02
• That seems odd. Can you have a 1x1px texture? What about 1024768x1024768? Surely there must be some parameters around it. – ashes999 Aug 19 '13 at 1:25
• It's really weird for your "design time" to have less information than "run time" code does. It's far more common for the editor to have all the information that run-time game does since the editor produces that information in most cases and can have tighter integration with the asset pipeline than the run-time game can/should. In many cases a good editor can just use the main game engine renderer for its editing, maybe with setting some special rendering flag to show collision volumes or such for object selection and such. – Sean Middleditch Aug 19 '13 at 2:01
• I think I failed to describe my situation sufficiently. It was more a question of how my design-time model can cleanly gain access to the run-time information. Please see my answer for the approach I ended up taking. – me-- Aug 21 '13 at 0:50

In the end I changed my visualizer control so that it could pass some state through to the visualizers. For the design-time visualizer control, I passed through a simple context as the state. The context has this interface:

public interface IDesignTimeVisualizersContext
{
Entity GetEntity(string id);
}


So now my design-time visualizers can look up and obtain the information they need from the run-time manifestation of the design-time data. I'm not certain this is the absolute best way, but it does work and now my design-time visualization 100% matches my run-time one.