Haven 2.0: "Hafen"

[RubyRed]

Right niow for simplsities sake it should all be based off the user of the weapon not cover.

Not saying that does not mean cover items could not be made to protect people from arrows ect...

[Oddity]

Much sadface at the news that it will still be a few more months. But hopefully it will be well worth the wait:

(16:36:18) <loftar> Well. don't look for Hafen just around the corner, if that's what you're asking.
(16:36:45) <loftar> It's going to take a least a couple more months.
-
(16:38:57) <Oddity> Any new news about your progress?
(16:39:19) <loftar> Well, we've been working a bit on mining the last week or two.
(16:39:23) <loftar> We also added tanning tubs pack.
(16:39:27) <loftar> Sans their previous bug. ^^
(16:39:31) <Bergzwerg> are there still 5 levels?
(16:39:38) <Bergzwerg> or its a secret?
(16:39:43) <loftar> The number of levels is and always has been quite variable.
(16:39:49) <loftar> It's just a variable of the mapgen.
(16:39:59) <loftar> We could change it anytime we wanted to.
(16:40:00) <Bergzwerg> it relates to trolls and dragons
(16:40:41) <deus> dragons confirmed?
(16:40:45) <loftar> But there are new mechanics for ores, minerals and cave-ins. I look forward to seeing you die while trying to figure them out. ^^
(16:41:00) <deus> can u collect the tears?
(16:41:02) <Bergzwerg> I died once from a cave in
(16:41:04) <Bergzwerg> it was sad
(16:41:13) <loftar> That's the whole point of the Haven project deus. Didn't you know?
(16:42:09) <Bergzwerg> anything new about alloys?
(16:42:45) <loftar> Well, currently there are none.
(16:42:47) <Bergzwerg> and the the metall processing overall
(16:43:04) <Bergzwerg> miniral/ore
(16:43:18) <loftar> It's not like I'll tell you the details beforehand.

[Ninijutsu]

Thank you oddity for keeping us plebs informed on the happenings in IRC.

[Oddity]

Minor info (nothing terribly important or new):

Question: From 0 to 10, how similar is Haven 2.0's combat system to current Haven?

A 5 or 6, perhaps. Many of the low-level constructs, like combat relations, targeting, auto-pursuit, some combat variables and such are very similar, but the more high-level constructs, like attacks, their availability, how they block, &c&c are quite different.

viewtopic.php?f=6&t=37974&start=1630#p510912

If it allays your fears somewhat, rest assured that we are fully aware that, to the extent that "magic" even exists, it needs a very large foundation of "real" in order to even be magic. Otherwise, it's just another mechanic. One thing I really dislike about games like WoW is that everyone and their aunt seems to have glowing eyes, runic swords, horned armors and epic helmets. When everything is epic, nothing is. This is the same reason why we never got as far as implementing witchcraft in Salem.

viewtopic.php?f=6&t=37974&start=1620#p510801

But then, how useful can stockpiles really be for building if you have to constantly pick up their contents and move them somewhere else?

Well, the purpose of drawing materials from stockpiles wasn't so much to make it easier to build things than it currently is in Haven, but rather to make it as easy as it currently is, given that construction sites no longer store materials in themselves, and I do think they do that much. Moving materials to a stockpile is just as easy as is moving materials into a construction site (arguably even easier due to some associated UI changes).

There are aspects of it that does make it easier to build, however, even if that wasn't strictly an intention. For instance, if you want to build something carriable (like a chest or a barrel), you can just plop down their construction sign right next to a stockpile and build it right away, and then carry it off, which I have found a nice thing.

Can you put materials in a wagon or minecart or something to act as mobile stockpiles?

There is no such thing currently, but we might consider it as it sounds like a potentially nice thing.

As for something that reminds slightly of it, however, it is possible to hold both a construction site and a container open at the same time, and thus to use the contents of that container directly for building without having to transfer it to your character's inventory (similarly to how it is possible to craft directly to and from containers).

viewtopic.php?f=6&t=37974&start=1610#p510779

When building, can players draw materials from stockpiles through walls? What is their range?

How do stockpiles interact with claims?

