Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 21 Sep 2013
Offline Last Active Today, 02:48 AM

Posts I've Made

In Topic: How to separate xyManager effectively into smaller responsibility classes?

03 May 2015 - 10:33 AM


unnecessary parameter passes


They're not unnecessary if they're needed.



Well, i am pretty sure passing some refs/pointers all around the code base just because somewhere deeply in the codebase somebody might want to use it is a bigger antipattern than using singletons...

And if 99 command from 100 don't use it, then i feel like it's unnecessary.

In Topic: How to separate xyManager effectively into smaller responsibility classes?

03 May 2015 - 08:57 AM

Thanks for the answer!

Global variables are evil - kill the singletons.


I totally agree, the question is how, without messing up with tons of unnecessary parameter passes everywhere? :)

So you know, i can have generic pools somewhere, but the question is how will i reach it from the places i need?
For example i will have a "TrainWizardCommand", which should know how to add a new unit, even tho this will be created in an OnClick event, for example in a Building class.


So, unless every single building have a pointer to the UnitPool (which is i think also avoidable) i ending up with keeping it as a singleton.


Another issue is, that i like to keep the Commands parameterlist as small as possible, so i am not sure if the right way is to pass the pools just because this case. Most command won't use this pool, but they will have other requirements.


Well, maybe i will be unable to keep the "1 command pattern for every cases", but it's possible that from the same function i can create different type of commands, and that's problematic.

For example, i have a unit with these skills:
- Summon 2 skeleton (Unit pool required for execution)

- Give a shield to a building (Building pool required, it would be kinda strange if a building would have a pointer to the pool, which contains the building itself)

- Give vision to somewhere in the map (map, or whatever will handle the fog of war required)


The "solutions" i see:

- Make some classes singleton, so i can reach them when i need, but then... i ended up with using singletons, which is kinda sad. :(

- Passing pointers around to the pools and other stuffs, which is even worse than the singleton way and make it a nightmare to refactor anything.


I don't really know what's the elegant way to handle this.


The holder class is probably a generic pool. Can probably be ObjectPool<T>, and then reused as ObjectPool<Building>, ObjectPool<BoundingSphere>, etc...

I will probably have 1 for buildings, 1 for units, 1 for Images (to don't read the same images over and over again just because i have 10 units from the same type)


If you have a generic model/mesh/material system, then instead of the building drawing itself, it can contain a model, which can drae draw itself. The building can also own a bounding shape that's used for frustum culling (it would also be linked to the model) and for your click detection.

The building's draw is actually just call it's sprite's draw. (i use SFML for this)

In Topic: How should i call my classes instead of "xyManager"?

13 December 2014 - 06:34 AM

ImageLoader then, or ImageCache. Or an ImageCache in which you plug an ImageLoader. Caching strategy doesn't depends on the format of the image IMO so you could plug different ImageLoaders for different formats and the ImageCache could store the data loaded by them. Then if you don't want a cache for certain things, just use the loader directly.



ImageCache sounds fine, thanks.


Then that "update" function should do less things.


Well, it updates the objects with the elapsed time. Yes, this can mean alot of things, like train units, move, attack and other stuffs, but i feel like it's reasonable.

In Topic: How should i call my classes instead of "xyManager"?

13 December 2014 - 06:16 AM



Your ImageManager may be problematic since it violates the single responsibility principle if implemented as a single class. The single tasks possibly involved here are (a) allocating local storage, (b) reading a resource from mass storage, © uploading the resource, (d) implementing a cache strategy, (e) granting access. Okay, all this together means to manage the resource, but the tasks are too different to be implemented in a single class. Instead, if you understand the manager as a facade granting a small API in front of the wrapped functionality, it is IMHO okay to name it "manager" if you wish.

I try to be a bit more accurate, there is not that much functionality in the ImageManager.

It has an Init function, which load the textures to a container, and have a function like that: sf::Texture getTileTexture     (Image::TileTexture texture);

Which give back the given texture (TileTexture is an enum)

So it does 2 things: Load the textures, and give an interface to get the texture you need.



Your BuildingManager and UnitManager are even more problematic. They implement some kind of scene setting but also implement collision detection and update services!? These tasks are not related and IMHO can not even be subsumed in a single "management".

No, these classes just iterate through all Units and Buildings, and call the update on them. Everything else is done by the given Unit's or Building's update function.

In Topic: (Tower Defense) Template metaprogramming or Factory functions to avoid class...

09 September 2014 - 06:02 AM

Thank you very much, this is simplify alot of thing. :)
(i am sad, metaprogramming were more interesting. :'( )