Quick discussion: Object creation pipeline about co-op-engine

[reddenx]

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]

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 [email protected] 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//issues/12#issuecomment-35163988
.

[reddenx]

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]

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 [email protected] 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 <[email protected]javascript:_e(%7B%7D,'cvml','[email protected]');>
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//issues/12#issuecomment-35168115
.

[reddenx]

Discussion concluded