Bay 12 Games Forum

Can we please try to avoid the multiple-page walls of text and the "if you *didn't* like this feature I would think less of you?" It's really smug and for some of you I really can't understand what you're saying. It's way easier to write a long post than a short one: please edit. (ex: this post was originally three times longer.)

I basically play Dwarf Fortress because I want to see dwarves do cute things that are totally inhumane, like stabbing a chicken because they think it killed the mayor. I guess I see prejudice as at least two features?

One is for creatures to not like each other because of cultural assumptions. I think there's some potential for this stuff to emerge from the existing group alliance stuff. Each civ currently has cultural knowledge of every other civ for the purpose of starting wars -- adding mechanics that make it possible for a civ to have wrong cultural knowledge would encourage holy wars, but it'd be tempered by the mitigating factors already built in.

The side I don't want: in the human world cultures develop symbolic ways to express hate and convince bystanders to agree: fake science like phrenology and The Bell Curve, slurs like "nigger" and "kike," de jure discrimination like separate buses and bathrooms and prisons and schools, ritualistic acts like lynching, cutting off hands, shaving heads, photographing, sterilizing. Prejudiced aggressors like inventing crimes or blaming the victims for the nasty things they did, and they get away with it even if it doesn't make sense.

I think this feature is actually really important. In the real world, whenever you're not actually the target of the prejudice, it's the more visible one, because if you're not the victim, you won't experience the violence and you don't need to know if if it's justified, but you can still see how the aggressor is talking. The lies are usually obvious and ridiculous, but the hate continues to spread because humans are weak to lies that appeal to their prejudices. Watching people you like fall into this stuff is like watching them develop cancer or something. I don't want my dwarves to do this because it will remind me of people I knew who became entrenched in this.

If any of the stuff I mentioned, including the language I used, makes you uncomfortable, then I don't think you want this stuff in a game like Dwarf Fortress. For many of you it doesn't seem like the topic has any sting. Most of the worst things humans ever did are related to prejudice, and many of you explicitly want dwarves to repeat those things. If they do, it should make you feel sick, or else it's not a good simulation.

Disclaimer: I hate every programming language. That's a jokey "hate" but also a serious one! My favorite languages for big projects used to be Haskell and Prolog -- I would still defend them but I tired myself out on them pretty quickly. They all have featuresets that are laser-targeted to one kind of problem at the expense of most others. I don't think either comes with any features or builtins that would help you with this project. My favorite language for world simulation is Inform, but it's probably too special-purpose for what you want.

I have a hunch you'd be happiest if you picked a popular language. Out of the ten most popular languages on this page (http://www.tiobe.com/tiobe_index) I think Java has the least wrong with it for writing big projects like this. (I can say much the same for C#, which trades lots of additional complexity for a ton of convenience features -- but it's not one of my primary technologies.) There's good libraries to get started with for curses-style development in Java, and the tooling is excellent, even though IMHO every major Java framework, including most of the builtins, is a design trainwreck. (Libraries with fewer aspirations of taking over your entire program are sometimes OK.)

Java is really verbose and the syntax is a little dated, though, so I can't recommend it super hard for small projects. It's a language that takes a lot of time and effort to get something done in even if you know what you're trying to do. At least it's fast! (it's closely comparable to C++)

I can't in good conscience recommend Python for something larger than 1000 lines -- the documentation doesn't really cover what errors anything is allowed to throw and there's no static type system, which makes it really hard to determine if your code is going to crash or not. The error handling builtins have much less bias towards defaulting to doing the right thing than the builtins in e.g. Prolog or Icon, but both of those languages have IMHO too much bias in the direction of guessing what you mean.

I don't really like the syntax in Python, but most languages in wide use have really inflexible syntax. (At least Python's syntax is less verbose...) My big issue with it is that it wasn't designed for continuation-passing, even though it can do it -- continuation-passing is a really common tool for writing multitasking programs or otherwise manipulating what order things happen in, and Python not having it is imho cumbersome.

If I'm not throwing you to Java and I'm not throwing you to Python, though, I'm almost certainly throwing you to C, Javascript, or C++ and all of those have deeper fundamental problems, IMHO. Please use Python over those! They all suffer from a much worse version of Python's problems. Except C++, which is pretty type-safe but can still fail at a moment's notice due to manual memory management. (C nominally has a type system, but I don't believe the rumors.)

Don't use PHP.

Some other languages to consider if you want something like Python are Ruby and Lua. Lua is effectively a smaller Python, but its builtins are tiny and you'll have to build everything you want yourself -- it's also hard to deploy. Ruby has better support for e.g. continuation-passing and continuations in general, which is a big win imho -- but it's far more complex and almost everything associated with it has horrific documentation.

(Disclaimer: I am far more experienced with C than with C++.) My experience with C++ is that a lot of my friends start big projects in it, then realize they made a bad memory management assumption at the beginning of their project and are pretty powerless to fix it. I don't think the memory management is as bad as a lot of people say, but you have to think about it all the time and every time you take a shortcut (which is constantly tempting) you're gambling on whether the shortcut you took is going to break your program in the future. It's also an extremely complicated language and a lot of the features interact in surprising ways. And it's famous for its cryptic error messages!

I think it would be a bad idea for someone who doesn't know exactly what he's getting into (meaning "has C or assembly language programming experience, and also has Java programming experience, and also understands how Java objects were implemented") to use C++. I think it's still not a good idea if you know the difficulties -- I don't like C++ very much -- but hey, some people don't use condoms, either.

If you really want to use C++, you might consider trying Rust if you get frustrated. Rust is about as difficult as C++ (it has a smaller featureset that can still create most of the same problems), but it comes with a checker to tell you when you make a mistake that's likely to break your program. Could also look into Modula-3, which I don't personally use but one of my friends does -- I wouldn't be the one to sell you on it though, and it's not widely used.

