Contributing to v4

[Magnate]

Someone suggested that there ought to be a sticky with a kind of "to-do" list for v4, in case anyone is thinking about contributing and wondering what would be good to work on. There's a detailed list of tickets on the tracker, but here is a higher-level summary of stuff that nobody's got round to starting yet. (We assume that you've read the v4 FAQ.)

1. Improving item generation. The main issues with this are:
- coming up with a better way of naming non-themed items with multiple affixes
- making certain combinations of affixes exclusive (e.g. "rusty" and "crystal").
- adding more affixes so that every item has a decent choice of prefixes for make, material and quality (as well as magical suffices) of all affix levels
- using affixes to create randarts

2. Improving the new combat system:
- checking that the different approaches (fin/prow/balanced) are approximately equally powered, including whether two different critical hit regimes are required for fin/prow crits
- converting archery to the new system (getting rid of launcher mult in favour of balance and heft)
- making throwing weapons a feasible alternative to archery

3. Overhauling the spell system. This is basically in the hands of whoever wants to do it, but at the very least a careful weeding of unused spells would be good, along with a check that the damage/mana progression of attack spells is sensible. Magic missile is no longer the no-brainer spell for magi, but the same cannot be said of OoD for priests (the higher-damage priest spells are too weak for their cost).

4. Rebalancing races and classes. Making them more distinct (e.g. combat preferences), and getting rid of half-elves for a start. Again, a lot depends on the ideas of whoever wants to do it.

5. Overhauling ID. Getting rid of pseudo (which is rendered pointless by affixes), and replacing it with a sensible approach to obviousness and runes (e.g. material affixes should be obvious).

6. Overhauling squelch. Really goes with ID above - instead of quality squelch based on pseudo, we need to be able to specify thresholds for squelching: <= +X for fin/prow/pvals. Also squelch "anything strictly less good than this item".

7. Improved AI, including monster mana and casting power, and better pathfinding/flow/understanding of LOS.

[saarn]

it strikes me that a lot of these changes are about manipulating game balance. I don't know much about the borg, but might it be possible to use it as a form of regression testing for balance? I'm thinking you could maybe look at several runs per some set of race/class combos and try to gauge relative difficulty based on deaths, turncounts, etc. I'm guessing it doesn't play a whole lot like a flesh and blood human, but it could certainly play a lot more games per unit time. Then again, if it has a lot of hardcoded tactics the whole idea may be a non-starter.

[d_m]

it strikes me that a lot of these changes are about manipulating game balance. I don't know much about the borg, but might it be possible to use it as a form of regression testing for balance? I'm thinking you could maybe look at several runs per some set of race/class combos and try to gauge relative difficulty based on deaths, turncounts, etc. I'm guessing it doesn't play a whole lot like a flesh and blood human, but it could certainly play a lot more games per unit time. Then again, if it has a lot of hardcoded tactics the whole idea may be a non-starter.

Getting the borg understanding v4 mechanics and playing it correctly would be a huge win, and I agree that once it was working it'd help with some of the balance issues.

[saarn]

Getting the borg understanding v4 mechanics and playing it correctly would be a huge win, and I agree that once it was working it'd help with some of the balance issues.

any sense how involved a task that would be? Are we talking just replacing some damage estimation, or hacking all kinds of heuristics?

[d_m]

any sense how involved a task that would be? Are we talking just replacing some damage estimation, or hacking all kinds of heuristics?

To do it all would be a huge undertaking.

That said, I think there is probably lots of low-hanging fruit, and it's the sort of thing that can probably be fixed piece-by-piece.

[Magnate]

To do it all would be a huge undertaking.

That said, I think there is probably lots of low-hanging fruit, and it's the sort of thing that can probably be fixed piece-by-piece.

Updating the borg to v4 is a hard choice between:

a. finding all the references in the ~60k lines of borg code to old-style V ego items and old-style V combat, and replacing them with systems to allow the borg to evaluate v4's ego items and combat

and

b. changing the borg at a lower level so that it uses the same mechanics as the game itself, meaning that it will evolve much more easily with future changes.

To expand on that a bit: the borg was designed to be completely separate from the game code. So it doesn't use any of the game's functions (for example, object_power() to evaluate the power of an object, or calc_blows() to work out how many blows it gets). Instead, all the logic in all these functions is duplicated in borg-specific functions. The only interaction with the game is when the borg scrapes the screen to get info, and puts commands in the queue. That's it.

This means that any time anything changes in the gameplay, that change needs to be replicated in the borg code (often in more than one place). This is why it's such a lot of work to update the borg for each release of V. Option a above is effectively doing the same kind of update for v4 - but it would be the first of many.

Option b is a fundamental change to the nature of the borg, integrating it much more closely with the game. Since it now sits in the master repo and ships with the game, there's no real reason not to do this. It's slightly more up front work (but don't underestimate the difficulty of option a), but much much better for the long term.

But yes, I fundamentally agree that the borg can be a useful balancing tool in the long run.

[APWhite]

Updating the borg to v4 is a hard choice between:

a. finding all the references in the ~60k lines of borg code to old-style V ego items and old-style V combat, and replacing them with systems to allow the borg to evaluate v4's ego items and combat

and

b. changing the borg at a lower level so that it uses the same mechanics as the game itself, meaning that it will evolve much more easily with future changes.

To expand on that a bit: the borg was designed to be completely separate from the game code. So it doesn't use any of the game's functions (for example, object_power() to evaluate the power of an object, or calc_blows() to work out how many blows it gets). Instead, all the logic in all these functions is duplicated in borg-specific functions. The only interaction with the game is when the borg scrapes the screen to get info, and puts commands in the queue. That's it.

This means that any time anything changes in the gameplay, that change needs to be replicated in the borg code (often in more than one place). This is why it's such a lot of work to update the borg for each release of V. Option a above is effectively doing the same kind of update for v4 - but it would be the first of many.

Option b is a fundamental change to the nature of the borg, integrating it much more closely with the game. Since it now sits in the master repo and ships with the game, there's no real reason not to do this. It's slightly more up front work (but don't underestimate the difficulty of option a), but much much better for the long term.

But yes, I fundamentally agree that the borg can be a useful balancing tool in the long run.

I don't think anyone knows that code better than I do and I would vote for the integration option. It would take some work, but I think it is worth it. I am happy to help in the project.

I have my hands tied until there is a working copy that runs in Visual Studio 2008. It is the best IDE for me to use. The debugging options are critical to tracking errors in the borg. I will only program in VS. The older versions of the game used to compile perfectly in VS, but recent changes to the code have rendered it inoperable.

As soon as you get the code base working again, I will step up and fix the borg. I have been the chief borg programmer for the last 16 years. I don't plan on abandoning the project.

[Magnate]

I don't think anyone knows that code better than I do and I would vote for the integration option. It would take some work, but I think it is worth it. I am happy to help in the project.

I have my hands tied until there is a working copy that runs in Visual Studio 2008. It is the best IDE for me to use. The debugging options are critical to tracking errors in the borg. I will only program in VS. The older versions of the game used to compile perfectly in VS, but recent changes to the code have rendered it inoperable.

As soon as you get the code base working again, I will step up and fix the borg. I have been the chief borg programmer for the last 16 years. I don't plan on abandoning the project.

Thanks Andrew - that's really great news. I hadn't realised we had broken VS2008 - I'm not a Windows coder myself but IIRC Blubaron uses VS2010 and it seems to work ok. I'm happy to try and help with finding solutions though. Please could you:

1. Tell us what steps you take to reach the problem with compiling in VS2008 (i.e. what is the fail message?), and

2. Tell us which versions the problem appears in (i.e. which is the latest version that you can successfully build?)

I'm really looking forward to helping integrate the borg!