0

So I ran into this little issue while working on an idea of a small online game.

Here's a simple idea of how it works: Client and server would use the same implementation of the "world" - objects, physics simulation. So say we have class World, which contains a vector of WorldObjects. WorldObject is a base class for other classes to derivate from (like PlayerObject, BoxObject, MonsterObject). The problem here is how to efficently declare custom rendering methods for those object classes. For example a PlayerObject has to be rendered differently than BoxObject.

The thing to keep in mind is that we can't just create a virtual render method, because that would imply that eg. BoxObject has to #include "OpenGL.h" which CANNOT be done on the serverside (we want to keep the serverside clear off graphic libraries).

So how can this be done? I've come up with an idea like this: create a separate singleton (only clientside) that would contain implementations of rendering methods for different object types (identified by an enum for example), but is that the best way to do this? Do you know anything more efficent and flexible?

Of coure we're talking C++ here, but if there's a rule or practice that you know and use in another language please do share (that's why I didn't really specify the language in the post). Thanks.

user3010228
  • 3
  • 1

1 Answers1

0

You may introduce types that derive from PlayerObject and BoxObject that support rendering, for instance PlayerObjectRenderable and BoxObjectRenderable (or more reasonably, you introduce Interface like Renderable). Then, when you create (or factorize) objects for client side, you create instances of those ObjectRenderable classes, and for server side you use the more generalized ones. When it gets into rendering you supply references or pointers to the Renderable interface. Client-side factory building objects might also be derived from the generalized one, and so on...

Kissiel
  • 1,925
  • 1
  • 13
  • 11
  • Indeed it would be a good idea to do PlayerObject:WorldObject,Renderable, but then the server would have to use it too, but on the other side PlayerObjectRenderable:PlayerObject,Renderable - what about the storage? Do I store this as a PlayerObject? Will I be able to cast this to Renderable when I grab a pointer to PlayerObject? I don't think it's possible this way without some kind of funky reinterpret_cast usage? – user3010228 Nov 19 '13 at 19:35
  • Yes, if you have a renderable player object, you should 'store' it by pointer/reference to player object in parts that do logic stuff, and you can store it as pointer/reference to Renderable in your graphics related code. The other way to do this is to cast PlayerObject pointer or reference to derived type using dynamic_cast; then, if cast is successful, you can use it as renderable. More on this here: http://stackoverflow.com/questions/2253168/dynamic-cast-in-c – Kissiel Nov 19 '13 at 20:07
  • Done some tests, and indeed it does work! As simple as that: WorldObject* OBJ = dynamic_cast(RENDERABLE_INSTANCE) Thank you for your responses and the link, understanding dynamic_cast is crucial for implementing this kind of system :) – user3010228 Nov 19 '13 at 20:29