I've had a look at this. I might give it a shot, but I'd probably have to study hnefatafl theory relatively extensively, which seems like work...

You can probably try doing it with tree search over every possible move (all that requires is a complete implementation of the rules, which Fishbreath has already done) along with a hacky value-of-pieces scoring function -- then start pruning options that, based on your strategic insight, look obviously not relevant. Most of your rules to do this will probably take a lot more computation than just exploring the tree, mind, so you will probably need to be pretty sure you are exploring very accurately once you start cutting moves, or you'll lose overall depth.

Implementing this correctly will probably result in an AI that's not very good at macro plans but is pretty good at not losing pieces due to two-or-three-move-long gambits, and possibly decent at throwing gambits like those at you.

Another more experimental option might be to find a way to train a neural net to evaluate board states, like AlphaGo did -- I don't know exactly how AlphaGo did it, but I'm guessing it did so by taking a board state, tree-searching it to the end (using whatever rules you used for your base tree search), and then giving that board state (and most of the intermediate ones) a value based on the win-lose probabilities that tree search turned up.

Unfortunately there's not a large corpus of hnefetafl games out there, so you can't do what AlphaGo did in seeding the tree search algorithm with a ton of data on what interesting-to-pro moves look like. My guess is that not having that data means that your tree search is going to need to err on the side of exhaustive no matter what.

If you wanted to sit down and learn a little strategy, an implementation that uses hacky guesswork to try to set itself up for long-term play might be interesting. One of the first successful checkers-playing programs trained itself on a large number of metrics that the authors thought might be relevant to successful checkers play -- stuff like "number of diamonds" or "density of flanks vs density of middle board" -- then optimized using a genetic algorithm to find the winning combinations for those long-term strategy metrics -- then used a scoring function based on all that math. It probably wouldn't be too hard to come up with metrics like that in Hnefetafl, and that might get you a significantly stronger scoring function than just "count pieces and see who has more." (Of course, "count pieces and see who has more" is a stronger scoring function than you think -- combined with a lot of ability for short-term tactics, a lot of chess bots did pretty well with it, IIRC.)



Those are three pretty closely related takes on implementing hnefetafl that don't require you to know very much strategy in advance. I bet you could probably do all of them at once, and I bet your result would be a hnefetafl program with a really dogmatic view of long-term planning but a lot of versatility in the short term. (because evaluating short-term boards near-exhaustively means not being surprised hardly ever.)

Fishbreath actually knows a lot about AlphaGo IIRC (his blog has tons-of-fun coverage of the games it played, at least, which spurred me towards actually watching the games in their four-to-six-hour glory) so ask him about all the things I said "gee I dunno" about. I am not an AI expert!!!!!!


EDIT: Minor note -- it looks kind of like the algorithm I'm talking about when I say "tree search" is not strictly Monte Carlo tree search. After doing some quick reading it looks like it's typical to evaluate all the way to the end of the game making random choices all the way. I'm specifically saying you should evaluate not-too-deep, and substitute a better "evaluate board" function when you get there, so that when you make your random picks they're likely to be representative. There are enough possible moves from each hnefetafl state that evaluating six or seven moves down at near random will probably not give you a good valuation of the position AFAICT.

I don't intend to jump on this right now because I have another AI project that's currently sucking up all my time, but this is an interesting problem that anyone who's not already working on an AI project should be jumping on.

FWIW, I hear his dev practices have improved since then, but if you want to see a lot of actual Toady code, Liberal Crime Squad is open source.

Based on the code in that project I think it's refreshing to see a guy who codes by introducing all the special cases right upfront, inline, with little or no abstraction where it's not absolutely necessary. For most projects of single-programmer scale you can just set the abstraction level right out at the gate by picking a programming language that makes good assumptions for your project, and then seldom thinking about it again. There are a lot of good videogame projects with easy-to-understand code which uses very little abstraction. (like Dungeon Crawl)

(sidenote and pet peeve: most programmers appear to think every abstraction they introduce is 'absolutely necessary.' This is what I mean: if the codebase size would increase superlinearly over time if you don't introduce whatever your abstraction is, your abstraction is absolutely necessary. Preventing the programmers from duplicating a constant or linear number of checks does not make the thing you introduced "absolutely necessary".)

IMHO many games are totally shaped by how they frame special cases -- "if we can't represent this spell effect as a callback taking the player object, we won't have that spell effect!" DF, being mostly unconcerned with methodology, outright refuses to play that game.

Unfortunately, AFAICT, Dwarf Fortress is one of those rare one-man projects where you can work yourself into a hole by assuming you don't need any extra abstraction and never deviating from that assumption. Example: Toady's mentioned in DF-talk about how the game's timescale assumptions are completely inconsistent, with lots of hardcoded special cases for every action, which means it's going to be nearly impossible to reconcile adventure mode time with dwarf mode time.

I think the arena completely forces allegiances based on faction association, to the point where tags like [CRAZED] and [OPPOSED_TO_LIFE] don't work correctly.

I'm not sure if it would be fun to introduce a mechanical difference but it might be fun to introduce a cosmetic difference here. I think making this a full-fledged mechanic would be a little confusing because unlike a lot of the things that change as political alignment does, (cop type, site names) this isn't something you can check voluntarily or have the opportunity to check very often, and I can't think of a natural way to inform the player of them.

You could have a dealership full of crappy gas guzzlers that vanishes based on environmental law or something, maybe.

Agreed on that point, because, even though such an option exists, it's buried in the advanced world generation parameters unlike the others.