Currently, stockpiles are only used for building at very close range (I don't remember exactly, but about a tile), so walls or claims shouldn't be an issue unless you really try to make it one.

viewtopic.php?f=7&t=38489&start=40#p510913

We actually implemented road-travel just the other day. So far it's very similar to what Potjeh initially proposed, in that milestones simply give you the option to fast-travel to the other end of the road, given that there are no obstacles on the way. If there are, you'll be stopped there. (It's not entirely complete yet however, as we haven't yet decided exactly what to do with travel-weariness.)

They won't be exclusive to the surface, but I doubt a single trail will be able to cross layers. That's not a greater problem than having to make a stopover, of course.

I don't think we're entirely decided on that, but the probable way we'll go is to make it possible to cross rivers with them, but at a fairly steep cost in the resulting travel-weariness.

[Granger]

Well, you could have 2 sorts of things, some were arrow pass and some no.
Just put a single digit 0 or 1 in the code of the object type ( wall, drying frame, ...).

Well, yes, but that is another variable to maintain for every object. If we keep doing things that way, then the number of variables to maintain scales as O(nm), if n is the number of objects in the game and m the number of mechanics. That is not sustainable.

Using sane defaults for feature flags (and putting some time into a editor for them) can drastically cut down on efford needed to implement/maintain features.
Do you configure object features/behaviours in a database and feed a codegenerator from that, or do you hardcode them per object type?

[loftar]

Using sane defaults for feature flags (and putting some time into a editor for them) can drastically cut down on efford needed to implement/maintain features.

Well, of course, but the point in this case was that it was a mechanic where I can't really see any reasonable "defaults", seeing as how the behavior would depend more on the object graphic than anything else.

Do you configure object features/behaviours in a database and feed a codegenerator from that, or do you hardcode them per object type?

The currently running Haven uses a code generator (fed from text source rather than any form of "database", however), but the Hafen systems are flexible enough in themselves that I haven't really felt any great need for one yet. Not to say that one couldn't be good for anything at all, but I haven't felt the need heavily enough to invest in one.

[Granger]

Using sane defaults for feature flags (and putting some time into a editor for them) can drastically cut down on efford needed to implement/maintain features.

Well, of course, but the point in this case was that it was a mechanic where I can't really see any reasonable "defaults", seeing as how the behavior would depend more on the object graphic than anything else.

Default being the more common case, so you only have to touch the ones differing (or an interface as below).

The currently running Haven uses a code generator (fed from text source rather than any form of "database", however), but the Hafen systems are flexible enough in themselves that I haven't really felt any great need for one yet. Not to say that one couldn't be good for anything at all, but I haven't felt the need heavily enough to invest in one.

Text source sounds like a classical flat-file database to me

My point was: if there is an interface to select groups of objects (and tag such selections) it would be relatively trivial to (pseudo sql):
alter table objects add featureBlockArrows boolean;
update objects set featureBlockArrows=false;
update objects set featureBlockArrows=true where objectName like "%wall%" or objectResName like "%palisade%";
when adding new features.

In case the stuff is in a DB there are quite some nice tools to have an interface capable of such stuff (nearly) auto-build (django admin does imho a good job for that, in case you're looking for something python).

[loftar]

Text source sounds like a classical flat-file database to me ;)

Perhaps, but then you could soon argue that anything is a database. :)

Normally, I wouldn't call something a "database" if it doesn't deal with some sort of indexing, at the very least.

My point was: if there is an interface to select groups of objects (and tag such selections) it would be relatively trivial to (pseudo sql):
alter table objects add featureBlockArrows boolean;
update objects set featureBlockArrows=false;
update objects set featureBlockArrows=true where objectName like "%wall%" or objectResName like "%palisade%";
when adding new features.

Clearly, this could devolve into a very broad discussion :), so I'll just touch briefly at some abstract points:

• The main point here is not how to carry out grouping implementation-wise or anything like that, but rather that in mechanics like this particular one, there's no obvious way to group things to begin with. As I said earlier, the problem is not in implementation, but in definition. If I wanted walls, specifically, to block arrows, nothing would be easier.
• A great many "properties" of various objects are calculated only at runtime, and thus aren't available for such operations at compile- or edit-time. (Your "objectResName" being a prime example thereof.)
• Such an approach would intrinsically require the separation of data from the code that implements unique behavior, and while such a thing has some merit, of course, it is not without backsides either. I have considered like things from time to time, but for now I have generally preferred to keep all code and data that is relevant to a particular mechanic in one place, so that it can constitute a self-contained unit.
• The operations you describe are not obviously robust over changes to orthogonal dimensions of parameters.

[Granger]

Clearly, this could devolve into a very broad discussion

Clean separation of code and data (in an OO style or by other means) has its merits (especially when it comes to extend a complex system with new functionality), nevertheless it needs careful planning to not paint oneselve into a corner (where usually then the ugly hacks start). Since you're the one to do the work (havn't seen the code doing the magic on the server, just being curious about how it works) i'm in no position to argue about this, so i i'll let it rest without feeling bad about it.

Nevertheless, i think you got my point. What you do with it is up to you, hopefully it brought you something.

Happy coding, looking forward to when i'm able to dive into the results of your work.

[LadyV]

@oddity Thank you for the updates notes now and then.