How big is your Level class/file?

[mcouk]

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.

[AgingMinotaur]

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

[Trystan]

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:

Code: [Select]

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:

Code: [Select]

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);
  });
}


[Trystan]

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?

[mcouk]

...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

[Krice]

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.

[Krice]

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.

[Trystan]

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.

[mushroom patch]

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.

[Trystan]

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.

[Kyzrati]

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.

[Krice]

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.

[LindaJeanne]

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?

[mushroom patch]

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. 

[Trystan]

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?