Messages

1

Design / Re: Nonstandard Attack Option

« on: December 17, 2015, 08:36:34 PM »

I definitely like the idea of monsters being able to learn player's patterns. It doesn't feel natural when I can get the AI to fall for the same trick every damn time.

2

Design / Re: Nonstandard Attack Option

« on: December 16, 2015, 09:18:53 PM »

@Krice: We get it. You know more than any of us can ever hope to about the right way to do roguelikes, your game, once you finally let anyone see it, will be better than anything else ever written, and the rest of us are morons. You've made that point many times, we get it.

But could you give new folk a chance to get settled before forcibly indoctrinating them with this wisdom?

@mekaerwin: I can't try the prototype easily, since I have Linux at home and Mac at work -- no easy access to Windows.  To be honest, I'm having a hard time imagining a P/R/S mechanic that I wouldn't simply find annoying -- but the, I find P/R/S annoying, so I'm probably not the intended audience. But, who knows? You might find a way to make it more interesting than what I'm imagining.

I thought I would give each mob a set of preferences (probabilities) to which action it would use but give it an ability to partially modify those preferences to what it has observed the players pattern as.

This does sound like an interesting programming problem, though.

What I'm trying to achieve is give the player an ability to learn monster patterns, but at the same time balance exploiting those with creating a player pattern the monster can exploit. I

I don't think I'm quite getting what you mean here. So the player wouldn't be free to chose round by round, but will need to have a pattern that they are limited in how much they can vary from? I'm having a hard time picturing what this looks like from the player's POV.

3

Development Process & non-technical / Re: Dungeon generator protoype

« on: December 19, 2014, 01:44:17 AM »

Very nice!

4

Programming / Re: How big is your Level class/file?

« on: December 14, 2014, 03:50:35 PM »

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

5

Design / Re: creating compelling monsters

« on: December 13, 2014, 08:00:14 PM »

I've had monsters talk to each other, to good effect.

I been thinking about this and it seems interesting and fairly easy to implement once you have some basic ai effects like fleeing, targeting, and helping allies. Alerting others is a good start but what if powerful or intelligent creatures could say things to affect the morale of nearby monsters ("It's no use, he has heavy armor!" to increase the chance of monsters fleeing or "Looks like she's running low on mana!" to make monsters less likely to flee) or change their tactics ("Use ranged attacks!" or "Support me, I'm going in!")? So a pack of orcs would be troublesome but a pack of orcs with an Orc Commander who shouts intelligent hints at allies would be much more troublesome because the entire group would be smarter.

I really like this idea. The game I've been working on, I've been looking at ways of making the creatures behave in more complex ways, including their interactions with each other -- I think I may have to steel this idea .

The AI system I'm designing right now chooses creature actions in two parts -- first, a "goal" is chosen (go get that food, get out of here there's too much danger, need to defend my territory from that intruder, I need to get that cool axe!....) based on what items and creatures (including the player) are in range, and the priorities for the particular creature. Then the steps needed to reach that goal are set, including the pathing.

Nothing groundbreaking, but this is my first RL.

6

Programming / Re: How big is your Level class/file?

« on: December 12, 2014, 04:28:48 AM »

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?

7

Programming / Re: How big is your Level class/file?

« on: December 11, 2014, 02:09:30 PM »

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?

8

Programming / Re: How big is your Level class/file?

« on: December 10, 2014, 06:32:36 PM »

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.

9

Programming / Re: How big is your Level class/file?

« on: December 10, 2014, 03:17:53 PM »

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!

10

Programming / Re: How big is your Level class/file?

« on: November 24, 2014, 08:09:04 PM »

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?

11

Programming / Re: How big is your Level class/file?

« on: November 23, 2014, 06:52:42 PM »

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.

12

Programming / Re: How big is your Level class/file?

« on: November 23, 2014, 01:54:01 PM »

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?

13

Programming / Re: How big is your Level class/file?

« on: November 20, 2014, 11:09:11 PM »

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

14

Programming / Re: How big is your Level class/file?

« on: November 19, 2014, 09:18:34 PM »

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.

15

Programming / Re: D language - class

« on: November 16, 2014, 11:53:26 PM »

(Derp -- hit "quote" instead of "Edit")