Re: [crossfire] Game change proposals
On 06/14/14 02:17 PM, Nicolas Weeger wrote: Hello. I'm not familiar to the original game, but I'd be careful with anything that is too time sensitive. I'd also like a better idea of what you envision. Is it something like there are 10 (or 20) different lockpicks in the game, and the character has to use them in the right order? Presumably, the lockpick skill should still come in to play in some way for this also (amount of time to pick the lock, or perhaps some amount of not needing the precise lockpicks or something) Something like that, yes - you need to use the correct lockpicks in the correct order. So you could have special doors requiring a special lockpick found in a special place. Makes sense - would the lockpicks be consumed (or perhaps break) on failed attempts? That might be another way to limit special door access - yes, you can pick it, but the lockpicks themselves are rare and/or expensive, so may not be worth it just for the sake of doing it. That is a big change, and probably fairly simple to do - most other games do this (those creatures may be attacking you with axes, but you don't get all those weapons when you kill them). Likewise, even of the items that are out there, one could reasonably ask do we really need the number of different swords out there that vary by a minor detail. I know some games do this, but that is more related to skins (this sword looks cool) - with the way crossfire is, that really isn't the case. I was thinking of adding a second treasure list to monsters, which contains items to drop at death. Would need to figure how to make steal work, though. I had thought of the second treasure list - the problem, is you could get a case where the creature is firing arrows at you, but drops something completely unrelated. Other games do that (often getting items completely unrelated to what the creature is using), but IMO, it is nicer if what is dropped matches what the creature had. I know sometimes in crossfire you are fighting something and getting hit by some wand attack, and I think 'I want to kill that creature to get that wand'. With the proposed system, that might not happen, but would be nice to have a chance. So perhaps what could be done is the existing treasurelists modified with something like a 'drop_chance' value - if the item is generated, that represents that chance that the item actually drops. At treasure creation time, the item could get marked with a flag based on that (I think FLAG_NO_DROP might already exist) That chance may be low, but at least you have a chance of getting what the creature is using. For stealing, I think only allow items that will drop when the creature is killed to be stolen works, so that also fixes that problem. That would be good, but is also a major change - the vast majority of maps would need to be refactored (maps with gobs of monsters would just be unplayable). Yes. On the other hand, it'd make for a nice map review :) Right - in some ways, it makes sense to do a bunch of big changes at one time for that reason - while reviewing maps for monster density, can also review them for doors, etc. Seems reasonable, though than in itself creates yet different issues (if a player can use a weapon effectively enough to constantly keep a monster stunned, probably makes for an easy combat) Then the monster isn't that high level, is it? I guess it depends exactly how those chances work. Is it a level comparison + random factor? or you do the attack and it happens? Or make it so the time the player needs to launch the stun attack is longer that the actual stun. Yep - some games also have other melee related stats (fatigue, adrenaline, etc), and one could imagine that the special attacks cost more fatigue, and fatigue only really recovers out of combat - so you could enter combat, do a flurry of special attacks, but after that, are basically just left doing normal attacks or something. Agree - most of those are side effects. The trickier part on some of those is whether resistances should exist and how to then factor them in - the number of attacks and number of resistances sort of go hand in hand. While one could certainly come up with different logic to handle those, that solution may just be more complicated. Note that if you did all the above changes, that is some fairly radical changes to the game (attack rate and item drop). Though perhaps the second comes from the first - if combat is a lot slower, that would then suggest there are a lot fewer monsters, which should then mean a lot lower item drop. Yes, radical changes is what I'm thinking of. There are a zillion hack-and-slash games. So maybe we should try something different? Maybe - that has always been a bit of challenge - trying to figure out exactly what crossfire is or should be. ___ crossfire mailing list
Re: [crossfire] Crossfire should use Git
On 06/14/14 11:30 AM, Kevin Zheng wrote: snip I believe the most compelling reason to use a DVCS is that it makes contributions easier. About a year ago a common complaint about my patches were that too many changes were lumped together in one patch, making it hard to review. While I could have used Git or Hg to make a local repository, I did not think that was worth the trouble. True - a DVCS certainly makes it easier to have/make multiple unrelated changes and make them available as individual patches (presuming good practices were followed and the developer remembers to check them in their local repo separately). I also think DVCS is also better if one is making really big changes that will take a while to do, because of the better branching, local commits, and merging - for something like SVN, you would pretty much need to make your own branch, which then also shows up in the main repo. Next, an adventure: I've taken the liberty to install and attempt to learn Mercurial. Since I am brainwashed by the Git world, please correct me if I'm wrong. My current workflow involves putting all non-trivial or multi-commit projects in a separate branch. Then I dangerously reorder, squash, and otherwise mutilate my local branch until it can be laid on top of the SVN trunk, where I dump back the linear history. If I used Hg, this would likely involve making many copies of the repository (since each branch is an entire checkout) for minor changes. Since I make extensive use of the Git staging area, I would wind up using `hg record` (an extension) very often. I would also end up maintaining patch sets using message queues (another extension), in order to clean up my changes before committing. In addition, it would be impossible for me to rebase my commits, which means that every branch would require its own merge. If you take a look at my commits, most have been squashed versions of local branch work. I'm not at all familiar with git, so I'm 100% how to compare the 2. I'm not 1005 sure why you would need many copies of the repository - there is nothing that prevents making a clone, making one set of changes, doing a local commit, making another set of changes, doing a local commit, and repeat as necessary. The only reason you would need many copies of the repository is if you were making different changes to each one - you could still do that with hg, but that seems like a somewhat odd way to develop code. Note you can reparent with mercurial quite easily - presuming there is a common parent, it is just a matter of doing 'hg pull newparent'. You can likewise do the same with the push, but you need to be up to date relative to the parent (mercurial will make sure this is the case). All that said, at work, we use the cadmium extensions which provide some nice features like 'recommit', which collapses all the commits in the branch into a single delta which can be pushed later. I'm not sure how available the cadmium tools are. But whether people use extensions or not for mercurial doesn't matter much - those extensions are local to them, and the main repo doesn't really care. So people can use whatever extensions work best for them. I advocated Git because we should use the VCS that I'm most familiar with. It works with the workflow that I'm most comfortable with. I welcome anyone familiar with Hg to reeducate my current workflow. If I am the only developer that makes use of such a workflow, then I apologize for being selfish and greedy. The problem is that if I took that attitude several years ago, we probably we be on mercurial. Crossfire is a community project, so has to meet the needs of many developers. While SVN is pretty limiting, one thing it has going for it is that it is quite simple to use - non hardcore developers can understand and use git without much problem - from many of the other posts I've seen, that is not true with git (and mercurial for that matter). So having something simple and easy to use has lots of advantages, with limited disadvantages (main one being that SVN is not a DVCS) Git has a good SVN bridge. Hg has a good Git bridge. Git does NOT have a good Hg bridge (Git's fault). If I keep my current workflow, then I'd much rather stick with SVN and play with local Git branches. IMO, that may just be the simplest way to go - I understand it is more pain for you, but there is a fair amount of pain to switch what VCS crossfire uses (I did this one before) - aside from the different commands people need to know, everyone also has to point to the new repo, you have to make sure there are not any outstanding commits, etc. Plus, from the other people that replied, there clearly was not an unanimous chorus of everyone agreeing to a move to git - granted the number of replies was limited, but if anything, seemed to be more opposition to it than those in favor. ___ crossfire
