1

I'm creating an HTML5 game using javascript and have got some problems during the first instantiation of the objects of the scene.

Scenario

  • Self-written 2d game engine that supports multiple types of objects.

'Glossary'

  • An object is a scene-related entity, and is always an extension of a model, which is abstract.
  • A scene contains a collection of objects.

Problem

When I instantiate the game scene I load the data of the scene from the local storage at first, and then I proceed to instantiate its objects. The problem is that the type of the game object (sprite, text...) is declared in the model, not in the object (that has a reference to the model). In this way I have to fetch the model of the object in order to know what type of game object I need to instatiate, and I really don't like it.
I could save the type of the object as a property of the object, but it would be logically wrong: I should not be able to redifine the type of the object decided in the model because it would easily break the implementation of the game object declared in the model. So, it has no sense saving the type of the object in the object itself given the fact that the model already has the job to declare it.
Hence, maybe I need a new architecture...

How can I avoid to fetch the model without breaking the logic of 'this is where I should save this property'?

If the question is not clear, please provide me some feedback: I'd be happy to improve it.

0

Simple, stop thinking of sprites or text as the types of the game object in the model. Those types are the responsibility of the view.

Let's say this game is chess. The models job is to know the state of the board. Types here should be things like: King, Knight, Pawn. The model should not know that you're presenting it with sprites, or text, or even in 2D. It's job is to know where the pieces are.

You should be able to slap different views on this model to present it different ways. The model shouldn't have to change when the view does.

You don't have to fetch from the model. The model shouldn't know anything about the view but it's free to talk to a view interface directly. The model OWNS this interface. It doesn't implement it. The view does. Whatever view that happens to be decides how the game is presented.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy