Temple of The Roguelike Forums
Development => Programming => Topic started by: Krice on November 19, 2014, 05:16:40 PM
-
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.
-
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.
-
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.
-
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.
-
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.
-
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;
/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 (http://martinfowler.com/books/refactoring.html)).
-
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.
-
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/ (http://refactoring.com/catalog/)
-
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 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.
-
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
-
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.
-
My creature and dungeon generation classes are usually the largest at around a few hundred lines
Not a roguelike?
-
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
-
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.
-
I prefer not to take file size too seriously and instead think about how many concepts are in each method/class/file....
...I think it's far more subjective and personal than people want to admit.
Agreed.
I know nothing about ActionScript, and only spent a handful of minutes looking over PugnaciousWizards2, but it was very easy going. I was able gain some basic understanding of what was going on very quickly, and left feeling like I'd perhaps want to spend a couple of hours on a code reading session with it.
Not a roguelike?
I don't see how that affects what makes good/bad code.
-
My creature and dungeon generation classes are usually the largest at around a few hundred lines
Not a roguelike?
Ahem:
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
As always,
Minotauros
-
Not a roguelike?
Mostly I've written 7DRLs and proof-of-concepts so I can try a new programing technique or gameplay idea. I do have a potentially larger roguelike in the works but no public code yet. Either way, I think most people would call PugnaciousWizards2 a roguelike.
I have noticed that once I get beyond the standard roguelike stuff like movement, combat, and level building, most of the new content is in new files or methods. Moving the details of your game into subclasses and functions that are passed around makes it easier to add details and content without cluttering the code that has the overall logic and flow.
For example, I've been putting the ai related to casting spells in the spells themselves and the spell casters just loop through their spells and ask for a function to actually cast the spell.
Here's the general spell caster ai at the beginning of the enemy ai that chooses which spell to cast or continues to the movement logic instead of casting a spell:
if (canCastMagic)
{
for each (var spell:Spell in magic)
{
var action:SpellCastAction = spell.aiGetAction(this);
if (Math.random() < action.percentChance)
{
action.callback();
return;
}
}
}
Here's specific spell caster ai within the HealAndWeaken spell that knows when and how to use this specific spell:
public function aiGetAction(ai:Creature):SpellCastAction
{
var chance:Number = ai.maxHealth > 10 && ai.health < 15 ? 80 : 0;
return new SpellCastAction(chance, function():void
{
cast(ai, ai.position.x, ai.position.y);
});
}
-
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.
Interesting. Mind sharing some code that is impossible to improve through refactoring?
-
...Also the earlier Design Patterns book, which Fowler was also a co-author on.
This is the third time is as many weeks I've heard this book mentioned. I may have to check it out.
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.
It's in fact the opposite; these are often inspired from real life situations. You should take a look at Game Programming Patterns by Bob Nystrom. You don't even have to buy it, he's made it available to read online for free. http://gameprogrammingpatterns.com (http://gameprogrammingpatterns.com)
-
Mind sharing some code that is impossible to improve through refactoring?
In a way I have been refactoring Kaduria from 2005. Next.. question. Well, to be honest, everything can be refactored, but in some point you have to put your hands up and start to write the actual gameplay content. I have been in that position for a long time now, but I have bad habit trying to improve the source code.
I also believe that when the class is big it's big. There is not much you can do about it without creating bunch of classes which then cumbersomely send messages back and forth. The total amount of code is possibly going to be the same or even more and it's just going to be slower with all that sending.
-
Mostly I've written 7DRLs and proof-of-concepts so I can try a new programing technique or gameplay idea.
I'm sorry but this has little to do with roguelikes and large scale projects. There are many reasons why Level is 4000 lines in Kaduria and one of them is not that it's bad source code.
-
Mostly I've written 7DRLs....
I'm sorry but this has little to do with roguelikes and large scale projects. There are many reasons why Level is 4000 lines in Kaduria and one of them is not that it's bad source code.
...did you just say that writing roguelikes has little to do with writing roguelikes? Some of your views are... um... unconventional to put it politely but that's just baffling.
I choose to write roguelikes with a small codebase in my spare time but I've worked on large scale projects too. A 15 year old FoxPro project, a C# project with about three million lines, large ruby projects that have had dozens of developers over the years. Hell, I once inherited codebase that had a single method that was over 3000 lines. And all of those projects were in active development, making real world money and solving real world problems while having new features added and being refactored at the same time. Finding the balance of refactoring and moving forward is not always easy and it's not always obvious but it is possible.
If you focus on avoiding large files you will probably avoid large files. If you choose to write large files, then you will probably write large files. There are proven techniques that you can use to change the shape of your code but you have to actually do the work. Besides; like I said earlier, large files are not inherently bad on a single person project.
-
Eh, it's true: People wildly overrate the value of 7DRL projects. They're roguelikes only by an absurdly reductive definition. The concept is a conceit at best that trivializes the classics.
Oh, but sorry to derail Krice's thread about how his game no one has ever played is the most sophisticated roguelike, the sheer ambition of which should command awe and respect. 4000 lines of level code says it all. Imagine: Just standing in one of Krice's dungeons, you are riding 50 pages of the mostly finely crafted C++, coded by a true maverick and visionary. I mean, if you could stand in one of those dungeons. Someday when it's ready, nay, when the world is ready, you may stand there and marvel.
-
Eh, it's true: People wildly overrate the value of 7DRL projects. They're roguelikes only by an absurdly reductive definition. The concept is a conceit at best that trivializes the classics.
I guess it depends on what you mean by "the value" but I think most people underrate the value of writing a 7DRL.
This is the programming subforum so I assume you mean the value to programmers. For one thing, it forces you to write code that allows new features to be added in a short amount of time without becoming too messy. And I only have a week - I can't put things off for next month or some other day. I can try a new language or architecture or technique without getting tied to it. Doing so much in such a short amount of time requires some skill and I learn a lot and improve as a programmer each year.
I really don't understand why people are so dismissive of 7DRLs. There's always a few duds, but each year has some real roguelike gems too.
Oh, but sorry to derail Krice's thread about how his game no one has ever played is the most sophisticated roguelike, the sheer ambition of which should command awe and respect. 4000 lines of level code says it all. Imagine: Just standing in one of Krice's dungeons, you are riding 50 pages of the mostly finely crafted C++, coded by a true maverick and visionary. I mean, if you could stand in one of those dungeons. Someday when it's ready, nay, when the world is ready, you may stand there and marvel.
Lol. So true. I've read many of his blog posts and I'd like to see his game in action but I doubt that will ever happen.
-
I really don't understand why people are so dismissive of 7DRLs.
This is not a common sentiment. The vast majority of people I know love and enjoy 7DRLs for their creativity and ability to explore the genre.
-
If you choose to write large files, then you will probably write large files.
You don't know what you are talking about. You are an example of a programmer who is poking roguelike genre with 7DRL projects, but it really afraid to go deeper into creating actual roguelikes, and is at the same time refusing to accept that small and large scale roguelikes are totally different kind of projects.
Guys like you have a programming background, usually working on projects other than games. Then you think game programming is easy. Yes, it's easy if you work only on concept projects like 7DRLs. I'm always laughing when these people start to realize how things are, but then step back and become afraid.
-
There's also value in the way 7DRL force you to complete a project, rather than give into the temptation for endless tinkering -- to make the hard decisions about what's really essential.
7DRL and more in depth projects are both roguelikes, and both give valuable -- if different -- programming experiences.
But then, I've always been irritated by "more a programmer than thou" attitudes. Shall we have a vim vs emacs flamewar while we're at it?
-
You know, Krice, given how deeply you seem to be immersed in the craft of the roguelike, it is surprising to me how little substance appears in your threads. I would think someone like you would have a lot of ideas about algorithms, data structures, implementation of artificial intelligence, environment generation, combat mechanics, and every other aspect of what would make a truly modern roguelike tick. I would think your threads would be full of things I had never thought of, ideas to ponder, or at least discussion and implementation of things I had thought of that I think are interesting.
Instead, what I see is generalities about programming I would expect from a typical commenter on a general interest tech blog, airy scepticism about any notion in programming that isn't in C++ books written in the 90s, constant references to your own project in ways that are transparently intended to suggest its superiority, and petulant responses to justified scepticism about your project and your interactions with other people. Yes, programming games of a certain scope is hard. That doesn't mean you get a lot of credit for trying. Many people here have done the same but don't feel the need to beat their drum about it constantly.
If you want people to take you seriously, which I doubt, but anyway, if that's something that interests you, either make a release or, maybe even better, post about aspects of your work that are actually interesting, that have some depth and show some insight. I would call your threads a combination of uninformed drivel I could get in a Slashdot comments section and obnoxious one-upmanship, but it's not even one-upmanship, rather some kind of pretense to it.
-
Is there a point to this thread Krice? I thought it was a genuine question about programming with several good replies, even sharing some techniques that people have found useful, but you've dismissed it all. Even when I agree with you, you dismiss what I say and just start making shit up about me, even saying that I'm "afraid" of writing roguelikes because I actually finish the roguelikes that I set out to write.
Why did you ask the original question in the first place? Are you looking for people's actual answers? Are you looking for a specific answer? Do you actually believe you're some sort of courageous lone genius and everyone else's real world experiences don't apply to you?
-
I thought it was a genuine question about programming with several good replies, even sharing some techniques that people have found useful, but you've dismissed it all.
I don't think there was a good advice how to split a class where everything seems to be connected anyway. I try to be open for new ideas and be a less dork, but it's difficult... I become defensive fast when people don't have experience from programming large scale roguelikes.
Another thing is that should you split classes when they become "too" big. If so, why? What is the "limit" of lines of source code per class?
-
[Redacted]
-
I don't think there was a good advice how to split a class where everything seems to be connected anyway.
I'll address this for the sake of others who find this thread while genuinely looking for answers -- but I'm under no illusions about what you will think of me or my reply.
One of the reasons you haven't been getting more concrete answers is because you're asking a very abstract question. I can't know whether or how to break up your level class, because I have no idea what it contains.
But the general answer to the general question of how to break up a huge class "when everything seems to be connected anyway": you need to take a step back and look at it from an architectural perspective. What is coupled due to a genuine need for coupling, and what just sort of ended up that way? Obviously, everything IS connected to everything else in some fashion, or it wouldn't be a single program. But there is flexibility in how tightly things are connected, and in what is connected to what, and where those connection points are.
As an example, I have a separate class for generating the "blueprint" of a level. It handles all the procedural level level generation code, and creates an array with the results. That array is then passed to a different class which uses the array as a blueprint for actually building the level. This second class then keeps track of the locations of things during gameplay.
It would be easy to say that "deciding what to put where" and "putting it there" are too tightly coupled to separate without causing even more complexity, but I have found that not to be the case.
One technique that I've found is helpful for finding hidden/unnecessary couplings is writing unit tests, because this helps you think about smaller more isolated pieces of code.
Like everything else, design patterns and refactoring can be used badly, and make more of a mess out of code than it was before. But that's true of any programming technique, and doesn't happen when the technique is used properly & when appropriate. What makes structuring large bodies of code difficult is the need to simultaneously look at the big picture of the whole, and also the smallest decomposable parts at the same time.
Another thing is that should you split classes when they become "too" big. If so, why? What is the "limit" of lines of source code per class?
It's not the number of lines that's significant, it's the amount of work the class is doing, and what responsibilities it has.
-
I don't think there was a good advice how to split a class where everything seems to be connected anyway. I try to be open for new ideas and be a less dork, but it's difficult... I become defensive fast when people don't have experience from programming large scale roguelikes.
There's excellent advice on splitting large files; separating concerns, refactoring, real world examples, etc. You have to actually do it though. If you want to change your code you have to change what you're doing. Like Einstein said: "We can't solve problems by using the same kind of thinking we used when we created them."
The principals of good programming within a large codebase are the same regardless of the product. If you are determined to dismiss anyone who doesn't have 4000 lines of C++ Level code then you're missing out on a lot of good advice and only hurting yourself for no good reason.
Another thing is that should you split classes when they become "too" big. If so, why? What is the "limit" of lines of source code per class?
Ultimately the reason for any programing technique, principal, or practice is to reduce the cost or risk of future changes. Clean code takes less time to add new features and is less likely to acquire bugs when changed; messy code takes more time to add new features and is more likely to acquire bugs when changed. Code that has high cohesion and low coupling is generally considered clean and good; code that has low cohesion or high coupling is generally considered messy and bad. There are a ton of good books, presentations, and blog posts out there on this stuff - you should check some out.
There's not hard "limit" - it's not like 1000 lines is good and 1001 lines is bad. It's more about the concepts and responsibilities than line numbers. No one can give specific advice about your code unless they see what you're asking about but it seems like there's several people who would help.
-
I become defensive fast when people don't have experience from programming large scale roguelikes.
sensiblechuckle.gif
Man, you ought to be a lot more gracious with the people who are humoring you in this thread.
-
What experience do you have of programming roguelikes?
You must be new here. I have experience from year 1995 when I started to program a next generation roguelike. Apart from studying in 1998-2001 it's been practically continuous development. The project (Kaduria) has about ~500K lines of code. Now.. show me your roguelike (doesn't have to be released) that has ~500K lines of code. Then we can possibly talk more about things.
-
If you are determined to dismiss anyone who doesn't have 4000 lines of C++ Level code then you're missing out on a lot of good advice and only hurting yourself for no good reason.
I think I'm going to keep what I have. I'm estimating the final size of Level can be a lot more than 4000 lines. Maybe something like 6000 with town generation routines.
-
You must be new here. I have experience from year 1995 when I started to program a next generation roguelike. Apart from studying in 1998-2001 it's been practically continuous development. The project (Kaduria) has about ~500K lines of code. Now.. show me your roguelike (doesn't have to be released) that has ~500K lines of code. Then we can possibly talk more about things.
“Measuring programming progress by lines of code is like measuring aircraft building progress by weight.”
― Bill Gates
-
What experience do you have of programming roguelikes?
You must be new here. I have experience from year 1995 when I started to program a next generation roguelike. Apart from studying in 1998-2001 it's been practically continuous development. The project (Kaduria) has about ~500K lines of code. Now.. show me your roguelike (doesn't have to be released) that has ~500K lines of code. Then we can possibly talk more about things.
If you're only interested in hearing from people who have worked on a single roguelike for 20 years, why not just email the ADOM guy? I think he's the only one who fits that description. He's actually had releases, too, so I'm sure you could learn something from him if you don't make up ridiculous excuses not to.
-
Krice,
Why did you start this thread anyway? It wasn't out of interest in having a discussion, or you wouldn't be so dismissive of everyone who tries to participate. It wasn't in the hope of learning anything, since your coding skills are so superior to what any of the rest of us could ever hope to be. So I'm confused: what did you hope this thread would become?
-
If you're only interested in hearing from people who have worked on a single roguelike for 20 years, why not just email the ADOM guy? I think he's the only one who fits that description. He's actually had releases, too, so I'm sure you could learn something from him if you don't make up ridiculous excuses not to.
I think ADOM's code is still old school C. Must be pain to maintain. He is actually talking about message routine refactoring in the newest blog post (I'm following ADOM blog) and it's just as you would think, it's even difficult to create a new message routine in gui, because the old is so hard coded (not cleanly modular). I know how it is, I have those same problems myself, but maybe not that bad, because since 2005 Kaduria has been mainly class-based. Although it's possible to create poor connections between classes as well, breaking something when another class is refactored.
But then again what would I learn? ADOM is not a next gen roguelike, it's nowhere near it. It's actually very old school, resembling mostly Nethack, but just has more everything. What would I learn from that or the fact that he is having constant problems with poorly written and hard to maintain C source code? Now he has like four or something guys helping him and it still seems to be difficult to add new features in the game. It's the reality in -actual- roguelike development. Not in theory or with 7DRL "roguelikes".
-
"How big is your X?"
That's the question he asks. His answer: "real big." It is completely obvious what this thread is about and why he started it. "Your X isn't as big? You think the size of X doesn't count? Well, I don't have time for people who haven't been working their X for 20 years."
It's just lame-ass trolling from Krice as usual. Confused? Just stop pretending his game exists and everything makes sense.
-
Why did you start this thread anyway?
I'm not so sure now. I realized no one here knows what I'm talking about. Could it be really that depressing?
-
Just stop pretending his game exists and everything makes sense.
You know, that's a bit old joke isn't it. I've heard it so many times.
-
Some jokes never get old. They're funny because they're true.
-
Krice, can you show us just a screenshot of all the Kaduria source files in their directory structure, with just file names and sizes? I'm genuinely curious as to what goes into a massive 500k loc roguelike project as big as many AAA games. I just want to see the files and how you've organized them--not source itself, mind you, just the files.
ADOM only has about 200k, by the way, so I've no doubt you've got everyone beat by a pretty wide margin.
-
Have you looked at code for any roguelike? Or any large project? Or any good code? You can learn a lot. You may want to try it.
I did a quick and dirty line count[1] check of how much code a few of the popular classic roguelikes have.
Dungeon Crawl Stone Soup 0.15.2 has 2,021,779 lines in "source". The largest files looked like definitions for monsters etc.
The latest Angband from github has 237,698 lines in "src". The largest files were "main" files and seemed to have a lot going on.
Nethack 3.4.3 has 134,313 lines in "src".
Brogue 1.7.44 has 39,284 total lines in "PlatformCode" and "BrogueCode". Most of it was core brogue code, not platform specific.
[edit]
Slash'EM Extended has 162,333 lines in "src". I don't know of any roguelike that has as much content, as many interactions, and as much gameplay complexity as what I've read about this game. It's dungeon.c file, which I imagine is the closest to your Level file, is 1,771 total lines.
If your codebase has 3 times as much well-written code as that then you should immediately do a beta release of your game. I'm sure it will become an instant classic and make the most beloved roguelike look like a boring and simplistic game for toddlers. I'm not even being sarcastic here - I'm 100% serious. If your game is as groundbreaking and breathtaking in scope, complexity, and elegance as you claim it is then you'd be a huge jerk for not sharing it.
[/edit]
[1] ( find ./ -type f -print0 | xargs -0 cat ) | wc -l
-
Dungeon Crawl Stone Soup 0.15.2 has 2,021,779 lines in "source". The largest files looked like definitions for monsters etc.
Damn. That's 10 times as much as ADOM, but I'll never believe it's 10 times more complex. I'm going to analyze this more thoroughly today, these numbers truly shocked me.
-
If your codebase has 3 times as much well-written code as that then you should immediately do a beta release of your game.
It's not ready yet. Line count doesn't tell everything, because how data is handled. Some games have lot of external data (Angband for example) and other include data in the source code. I like to include data in the source code, I'm not a big fan of scripting data. Almost all data is in the source code, except of course tiles and other graphics.
Another big factor is the game engine vs. "hacking" approach. With good game engine you can reduce the amount of source code to handle complex stuff. However it often means more time spent on writing the game engine. Kaduria is somewhere between full game engine and hacking.
-
Krice, can you show us just a screenshot of all the Kaduria source files in their directory structure, with just file names and sizes? I'm genuinely curious as to what goes into a massive 500k loc roguelike project as big as many AAA games. I just want to see the files and how you've organized them--not source itself, mind you, just the files.
500K is not that big.
http://koti.mbnet.fi/paulkp/temp/filelist.txt
-
Thanks, organization looks rather typical, actually, with relatively small file sizes compared to what I thought you might be implying for the project as a whole. (For comparison, my latest project has 30 files over 30 KB, 6 over 100 KB.)
But unless I'm missing something, without the VS project-related files, the pure source on that file list is just a few megabytes, which can't possibly hold 500k loc. More like 50k. So where's the rest of the source?
-
Some quick stats, just for fun.
Given the file hierarchy text, I quickly ran a python script to count size of source data in bytes (http://pastebin.com/5UytpuhS (http://pastebin.com/5UytpuhS))
It came up as 1072070 bytes, AKA a megabyte of pure source.
My infant roguelike project at the moment (nothing particularly big) is 867041 bytes, and 28267 lines of code.
My style is not verbose. I've seen Krice's style, it's not verbose either.
So there you go. Assuming that the hierarchy given is all there is, and a linear relationship between my proj size and Kaduria, Kaduria is at approx. 36K lines of code. Not 500K.
-
I had a feeling that something is wrong. And it's not even 50K, it's 48K.
-
48k lines of code isn't much to show for 20 years of continuous development, someone with an unreleased 500k line superproject should give you some tips
-
Okay... good thread, guys. Clarifying.
Krice, I hope you've gained a useful perspective here. Your efforts, though commendable in their persistence, are actually fairly ordinary. Lots of people here have written a bunch of code without reaching what they consider a finished product or even something worth releasing. A lot of them have done so in a much more reasonable amount of time too.
You should also understand that people here are sceptical about your claims about things because your commentary often seems pretty clueless. For example, I doubt anyone else here would have such a tenuous intuitive grasp of the difference between 50k and 500k lines of code that they would make an incorrect claim like yours in public. Most people here can probably name well known open source projects with codebases of these sizes off the top of their heads and immediately get a feel for the plausibility of your claims...
-
48k lines of code isn't much to show for 20 years of continuous development
I'm not that sure. It must be more engine/data-driven than I thought. Like I said, you can't say much from the size itself, even so because Kaduria is C++ with data-driven style (less code compared to procedural style). What is interesting is how the size will grow now that I have started to "hack" content in the game.
-
Like I said, you can't say much from the size itself, even so because Kaduria is C++ with data-driven style (less code compared to procedural style)
Now.. show me your roguelike (doesn't have to be released) that has ~500K lines of code. Then we can possibly talk more about things.
Funny how only now that it's out you don't have 500k lines, size doesn't matter.
But honestly, the fact you've been working on something for almost 20 years without a release says more about it than any amount of code ever could. You could be the greatest programmer in the world, but if you can never finish your projects it doesn't even matter.
-
Krice is the Cleve Blakemore of roguelikes only not quite crazy enough to be interesting
-
But honestly, the fact you've been working on something for almost 20 years without a release says more about it than any amount of code ever could.
It doesn't say anything about the game. Leonardo Da Vinci was a known procrastinator, he sometimes spent years in one painting, started projects he never finished etc. Yet we now think he was a genius. I know how it is, because he was not good at just one thing, but was interested about many things.
-
How can someone make it to your advanced age and still, apparently without irony, draw such ludicrous comparisons?
-
I'm laughing so hard I think I might swallow a tonsil. This thread is GOLD.
-
How can someone make it to your advanced age and still, apparently without irony, draw such ludicrous comparisons?
I don't know, comparing the world's greatest renaissance man to a depressed, Scandinavian dude who has spent 20 years not releasing an esoteric and unpopular computer game seems pretty legit to me
-
I'm just yanking your chain Krice, I am with you all the way and go to sleep every night with your words of wisdom running through my thoughts:
We roguelike developers are the jedi knights of programmers. The task of making a roguelike is everlasting battle against the dark side of commercial games. Only knights with true devotion will last in that battle! Join us and together we will rule the galaxy!
-
Dungeon Crawl Stone Soup 0.15.2 has 2,021,779 lines in "source". The largest files looked like definitions for monsters etc.
These numbers looked so unbelievable to me that I had to check that. I used a 'real' tool, not the wc command, so I could count actual code lines, not just lines. I excluded the 'contrib' directory, which contains external libraries. Here are the results:
* 61836 lines (with LUA files)
* 48561 lines (only C++)
-
Dungeon Crawl Stone Soup 0.15.2 has 2,021,779 lines in "source". The largest files looked like definitions for monsters etc.
These numbers looked so unbelievable to me that I had to check that. I used a 'real' tool, not the wc command, so I could count actual code lines, not just lines. I excluded the 'contrib' directory, which contains external libraries. Here are the results:
* 61836 lines (with LUA files)
* 48561 lines (only C++)
Neat. I didn't know there were external libs included and I figure the definition files had a lot of comments so it's good to see the numbers match the other roguelikes. Thanks for getting better stats for this.
-
* 61836 lines (with LUA files)
* 48561 lines (only C++)
Kaduria has currently 48810 lines of C++.
-
Wow, you mean kaduria is better than crawl? You should release it!
-
Wow, you mean kaduria is better than crawl?
It's going to be, I hope. The problem with both Crawl (Stone Soup) and Tome is that they try too hard and they do it the wrong way. You know, there is plenty of "everything" stuffed in but it makes boring and unfocused gameplay where you just bash everything.
-
-______________________-
-
Any technical issues aside, developing completely in a bubble, without player feedback, will most likely be detrimental. Should probably release a current, stable build and see how that goes.
-
The real question here is: What would Leonardo Da Vinci do?
-
Kirce, what makes your program "next-gen" and (hopefully) better than those others? So far I've only seen you say what you dislike about the others, but I haven't seen you say how your program does things better.
Kyzarti -- great, now I have the following earworm:
what would L'n'ardo D'vinci do,
if he were here right now?
he'd make a plan and see it through
that's what L'n'ardo D'vinci'd do!
-
Kirce, what makes your program "next-gen"...?
It was started 20 years ago....
-
Kirce, what makes your program "next-gen"...?
It was started 20 years ago....
Earlier when ADOM was mentioned, he claimed that ADOM wasn't "next-gen" like his was. I'm wondering what it is about his game that causes him to refer to it as "next-gen" & more advanced than currently popular roguelikes.
-
I think the point is that he started in the 90s and that's what you called new things back then. At the time, ADOM wasn't new, hence not "next-gen."
-
Should probably release a current, stable build and see how that goes.
It's probably not a bad idea once there is a playable version. It would certainly follow the roguelike tradition where player feedback helps developers balance the game. I don't need actual ideas, because I have them already. I'm extremely creative person, a fact that you will find out.
-
Kirce, what makes your program "next-gen" and (hopefully) better than those others?
I'm in a odd position that I know what it is, but no one else doesn't seem to have an idea. Funny thing is that I knew it even back when I started programming Kaduria. Just imagine how strange it is that people have had all this time to make it first, but until now I haven't seen anything exactly like it. Developers still like to keep the traditional gameplay and feel of roguelikes. I guess it's ok, but it's not next gen.
I think Leonardo must have felt the same way. He must have been thinking "why no one else is doing what I do?"
-
So, you have no idea how your game is different from currently popular games, you just know that it is, somehow? If you don't know in what way it's different, then on what are you basing the conclusion that it's different?
-
Kirce, what makes your program "next-gen" and (hopefully) better than those others?
I'm in a odd position that I know what it is, but no one else doesn't seem to have an idea. Funny thing is that I knew it even back when I started programming Kaduria. Just imagine how strange it is that people have had all this time to make it first, but until now I haven't seen anything exactly like it. Developers still like to keep the traditional gameplay and feel of roguelikes. I guess it's ok, but it's not next gen.
I think Leonardo must have felt the same way. He must have been thinking "why no one else is doing what I do?"
I doubt that. People who actually do new and original work have a pretty good idea of where their work fits into the grand scheme of things, how it relates to other work that's been done and is being done by other people, and why and how their approach differs from everyone else's.
-
I give this thread 100 out of a possible 10.
-
So, you have no idea how your game is different from currently popular games, you just know that it is, somehow? If you don't know in what way it's different, then on what are you basing the conclusion that it's different?
At least he is making his idea. There are too many who sit on the sidelines and criticise, or post about how great their idea is and expect others to line up (without being told all the special details so they can't steal it) and work on it.
Krice you're bragging about stuff you can't or won't substantiate, which isn't a good characteristic, but good on you for making something.
-
So, you have no idea how your game is different from currently popular games, you just know that it is, somehow?
I think something was lost in translation. Of course I know the difference. I know everything.
-
So, you have no idea how your game is different from currently popular games, you just know that it is, somehow? If you don't know in what way it's different, then on what are you basing the conclusion that it's different?
At least he is making his idea. There are too many who sit on the sidelines and criticise, or post about how great their idea is and expect others to line up (without being told all the special details so they can't steal it) and work on it.
Krice you're bragging about stuff you can't or won't substantiate, which isn't a good characteristic, but good on you for making something.
I'm baffled by your Krice boosting. The obvious interpretation of his interaction here is that his game is a hoax, hence complete lack of specifics, lack of intelligent things to say about game design, lack of the usual indicators of active development, e.g. video, etc. etc. He contributes zero to threads about algorithms, beyond complaints about things being "too complicated" and telling confessions of being unable to get basic things right (e.g. not being able to keep rooms from colliding in dungeon generation). You would think someone who worked on these games for 20 years would have thought enough about these kinds of things that he'd have something to say about them.
What he does post is rather unsophisticated criticism (e.g. "crawl and tome are too big and do it wrong") and self-aggrandisement, such as this thread. He shows no interest in producing anything at all. He's interested in making comparisons between his probably nonexistent game and everything else, comparisons between himself and renaissance masters, etc. For whatever reason, he is constantly indulged here and in the predecessor newsgroups in spite of ample evidence that he's just some kind of obsessed troll.
I appreciate your perspective re: development and I totally agree Krice is under no obligation to release anything even if he does have a real game. But, if he does not want to release anything, then he has an obligation not to post constant, obnoxious comparisons between everything ever under discussion and his alleged game and creative genius. It's just pure trolling.
-
So, you have no idea how your game is different from currently popular games, you just know that it is, somehow?
I think something was lost in translation. Of course I know the difference. I know everything.
OK, I'll ask again then. What is it about your game that's different from currently popular rougelikes?
-
What is it about your game that's different from currently popular rougelikes?
I'm not going to reveal it, but if you have followed Kaduria's blog you may get some idea of it I guess.
-
It's just pure trolling.
How do you know that for sure? I find your lack of faith disturbing.
-
It's just pure trolling.
How do you know that for sure? I find your lack of faith disturbing.
If it looks like a duck, quacks like a duck, etc.
-
Your previous trolls were way more fun krice, you are becoming too blunt and obvious (more than you were I mean). Please up your game a bit, keep me entertained!
-
What is it about your game that's different from currently popular rougelikes?
I'm not going to reveal it, but if you have followed Kaduria's blog you may get some idea of it I guess.
From what I remember, the only gameplay related posts were about cave and dungeon generation algorithms not working how you wanted, several posts - many years apart - about bridge building algorithms that don't work, females can't be warriors, and some vague things about farming or plant growth.
So caves, dungeon rooms that can't be reached, bridges to nowhere, weak females, and possibly interesting plant growth.
Anything else?
-
I believe it was originally billed as "a roguelike with irregularly shaped rooms." Deep thinking from the beginning.
-
So caves, dungeon rooms that can't be reached, bridges to nowhere, weak females, and possibly interesting plant growth.
I think the dungeon generation works mostly and bugs can always be fixed. The hardest part is the structure of the level which means what kind of connections there are etc. When you work only on "classic" dungeons you don't have to think about that kind of stuff anyway. Bridge algorithm works very nicely now. Females are weak, it's called low fantasy (more realistic than high fantasy) and there will be a simulation of plant growth which actually makes interesting way to generate a level with plants plus there may be possibility for farming.
But those are only some minor details.
-
How do you know that for sure? I find your lack of faith disturbing.
20+ years, dude. I find your excess of conviction disturbing.
-
Normally I'd say not to worry about people stealing your ideas, because ideas are cheap, it's the work that's hard, and if you've already started you have a head start anyway.
But with a 20+ year development cycle, someone could legitimately steal your idea and make it before you do.
Of course, with a 20+ year development cycle, if your ideas are really that good, you probably owe it to the world to let someone else use them. Plus, by the time your game does come out, everyone will have moved on from the game that stole your idea decades ago anyway.
-
But with a 20+ year development cycle, someone could legitimately steal your idea and make it before you do.
Of course, with a 20+ year development cycle, if your ideas are really that good, you probably owe it to the world to let someone else use them.
No, world owes to me. Besides, Nethack's development cycle is 10 years more and we are still waiting for the new version. No one thinks it's odd.
-
Drawing comparisons between things that don't exist and things that do is a pretty empty exercise. For example, pink elephants are also like nethack in that they haven't had a release in ten years.
-
"How big is your X?"
That's the question he asks. His answer: "real big." It is completely obvious what this thread is about and why he started it. "Your X isn't as big? You think the size of X doesn't count?
I'm thinking this about sums it up.
-
Drawing comparisons between things that don't exist and things that do is a pretty empty exercise.
I don't know why so butthurt, but it will be all right when Kaduria is released.
-
Drawing comparisons between things that don't exist and things that do is a pretty empty exercise.
I don't know why so butthurt, but it will be all right when Kaduria is released.
No need. I hereby announce my own project, mushroom patch simulator (MPS). Mushroom patch simulator has the following advanced, next-gen roguelike features:
- Irregularly shaped rooms.
- Plant AND fungus growth features, including sentient flora. Imagine BEING the plant life.
- Bridges, both mushroom-based, normal yellow table cloth style, and a special bridge mode with suspension support and jumping fish that attack the player.
Of course, this is just a small sampling of what mushroom patch simulator offers. MPS offers the definitive roguelike experience, incorporating the most advanced concepts in roguelike development, 20 years in the making. Think of it as nethack if nethack hadn't had a release in 20 years. It's like double nethack. With mushroom patches.
Stay tuned for incessant updates on mushroom patch simulator thinly disguised as questions about programming and/or interest in the projects the rest of you are working on as well as favorable comparisons between MPS and other great works of the human mind. By the way, what does everyone think about using Visual Basic as the GUI engine for MPS?
-
You know, Kaduria also has mushroom which I plan to grow next to host plants.
-
If you look carefully, there's a mushroom in Vitruvian man too. Guess great minds think alike.