CODEWITHSUNDEEP
javascriptoop
gabber12
gabber12

Reputation: 1124

Modeling oop hierarchy for a game

I thought of starting a html5 game development project.
I started my game project with modelling it. I came up with something like this.

Game

   Array of Entities
   Timer
   score
   some methods for initializing
   master draw
   master update


Entity

   Update
   Draw

What happens is that the master method(update or draw) calls the update/draw method on each entity.

The model seemed clean enough to me and i started to code but then i realized that there is no way of communication between different entities.

The update method of one entity would need to consider the state of other entities.

I have coded each update functions prototype with same set of arguments so that i can loop over the entities and call them easily.

Please can somebody suggest ways to overcome the problem. What changes should be done to the model?
Also how do you get better at modelling software architecture and extending it. How do you decide how much part of code to keep abstracted?

Upvotes: 1

Views: 143

Answers (2)

shieldgenerator7
shieldgenerator7

Reputation: 1756

I've encountered this problem before, too. What I've done is give one entity a reference to the other player (in a game with just two entities), and/or give the entity a reference to the whole game model. By giving the entity the whole game model, it can see its surroundings and other entities around it and act accordingly.

Upvotes: 0

meetamit
meetamit

Reputation: 25157

Ok... that's a pretty broad question, and you're probably not going to get a definitive answer here. But genrally, you need to think of your game in terms of Model-View-[something else]. Here [Something else] can be "Controller" or "ViewModel", or something in-between.

The model, as referred to by the Model-View pattern (not as you refer to it above), knows about and maintains the game logic and none of the visual representation of it. Game logic includes score, level, players etc. Each View in your game (a view can be a score box, or a player character) has a reference to the model and extracts from the model the info it needs to render itself. That's how you share info between the views – through a centralized model (sometimes models have sub-models, in complex games, but start simple, with a single model class).

When you find that your views need some coordination of logic that's not inherently model-based, that's when you introduce controller or viewModel logic.

I'm sure if you google "game design patterns" (with or without "javascript") you'll find all kinds of interesting tutorials on the matter.

** EDIT: **

In your case, you probably should think of Game as your controller. At initialization, it would instanciate a Model, which is where you put the score and timer logic (so, not inside Game. Then it would instanciate the array of Entities, giving each one the instance of Model. In the update method, Game would invoke appropriate methods to update Model, then call update() on each Entity, which would read the state out of Model and redraw accordingly.

There's a variation of this where Game doesn't call update() on entities, and instead, changes to Model trigger events that are subscribed to by each Entity.

Upvotes: 2

Related Questions