Hello
I have some troubles with structure of my game. I want to have about 30 types of buildings, so I wrote virtual class building, and for each type of building one derived class. I have all my buildings in one array called building_list. Problem is that every type of building has different functions. So it will be about 90 functions probably. I dont think, that its a good idea to have 90 virtual functions in base class building, but I dont know how can I avoid it. And I want to have all buildings in one array. Is it possible to do it somehow?
Thanks for answers.
5 replies to this topic
Sponsor:
#4 Moderators - Reputation: 4655
Posted 10 July 2012 - 01:54 PM
Of course you can separate your data in different ways more than just one single big class, but modelling the game in the language is not really flexible. What is the alternative to lots of members; lots of functions? At least the data members can be easily set dynamicallyfrom external sources so you can tweak eveyrhing as you like and create new building, units, weapons, monsters, player classes, cities and whatever by just poking around in a text file. Your alternative here would be to program them in the source code and recompile your whole game.
A better and more specific answer to your particular situation can perhaps be given if you describe your situation and what all you 30 types and 90 functions are.
A better and more specific answer to your particular situation can perhaps be given if you describe your situation and what all you 30 types and 90 functions are.
Edited by Brother Bob, 10 July 2012 - 01:55 PM.
#6 Members - Reputation: 846
Posted 13 July 2012 - 07:08 PM
You may be running into the M*N problem (a typical issue in OOP), with M being #buildings, and N #operations-on-buildings, and M*N being your code complexity.
A solution wouldn't be to go back to procedural programming (as someone noted: "What is the alternative to lots of members; lots of functions?").
Instead, consider a generic programming (GP) solution -- if there is a common algorithmic functionality to what you're trying to achieve, perhaps a few (instead of "lots") free-standing (i.e., not member) function templates parametrized on your building-type might be the way to go? In case of STL, this solution allowed to bring down code complexity from M*N (which would've been the case if the containers & algorithms were to be organized into a class hierarchy and distinguished when operated upon via virtual member functions -- the OOP way) to M+N (which is the case for generic container classes (no virtuals) operated on by generic (parametrized by container and/or iterator type) algorithms) -- so, arguably, that's a common way to deal with this problem :-)
See:
http://gsd.web.elte....cles/icai99.pdf
https://github.com/b...aph_library.pdf
A solution wouldn't be to go back to procedural programming (as someone noted: "What is the alternative to lots of members; lots of functions?").
Instead, consider a generic programming (GP) solution -- if there is a common algorithmic functionality to what you're trying to achieve, perhaps a few (instead of "lots") free-standing (i.e., not member) function templates parametrized on your building-type might be the way to go? In case of STL, this solution allowed to bring down code complexity from M*N (which would've been the case if the containers & algorithms were to be organized into a class hierarchy and distinguished when operated upon via virtual member functions -- the OOP way) to M+N (which is the case for generic container classes (no virtuals) operated on by generic (parametrized by container and/or iterator type) algorithms) -- so, arguably, that's a common way to deal with this problem :-)
See:
http://gsd.web.elte....cles/icai99.pdf
https://github.com/b...aph_library.pdf
Edited by Matt-D, 13 July 2012 - 07:10 PM.






