subversion etiquette?

[saarn]

I'm planning to check out a copy of the V trunk and play around with the AI for groups of orcs/trolls/ogres, but I couldn't find any description of standard subversion practice on rephial. Do most people make branches and merge back in when their change is ready/approved, or is there some other flow? I saw on rephial that it suggested committing early and often, but I'm not particularly sure that what I want to play with will be functional any time soon, or if it would ultimately improve gameplay, so committing to the trunk seems like a very bad idea.

[Nick]

Unless takkaria has specifically given it to you, I suspect you don't have commit access (I'm not sure how branches are handled). A common way of getting new stuff accepted is posting it as a patch to the angband-dev mailing list.

[takkaria]

I'm planning to check out a copy of the V trunk and play around with the AI for groups of orcs/trolls/ogres, but I couldn't find any description of standard subversion practice on rephial. Do most people make branches and merge back in when their change is ready/approved, or is there some other flow? I saw on rephial that it suggested committing early and often, but I'm not particularly sure that what I want to play with will be functional any time soon, or if it would ultimately improve gameplay, so committing to the trunk seems like a very bad idea.

As Nick said, people get commit access when they write enough code of a good enough wuality to make it worthwhile over just submitting patches. What AI work are you thinking of doing?

[buzzkill]

What AI work are you thinking of doing?

Oh Boy! I hope it's a Monty Python-esque song and dance routine.

[saarn]

AI wise, I want to concentrate on monsters that appear in hordes and should be smart, but let themselves be drawn into long, repetitive battles one on one in a corridor. Ideally, I'd like to possibly take this to the point of formations/combined arms tactics, but where I want to start is with improved strategy. In broad terms, I think orcs should set things up and be more patient.

For my first pass, I was thinking of the following:

A big mass of orcs should subdivide into a number of smaller groups, each large enough to hold down a room on its own, and these groups should then move to the rooms that will most subdivide the dungeon (prevent @ from getting around easily). Here, I'm thinking of treating the dungeon as an undirected graph where orcs in a room creates a vertex cut. I'd like to choose the vertex cuts such that the maximum size of connected graph is minimized, and following that, to maximize the number of disconnected graphs.

An additional weight factor would be the size of the graph occupied by @.

Tactically, orcs should choose battles based on whether other groups can come in from behind, whether battle will be in a corridor or room (generally should not chase @ into the corridor unless another group can come from behind). A simple way to do this might be to look at the distance separating other groups from @ and the expected time the force can hold out against @ on their own. This could be improved by actually simulating battle to determine whether to fight or wait.

From a gameplay angle, I'd like to make some of these things stronger as depth increases, and/or tie the use of better AI to the presence of a captain or unique. Getting the right level of nasty to keep things interesting as opposed to abusive may be the largest challenge.

[buzzkill]

Give Orc Shamans/Priests/Mages Stone to Mud, and CLW on other, and maybe some other others like bless and remove fear. If they're going to start acting intelligently, they might as well have some useful spells. Give individual packs a 'morale' rating that would dictate their dedication to the battle as a whole.

[saarn]

I was definitely thinking a bit about having the magicians heal other monsters, and was also thinking about letting the grunts tunnel at the same rate as a player with a relatively heavy weapon, but figured this would be a big game change, and should probably be put off for when I get to playing with tactics (I think that is probably more complicated than strategy and more likely to draw complaints of unfair behavior). I like the idea of a morale rating-- it makes sense that if half the monsters in a room are eradicated by a massive fireball that the rest of the group should flee in fear if there aren't serious reinforcements.

[CloneDeath]

Concerning moral, I liked how they did it in 1st edition AD&D.

Going off memory, it went something like this:

The group had a moral value, and you rolled against it, if you succeeded then the monster still fight, if you fail then they run away.

You do a moral check when:
1) The first monster in a group dies (watching some die is very traumatic for weaker monsters who are not used to battle)
2) Half of the group is dead
3) The player does something very Intimidating (ie: Casting a fear spell, summoning an illusion of a dragon, Screaming and acting like a crazy person, etc...)

That is just from how it is done in AD&D, but I imagine if you dumb it down to check for 1 and 2, it shouldn't be too hard to incorporate. The check itself should be super simple, it is determining what the "moral value" that you have to figure out so that it works.

[d_m]

Do most people make branches and merge back in when their change is ready/approved, or is there some other flow? I saw on rephial that it suggested committing early and often, but I'm not particularly sure that what I want to play with will be functional any time soon, or if it would ultimately improve gameplay, so committing to the trunk seems like a very bad idea.

I don't know if you've ever used a dynamic version control system (like mercurial or git) but I am tracking Angband's HEAD using a mercurial repository:

http://bitbucket.org/d_m/angband

I can't explain all of Mercurial here, but the advantage of it for the type of work you're doing (which will probably require many commits, changes, bugfixes, etc) is that you essentially clone the repo into your own local repo, commit there as often as you like, and also keep pulling in new updates to sync your code with commits happening in Angband's main repo.

This is like having tons of uncommitted work in your SVN checkout, except that you have a history of your own work, and can back out your commits, delete modifications to revert to a recent version, etc. With SVN, if you accidentally mess up a file, you have no history (other than the last version in HEAD) to go back to.

Anyway, let me know if you do end up using my mirror. It often gets a day behind HEAD (I am currently manually syncing it up each day). I should probably set up a cron job to sync automatically, but so far (from what I can tell) there hasn't been any usage (other than my own).

To everyone else: if Angband moved to a DVCS (like mercurial or git) it would make development easier for authors without commit access, or variant authors who often aren't going to commit back but might be interested in tracking Vanilla's HEAD.