Separation of concerns (rendering and game logic)

[HoratioHuffnagel]

Hi!

I am starting a new game at the moment (JavaScript/HTML5) - and I really want to make a concerted effort to get the architecture right. The issue I am struggling with right now, is how to separate the game logic from the rendering, how to actually structure that separation, how granular should I get with object representations etc. 

The game type is a simple match 3 (bejeweled-esque) kind of game. And I would normally just go about creating a board class, have a class for a "jewel", and the board contains a list of "jewels", with each Jewel holding a reference to it's texture, but also containing the logic that can be performed on each "jewel". 

However, I may have to put the game logic server side at a later date. Any suggestions on how best to separate the logic / rendering so I can avoid a tangle later on?

Cheers.

[scheffgames]

The best teacher for architecture structure is experience. Just start coding it and keep the desired goals in mind.

In my experience - with Phaser and Unity and SDL - the best thing to do it's to have each object as self-sufficient as possible and with very little or no dependencies to other objects. A "shy" object if you like - just exposes the minimum amount of properties and methods to other objects. Each object manages drawing and logic for itself. It might seem a good idea to defer the drawing to other master/manager objects but you'll end up with a big furry mess. 

[b10b]

For a puzzle game I would predict that the server-side logic may only share a minority of the client-side logic, potentially none at all other than for testing?  Whereas it may share the majority of data / value objects.  My advice is start there - define the read-only aspect of each Object and ensure that is self contained and portable.  Next steps would be to create the Objects that read the data and add logic to accomplish their tasks - ideally in a component and/or system way to allow re-use from client to server if warranted (and be cautious of Event dependencies).  Finally inject the view to each Object, which will likely share little between client-side and server-side as it will serve quite different masters.

[HoratioHuffnagel]

Thanks guys - firstly, sorry for the late reply (things got very busy!). Secondly, your replies make a lot of sense.