Temple of The Roguelike Forums
Development => Programming => Topic started by: Krice on August 13, 2010, 04:07:49 PM
-
How big is your biggest file? I was thinking to combine all three .cpp files of Creature class (in Kaduria) but it would be 3134 lines then. That's too big. Currently the biggest file is level.cpp (2225 lines) but I have Level class in four different .cpp files, so together they would be really huge.
-
Monsters.cpp - 8581 lines
-
Monsters.cpp - 8581 lines
Is that a major roguelike?
-
It's my 'Wizard's Quest'.
Monsters in wq are code driven.
I.e. each monster type is represented by a separated class.
-
each monster type is represented by a separated class.
Is it too much to ask why? I can't see any reason to do that. It's just generating a lot of classes with maintaining problems for sure.
-
Most monsters have unique abilities.
Some have special AI tweaks.
Stats of monsters are not fixed (depends on level),
and some monsters have dynamic stats.
I don't have any kind of maintaning problems :)
-
Yeah, but small things like that could be easily made data-driven. One day I was dreaming of full data-driven game object system (no inheritance and no switch-cases, just data) but that might not be possible unless everything is super generic.
-
Yeah, but small things like that could be easily made data-driven. One day I was dreaming of full data-driven game object system (no inheritance and no switch-cases, just data) but that might not be possible unless everything is super generic.
Well. If I add all special AI behavior into single AI method with lots of ifs... It will be really hard to maintain :)
It's not that I think that code driven monsters and items are superior to data driven.
After all wq is my first attempt to make a roguelike.
This method definitely works, and provides more than enough flexibility.
But adding new monsters, or making some global rebalancing is indeed cumbersome.
Most likely in my next rl I'll try to implement what your are talking about - fully data driven game.
But IMO that will require much more careful planing, and some complex tools, to work with data.
I don't want to start any new projects before I finish todo list of wq.
But after this I'll be glad to discuss data driven roguelike, if you are interested :)
-
6989 :D
PC PC only action.
It looks like I need to cut it. ::)
-
Software engineering rules of thumb say, 20 lines per method, otherwise try to split. 1000 lines per class, otherwise split.
My old prof said "A procedure must be short enough that I can see in one look what it's doing". At the time I felt this a bit a harsh requirement, but actually he was right. Having code in small, easy to understand pieces avoids mistakes.
Of course all rules have exceptions. But they come from good and bad experience.
-
As I know “20 lines per method” rule brings more troubles than profit.
-
Can you elaborate on that? I'm sure I get involved in such a discussion again, and it would be good to know more about the why's and how's :)
Edit: Personally I'd rather make a "one task per method" rule than a certain number of lines. If a method consists of several sub-tasks, better move those into their own methods. This is still very blurry, but generally what I try to do and it seems to help.
-
With functions the evolution seems to go like this: as a beginner you write very long functions trying to do everything. In intermediate level you make short functions out of everything and finally when you reach the master level you write functions only if it's called more than once (in basic classes, data type classes are different case..)
I think it's quite hard to avoid large classes in roguelikes.
-
The whole "20 lines per function" metric, as well as a pervasive use of design patterns, works well in an academic setting, where professors or peers might need to easily review your code or analyze it from an academic perspective.
In a professional or personal project, the criteria are different: 1) does it work? 2) is it efficient? 3) is it easy to maintain?, in that order-- and if you're the only one on the project, 3 ceases to be as important.
I personally find shorter functions harder to understand than longer ones, since they usually rely heavily on other function calls, which makes tracing the logic and debugging a bit of an adventure. As Krice mentioned, I will usually only split functionality out into a function if it needs to be called from multiple spots.
The overhead of a function call can be expensive if it needs to be called once per pixel, 60 times per second, for example, hence the old SDL trick of inlining screen buffer writes instead of using a function.
Ebyan "Nolithius" Alvarez-Buylla
http://www.nolithius.com
-
My Unit::receiveDamage and LevelGenerator::generate methods are about 800 lines each.
And I'm not quite sure that I can split them.
There is so much local variables, that splitting them will born really hairy methods.
IMO method/function can be as big as it needs as long as it is well commented and structured.
-
I personally find shorter functions harder to understand than longer ones, since they usually rely heavily on other function calls, which makes tracing the logic and debugging a bit of an adventure.
A good IDE helps with the tracing aspect. The method/function names bear semantics.
A method call "move_monsters" tells quite well what it does. A 20 line block of code which does it, doesn't tell so easily. So each called function has a name that speaks for itself, and basically lifts the whole thing onto a higher level.
I agree that the innermost loops of a pixel processing pipeline have different constraints. But still, many languages can inline functions, so you do not loose performance due to the split, and still gain the higher semantic level.