Closed rickbatka closed 10 years ago
reddenx
commented
10 years ago A more common solution I've seen to this is at this point we need to load all our assets up front and put them in some sort of asset singleton (sound textures fonts). For loading we just pass the world or level object (whatever will eventually contain these objects) in for the factory to add it to. This keeps the factory independent of the main game and removes content as a problem entirely.
rickbatka
commented
10 years ago Ok, so we are in agreement that the factory will need a ref to the game object. I am perfectly ok with a singleton for assets as well. We know they'll be set up and available an time after load content.
Still need to address how the factories are accessed. I think there are many valid places that may need them - brain, network, physics, ai director. That means the factories are either static or singletons. So the game service model fits perfectly.
We can do some reading if you are nervous abut using them from a performance perspective.
On Saturday, February 15, 2014, Sean notifications@github.com wrote:
A more common solution I've seen to this is at this point we need to load all our assets up front and put them in some sort of asset singleton (sound textures fonts). For loading we just pass the world or level object (whatever will eventually contain these objects) in for the factory to add it to. This keeps the factory independent of the main game and removes content as a problem entirely.
From: Rick Batka Sent: Saturday, February 15, 2014 10:11 AM To: rickbatka/co-op-engine Cc: Sean
Quick discussion:
I started moving the creation of game objects out into factories and it seems the factories need to be coupled to the main game for several reasons. They need to get textures that the game has loaded, they need to put the newly built objects into the quadtree, and they need to put the new objects into the lists for update, as far as I can tell.
I was thinking, then, that each factory should get initialized with a ref to the main game in the game.init (or right after loadcontent or whatever). Then, each factory can expose itself via a GameService like we do for the ActorInformationService now. This way, different places can spawn things into existence, without knowing / carinng about the guts of hooking up textures and such.
Example: inside player brain, input notices we pressed the "Build" button and we determine we are in a valid state to build a tower. We call TowerCreationService.GetUnbuiltStandardArrowTower() and it's automatically wired into the game everywhere it needs to be.
Thoughts / concerns?
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/rickbatka/co-op-engine/issues/12#issuecomment-35163988 .
reddenx
commented
10 years ago Service Providers
Actually I'm pretty happy with the service providers, they fit pretty well, what I was concerned with originally was performance in the update loop, but since they are only really referenced on demand and not constantly I'm not too worried about performance.
Factories
I'm fine with static until they start to require dynamic resources, at which point it would be safe to move them into singletons or change the way we instantiate objects entirely. I don't really see this being a pressing issue for a while, and it being pretty loosely coupled (static) it shouldn't be too hard to refactor once it is a problem.
rickbatka
commented
10 years ago Cool, I actually was trying to say that the service model lets us avoid having to make the factories static, which is rad. They're basically a fancy singleton.
On Saturday, February 15, 2014, Sean notifications@github.com wrote:
Service Providers
Actually I'm pretty happy with the service providers, they fit pretty well, what I was concerned with originally was performance in the update loop, but since they are only really referenced on demand and not constantly I'm not too worried about performance.
Factories
I'm fine with static until they start to require dynamic resources, at which point it would be safe to move them into singletons or change the way we instantiate objects entirely. I don't really see this being a pressing issue for a while, and it being pretty loosely coupled (static) it shouldn't be too hard to refactor once it is a problem.
From: Rick Batka Sent: Saturday, February 15, 2014 12:25 PM To: rickbatka/co-op-engine Cc: Sean
Ok, so we are in agreement that the factory will need a ref to the game object. I am perfectly ok with a singleton for assets as well. We know they'll be set up and available an time after load content.
Still need to address how the factories are accessed. I think there are many valid places that may need them - brain, network, physics, ai director. That means the factories are either static or singletons. So the game service model fits perfectly.
We can do some reading if you are nervous abut using them from a performance perspective.
On Saturday, February 15, 2014, Sean notifications@github.com<javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:
A more common solution I've seen to this is at this point we need to load all our assets up front and put them in some sort of asset singleton (sound textures fonts). For loading we just pass the world or level object (whatever will eventually contain these objects) in for the factory to add it to. This keeps the factory independent of the main game and removes content as a problem entirely.
From: Rick Batka Sent: Saturday, February 15, 2014 10:11 AM To: rickbatka/co-op-engine Cc: Sean
Quick discussion:
I started moving the creation of game objects out into factories and it seems the factories need to be coupled to the main game for several reasons. They need to get textures that the game has loaded, they need to put the newly built objects into the quadtree, and they need to put the new objects into the lists for update, as far as I can tell.
I was thinking, then, that each factory should get initialized with a ref to the main game in the game.init (or right after loadcontent or whatever). Then, each factory can expose itself via a GameService like we do for the ActorInformationService now. This way, different places can spawn things into existence, without knowing / carinng about the guts of hooking up textures and such.
Example: inside player brain, input notices we pressed the "Build" button and we determine we are in a valid state to build a tower. We call TowerCreationService.GetUnbuiltStandardArrowTower() and it's automatically wired into the game everywhere it needs to be.
Thoughts / concerns?
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHub< https://github.com/rickbatka/co-op-engine/issues/12#issuecomment-35163988>
.
Reply to this email directly or view it on GitHub.
Reply to this email directly or view it on GitHubhttps://github.com/rickbatka/co-op-engine/issues/12#issuecomment-35168115 .
reddenx
commented
10 years ago Discussion concluded
Quick discussion:
I started moving the creation of game objects out into factories and it seems the factories need to be coupled to the main game for several reasons. They need to get textures that the game has loaded, they need to put the newly built objects into the quadtree, and they need to put the new objects into the lists for update, as far as I can tell.
I was thinking, then, that each factory should get initialized with a ref to the main game in the game.init (or right after loadcontent or whatever). Then, each factory can expose itself via a GameService like we do for the ActorInformationService now. This way, different places can spawn things into existence, without knowing / carinng about the guts of hooking up textures and such.
Example: inside player brain, input notices we pressed the "Build" button and we determine we are in a valid state to build a tower. We call TowerCreationService.GetUnbuiltStandardArrowTower() and it's automatically wired into the game everywhere it needs to be.
Thoughts / concerns?