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 Jan 08 2015 02:26 AM

Posts I've Made

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. :'( )

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

09 September 2014 - 03:15 AM

Well, actually that's the point of templating it.


I want to be able to easily add new things to the game.

For example, i imagine a header like this:

using MageTower = Tower<MageTowerDamage, MageTowerRange, MageTowerAttackFunction, MageTowerSpecialAbilityFunction> ;

That's it, i create a new tower in 1 line, the base stats (Damage, Range, Attack Speed etc) are defined in a different header next to each other, and the complicated parts, the lambdas (how to attack, special abilities etc) are defined in another header.


I am not done with that design, it's pretty much just an idea, but the point of it is actually to avoid things like this:


enum class TowerType

Tower& createTower(TowerType type)
	case TowerType::ARROW:
		return *new Tower(100, 50);
	case TowerType::MAGIC:
		return *new Tower(50, 100);
	case TowerType::BOMB:
		return *new Tower(300, 25);


 Imagine if i have 50 tower in your enum, and a 50 case in the switch statement. Even worse, there could be like 200, or even 500 minion, with the same design. It's pretty hard to read and develop further. I think the programmer just loose himself easily in that.

In Topic: Battalions, new-age online RTS

01 September 2014 - 12:38 AM

Well, without reading the pdf i can't really help you, but i think if you would speak that way, it would be more inspiring. smile.png


"I believe, that in a Strategic game the most important part must be the strategy: planning your infrastructure, train as optimal army as you can etc. For me it's not acceptable, when the game is decided by microing. I believe in strategic games without micro. Wanna join? :)" (actually i believe in the same, i don't play RTS-s just because of microing)

You shouldn't speak about the details, you shouldn't speak about HOW you achieve the goals, or WHAT is the goal.

You should speak about Why you make your decisions. If the Why is clear, everybody can get similar dicisions using your Why as a filter.


However, if you speak about What you do or How you do, everybody will have a "better" idea, and you will feel like noone understand you. smile.png


You can get peoples for your project who believe what you believe only if you speak about what you believe.


I am not a psychologist btw, sorry if it's too much in that direction... biggrin.png