How big is your Level class/file?

[Krice]

In my roguelike projects the Level class, responsible for containing game objects and creating levels, seems to become big. In Kaduria it's about 4000 lines (.cpp file only, including all lines). I don't think it's that big, but.. I don't know how to break it to smaller pieces. Actually I have total of 31 files (classes) in the 'game world' context so not everything related to dungeon generation is in Level class.

Edit: I think we may have discussed this before, but let's do it again.

[LindaJeanne]

Personally, I don't like classes to get that monolithic; I have things broken down into smaller modules.

I'm still pretty early into my first Rougelike. But my Arena* class:

• Contains a numpy** array of Node objects. This represents the physical space
• Contains a networkx*** Graph connecting the same node objects. This forms the master navigation graph, that all other navgraphs align to.
• Keeps track of what Creature and Item objects have been added to the Arena, until they are removed or destroyed
• Ensures that the bi-directional pointers(Creature <---> Node the creature is in; (Item to the Node it's in, Node's list of Items it contain) stay in synch by handling all the calls to update them.

And that's pretty much it. I have a separate ArenaGenerator class (or rather, class tree) to do most of the dungeon generation -- the Generator class produces a two- or three- dimentional NumPy array of tokens, which is passed to the Arena constructor, which uses it as a blueprint to build it's own NumPy array of Nodes.  (
In general when programming, if a class starts getting too large, I check for additional responsibilities that can be decoupled from each other.

*name "Arena" chosen because it can describe either a traditional Rougelike level, or something less flat,  ala dwarf fortress.
** Yes, Python. I had never programmed anything in Python and wanted to learn, so I used learning the language to be an "excuse" to build my first Rougelike. Coming from more purely OOP languages, it's been an interesting shift learning the "Pythonic" way of doing things.
*** Initially tried to use graph-tools, but I couldn't get Python and Boost to play nicely together. I might try graph-tools again when I get further in the process, if it looks like the speed from the BOOST libraries will be neccesary.

[Xecutor]

My Level.cpp is small. Because it only contains methods for level manipulation.
DungeonGenerator.cpp is big.
And the biggest is Monsters.cpp. I don't know how can I split it.

[TheCreator]

There is nothing wrong about big files, as long as methods contained inside are not too long and are all well-named. Striving to split the contents to smaller pieces you might end up creating even a bigger mess. A separate class/file makes sense only when it is natural and obvious to be separate. If you don't see what you should move, do not move.

[reaver]

There is nothing wrong about big files, as long as methods contained inside are not too long and are all well-named. Striving to split the contents to smaller pieces you might end up creating even a bigger mess. A separate class/file makes sense only when it is natural and obvious to be separate. If you don't see what you should move, do not move.

Also, too many source files and your compilation performance will drop.
Finally, the grammar nazi in me screams in agony:
It's ROGUELIKE, not ROUGELIKE!
It's in the bloody name of the forum, top of the page, as well as the address bar!

Ahem, sorry for the outburst.

[mcouk]

When I see a class that is 500 lines or more I start to question the design of that class. That also goes for any methods that are more than just a handful of lines long.

For the last couple of months I've been reading through the source of various roguelikes and I'm shocked at how big some of the files can be -- one was almost 20K lines long. Yikes! We have a saying where I come from; "code is written once, but read many times."

Considering that many roguelikes take years to complete it's quite unlikely you'll remember exactly how all your code works, so you're going to be spending considerable time reading through what you previously wrote. Traversing a ten thousand line file trying to find where you think that piece of code is is not what I'd call an enjoyable pastime.

The basic rule of good OOP is that each class/method should have a single responsibility. Admittedly, that's a bit trickier in something such as dungeon generation, but any code with tightly related functionality could be split out into its own class. Methods that are dozens/hundreds of lines long should be extracted into smaller methods then where appropriate, extracted into additional classes or modules.

Arguments which state that many files end up creating a bigger a mess are in my eyes incorrect. In the worse case scenario, you're just moving the mess around. However, once we encapsulate related functionality we start to better understand what our code is doing, regardless of how many files that creates. I would agree though that having your 'src' directory containing thousands of files is going to be unwieldy so the answer to this is to create a proper directory structure. An example could be something like;

Code: [Select]

  /src/levels.cpp
  /src/levels/doors.cpp
  /src/levels/traps.cpp

Over the last few months I've been working through a book about refactoring and this more than anything has helped me better understand how to break code up into more manageable chunks. I highly recommend you take a look at "Refactoring: Improving the Design of Existing Code" by Martin Fowler (http://martinfowler.com/books/refactoring.html).

[Krice]

For the last couple of months I've been reading through the source of various roguelikes and I'm shocked at how big some of the files can be

Well, did you ever write a roguelike? I'm interested to hear about real life examples and also know how many lines exactly you have on something like dungeon generation.

The level class in Kaduria has game object lists and an instance of map which itself is multi-layered and a class of its own. Still, I feel like I have to control map and objects in the same class (Level). It could be possible to move creation on another class, but then you would have to somehow access both map and objects, because the map has game objects and terrain both.

[mcouk]

Well, did you ever write a roguelike? I'm interested to hear about real life examples and also know how many lines exactly you have on something like dungeon generation.

Apologies Krice, I misunderstood your original post. When you said;

I don't think it's that big, but.. I don't know how to break it to smaller pieces  ....  I think we may have discussed this before, but let's do it again.

I understood that as you wanting thoughts and ideas on how one goes about reducing the size of classes. Those we're my thoughts.

I still highly recommend the Refactoring book. Martin Fowler has a site where he's put up the basic catalog outline; it may give you some ideas. http://refactoring.com/catalog/

[LindaJeanne]

I second the recommendation for the Refactoring book; it is excellent. (Also the earlier Design Patterns book, which Fowler was also a co-author on.)

[Kyzrati]

I agree with TheCreator in that file size doesn't matter so long as classes are subdivided into enough methods (or in some cases class-type members) that make sense.

I have more than a few cpp files of at least 5000-6000 lines each, and I love it. All the file contents are organized into clear sections that are also described and organized in the header file, where it's pretty clear what each section is responsible for. Further spitting all those features into separate classes and files would result in a massive number of files and be extremely annoying (for me) to work with. I can work much more efficiently with large files that contain everything related to a particular feature, even if said "everything" is a lot of stuff like what's required to build a map.

To Krice's question, in Cogmind the main class for adding content to a level and maintaining it is 5,600 loc, while the generation of the layout itself is a completely separate class at 3,000 loc.

[Trystan]

My creature and dungeon generation classes are usually the largest at around a few hundred lines ^[1]. I'm okay with that since any complicated things are usually delegated to other objects. If I have items or actions or ai stuff broken out, those are usually very small - generally 10 to 50 lines maybe.

I prefer not to take file size too seriously and instead think about how many concepts are in each method/class/file. Splitting things into a bazillion little files can make the interactions hard to reason about and make it difficult to see at a glance how things work and what my changes will affect (for me at least). Keeping everything in one huge method where control bounces up and down and in and out and a bunch of variables are changing everywhere can make it impossible to know what's going to happen and what my changes will affect (for me at least).

I think it's far more subjective and personal than people want to admit. Especially on a one-person project. Try different things; do more of what seems to help; do less of what seems to hurt.

The basic rule of good OOP is that each class/method should have a single responsibility.

That's true of all code^[2], OOP or not. The subjective part is what constitutes a single responsibility. I don't agree with the "have one and only one reason to change" definition but some people really like that.


[1] - For PugnaciousWizards2, counting whitespace, comments, curly braces, and all:
    WorldGen.as = 448 lines
    Creature.as = 262 lines
    Spell.as (the base spell class) = 13 lines
    Telekenesis.as (the largest and by far most complex spell and creature ai) = 104 lines

But that's ActionScript so the OOP boilerplate, whitespace, etc means that the smaller files are mostly not code.

[2] - Unless performance, policy, etc, are more important

[Krice]

I second the recommendation for the Refactoring book; it is excellent. (Also the earlier Design Patterns book, which Fowler was also a co-author on.)

I've read Design Patterns and I really hate that book and concept of patterns. It's like always in textbook examples which in no way can be applied in all real life situations.

[Krice]

My creature and dungeon generation classes are usually the largest at around a few hundred lines

Not a roguelike?

[TheCreator]

I've read Design Patterns and I really hate that book and concept of patterns. It's like always in textbook examples which in no way can be applied in all real life situations.

The same thing applies to the Fowler's book, unfortunately. I'd love to see that guy refactoring a "real life" code. However, the very idea of refactoring before adding any new features is always worth considering. Or, at least, you can no longer say you don't have time for refactoring .

http://i.imgur.com/IrMHHWE.jpg

[Brokenkingpin]

4000 lines really is on the large side. It sounds like it has become a dumping ground for logic that maybe should be contained in separate classes.