ertes 2017-03-04 15:46:55
try to think less in "objects" or "instances"… think in terms of behaviours… and don't insist on uniform representations… for example a "player" doesn't have to be (and perhaps shouldn't be) an value of type Player; it may manifest differently depending on context
ertes 2017-03-04 15:47:34
in a map of all currently active game objects, it may manifest simply as something with a position and a rendering function
Squarism 2017-03-04 15:49:19
What i refered to as GameServerInstance is really 2 types of channels. 1 to game, N to players.
Squarism 2017-03-04 15:50:02
both type parameterized depending on game implementation
ertes 2017-03-04 15:55:41
why do you need a message type to begin with?
Squarism 2017-03-04 16:01:32
It felt natural when i had just one game. Played well with AEson to/from json. Plus both in and out messages could be of "control" messages that needed to be inspected in networking/game loop.
Squarism 2017-03-04 16:02:20
But i understand what you mean. I could delegate decoding / encoding to games themselves
Squarism 2017-03-04 16:02:42
and have one generic message type for all games
Squarism 2017-03-04 16:02:49
doable
Squarism 2017-03-04 16:02:52
maybe
srk 2017-03-04 16:03:27
yeah. I'm trying similar thing
srk 2017-03-04 16:04:09
I have plain text messaging implemented that I want to combine wih serialization
srk 2017-03-04 16:04:35
so nodes can use any protocol over that
Squarism 2017-03-04 16:11:32
ertes, thanks for taking your time. As i have no better ideas ill persue that
