Re: [crossfire] Plan to commit combat changes to trunk
I've been playing with the rebalance of melee combat for crossfire for a while, and while not 100% done, I think it is complete enough to warrant committing it to the trunk and hopefully getting more exposure. Now for folks running trunk servers, while the change will not cause anything to actually break (or it shouldn't), it will cause a change in game play, so folks may find combat tougher. Gonna be hard on permadeath servers :) I have also limited the generators, via arch change, to only generate 5 monsters before the generator dies. I'm sure some maps need updating - that 5 monster limit is actually a pretty good compromise - it tends to fill up those empty dungeons that rely on generators to fill them up, but also keeps monsters at a reasonable level. That's a major change, though. Many maps, especially some training centers or Gorokh's final map, actually rely on illimited generators. So maybe that should not be committed for now, or made optional for map designers to decide. I could do all this work in a branch - I'm just don't think that is really worthwhile - the main point of the trunk is to work on the big projects like this. I'd say that where things are now, it has moved beyond expiremental code to code that will be used, but some more work is still needed. I'll start another thread about future changes for balancing. But I'm willing to discuss, and for folks to see this as a heads up if you are running a trunk server. Agreed, trunk is for big changes... Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Next release
Le lundi 31 décembre 2007, Mark Wedel a écrit : Had mentioned several months back I was going to do a new stable release in the near future. Between getting sidetracked and waiting for some changes to get put back, I never got around to making a release. Hopefully there will be a Windows release, last tests show everything work as intented, just need to ensure all DLLs are packed as needed :) Client has metaserver2 support, and server should too when I get the time (unless someone else does it before, of course ^_-) Nicolas -- http://nicolas.weeger.org [Petit site d'images, de textes, de code, bref de l'aléatoire !] signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Balance changes
Having the action take a long time would just be perceived as lag, and so should be avoided if at all possible. Brewing potions (or beer!) could easily have a time lag: it takes time for the stuff to brew. BUT it does not mean the player should stand immobile: the player should keep the forge hot while the steel is heating etc. Hammering the blade into shape DOES take some time, but if we make the preparations time consuming (without making the player immobile), the balance can be achieved without making the hammering last too long. This has two advantages: scripting does not make it any faster and it is realistic (except for the hammering-takes-no-time-part, which is game-technically required so that players don't think it's lagging or get bored): it takes some time to heat a forge, it takes some time for the metal to heat up etc. Adopting a similar system to the one used by rods now to prevent overuse may be most appropriate. I have never created a rod. How does this happen? -Juha -- --- | Juha Jäykkä, [EMAIL PROTECTED]| | home: http://www.utu.fi/~juolja/ | --- signature.asc Description: This is a digitally signed message part. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Plan to commit combat changes to trunk
Nicolas Weeger wrote: I've been playing with the rebalance of melee combat for crossfire for a while, and while not 100% done, I think it is complete enough to warrant committing it to the trunk and hopefully getting more exposure. Now for folks running trunk servers, while the change will not cause anything to actually break (or it shouldn't), it will cause a change in game play, so folks may find combat tougher. Gonna be hard on permadeath servers :) Hence the warning. May not be a bad idea for server admins to make a backup of the player files, just in case. I have also limited the generators, via arch change, to only generate 5 monsters before the generator dies. I'm sure some maps need updating - that 5 monster limit is actually a pretty good compromise - it tends to fill up those empty dungeons that rely on generators to fill them up, but also keeps monsters at a reasonable level. That's a major change, though. Many maps, especially some training centers or Gorokh's final map, actually rely on illimited generators. So maybe that should not be committed for now, or made optional for map designers to decide. So maps themselves can always override it. This is just the basic archetype property. Now folks could use the old archetypes, disable that section of code, etc. However, I think the better answer is to run with the new archetypes, see what is broken (or needs to be adjusted) and fix it. That needs to get done sooner or later, so may as well do it sooner. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
Re: [crossfire] Balance changes
Nicolas Weeger wrote: While I haven't adjusted bow combat, from the basic uses I've done so far, it seems to be somewhat reasonable - the fire/kill rate is somewhat close to to melee - big advantage is that you're not right next to creature. Big disadvantage is you need to carry thousands of arrows about. A thought here is to greatly reduce the odds of arrows (at least non special ones) being destroyed, so you can at least get back most of the arrows you fire (special ones, like the assassinating whatever should still be one shot). Agreed on one shot assassination, but it does need to do real extra damage, else no need for them - I'd rather carry/make 3 regular arrows than take the time to find all ingredients for a special one! I think many recipes may be too hard (or do not generate enough of an item) for the ingredients required - that is certainly another balance issue there - alchemy has never been balanced, it should be done. But that isn't quite as main part of the game as say magic and fighting is, and is also balance in a different nature (difficulty of ingredients, difficulty of recipes, etc) 4) Related to this, better version of low level spells can be put in the game. At level 10, maybe give out 'medium bullet' type of thing, which costs more than the small one, but does more damage and also scales up to higher level. Please, no. No small fireball, medium fireball, large fireball, extra large fireball, xxx fireball, mega fireball, guaranteed most powerful fireball. I'd rather have just damage/range gain for levels. Just doing damage/range gains per level may be workable with the revised monsters. In the past, that didn't work when a first level monster had 20 hp and the level 20 monster had 2000 - there just wasn't any good way to scale up the damage on the spell properly. But it is probably too early to really say if that is the case. But the other issue with different versions is a mix of area vs damage. The bolt vs cone is simplest example - for any given space, a bolt does more damage, but the cone hits many more spaces, and its total damage potential is probably higher. For things like bolts and cones, scaling up is pretty straight forward. For exploding balls, this is less clear cut. It is very possible that in some circumstances, I want a fireball that explodes in a relatively small radius but puts a good amount of damage in that radius (imagine targeting one creature). However, there are other cases where maybe I want it to hit a quite big radius, but am willing to have it do less damage for any given space. One can come up with some form of control language (cast fireball radius=3, dam=15, duration=8) type of thing, but at minimum, that would need some form of interface on the client. The harder part IMO is trying to sort that out on the server side. It is fairly straight forward to say 'a fireball of radius=3, base damage=20, duration=5 cost X sp' and 'a fireball of radius=6, base damage=10, duration=6 costs y SP' an balance out those SP or other values. It is much harder to do that formulaicly and have good values. The issue isn't as much players choosing values that are not effective (spell costs 100 mana and doesn't do a whole bunch), the greater potential problem is the reverse - player seeing that they can minimize (or maximize) certain of those variables and effectively get very effective (in terms of damage/mana) spells for certain situations. Now the morrowind/oblivion commercial game had a way to make custom spells, but from my experience there, the custom spells the player could make would cost a lot more mana than the pre define spells in the game (probably for that same reason - it is resorting to some simple formula to figure out cost). Crossfire could of course do the same thing, that basic low level fireball, when cast a high levels, results in a big fireball with lots of damage, but the player could limit its damage or affect, and get some savings in mana cost (but done in such a way that the cost savings are not really good). But I'm also not sure if a few different varieties of the spells are a bad thing. Sure, 10 varieties of fireball is bad, but I'm not sure if 3 (small, medium, large). I think some of the problem with number of spells is just spells get added, like 'wouldn't it be neat to have a lightning ball' type of thing. There are lots of attacktypes, so one could make a huge number of spells, and I think some serious pruning may be in order when spells are redone. I've also had some thoughts on other classes: Thief/Rogue - crossfire doesn't really have much like this. One thought to make this a more viable class is to remove the search and disarm traps from other classes - most game systems does not allow a mage to disarm traps. This doesn't help as much in standalone, but helps in party play (having that thief to find and
Re: [crossfire] Balance changes
Anton Oussik wrote: Yes, fair enough. Some spells today are already improvements of older versions though, e.g. the snowstorms, so you already have a bit of chasing higher version of a spell around. Perhaps it is a question of striking the right balance between having too many similar spells of different levels and too few spells to encourage progressing. But current system, those are distinct spells, and not upgrades. When you learn medium snowstorm, you still have small snowstorm available. There are two real effects of this - if you lose a level, you may not be able to cast medium snowstorm, but you still have the small snowstorm you can cast, since they are distinct spells and not an upgrade. It also means that for any given spell, there is still just one spellbook. I personally don't think having too few spells would discourage progressing so long as the spells you have get better. Fighter classes have no spells, you people progress in them because they can do more damage, get exp, etc. I see the spellcasting skills the same way. If you learn those first level spells and never get any more exp in the spellcasting classes, you're likely to find out pretty quickly that those first level spells (or more relevent, first level casting level), just doesn't cut it. Casting a level 1 bullet spell at a level 10 monster won't ever kill it, etc. Having the action take a long time would just be perceived as lag, and so should be avoided if at all possible. It depends on how it is done. If there is a graphic showing the the character working, gives some feedback. Likewise, if the player can hit a key and say move, and thus stop what they were working on, that also eliminates any perception of lag. Multi-stage item creation could easily be scripted and may get tedious unless exp and possibly money award is sufficient. IMO, item creation is only of interest for players that find that type of thing interesting. Some folks find it interesting to play a game, going into the forest to chop the wood, bring it back, and spend time making arrows. If they do, crossfire should try to provide a way for that to work and for them to get exp, and perhaps take part in some way in the game (provide arrows for anyone that wants them, etc). However, if what you find fun is zapping monsters with spells or killing them with a sword, that won't appeal to you, and there probably isn't any way to change it that would make it appeal to you - or at least not change it in a way that preserves any sort of balance. Most anything in the game could get scripted, if someone has the incentive to do so. I don't think there is any real way to prevent that - even something like a fatigue system (where you need to refrain from creating an item for some time) doesn't prevent scripting, it just slows it down (it means the script keeps the character idle until the requisite time passes). But in the end, it also comes out to basically the same thing - trying to limit how fast a character can do these actions - it can be done by making the actions slow, requiring rest period, multiple stages, etc. I'm not sure what the best answer is. ___ crossfire mailing list crossfire@metalforge.org http://mailman.metalforge.org/mailman/listinfo/crossfire
