From nicolas.weeger at laposte.net Fri Jun 1 16:16:14 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 1 Jun 2007 23:16:14 +0200 Subject: [crossfire] The future of Crossfire Message-ID: <200706012316.15083.nicolas.weeger@laposte.net> Hello. I'd like to start a debate on what we want for the future of Crossfire. By future I guess we can say 2.0 and later versions - 1.x branch shouldn't change much, and trunk is still some time away. Lately, we've been too focused on code, I think, and not enough on features making the game we want to make - we don't even really know what game we want. IMO, we should first decide what we want to do (and no, saying "let's fix sounds" or "let's improve spell performance" or "let's fix bugs") is not deciding what we want to do, merely fixing. I think we suffer from lack of vision. We suffer from not enough coordination. What kind of game do we want? What kind of gameplay? This should guide our code, not the other way around. Example, if we want to someday have more than 15 or 20 players, threading will probably be mandatory. But threading for the sake of it isn't useful if we don't want to aim for many players. So, what would be everyone's vision of the game? My goal is to have a fun game, with fun quests, items, skills, maps. Fun meaning interesting, challenging, many many things :) Also multiplayer, eg collaboration and/or competition. Multiplayer spells (ok, those exist, but haven't been much discussed), multiplayer quests, and so on. From that we should decide what we plan to code - rewrite some obsolete stuff, refactor, whatever. Sorry if the tone sounds harsh. I am concerned by where we are going - or rather where we aren't really going, or not all together. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From leaf at real-time.com Fri Jun 1 17:36:39 2007 From: leaf at real-time.com (Rick Tanner) Date: Fri, 01 Jun 2007 17:36:39 -0500 Subject: [crossfire] Undead dragon In-Reply-To: <200705301918.02485.nicolas.weeger@laposte.net> References: <200705301918.02485.nicolas.weeger@laposte.net> Message-ID: <46609F77.1000200@real-time.com> > With relation to the bug at > http://sourceforge.net/tracker/index.php?func=detail&aid=1727118&group_id=13833&atid=113833 > (which isn't per se a bug - dragons worshipping Devourers aren't dragons > anymore). > > The is_dragon_pl() function will though return 1, allowing such a dragon to > gain resistances. > > So undead dragons can gain resistances, but can't enter dragon guilds. > > What do you think of that? It's often confusing to players... > IMO undead dragon must be able to gain resistances, else too hard. > On the other hand, entering a guild, we can decide some dragon guilds reject > undead dragons. > So I'd say we keep the situation this way :) What about this work around? Add a new map to the lower/dungeon area of the Devourers Temple which only allows undead to enter and has the various elemental residue available for switching a dragon's metabolism. This could also tie in to a quest (similar to the Scorn Royalty quest) where only those who accomplish certain tasks or turn-ins could enter. Or, a dungeon level added to the dragon guild for the undead dragons. Just a couple of ideas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070601/1a44dff1/attachment.pgp From alex_sch at telus.net Fri Jun 1 21:49:04 2007 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 01 Jun 2007 20:49:04 -0600 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706012316.15083.nicolas.weeger@laposte.net> References: <200706012316.15083.nicolas.weeger@laposte.net> Message-ID: <4660DAA0.4070004@telus.net> Nicolas Weeger wrote: > Lately, we've been too focused on code, I think, and not enough on features > making the game we want to make - we don't even really know what game we > want. > Well I'd say that focus on code is the result of two things: 1) Much code being messy/unmodularized in the first place 2) The aforementioned lack of even vision for what we want to do in the larger picture. Both issues are important to solve (and some has been done in terms of #1), but #2 is certainly a more fundamental issue (and unfortunately, consequently often more tempting to try to push to the side instead of dealing with it). > > > Example, if we want to someday have more than 15 or 20 players, threading will > probably be mandatory. But threading for the sake of it isn't useful if we > don't want to aim for many players. > Agreed on the logic of the how to define the importance of threading. On this specific issue of how many players we want to aim for, personally I'd say that given the nature of the maps as they are, it would be best to aim for the 40 to 50 area on a server. > So, what would be everyone's vision of the game? > > My goal is to have a fun game, with fun quests, items, skills, maps. Fun > meaning interesting, challenging, many many things :) > Also multiplayer, eg collaboration and/or competition. Multiplayer spells (ok, > those exist, but haven't been much discussed), multiplayer quests, and so on. > "What kind of gameplay" can be something difficult to define, but I'd say your goal is good (though vague). In some ways, how I'd state my vision of what sort of game, would be comparing it to the well known area of Pupland. The maps of Pupland are often regarded as some of the best in Crossfire, they have extensive cohesive lore which is well integrated into the maps, it has lots of fun puzzles and quests, it has some fun items, it has some strong collaborative maps, it even has custom images (When playing, I found it neat to find something that I've never seen a look-alike for before (i.e. red crown in the old city of scorn, the fortune dagger and necromancer of ancient pupland)), and many of the things you say. I'd say that in many ways, the direction I'd say we should look in for Crossfire, would be in the direction of Pupland, but look further than that. Despite it's shortcomings in some areas, I would say that in many ways, Pupland is a good symbol for much we are looking for. I believe that Crossfire largely has the 'tone' of game that I envision for it, it's just that this 'tone' is muddied in other things (i.e. there are a significant number of little dungeons around with no plot of significant and are just hack'n'slash things that often aren't even that big). One thing I think, is that often we are too afraid of removing. Frankly, I'd say there are a rather large number of dungons/maps that are so lacking in plot that they might as well be removed. When playing, I personally find things like Pupland's quests, or the arena, and other things with more interactivity than hack'n'slash to be what keep my attention. All too often I find I'd enter a building or cave or something hoping to find something interesting or at least a little fun, but oh, it was just another hack'n'slash or perhaps an inn in which there were some quest clues, but too sparsely spread between a very large number of NPCs to be useful unless something else directed me there first. > >From that we should decide what we plan to code - rewrite some obsolete stuff, > refactor, whatever. > Well, I'd say some types of cleanup/refactoring etc. are important regardless of what is decided for goals, but indeed we should pay more attention to what we want for goals in the bigger picture. > Sorry if the tone sounds harsh. I am concerned by where we are going - or > rather where we aren't really going, or not all together. > It is something I would say that many of us, if not all, are rightly concerned about. Alex Schultz From mwedel at sonic.net Fri Jun 1 22:45:48 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 01 Jun 2007 20:45:48 -0700 Subject: [crossfire] The future of Crossfire In-Reply-To: <4660DAA0.4070004@telus.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4660DAA0.4070004@telus.net> Message-ID: <4660E7EC.2030105@sonic.net> One thing that can also help in this discussion is figure what should/will remain the same. I suspect that for most crossfire players, there are aspects they like already. But you also want to avoid the discussions that basically amount to a new game (or maybe more like some other game out there)/complete rewrite. To me, the biggest immutable thing is probably the map (both file format and how displayed) - changing it to a 3D game (which sometimes comes up) is such a major change in many areas that it hardly would seem to be the same game after it is done. I also think that except for some balance, the spells and combat stuff is OK (but perhaps a bit fast). I also think that somewhat specific examples may be needed. For example, saying you want a 'fun game/fun quests/fun whatever' sounds good to me, but is somewhat vague - does that just mean more maps? Or what does it take to make a question fun vs boring? So after playing some single person non on-line games, some quick thoughts of mine: - NPCs in crossfire a really quite boring. Trying to have any conversation with them is often annoying (as trying to figure out correct words is sometimes difficult), but they are also very static - you go to the bar, and just see a bunch hanging around. Improving conversation is easy, but that doesn't remove the pretty static nature of them. Within other games, the NPCs move around - they can join you to help you do something, or maybe they are duping you into something (take me to my friend joe, and which point when you get near joe, the npc with you ends up attack joe, etc) And just seeing some wandering NPCs on the world map would add some color. - Maps: All to many are just hack and slash - if you're tough enough, you survive and win, if not, well, your dead - need to be more maps where the focus isn't killing everything. It's hard to really think what all types of puzzles there can be. And while it may not suit everyones taste, even having some maps where there are few/no monsters but instead a puzzle or gathering of items to reassemble or whatever would probably be interesting to some. Other problem I find is that often times, movement of both creatures and player is so fast that very little in the way of tactics come in - often time by the time you realize that weapon A isn't working, by the time you switch to weapon B, you're in big trouble Last problem is that I think the map content of crossfire is not expanding fast enough - this may be one reason why there are still lots of bad maps about. If you look at most commercial RPG games, it often isn't the gameplay that changes much between versions, but rather a completely new mapset (effectively), so there are new things to see, new dungeons to go in (with no clue what to find, etc). So for long term players, there really isn't any sense of newness - I don't play a lot, and one reason is because there isn't any sense of newness - it sort of goes down to playing these set of maps, then those, etc. One cause of this may be that most of us are more programmers than map makers, so we gravitate towards programming. It may be that we should aim for 1 big map addition per month/quarter - for example, a goal of making an underground dwarven city with 10 associated quests. If several people worked on such projects, it certainly would be achievable (and a nice benefit of several people working on it is that none of them would be familiar with all of it, so when they went to play it the first time, there would be portions of it they haven't seen before) - Immersion: Crossfire, given its limited sounds (and until recently, no music, but client side support for music is still needed) was really only a visual game - I know some people don't have any computer volume when playing crossfire, but for those of that do, having more sound effects to add ambiance. - Races/classes: Would be nice for more of these to have longer term affects than they do right now - we've discussed that in the past. Some could just be certain objects usable only by certain classes (helm only usable by wizards, no one else, etc), some could be more special maps (fighter guild hall only allowed to fighters), etc. I've probably rambled more than enough here. Some of these points are easier to do than others. From nicolas.weeger at laposte.net Sat Jun 2 04:07:44 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 2 Jun 2007 11:07:44 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <4660E7EC.2030105@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4660DAA0.4070004@telus.net> <4660E7EC.2030105@sonic.net> Message-ID: <200706021107.44885.nicolas.weeger@laposte.net> I realize my previous mail was quite vague, so I'll try to expand some :) What I mean by a fun game covers many things: * a coherent world. What is the story of Scorn? Why is there an underground city? This should be, at least partially, part of the game (for Scorn it's probably already the case, I don't know). Ok, we can have unrelated maps, sometimes, but let's try to not abuse that :) * coherent also means "if Navar bans undead/necromancer, why can an undead player enter?" * more non hack and slash quests. HnS/grinding can be fun, but it shouldn't be the only point. Make players think, force'em to know or travel the world, things like that make the game fun - assuming traveling is fun too. * as Mark said, we don't have tactics for now. Just go straight in monsters, if wrong sword/spell, oops, too bad, you're dead. IMO, there shouldn't be any way to die suddenly without some warning (concrete example: entrance of wizard tower, monsters you see are just birds/goblins - but if you don't take attention you fall into a pit and face 3 red dragons, oops). I am not advocating removing danger, or having a game where you can't die. Just that there should be more game balance about how fast you die (of course, if you ignore all warnings before doing the fire god, you'll die pretty fast, but that's because you didn't pay attention to the clues) * defined classes and races, with their limits. Currently, except the meditation skill of the monk, profession doesn't matter at all, you can get all skills. As you said, items usable only by some classes, or maybe limit the maximum skill level, or whatever. Or make it harder to train in things you don't use, whatever. Concerning static NPCs, yes, they are static - which is why you can script them using Python, using the animator (hopefully it isn't too broken). IMO we could almost have a special script per "important" NPC, that is part of the game. Scripting is programming, so we developers shouldn't have too many issues with that ;) And I'll also add, quest rewards could be scripted items, too. Fun example is the Occidental Mages weapons/rings. Scripting items isn't hard, and can be used to make interesting things (rhyzian amulet that works like a GPS). I agree map content (and graphic content) don't expand fast enough. But we must try to keep some coherence. Adding yet another HnS map is easy, doing a "real" quest takes more time. Just look at all abandonned maps in the tree :) Of course an incremental process can be done. Add a small map here, another there, link them, add some salt/hints, you're done. That's also why I (kind of) started to list quests, to know what exists, what should be improved/cleaned, and so on. Note that my mapper was improved to display "real" exits to other maps, closed exits, roads, so we can easily see what the world looks like. About removing stuff, yes, we should remove/rewrite/rebalance maps. But that should be done when we know what we want, not before. The same is true for archetypes - many are not used, and could be. And we could use much more archetypes (last time I tried to make a house, I couldn't find a sink, cupholders, you name it ;p). Code-wise, I'd like some documented things. How is slaying supposed to work? What are materials supposed to do? What does "undead" mean? How are monsters supposed to behave (see the bug about dark elves)? Some are obvious, some aren't, and need to be decided. I'd like to see some parts of the code rewritten, or simply trashed (obsolete protocol). On the other hand, this shouldn't be our aim - our aim is the fun part above. Code should be there to support the game. Got 5 mins? better work on a small map than do code :) (unless it's correcting bugs) I agree some things can be kepy: 2d view (but then, what perspective?), overall combat and spell system, maps format. But we need to balance a few things. So, concretely, the steps I'd do are: * decide how to plan/expand the world. What are the large regions? What is their history? * add this content, partially, in the game. Give relief to the world (what is the story of the dragon hangars? why is pupland terminal like that? you name it) * work on speed/ac/wc balance. Maybe not rewrite from scratch, but think really hard about it * document, document, document. We should have enough documentation so that anyone wanting to contribute can be pointed to the wiki/source tree and check rapidly "what kind of maps are allowed in Brest?". This also covers "what are materials supposed to do?", "how is slaying supposed to do?", "can an undead dragon enter the dragon guild?". We also need documentation for when people drop from the project and leave some partial stuff. * if possible, use the unit testing framework. Probably mostly for high-level stuff, but we can try to think of weird stuff. Granted, meaningful unit tests are hard to write... If I were to do a weird comparison, I would say I'd like a combat system kind of like Diablo II. You can die unexpectedly, but you can also plan, collaborate with others, retreat when needed, ... On the other hand, I'd like much more thinking/non HnS stuff :) The Pupland example is quite interesting (though I don't know all its gory details ;p). Different quests, thinking from the player, complex intrigue, all this is fun. A last thing. We sometimes don't know how to decide between different possibilities. That we should fix. We need ways to decide. Ideally, we should have a "map supervisor", a "graphics supervisor", a "game balance supervisor", a "code supervisor", people who try to maintain the overall coherence and can decide if/when we don't reach a consensus. Unfortunately, right now, we're not really enough for that, I'm afraid. So we'll have to do our best :) And I do realize up to now the way to decide is "you code and commit, you decided for others" (not a criticism, I did enough of that kind of decision ^_-) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Jun 3 05:38:25 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Jun 2007 12:38:25 +0200 Subject: [crossfire] "identification" skills patch In-Reply-To: <200705202256.04076.nicolas.weeger@laposte.net> References: <200705202256.04076.nicolas.weeger@laposte.net> Message-ID: <200706031238.25523.nicolas.weeger@laposte.net> > http://sourceforge.net/support/tracker.php?aid=1638868 is a patch that > makes the various identifying skills (smithing, alchemy, ...) work on a > zone instead of a single spot under the player. Committed the patch. Should behave like previous identification, except now a larger area :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Sun Jun 3 16:30:27 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 3 Jun 2007 23:30:27 +0200 Subject: [crossfire] Vertical map-tiling Message-ID: <200706032330.28127.nicolas.weeger@laposte.net> Hello. I remember, quite a long time ago, discussion about "vertical" map-tiling, that is from eg the top of a tower see the ground below, belonging to another map. Anyone remember that, and how it was implemented? I think it was like the 4 other map tiles, except used in a different way. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sun Jun 3 18:53:24 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Jun 2007 16:53:24 -0700 Subject: [crossfire] Vertical map-tiling In-Reply-To: <200706032330.28127.nicolas.weeger@laposte.net> References: <200706032330.28127.nicolas.weeger@laposte.net> Message-ID: <46635474.5020500@sonic.net> Nicolas Weeger wrote: > Hello. > > I remember, quite a long time ago, discussion about "vertical" map-tiling, > that is from eg the top of a tower see the ground below, belonging to another > map. > Anyone remember that, and how it was implemented? > > I think it was like the 4 other map tiles, except used in a different way. Don't know if it was ever really done, but I know it was theoretically possible. If we presume a square building with an interior courtyard, your first level would have to consist of at least 5 maps: 123 456 789 With the 5 map being common to all levels. You have to use 9 maps, because when tiling, the map has to tile with a map the same size, and can only tile to 1 map in each direction. So for second level, you would do something like: ABC D5E FGH And so on as you go up. Note that you have the layers below visbile to the next layer - perhaps the next layer, the main building doesn't go up, just towers at the corners, so could do something like: IBJ D5E KGL Note that you would basically use the inverse for layers 1 and 2 if you wanted a central tower that could see the terrain around it. and I believe I have a simple example in the test directory of a two store house which is done as: 12 and 13, where 1 is the common front yard, with 2 and 3 being the floors. From lalo.martins at gmail.com Sun Jun 3 19:01:13 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Mon, 4 Jun 2007 00:01:13 +0000 (UTC) Subject: [crossfire] Vertical map-tiling References: <200706032330.28127.nicolas.weeger@laposte.net> Message-ID: Also spracht Nicolas Weeger (Sun, 03 Jun 2007 23:30:27 +0200): > Hello. > > I remember, quite a long time ago, discussion about "vertical" > map-tiling, that is from eg the top of a tower see the ground below, > belonging to another map. > Anyone remember that, and how it was implemented? > > I think it was like the 4 other map tiles, except used in a different > way. That was the idea. It was never implemented, of course. Points I remember: - Any "nothing" spaces in the upper map, should display the lower map instead. Maybe we'd want some visual clue that the space is at a lower level, though. - And of course walking into one of those sends you down. - There should be an optional "offset", for the case the upper map is smaller? I'm not too keen on this one, better make the maps the same size and use "nothing" spaces as above. Also, this wasn't discussed before, but I'd like the map format to store a height between each vertically-tiled map and the one below it; preferably both. This way if we later come up with an use for that, we don't need to hurry back filling up all maps with values :-P best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From mwedel at sonic.net Sun Jun 3 19:29:36 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 03 Jun 2007 17:29:36 -0700 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706021107.44885.nicolas.weeger@laposte.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4660DAA0.4070004@telus.net> <4660E7EC.2030105@sonic.net> <200706021107.44885.nicolas.weeger@laposte.net> Message-ID: <46635CF0.3020909@sonic.net> Nicolas Weeger wrote: > I realize my previous mail was quite vague, so I'll try to expand some :) > > > What I mean by a fun game covers many things: > * a coherent world. What is the story of Scorn? Why is there an underground > city? This should be, at least partially, part of the game (for Scorn it's > probably already the case, I don't know). Ok, we can have unrelated maps, > sometimes, but let's try to not abuse that :) I agree - certainly more stories on why the ways things are would be good. This can also be used to explain other aspects of the game. Other questions are: What is the governement structure? Of the main towns on the main continent, is each effectively a city state, or is there a central king? Extra lore about the world could be used to explain other things. One could come up with something that each god basically created one of the races - gnarg created the dwarves, and they lived in the bug underground cavern. Lythandir created the elves, and they live in their forest town. Some of the other gods created some of the different races, which could explain why there is scorn, santo dominion, and navar city - since there are several different races of humans, those were some of the places they just lived. > * coherent also means "if Navar bans undead/necromancer, why can an undead > player enter?" Agree. OTOH, the security there is quite week - even if you're not undead, you could come in with a bunch of necromancy type items. > * more non hack and slash quests. HnS/grinding can be fun, but it shouldn't be > the only point. Make players think, force'em to know or travel the world, > things like that make the game fun - assuming traveling is fun too. True - it would be good if there were more things just out on the world. AT one time, the idea of the weather system was also to extend into having herbs and other stuff grow up - if you have to wonder from A to B, you might find some useful herbs for you. In some games, recovering an item from a place far away (but not particularly dangerous) is a not infrequent type of quest. But I also think that more varied rewards for quests would be nice - it would be nice to have some other things that could be given, like experience points, learning new skills, increasing reputation (an idea talked about before but never added), etc. And while a lot of this could be done with scripts, I'll state this: For any point that comes up where it could be done with a script, there should then be an example script set up that does that, with it clearly documented (ideally at the top of the script) with the values to change. It doesn't do me any good to say 'it can be done with a script' if it now takes me 2 hours to write/test that script or figure out if there is a suitable one elsewhere I can modify. In the case above, there should be a sample script that looks for an item in the player, and then gives the player some skill exp (or that skill if they don't have it). In that sample, at the top of the script would be the skill I want to grant/add exp to, the amount of exp to add, and the item it is looking for. It shouldn't be a need for me to look through the entier script to figure out what needs to be changed. > * as Mark said, we don't have tactics for now. Just go straight in monsters, > if wrong sword/spell, oops, too bad, you're dead. IMO, there shouldn't be any > way to die suddenly without some warning (concrete example: entrance of > wizard tower, monsters you see are just birds/goblins - but if you don't take > attention you fall into a pit and face 3 red dragons, oops). I am not > advocating removing danger, or having a game where you can't die. Just that > there should be more game balance about how fast you die (of course, if you > ignore all warnings before doing the fire god, you'll die pretty fast, but > that's because you didn't pay attention to the clues) Agree - instant death isn't really ever good, otoh it seems fair to me that if you just enter caves/dungeons at random, you're sort of on your own (finding the dragon cave in the nobility quest is hard, but if a low level character did, they would die pretty quickly, but to me, that would seem reasonable - its far enough off the beaten path that a low level character probably shouldn't be wandering there in the first place. As far as speed of combat/damage, I've had this idea I never got around to implementing: Add a settings option, like damage_factor, which is a percentage, with 100 being default. In the hit_... functions, modify damage calculation to do something like dam = dam * 100 / damage_factor. Some extra work here would need to be added to take care of rounding issues (I know there is code that does it for resistances). This makes it very easy to tune down the rate of damage, and thus how fast both players kill creatures and creatures kill players - it does change game play in some other effects - since damage is reduced, healing spells (or items) are effectively more powerful - they'll keep you alive longer. It's a matter of debate if spell/grace/hp regen should be similarly slowed - if you don't, it may mean that your mana would recharge enough during combat to do something with it again, and hp regeneration becomes even more powerful. But if you slow it down, then it would be painfully slow to regain those attributes after combat. I'd be tempted to not have those affected at first (or maybe a separate setting for that). I think this change is actually fairly easy to make, because I think almost all damage calculation goes through 1 function. > * defined classes and races, with their limits. Currently, except the > meditation skill of the monk, profession doesn't matter at all, you can get > all skills. As you said, items usable only by some classes, or maybe limit > the maximum skill level, or whatever. Or make it harder to train in things > you don't use, whatever. This has been discussed before, and I think a lot of good ideas/solutions come up with - just no one ever got time to make the changes. > > Concerning static NPCs, yes, they are static - which is why you can script > them using Python, using the animator (hopefully it isn't too broken). IMO we > could almost have a special script per "important" NPC, that is part of the > game. Scripting is programming, so we developers shouldn't have too many > issues with that ;) But here's the thing - if I have a quest to escort an NPC from scorn to navar city, what would that script look like? Right now, I envision it being pretty complicated - I think it'd probably be good to have some amount of C code backend to simplify it. for example, within the script, you'd probably really just want to be able to set waypoints (go to x,y, apply exit, got to x1,y1, etc). but let the C/monster code deal with it moving between those waypoints - in that way, it also can take care of if there are enemy monsters about, what to do in that case, path is blocked, etc. I know all this could be done in python, but it would seem to be become a pretty complicated python script at some point. From alex_sch at telus.net Sun Jun 3 20:11:47 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 03 Jun 2007 19:11:47 -0600 Subject: [crossfire] Vertical map-tiling In-Reply-To: <200706032330.28127.nicolas.weeger@laposte.net> References: <200706032330.28127.nicolas.weeger@laposte.net> Message-ID: <466366D3.9080001@telus.net> Nicolas Weeger wrote: > Hello. > > I remember, quite a long time ago, discussion about "vertical" map-tiling, > that is from eg the top of a tower see the ground below, belonging to another > map. > Anyone remember that, and how it was implemented? > > I think it was like the 4 other map tiles, except used in a different way. > > > Nicolas > Hmm, I'm not sure how this could be implemented, but this reminds me of an idea I had for tiling which could do this easily and much much more. Basically, the idea I had, was making "see-through portals" of sorts. They would be objects placed on a map, and they would 'open' to another map. They would work just like exits except one could see through them (they look like what's on the tile they teleport to) and spells/monsters/etc. would also be teleported while preserving their movement. These "portals" (which need a better name), could be placed on a map however one wishes, to create ANY pattern of custom 'tiling'. It's also plausible for a Gridarta to be made to automatically adjust to coordinates of each object and insert them to fill areas easily. The more I think about this, the easier it seems to me it would be to make, and it would allow this "vertical" map-tiling as well as so much more. Alex Schultz From yann.chachkoff at myrealbox.com Mon Jun 4 11:18:42 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Mon, 4 Jun 2007 18:18:42 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <46635CF0.3020909@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706021107.44885.nicolas.weeger@laposte.net> <46635CF0.3020909@sonic.net> Message-ID: <200706041818.49187.yann.chachkoff@myrealbox.com> Le lundi 4 juin 2007, Mark Wedel a ?crit : > Extra lore about the world could be used to explain other things. > A lot of lore material is already available for a long time on the wiki. The problem is not really adding extra lore, but using what's already written in maps. Writing more lore is pointless if it keeps being ignored in the map-making process. > And while a lot of this could be done with scripts, I'll state this: For > any point that comes up where it could be done with a script, there should > then be an example script set up that does that, with it clearly documented > (ideally at the top of the script) with the values to change. > Although creating templates or grouping often used script functions into libraries can definitely be done, it is unrealistic to expect a template for each use we can possibly think about; a lot of code would be specific to each NPC anyway. > It doesn't do me any good to say 'it can be done with a script' if it now > takes me 2 hours to write/test that script or figure out if there is a > suitable one elsewhere I can modify. > Just for the record, spending hours to figure out how the C code is supposed to work is already necessary, so I wonder why you are insisting so much on that specific point. > In the case above, there should be a > sample script that looks for an item in the player > This is called creating a library and it can of course be done once we have a clear view of the needed common functions to put into such a library. > I think this change is actually fairly easy to make, because I think > almost all damage calculation goes through 1 function. > Except that changing the pace of combats also involves changes of a lot of maps, which were designed with the idea of fast hack-n-slash. Rooms full of monsters will become either impossible to empty, or very boring to do. I don't think you can dissociate the code modifications from map issues it will create. > But here's the thing - if I have a quest to escort an NPC from scorn to > navar city, what would that script look like? Right now, I envision it > being pretty complicated - I think it'd probably be good to have some > amount of C code backend to simplify it. > Python supports the use of script libraries, so common useful functions could easily be moved into such a library, removing the need to add C code. I also have a hard time understanding how replacing a supposedly complex Python script by an equally complicated C code would make things simpler in the end. > I know all this could be done in > python, but it would seem to be become a pretty complicated python script > at some point. > So what ? Scripts weren't made with the idea of restricting their usage to "Hello World" kind of uses. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070604/75175865/attachment-0001.pgp From nicolas.weeger at laposte.net Mon Jun 4 12:27:14 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 4 Jun 2007 19:27:14 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <46635CF0.3020909@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706021107.44885.nicolas.weeger@laposte.net> <46635CF0.3020909@sonic.net> Message-ID: <200706041927.14494.nicolas.weeger@laposte.net> > But I also think that more varied rewards for quests would be nice - it > would be nice to have some other things that could be given, like > experience points, learning new skills, increasing reputation (an idea > talked about before but never added), etc. Been working on that :) My quest reward for Lursendis is, hopefully, quite fun :) And I got other items, working on the corresponding quests. (credit where credit is due: Yann helped for the ideas :)) > And while a lot of this could be done with scripts, I'll state this: For > any point that comes up where it could be done with a script, there should > then be an example script set up that does that, with it clearly documented > (ideally at the top of the script) with the values to change. > > It doesn't do me any good to say 'it can be done with a script' if it now > takes me 2 hours to write/test that script or figure out if there is a > suitable one elsewhere I can modify. In the case above, there should be a > sample script that looks for an item in the player, and then gives the > player some skill exp (or that skill if they don't have it). In that > sample, at the top of the script would be the skill I want to grant/add exp > to, the amount of exp to add, and the item it is looking for. It shouldn't > be a need for me to look through the entier script to figure out what needs > to be changed. Moot point, as Yann said. Yes, we'll document scripts, but at some point they'll need to be customized. Granted, some generic scripts could be made when they're needed, and their parameter sent in the event object itself (eg: what skill to add to). Check http://wiki.metalforge.net/doku.php/cfpython#scripts_part_of_crossfire_default_maps for existing scripts - comments welcomed if not clear enough. Look at the scripts I committed yesterday for Lursendis (maps/python/monsters/[farnass|lursendis].py). Those are quite specific things. Some can be reused (moving on the same tile from the chicken script), but most is just custom code for this quest. Note that you can also do a plugin in C, if you prefer, check http://wiki.metalforge.net/doku.php/server_plugin#creating_a_plugin for details :) Of course feel free to ask if help is needed with the plugin API - the Python part is pretty well documented I think, the "raw" probably isn't. But again we're doing it wrong: first let's think of the kind of items we want, then let's make the scripts we need - not the other way around, "it would be great to be able to..." and never use that. I even volunteer to do scripts if people ask me, when they need something for a quest :) You mention a skill/exp giving script, want me to do it? Would it help you write/finish a quest? Would people actually use it? (see at the end of the mail) > But here's the thing - if I have a quest to escort an NPC from scorn to > navar city, what would that script look like? Right now, I envision it > being pretty complicated - I think it'd probably be good to have some > amount of C code backend to simplify it. > > for example, within the script, you'd probably really just want to be > able to set waypoints (go to x,y, apply exit, got to x1,y1, etc). but let > the C/monster code deal with it moving between those waypoints - in that > way, it also can take care of if there are enemy monsters about, what to do > in that case, path is blocked, etc. I know all this could be done in > python, but it would seem to be become a pretty complicated python script > at some point. Then, again, do a C plugin if you prefer. Heck, if people ask nicely enough, I'd even write a C++ basic plugin so people can code plugins in C++ - as long as people do write content! And we'll naturally refactor what we can when time comes. But again, that's backward thinking, code before contents - whereas it should be the other way, first think what you want, do code for it, refactor when needed. Ideally of course the code would be totally customizable, reusable, already refactored, but better to code then refactor that code and never use. Just look at the many things never used: quest system, multiplayer spells, new material code - that should give some hints, I guess :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Mon Jun 4 12:29:55 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 4 Jun 2007 19:29:55 +0200 Subject: [crossfire] Code cleaning Message-ID: <200706041930.00142.nicolas.weeger@laposte.net> Hello. I'd like to remove the following things from trunk: * multiplayer spells support. Never used, and current implementation is bad I think * quest system. Again, that's not really thought of, would need much more thinking - or even specific coding per quest * "new material" code. No one seems to know what it's supposed to do, how it works (does someone actually use it?). I'd keep the idea of material flags / combination, but remove other things. Opinions? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070604/fda44a0e/attachment.pgp From nicolas.weeger at laposte.net Mon Jun 4 13:41:23 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 4 Jun 2007 20:41:23 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <46635CF0.3020909@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706021107.44885.nicolas.weeger@laposte.net> <46635CF0.3020909@sonic.net> Message-ID: <200706042041.23938.nicolas.weeger@laposte.net> > But I also think that more varied rewards for quests would be nice - it > would be nice to have some other things that could be given, like > experience points, learning new skills, increasing reputation (an idea > talked about before but never added), etc. Just added an experience rewarder script. Documentation is available at http://wiki.metalforge.net/doku.php/cfpython#experience_rewarder Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Mon Jun 4 15:29:04 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 4 Jun 2007 22:29:04 +0200 Subject: [crossfire] Bracers Message-ID: <200706042229.04493.nicolas.weeger@laposte.net> Hello. Related to bug http://sourceforge.net/tracker/index.php?func=detail&aid=1730874&group_id=13833&atid=113833 about bracers not working correctly, the issue is simple: fix_object() treats bracers differently than a girdle. Bracers are actually considered like a FORCE, and has specific treatment. Is there somewhere a document describing why this is the case? More generally, is there a document explaining why some items are fixed in a certain way, and others in another? :) (also, wondering about fix_living, sure sounds messy with all those cases...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From alex_sch at telus.net Mon Jun 4 16:33:37 2007 From: alex_sch at telus.net (Alex Schultz) Date: Mon, 04 Jun 2007 15:33:37 -0600 Subject: [crossfire] Code cleaning In-Reply-To: <200706041930.00142.nicolas.weeger@laposte.net> References: <200706041930.00142.nicolas.weeger@laposte.net> Message-ID: <46648531.3010507@telus.net> Nicolas Weeger wrote: > Hello. > > I'd like to remove the following things from trunk: > * multiplayer spells support. Never used, and current implementation is bad I > think > * quest system. Again, that's not really thought of, would need much more > thinking - or even specific coding per quest > * "new material" code. No one seems to know what it's supposed to do, how it > works (does someone actually use it?). I'd keep the idea of material flags / > combination, but remove other things. > > Opinions? > IMHO all of things are good to remove for cleaning. It might be interesting to bring ideas (and perhaps some code) from those back later, but for now I think cleaning them out as they are unused would be better. Alex Schultz From mwedel at sonic.net Mon Jun 4 16:51:28 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Jun 2007 14:51:28 -0700 Subject: [crossfire] Bracers In-Reply-To: <200706042229.04493.nicolas.weeger@laposte.net> References: <200706042229.04493.nicolas.weeger@laposte.net> Message-ID: <46648960.1060808@sonic.net> Nicolas Weeger wrote: > Hello. > > Related to bug > http://sourceforge.net/tracker/index.php?func=detail&aid=1730874&group_id=13833&atid=113833 > about bracers not working correctly, the issue is simple: fix_object() treats > bracers differently than a girdle. Bracers are actually considered like a > FORCE, and has specific treatment. > > Is there somewhere a document describing why this is the case? > More generally, is there a document explaining why some items are fixed in a > certain way, and others in another? :) > > (also, wondering about fix_living, sure sounds messy with all those cases...) Probably not. This code I think goes way way back, where what certain items could grant was based on type. A lot of crossfire seemed to follow the AD&D model, where bracers only granted a few specific things, so may not have been an issue. The trunk should probably be changed so that all equipable are treated the same way - same attributes grant same bonuses, etc. Some of this may require some extra work (IIRC, exp is used for some objects to denote bonus speed - a bonus_speed attribute should really be used instead). That not only simplifies the code, but also makes it easier for map makers to understand. From mwedel at sonic.net Mon Jun 4 16:59:49 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Jun 2007 14:59:49 -0700 Subject: [crossfire] Code cleaning In-Reply-To: <200706041930.00142.nicolas.weeger@laposte.net> References: <200706041930.00142.nicolas.weeger@laposte.net> Message-ID: <46648B55.9040003@sonic.net> Nicolas Weeger wrote: > Hello. > > I'd like to remove the following things from trunk: > * multiplayer spells support. Never used, and current implementation is bad I > think > * quest system. Again, that's not really thought of, would need much more > thinking - or even specific coding per quest > * "new material" code. No one seems to know what it's supposed to do, how it > works (does someone actually use it?). I'd keep the idea of material flags / > combination, but remove other things. sounds good to me. From mwedel at sonic.net Mon Jun 4 17:34:16 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 04 Jun 2007 15:34:16 -0700 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706041818.49187.yann.chachkoff@myrealbox.com> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706021107.44885.nicolas.weeger@laposte.net> <46635CF0.3020909@sonic.net> <200706041818.49187.yann.chachkoff@myrealbox.com> Message-ID: <46649368.9030703@sonic.net> Yann Chachkoff wrote: > Le lundi 4 juin 2007, Mark Wedel a ?crit : >> Extra lore about the world could be used to explain other things. >> > A lot of lore material is already available for a long time on the wiki. The > problem is not really adding extra lore, but using what's already written in > maps. Writing more lore is pointless if it keeps being ignored in the > map-making process. Fair enough. It is sometimes hard to find the correct information, or if there is even correct information. It may be a question if there is a better way to organize the wiki - I don't know if there is - unless one is to read everything on the wiki, it can get confusing fairly quickly - you see same/similar topics under different sub pages, and in same cases, they go to the same page, in other cases, they go to different topis, so it can make it difficult to know if you've actually read all the relevant informatin. > >> And while a lot of this could be done with scripts, I'll state this: For >> any point that comes up where it could be done with a script, there should >> then be an example script set up that does that, with it clearly documented >> (ideally at the top of the script) with the values to change. >> > Although creating templates or grouping often used script functions into > libraries can definitely be done, it is unrealistic to expect a template for > each use we can possibly think about; a lot of code would be specific to each > NPC anyway. But I'm not saying that I need a sample script for every possible NPC out there. I am saying that there should be sample scripts for some of the more frequently used/desired type of NPCS, or scripts in general. sure, if I'm asking for something fairly obscure or something that will be used once, I should expect that I'll need to write my own script. But if all I want is an NPC that takes and item and gives an exp reward, that should be standard enough that I shouldn't need to write that from scratch. Likewise, an NPC which I can program to move about shouldn't be so uncommon that I need to write that from scratch either. It is a fair discussion if these are really common enough things, etc. But I was stating that from my point, these are things that should be added to 'future crossfire'. > >> It doesn't do me any good to say 'it can be done with a script' if it now >> takes me 2 hours to write/test that script or figure out if there is a >> suitable one elsewhere I can modify. >> > Just for the record, spending hours to figure out how the C code is supposed > to work is already necessary, so I wonder why you are insisting so much on > that specific point. But a map maker should not need to look at the code to write a map. If things are documented correctly (which certainly isn't always the case), they just modify certain object attributes to get what they need. Now at some point, someone actually wrote the C code to put that logic in. I'm basically saying that for common scripts, that same level of work should be done with sample python scripts. Also, keep in mind that not all map makers are going to be programmers. So if such a map makers asks 'how do a I do foo', where foo is a fairly basic feature, saying 'you can write a python script to do it' is fairly useless for that person. >> I think this change is actually fairly easy to make, because I think >> almost all damage calculation goes through 1 function. >> > Except that changing the pace of combats also involves changes of a lot of > maps, which were designed with the idea of fast hack-n-slash. Rooms full of > monsters will become either impossible to empty, or very boring to do. I > don't think you can dissociate the code modifications from map issues it will > create. Maybe. If it becomes boring, I'd say that is more an issue for the player (and perhaps a bug on the map) - remember, such a change shouldn't necessarily change the difficulty of things much, just the pace. I'd almost say that any map that is so full of monsters such that it becomes boring to hack through them with a slower damage rate, that probably qualifies as not a very good map in the first place. A couple other thoughts I have: 1) I think sometimes we become overly cautious about making changes that may have bad effects or create other things that need fixing - the problem is that this tends to paralyze us into not making any change at all, which doesn't help us go forward. 2) Given this would be something in the settings, and the default would keep behavior as it is now, there really isn't much downside - changing the settings makes it easy to see what the affects are (and perhaps other things that need to be adjusted, like spawn rate of monsters), but does make it easy to see what the effects are and how it plays out. > >> But here's the thing - if I have a quest to escort an NPC from scorn to >> navar city, what would that script look like? Right now, I envision it >> being pretty complicated - I think it'd probably be good to have some >> amount of C code backend to simplify it. >> > Python supports the use of script libraries, so common useful functions could > easily be moved into such a library, removing the need to add C code. > I also have a hard time understanding how replacing a supposedly complex > Python script by an equally complicated C code would make things simpler in > the end. My point above is that if I write a script that moves an NPC, I basically want something like: move_to(x,y); apply_exit(); move_to(x1, y1); move_to(x2, y2); move_to(x3, y3); apply_exit(); move_to(.., ..) Where each action doesn't get processed until it does the previous one (we don't start move to x2,y2 until we reach x1, y1, etc. In addition, that move logic should probably have some options, like avoid obstacles (if something is in the way, will change course), will pick up things while it moves, will (or won't) attack enemy creatures as it moves, etc. How exactly all that logic is done, I don't really care much - if it is with python libraries, fine. If there is C code to help, fine. One concern on something like this, especially if there are a lot of NPCs about, is actual performance - if all done in python code, I'd have to imagine there'd be a fair amount of extra overhead as it examines the objets on all the surrounding spacing, as it looks for alternative paths, etc. From crossfire at kahnert.de Tue Jun 5 15:08:42 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Tue, 5 Jun 2007 22:08:42 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706012316.15083.nicolas.weeger@laposte.net> Message-ID: <20070605200842.GA27233@cthulhu.desy.de> Hello, On Fri, Jun 01, 2007 at 11:16:14PM +0200, Nicolas Weeger wrote: > What kind of game do we want? What kind of gameplay? I'm not a CF developer, just my $0.02. Crossfire is / was the base for some other games. In some cases just the idea / gameplay in some other cases even the code. Check out FIXME_name. They play with only two spells and two prayers (magic bullet, probe, Cause Light Wounds and Minor Healing since years) but they have more players than CF. The people like good graphics. The gameplay / deep isn't that important against a pretty look and feel. You could focus on gameplay, maps and features without improving the garphics. Ok, will be a nice game for a few players who also like to play [for example] nethack. And it will be fun for the developers, too. :) But you won't reach much players. > So, what would be everyone's vision of the game? On Fri, Jun 01, 2007 at 08:45:48PM -0700, Mark Wedel wrote: > To me, the biggest immutable thing is probably the map (both file > format and how displayed) - changing it to a 3D game (which sometimes > comes up) is such a major change in many areas that it hardly would > seem to be the same game after it is done. That's the point. A 3D game is much more work than 2D - in any cases. And you have to make a decision, which way you like to go. 1) Stay with 2D and improve gameplay / deep. 2) 3D game, lot of coding work, and also a lot of design work, new maps are harder to create, ... 1,1 Top If you decide for 1), you don't need to call it Crossfire2. If you decide for 2), you need to ask yourself if you have the people doing all the graphics work... If the CF team has good designers, why didn't changed the art design over the past few years? But wouldn't better graphics result into more player with more people supporting the project? It's a hard decision. And having a bad 3D implementation would make it worser than better. I played nethack on telnet, very nice game. But I don't like Falcon's Eye - bad gameplay (same game, different display). > - NPCs in crossfire a really quite boring. Trying to have any > conversation with them is often annoying (as trying to figure out > correct words is sometimes difficult), but they are also very static - > you go to the bar, and just see a bunch hanging around. Improving > conversation is easy, but that doesn't remove the pretty static nature > of them. Yesterday on metalforge: ScottyOB has entered the game. ScottyOB chats: Is it just me, or is this game slow? A chats: Whats your speed? ScottyOB chats: I don't know... This is the first time I've played this before. I just mean moving around town ScottyOB chats: Like, I'd push the right arrow, and wait half a second before he moves? A chats: If you're carrying a lot of stuff, you'll be very slow. A chats: Or if you have a slow internet connection. ScottyOB chats: I have no idea how to start leaning this game ScottyOB chats: How do I interact with people? ScottyOB chats: NPC's A chats: "say hi" ScottyOB chats: I think I'll head back to my MUD's. I didn't get into this game :( ScottyOB chats: yeah, I don't get it. It tells me to go west for beginners, and there's just a wall there :( ScottyOB chats: and all this guy keeps asking is "What did you say?" whever I try to speak with him ScottyOB quits the game. > - Maps: All to many are just hack and slash - if you're tough enough, > you survive and win, if not, well, your dead - need to be more maps > where the focus isn't killing everything. So you like to stay on a 2D map? For 3D you need to change every map anyway... If you ask me, I would say the first question of all should be: Stay with 2D or implement 3D? Kind regards, J?rgen From mwedel at sonic.net Tue Jun 5 16:10:46 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 05 Jun 2007 14:10:46 -0700 Subject: [crossfire] Summary, was Re: The future of Crossfire In-Reply-To: <200706012316.15083.nicolas.weeger@laposte.net> References: <200706012316.15083.nicolas.weeger@laposte.net> Message-ID: <4665D156.8000208@sonic.net> I think the discussions started to get off topic a bit (my fault), going more into implementation details vs the broad these are things we should/want to do. so I thought I'd go back and summarize those. If I'm missing something, let me know. I'm trying to keep things general here, and not go into details on how to do it. I think once we have the topics down, the we can look at how to do it. Some may be easy, others may be hard: - Better maps/quests - more on the thinking side, less on the 'you just need to kill everything and your done' side. How many more maps are needed is a more difficult question - at some level, this is ongoing, but we probably want to have some sort of goal for X number of maps by 2.0 or something. Some of these may be localized puzzles (in the sense that everything for the puzzle is in the dungeon itself), others may be broader, like pupland, where clues are all over the place, etc. - Remove some of the old/bad maps - this can be harder to determine - what is really a 'bad' map? Maps with all hack and slash and no puzzle are not particularly interesting, but at the same time, if we'd remove all of those, wouldn't be much left - it may be more that we need to better work on categorizing the maps or something - that's a puzzle dungeon, that is hack and slash, etc, and somehow have those tags on the exits themselves, so if you wander accross a map, you could know the type of map (plus perhaps other information, like level range?) Because that is certainly another annoying point - finding some map and then finding it is way too easy or too hard - because many maps mix monsters, you can't necessary look at the first few monsters to know. - Better NPCs. NPCs should be more visible - some wander about town, some perhaps in the wilderness - as of now, they pretty much all just hang out in the tavern, which doesn't add much color - Better NPC conversations - for many NPC's, trying to figure out what they know and getting them to say it can be frustrating since it is specific word match and many times players don't know what word - Better NPC interaction - in many cases, giving/taking items is a bit confusion, since it is an altar nearby the NPC which is doing the actual work, so that if the NPC moves away, or you just can't figure out the right space, the transaction doesn't work. - Slow down combat - combat is too fast so there is no tactics. Combat should be slowed down so that there are tactics and time to react to events. IMO, crossfire should be an adventure/RPG game more than an action game. Note that slowing down combat will likely have other effects - reduce gain of exp, reduce gain of wealth, etc. - Add better (some?) sound/music support. Music files are on the tracker, and so map level music probably isn't hard. The game is missing lots of potential sound effects (just things like gates opening), so would be nice to be able to add more to give a more immersive feel. - Races & Classes: Need to be more distinctive. Perhaps several races should be removed (not especially distinctive from one another- was more relevant back when race & class was the same thing). Classes need to be redone so that there is more importance in choosing the class you take beyond starting skills, so that high level wizards and fighters actually look quite a bit different. - Coherent world - rules should apply that make sense. A lot of this may be in backstory on the wiki - it might be nice to move more of this (or copies of this) in game, in books in the library, etc. - Add missing documentation - everything about archetypes should be documented. Some code cleanup likely in order to make objects behave in a consistent fashion. - Better testing - make more use of testing framework. From nicolas.weeger at laposte.net Wed Jun 6 12:20:15 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 6 Jun 2007 19:20:15 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <46649368.9030703@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706041818.49187.yann.chachkoff@myrealbox.com> <46649368.9030703@sonic.net> Message-ID: <200706061920.15283.nicolas.weeger@laposte.net> > Fair enough. It is sometimes hard to find the correct information, or if > there is even correct information. It may be a question if there is a > better way to organize the wiki - I don't know if there is - unless one is > to read everything on the wiki, it can get confusing fairly quickly - you > see same/similar topics under different sub pages, and in same cases, they > go to the same page, in other cases, they go to different topis, so it can > make it difficult to know if you've actually read all the relevant > informatin. Then feel free to ask on the list :) People will answer if they wrote about the subject on the wiki :) > I am saying that there should be sample scripts for some of the more > frequently used/desired type of NPCS, or scripts in general. sure, if I'm > asking for something fairly obscure or something that will be used once, I > should expect that I'll need to write my own script. > > But if all I want is an NPC that takes and item and gives an exp reward, > that should be standard enough that I shouldn't need to write that from > scratch. Yes. But no one so was used the plugins/scripting support at all. Now we are starting to see a few things, and as I said I'm ready to develop if people need help - but the mere fact no one asked also means there was no need. So call to all map makers: imagine things! Dream of fun things! You'll get help for scripting if you need it. > 1) I think sometimes we become overly cautious about making changes that > may have bad effects or create other things that need fixing - the problem > is that this tends to paralyze us into not making any change at all, which > doesn't help us go forward. Maybe, but game balance can be hard to maintain. Having a 2.0 branch is the right opportunity for this kind of things. So let's break havoc! :) > My point above is that if I write a script that moves an NPC, I > basically want something like: > > move_to(x,y); > apply_exit(); > move_to(x1, y1); > move_to(x2, y2); > move_to(x3, y3); > apply_exit(); > move_to(.., ..) > > Where each action doesn't get processed until it does the previous one > (we don't start move to x2,y2 until we reach x1, y1, etc. > > In addition, that move logic should probably have some options, like > avoid obstacles (if something is in the way, will change course), will pick > up things while it moves, will (or won't) attack enemy creatures as it > moves, etc. No, you should say: move_to(exit_x, exit_y) apply_exit() move_to(other_exit_x, other_exit_y) Note that you can already - in Python import CFMove and use get_object_to(object, x, y) ; in C use the cf_object_move() wrapper. > How exactly all that logic is done, I don't really care much - if it is > with python libraries, fine. If there is C code to help, fine. One > concern on something like this, especially if there are a lot of NPCs > about, is actual performance - if all done in python code, I'd have to > imagine there'd be a fair amount of extra overhead as it examines the > objets on all the surrounding spacing, as it looks for alternative paths, We'll deal with performance issue when we encounter it :) Let's first write content :) We can always rewrite parts in C later, tweak stuff, whatever - many possibilities, which we'll use when the need arises. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From nicolas.weeger at laposte.net Wed Jun 6 12:47:00 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 6 Jun 2007 19:47:00 +0200 Subject: [crossfire] Summary, was Re: The future of Crossfire In-Reply-To: <4665D156.8000208@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4665D156.8000208@sonic.net> Message-ID: <200706061947.04197.nicolas.weeger@laposte.net> > - Better maps/quests - more on the thinking side, less on the 'you just Agreed. > - Remove some of the old/bad maps - this can be harder to determine - what I'd rather recycle them if possible. We don't have that many map makers :) As a related note, I'd use the 'lore' field of maps to describe what quests they are part, things like that (lore is never displayed except by DMs using the dumpmap command). Splitting the author field (as a feature request says) could also help, maybe even a special "quest" field. But that's really not that an urgent thing. > - Better NPCs. NPCs should be more visible - some wander about town, some > perhaps in the wilderness - as of now, they pretty much all just hang out > in the tavern, which doesn't add much color *nods* > - Better NPC conversations - for many NPC's, trying to figure out what they > know and getting them to say it can be frustrating since it is specific > word match and many times players don't know what word Yann's CFDialog will help, we just need imagination for creating the dialogs :) > - Better NPC interaction - in many cases, giving/taking items is a bit > confusion, since it is an altar nearby the NPC which is doing the actual > work, so that if the NPC moves away, or you just can't figure out the right > space, the transaction doesn't work. Scripting will help. And/or use a trick (in Lursendis quest, a NPC asks the player to put ingredients in a stove. A hook on its close event makes the NPC check the contents). > - Slow down combat - combat is too fast so there is no tactics. Combat > should be slowed down so that there are tactics and time to react to > events. IMO, crossfire should be an adventure/RPG game more than an action > game. Note that slowing down combat will likely have other effects - > reduce gain of exp, reduce gain of wealth, etc. Agreed, to the condition we don't become a turn-based game :) Let's say a reasonable reaction time and planning should save one's life often, unless really going in weird places or really unlucky. I'd add stats (wc/ac/...) rebalancing, while we're at it :) > - Add better (some?) sound/music support. Music files are on the tracker, > and so map level music probably isn't hard. The game is missing lots of > potential sound effects (just things like gates opening), so would be nice > to be able to add more to give a more immersive feel. Agreed. We need client support, though. > - Races & Classes: Need to be more distinctive. Perhaps several races > should be removed (not especially distinctive from one another- was more > relevant back when race & class was the same thing). Classes need to be > redone so that there is more importance in choosing the class you take > beyond starting skills, so that high level wizards and fighters actually > look quite a bit different. Yep. > - Coherent world - rules should apply that make sense. A lot of this may > be in backstory on the wiki - it might be nice to move more of this (or > copies of this) in game, in books in the library, etc. Agreed. > - Add missing documentation - everything about archetypes should be > documented. Some code cleanup likely in order to make objects behave in a > consistent fashion. Agreed, but shouldn't be the priority. Documenting when fixing, yes. Documenting just to document, well, rather do something else if you can (what? I did document like crazy just for the sake of it? No, you're just dreaming ^_-) > - Better testing - make more use of testing framework. Harder to do. Writing real meaningful tests takes almost as much patience as writing the code to be tested, and is error-prone too. I'd rather add assert() every place it makes sense. More important, document the intended behaviour (granted, a unit test is used for that, but sometimes it's not worth writing). What are abilities supposed to do? What should be the behaviour of fleeing NPCs, especially those that have a bow/horn/rod to fire with? IMO, this should be our medium to long term. Of course if we could do all this in a reasonable delay, it could be into CF 2.0, but it shouldn't delay the release too much just for that. Better release incremental things if possible. As usual, we also depend on people actually doing the code/work at some point :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070606/81acdfb5/attachment.pgp From mwedel at sonic.net Wed Jun 6 22:46:36 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 06 Jun 2007 20:46:36 -0700 Subject: [crossfire] Summary, was Re: The future of Crossfire In-Reply-To: <200706061947.04197.nicolas.weeger@laposte.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4665D156.8000208@sonic.net> <200706061947.04197.nicolas.weeger@laposte.net> Message-ID: <46677F9C.9000805@sonic.net> Nicolas Weeger wrote: > As a related note, I'd use the 'lore' field of maps to describe what quests > they are part, things like that (lore is never displayed except by DMs using > the dumpmap command). Splitting the author field (as a feature request says) > could also help, maybe even a special "quest" field. But that's really not > that an urgent thing. Not sure, but I think the maplore field was envisioned as something that could be collected and then put into in game material (on a cave deep in the forest there is a power weapon) type of messages in books or scrolls, or even NPC's perhaps. But nothing preventing the addition of other fields to hold game information (related quests, etc). Or maybe depending on the format of the data itself, could be in the lore. The lore idea, and discussion on it, I thought were really good. It was just something never finished - lots of things like that in crossfire. >> - Slow down combat - combat is too fast so there is no tactics. Combat >> should be slowed down so that there are tactics and time to react to >> events. IMO, crossfire should be an adventure/RPG game more than an action >> game. Note that slowing down combat will likely have other effects - >> reduce gain of exp, reduce gain of wealth, etc. > > Agreed, to the condition we don't become a turn-based game :) > Let's say a reasonable reaction time and planning should save one's life > often, unless really going in weird places or really unlucky. I'd add stats > (wc/ac/...) rebalancing, while we're at it :) I don't think crossfire can ever become turn based, not so long as it remains multiplayer. A fair amount of rebalancing is probably needed - speed, weapon speed, and as said, wc and ac are also a bit out of whack. > >> - Add better (some?) sound/music support. Music files are on the tracker, >> and so map level music probably isn't hard. The game is missing lots of >> potential sound effects (just things like gates opening), so would be nice >> to be able to add more to give a more immersive feel. > > Agreed. We need client support, though. Yes, I was planning on looking at that soon. > >> - Races & Classes: Need to be more distinctive. Perhaps several races >> should be removed (not especially distinctive from one another- was more >> relevant back when race & class was the same thing). Classes need to be >> redone so that there is more importance in choosing the class you take >> beyond starting skills, so that high level wizards and fighters actually >> look quite a bit different. > > Yep. It may be a question of how many races and how many classes there should be. IT seems to me that there are a lot of classes in addition to races. We've had past discussions on some aspects - one thing may be to have a more basic selection of classes than we have now, with an idea of some custom class creation method, so that we don't have to try and cover all all possible magic/skill combos like we do now. >> - Add missing documentation - everything about archetypes should be >> documented. Some code cleanup likely in order to make objects behave in a >> consistent fashion. > > Agreed, but shouldn't be the priority. Documenting when fixing, yes. > Documenting just to document, well, rather do something else if you can > (what? I did document like crazy just for the sake of it? No, you're just > dreaming ^_-) But in some cases, it isn't clear what the correct behavior is - in those, we should just document something (x behaves like ...) vs trying to write in exceptions, etc. I'm personally in favor of clean code with clear meanings vs code with lots of exceptions, questions on how it should operate, etc. > > IMO, this should be our medium to long term. Of course if we could do all this > in a reasonable delay, it could be into CF 2.0, but it shouldn't delay the > release too much just for that. Better release incremental things if > possible. We should probably add these things to the main TODO list. it may be worth while to add these items to the list. OTOH, a fair number may already be there. The problem is that the TODO list is so long that it sometimes becomes hard to figure out what should really be tackled next. I'll note that the TODO list on the wiki (http://wiki.metalforge.net/doku.php/dev_todo_new) often seems more code oriented, where a lot of the changes we're discussing here are more map level level. In fact, of the list I did, arguably very few of those require code changes - many might just be archetype and map changes. > As usual, we also depend on people actually doing the code/work at some > point :) Right - and the problem there is that whenever people are volunteers, they'll work on what they want to work on, and not necessarily lists like this that we put together. From nicolas.weeger at laposte.net Thu Jun 7 12:29:36 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Thu, 7 Jun 2007 19:29:36 +0200 Subject: [crossfire] Code cleaning, part 2 Message-ID: <200706071929.39369.nicolas.weeger@laposte.net> Hello. Here are more things I'd like to remove from trunk: Obsolete/old protocol things: * item1 support, map0 / map1 / map1a, and related things map2 makes obsolete (map_scroll, mapredraw, i think). Map2 is over one year old on the client side, so no excuse no not support that * non exp64 skill support. Again, this is quite old, all clients should support that. * face/face1 support. Again, obsoleted by face2 * pixmap/bitmap. From what I gather, those were used for xpm/bmp pics, replaced by png years ago * old 'Old_Mode' enum and related things in the code. I'm not even sure clients actually still support that. * Crossedit. Gridarta is much more powerful, Java will/is be free as speech, so supporting it doesn't seem that high priority. It isn't actively developed. Also of course remove related things ("editable" field from archetypes, things like that) As a side note: it would be nice to write (in protocol, archetypes, ...) the date a new thing (map2) making another "obsolete" (map1a) is committed, so we have a trace of "can be removed after some time" stuff. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070607/37223226/attachment.pgp From mwedel at sonic.net Thu Jun 7 18:45:13 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 07 Jun 2007 16:45:13 -0700 Subject: [crossfire] Code cleaning, part 2 In-Reply-To: <200706071929.39369.nicolas.weeger@laposte.net> References: <200706071929.39369.nicolas.weeger@laposte.net> Message-ID: <46689889.3040503@sonic.net> Nicolas Weeger wrote: > Hello. > > Here are more things I'd like to remove from trunk: > > Obsolete/old protocol things: > * item1 support, map0 / map1 / map1a, and related things map2 makes obsolete > (map_scroll, mapredraw, i think). Map2 is over one year old on the client > side, so no excuse no not support that > * non exp64 skill support. Again, this is quite old, all clients should > support that. > * face/face1 support. Again, obsoleted by face2 > * pixmap/bitmap. From what I gather, those were used for xpm/bmp pics, > replaced by png years ago No problem with all of that. > * old 'Old_Mode' enum and related things in the code. I'm not even sure > clients actually still support that. IMO, Old_Mode could go away. It isn't used by clients - rather it dates back before we had clients, where the method of connecting was to connect to the crossfire server (on that port), and then do something like 'add myhost:0' - at which point the server would open an x-connection to your host. there are some other commands supported in oldmode socket, like who, maps, etc. However, getting rid of old mode simplifies a fair amount of code (in particular, all the Socket_Command stuff could also go away). It would seem to me that requiring authentication (in the form of a character) isn't a bad thing. Also, I seem to recall some text like clients? If so, it would be easy enough to perhaps modify one of those to give an old socket like capabilities (you run the client, log in, and it lets you do maps, who, whatever, but its only logic is to encode/decode the packets and print out the drawinfo stuff - it doesn't try to deal with map, items, etc). But I'm not even sure if that functionality is needed. Note that with the above changes, I think both the client and server should get a bump in protocol version numbers. > > * Crossedit. Gridarta is much more powerful, Java will/is be free as speech, > so supporting it doesn't seem that high priority. It isn't actively > developed. Also of course remove related things ("editable" field from > archetypes, things like that) I'm presuming you're just going to remove this stuff from the trunk, and not the stable release, correct? In which case, to diffuse some issues, one could still run crossedit from the stable area so long as things don't change in incompatible ways (which I don't expect to happen anytime soon). > > > As a side note: it would be nice to write (in protocol, archetypes, ...) the > date a new thing (map2) making another "obsolete" (map1a) is committed, so we > have a trace of "can be removed after some time" stuff. Fair enough - I'll try to remember that in the future. However, you can probably do a svn info (or is it svn log) to see when commits where and what the messages are, so could perhaps back date some of this. > > Nicolas > > > ------------------------------------------------------------------------ > > _______________________________________________ > crossfire mailing list > crossfire at metalforge.org > http://mailman.metalforge.org/mailman/listinfo/crossfire From mail-lists+cfdev at dogphilosophy.net Thu Jun 7 21:42:52 2007 From: mail-lists+cfdev at dogphilosophy.net (mail-lists+cfdev at dogphilosophy.net) Date: Thu, 7 Jun 2007 20:42:52 -0600 Subject: [crossfire] The future of Crossfire In-Reply-To: <4660E7EC.2030105@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4660DAA0.4070004@telus.net> <4660E7EC.2030105@sonic.net> Message-ID: <200706072042.52712.mail-lists+cfdev@dogphilosophy.net> Where to start, let's see... I suppose it's helpful for context if I start with how I think of Crossfire already, since the premise is that it should improve without changing what it is now. Of course, if I am completely off-base on this, at least you'll know where I'm coming from here... I think of Crossfire as a mash-up of a tile-based, semi-real-time strategy RPG with a "Gauntlet"-like style of play, and possessing multiplayer capability. (I should add that I think this is something that makes Crossfire relatively unique, not a bad thing.) I say "semi-real-time" because although it is technically "real-time", the tile-based movement makes it feel almost like a turn-based game, though the turns are REALLY short (I think slowing the game down a bit would help enhance this effect, and make it a lot easier for the play to be more tactical/strategic than it is now.) I like the gigantic map and the already-large variety of things in the world, and adding more will only make it better in my opinion. One of the joys of playing Crossfire, in my opinion, is just exploring and finding new things. The only problem with the existing map that has come up a few times in one form or another is that it's occasionally difficult to find a "Bed to Reality". Adding a few more Inns or their equivalent around the countryside (and making sure they're not too hard to find in big cities) would be helpful for that. Of course, adding more stuff brings up the problem of graphics (and sounds). It occurs to me that there are a number of other open-source games that might not mind people making use of their graphics and such provided they're given proper credit. Maybe some of the graphics from, say, Wesnoth could be adapted for Crossfire use, for example? As far as the races, it seems like there's a definite desire for less redundancy and wider variety. The new "Dragon" race is about as different from the others as possible with it's special development mechanics, and it seems to be very popular for it. Seems like more "special stuff" for any of the other races that are kept or added would be a winner. Now, as far as adding drastically different things like that - isn't there a fair amount of hard-coding to support the Dragon stuff right now? How hard would it be to move some of the more radical differences out to things that can be implemented in arch's? More "plain language" explanations of how things work and how to make new things would be helpful too. I'm planning to try to contribute a bit in that respect while I (hopefully) have some time over the next few weeks. As far as "classes" and initial character generation: On Friday 01 June 2007, Mark Wedel wrote: [...] > - Races/classes: Would be nice for more of these to have longer term > affects than they do right now - we've discussed that in the past. Some > could just be certain objects usable only by certain classes (helm only > usable by wizards, no one else, etc), some could be more special maps > (fighter guild hall only allowed to fighters), etc. Personally, I'd still prefer to see the "classes" be LESS of an issue, at least in terms of the "hall of selection" effects. I think a lot of the "only members of the X profession/class can enter/use this item/whatever" things ought to work like the dieties do now - you join one after you start, if you want, and then are hit with the restrictions (and given the benefits). Then, on the one hand, you could either greatly reduce or even completely eliminate the "class" choice in the "hall of selection". THAT would in turn open up the ability to have a HUGE variety of effective classes without annoying people - since you find and join them later, you don't end up having to pick from 50 different selections right at the beginning. That also opens up some possibilities for plotlines - what happens when someone joins the assassin's guild and then changes their mind and joins some other class organization? From then on, they're hunted by NPC members of the assassin's guild...("But if you deliver a ransom of 10000 platinum to so-and-so in such-and-such a room, you will be forgiven.") I seem to recall that at one point the idea of having the Hall of Selection be like a shop was discussed. You give the starting character so much money, and they go around "buying" starting skills, abilities, and items (whether they get to keep some or all of what they don't spend can be figured out later...) I do like the idea of having the "class" modify how easy or hard it is to learn certain skills though. Would that just be a plus X% or minus X% modifier granted by class membership? Just a couple of thoughts for discussion... From alex_sch at telus.net Thu Jun 7 22:19:21 2007 From: alex_sch at telus.net (Alex Schultz) Date: Thu, 07 Jun 2007 21:19:21 -0600 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706072042.52712.mail-lists+cfdev@dogphilosophy.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4660DAA0.4070004@telus.net> <4660E7EC.2030105@sonic.net> <200706072042.52712.mail-lists+cfdev@dogphilosophy.net> Message-ID: <4668CAB9.5030606@telus.net> mail-lists+cfdev at dogphilosophy.net wrote: > On Friday 01 June 2007, Mark Wedel wrote: > [...] > >> - Races/classes: Would be nice for more of these to have longer term >> affects than they do right now - we've discussed that in the past. Some >> could just be certain objects usable only by certain classes (helm only >> usable by wizards, no one else, etc), some could be more special maps >> (fighter guild hall only allowed to fighters), etc. >> > > Personally, I'd still prefer to see the "classes" be LESS of an issue, at > least in terms of the "hall of selection" effects. I think a lot of > the "only members of the X profession/class can enter/use this item/whatever" > things ought to work like the dieties do now - you join one after you start, > if you want, and then are hit with the restrictions (and given the benefits). > Then, on the one hand, you could either greatly reduce or even completely > eliminate the "class" choice in the "hall of selection". > Actually, there is nothing in Crossfire that is like "only members of the X profession/class can enter/use this item/whatever"... At the lower level, things currently are a bit restrictive, however it doesn't take long at all (level 30 at most?) for a character to accumulate all useful skills via skill scrolls which can grant nearly any skill. I believe the only exceptions to this condition of "Anybody can get any skill easily" are clawing (racial), flame touch (racial), and meditation (monk). The issue is, at low levels, things are indeed a bit restrictive in terms of class, HOWEVER at mid to highish levels class distinctions completely vanish (unless one is a monk with meditation and no weapons). The issue is that classes do mean nothing beyond level 30 or so, and while this in itself isn't a problem, it's a large inconsistency between higher and lower levels, and more importantly it creates a problem where high level players become so generic and indistinguishable from eachother. What is needed, is *something* which promotes diversity among higher level players, and making class distinctions firmer at higher levels is often seen as one way to achieve this. Alternative ideas for promoting diversity among high level players would be just as good in my opinion though. :) Alex Schultz From mwedel at sonic.net Thu Jun 7 22:40:50 2007 From: mwedel at sonic.net (Mark Wedel) Date: Thu, 07 Jun 2007 20:40:50 -0700 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706072042.52712.mail-lists+cfdev@dogphilosophy.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <4660DAA0.4070004@telus.net> <4660E7EC.2030105@sonic.net> <200706072042.52712.mail-lists+cfdev@dogphilosophy.net> Message-ID: <4668CFC2.9030706@sonic.net> mail-lists+cfdev at dogphilosophy.net wrote: > Where to start, let's see... > The only problem with the existing map that has come up a few times in one > form or another is that it's occasionally difficult to find a "Bed to > Reality". Adding a few more Inns or their equivalent around the countryside > (and making sure they're not too hard to find in big cities) would be helpful > for that. Yes. Now in some cases, the actual need for a bed to reality is limited. You can always save your character if you exit the client (but there should really be a better interface then just closing the connection). The problem is that if you come back a day later, you can't be sure if you'll show up on the map you were on, or back at your savebed. Putting savebeds in dungeons tends not to be great, because in that day elapsed scenario, all the monsters are now back again, and you may find yourself surrounded. But I doubt that is really the problem. The issue is more likely that you've travelled someplace far on the big world to be near a dungeon, but don't have time to complete it, etc, so want to save at that position without having to restart from the city. At higher level, there are spells for this, but that doesn't help low level. I'm not sure if this would solve the problem being asked, but I wonder if just allowing save locations to be persistent (not reset to last savebed) anyplace outdoor on the big world would basically fix the problem? > > Of course, adding more stuff brings up the problem of graphics (and sounds). > It occurs to me that there are a number of other open-source games that > might not mind people making use of their graphics and such provided they're > given proper credit. Maybe some of the graphics from, say, Wesnoth could > be adapted for Crossfire use, for example? Its certainly possible that other sources are available. One 'problem' that can arise is that the style of graphics is different, so since taken from another source looks really out of place. I'd probably note that new maps in most cases probably don't need new graphics. New objects maybe, but in same cases, possible existing images can be altered (change the color, etc). > > As far as the races, it seems like there's a definite desire for less > redundancy and wider variety. The new "Dragon" race is about as different > from the others as possible with it's special development mechanics, and it > seems to be very popular for it. Seems like more "special stuff" for any of > the other races that are kept or added would be a winner. > > Now, as far as adding drastically different things like that - isn't there a > fair amount of hard-coding to support the Dragon stuff right now? How hard > would it be to move some of the more radical differences out to things that > can be implemented in arch's? Depends on what needs to be done. IIRC, the main thing for the dragon is the logic for when the eat stuff to get resistances, and some special code when they gain levels. I think the level code gain (spells) is largely controlled by treasurelists in the dragon player - the only logic there is to check if the character is a dragon, and if so, if they get special abilities. However, at some point, some amount of work has to be hardcoded. At a very basic level, equippable items are hardcoded in that they give ac, protections, etc. I don't think it is terrible to have race/class special abilities coded to some extent - yes, ideally as much of that should be pulled from the archetypes as possible, and it would certainly be interesting for all races/classes to get certain 'special' abilities as they gain levels. But if some code is needed for some extra logic, I'd hardly consider that terrible. > That also opens up some possibilities for plotlines - what happens when > someone joins the assassin's guild and then changes their mind and joins some > other class organization? From then on, they're hunted by NPC members of the > assassin's guild...("But if you deliver a ransom of 10000 platinum to > so-and-so in such-and-such a room, you will be forgiven.") Maybe if actual class guilds are added to the game. Right now, there really are not any class guilds - there are general guild houses, but those just require some number of characters to start a guild. The dragons effectively have a guild, but no one else does. And unless these in game/class guild have various special benefits, you may get a case where there just isn't a reason to join them. If you already have the fighter skills, and have joined the mage guild for more spells/skills, you could just be a member there even though you are effectively a fighter. So unless the guild grants some bonus or special training, may not add a whole bunch. I think the past it has been discussed that the different classes determine what skills you start with, as well as major/minor skills - major skills gain exp faster, etc, and there is no way to get a minor skill to a major skill (skill scrolls would only give minor skills, etc). So someone that starts as barbarian could still pick up the magic skills, but because those are minor skills, would be very difficult for them to ever approach being as good as a major. Exactly how much difference there is could perhaps be setable. Minor skills could also be capped at some max level, effectively limiting how good also. I'd also perhaps be nice for most skills to grant special abilities at certain points - maybe bonus hp or mana, bonus spell, etc. That could certainly come later, but that could also be used as a balancing point to some degree. From mail-lists+cfdev at dogphilosophy.net Thu Jun 7 23:52:58 2007 From: mail-lists+cfdev at dogphilosophy.net (mail-lists+cfdev at dogphilosophy.net) Date: Thu, 7 Jun 2007 22:52:58 -0600 Subject: [crossfire] The future of Crossfire In-Reply-To: <4668CFC2.9030706@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706072042.52712.mail-lists+cfdev@dogphilosophy.net> <4668CFC2.9030706@sonic.net> Message-ID: <200706072252.58943.mail-lists+cfdev@dogphilosophy.net> On Thursday 07 June 2007, Mark Wedel wrote: [...] > I'm not sure if this would solve the problem being asked, but I wonder if > just allowing save locations to be persistent (not reset to last savebed) > anyplace outdoor on the big world would basically fix the problem? Actually, it would, at least in terms of what *I* was thinking about (not sure about the others who've brought up similar topics). [...] > > That also opens up some possibilities for plotlines - what happens when > > someone joins the assassin's guild and then changes their mind and joins > > some other class organization? From then on, they're hunted by NPC > > members of the assassin's guild...("But if you deliver a ransom of 10000 > > platinum to so-and-so in such-and-such a room, you will be forgiven.") > > Maybe if actual class guilds are added to the game. Right now, there > really are not any class guilds - there are general guild houses, but those > just require some number of characters to start a guild. The dragons > effectively have a guild, but no one else does. That is actually what I had in mind (of course that goes right back to the problem of people needing to make maps for it...) > And unless these in game/class guild have various special benefits, you > may get a case where there just isn't a reason to join them. If you > already have the fighter skills, and have joined the mage guild for more > spells/skills, you could just be a member there even though you are > effectively a fighter. So unless the guild grants some bonus or special > training, may not add a whole bunch. That, also, is what I had in mind. In essence, the "hall of selection" right at the beginning ends up only equipping the character with a few basic, comparatively generic skills to get started. To differentiate more and gain particular special abilities, the player goes and finds one of the more specialized "guilds" to join. Each one might conceivably have a variety of specialized and unique abilities or skills that it grants. To prevent abuse - each guild might cost the character a flat percentage of their experience (and joining one would typically invalidate membership at another), so it's not hard to "dabble" at low levels, but by the time you reach high levels it becomes a serious penalty to switch. Basically, the idea would be to give another way to provide major differences between the characters besides "race" - and one that can occur during play rather than prior to it - which would also add more color and background to the world setting at the same time. You could even have some "guild" classes that are allowed only to particular diety-worshippers, some perhaps only switchable to from others (so some of the current 'mixed-skill' classes in the hall of selection e.g. Paladins might only allow fighters or priests to join [they give up being a 'mere' fighter or priest to become a 'paladin']). Basic, simple "guilds" could either be pre-existing in the hall of selection ("Figher, Priest, Thief, Sorceror" - a nice, simple set of selections) or immediately accessible near the starting point in Scorn or Navar, while the more esoteric ones are placed in harder to find areas. > I think the past it has been discussed that the different classes > determine what skills you start with, as well as major/minor skills - major > skills gain exp faster, etc, and there is no way to get a minor skill to a > major skill (skill scrolls would only give minor skills, etc). Each guild/class could have a table of skill experience modifiers (skills not listed in the table default to "100%" i.e. character gets normal experience for that skill). Essentially "forbidden" skills are set to 0% - the character MIGHT have some points left over after paying the "join the class guild" experience penalty, but would not advance any further. Especially favored skills might be set to %200 or something of the sort. Yeah, I know, more hardcoding, but at least it would be applicable to all characters...I wouldn't EXPECT this to be too hard to add (would it?), but then, I'm a minimally-competent C programmer and haven't actually looked at the experience-awarding code directly... > I'd also perhaps be nice for most skills to grant special abilities at > certain points - maybe bonus hp or mana, bonus spell, etc. That could > certainly come later, but that could also be used as a balancing point to > some degree. Agreed - this could also be a mechanic of the class/guild itself. I'm going to have to try to learn map-making... From nicolas.weeger at laposte.net Sat Jun 9 02:27:19 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jun 2007 09:27:19 +0200 Subject: [crossfire] Code cleaning, part 2 In-Reply-To: <46689889.3040503@sonic.net> References: <200706071929.39369.nicolas.weeger@laposte.net> <46689889.3040503@sonic.net> Message-ID: <200706090927.23528.nicolas.weeger@laposte.net> > IMO, Old_Mode could go away. It isn't used by clients - rather it dates > back before we had clients, where the method of connecting was to connect > to the crossfire server (on that port), and then do something like 'add > myhost:0' - at which point the server would open an x-connection to your > host. That's part of stuff I'll clean, yes :) Basically, unused functions. > Note that with the above changes, I think both the client and server > should get a bump in protocol version numbers. Probably. Hopefully, setup command would help, too - client says 'setup map1', server replies 'sorry, you're too old to play here'. > I'm presuming you're just going to remove this stuff from the trunk, and > not the stable release, correct? In which case, to diffuse some issues, > one could still run crossedit from the stable area so long as things don't > change in incompatible ways (which I don't expect to happen anytime soon). Trunk only, yes. I don't care much for branch cleaning :) > Fair enough - I'll try to remember that in the future. However, you can > probably do a svn info (or is it svn log) to see when commits where and > what the messages are, so could perhaps back date some of this. Or look in the Changelog. But then you have to look at multiple files (protocol lists map, map1, map1a, map2, but when was map1a introduced? need to check Changelog, also "map2" doesn't necessarily appear, it may be map v2" or anything else) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070609/4a0e961e/attachment.pgp From nicolas.weeger at laposte.net Sat Jun 9 02:31:41 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jun 2007 09:31:41 +0200 Subject: [crossfire] Summary, was Re: The future of Crossfire In-Reply-To: <46677F9C.9000805@sonic.net> References: <200706012316.15083.nicolas.weeger@laposte.net> <200706061947.04197.nicolas.weeger@laposte.net> <46677F9C.9000805@sonic.net> Message-ID: <200706090931.41916.nicolas.weeger@laposte.net> > The lore idea, and discussion on it, I thought were really good. It was > just something never finished - lots of things like that in crossfire. Yes, which is why we need a goal to reach, so we can focus on it. > > Agreed. We need client [sound] support, though. > > Yes, I was planning on looking at that soon. I know other people are looking at that, so maybe take care to not duplicate work :) > But in some cases, it isn't clear what the correct behavior is - in > those, we should just document something (x behaves like ...) vs trying to > write in exceptions, etc. I'm personally in favor of clean code with clear > meanings vs code with lots of exceptions, questions on how it should > operate, etc. Yes, that's also what I meant by documenting. Behaviour doesn't seem to make sense? Then decide it, and write that down. Example is "abilities", they apparently don't work, no documentation - so what to do? > The problem is that the TODO list is so long that it sometimes becomes > hard to figure out what should really be tackled next. I'll note that the > TODO list on the wiki (http://wiki.metalforge.net/doku.php/dev_todo_new) > often seems more code oriented, where a lot of the changes we're discussing > here are more map level level. In fact, of the list I did, arguably very > few of those require code changes - many might just be archetype and map > changes. Yes, we got to many todo lists. But then we could have 2 different ones: code, and content. > > As usual, we also depend on people actually doing the code/work at some > > point :) > > Right - and the problem there is that whenever people are volunteers, > they'll work on what they want to work on, and not necessarily lists like > this that we put together. Well, currently there aren't many people with SVN access active, and the ones I know support the cleaning and also think content is nice to have. So maybe we could try to concentrate on that, maybe add some new features required to create fun content, but not start mega refactoring work just for its sake. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070609/df5eb46b/attachment.pgp From crossfire at kahnert.de Sat Jun 9 07:52:25 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sat, 9 Jun 2007 14:52:25 +0200 Subject: [crossfire] map design guideline (was: Summary) Message-ID: <20070609125225.GA1316@cthulhu.desy.de> Hi, On Tue, Jun 05, 2007 at 02:10:46PM -0700, Mark Wedel wrote: > - Better maps/quests - more on the thinking side, less on the 'you > just need to kill everything and your done' side. How many more > maps are needed is a more difficult question - at some level, this > is ongoing, but we probably want to have some sort of goal for X > number of maps by 2.0 or something. Some of these may be localized > puzzles (in the sense that everything for the puzzle is in the > dungeon itself), others may be broader, like pupland, where clues > are all over the place, etc. introduce a "map design guideline". Only maps which won't violate the policy are allowed to add / stay. A map should make sense. It has to be harmonious and coherent. For example, if you slay a dragon and reach the dragon hoard, you'll find some random_treasure, like a hauberk, dagger, water, cake, ... Wow, this dragon was able to collect real valuable stuff... But usually the dragon will burn the hoard with fire. No treasure at all. So a dragon should have a cave, with an entrance where you can fight and hopefully slay it and at the end of the cave the dragon hoard. Don't let the dragon burn it's own treasure. Or the monsters living in a map. Why they're there, why they're mixed up this way, etc. Check out this map: http://www.metalforge.com/mapper/pup_land/lone_town/town_ud2.html What's the idea of this map? Why there are lot of trapped monsters. Who trapped the dragons there? For which purpose? Why they're not famished or who fed them and how? Or how do they come in and out? What's making a titan there? Having some vampires in the underground town seems reasonable, but what about the titan and the dragons? I don't understand this map. And there are lot of maps like this. > - Remove some of the old/bad maps - this can be harder to determine - > what is really a 'bad' map? Any map which violate the "map design guideline". ;-) > Maps with all hack and slash and no puzzle are not particularly > interesting, but at the same time, if we'd remove all of those, > wouldn't be much left Indeed, the most popular map is raffle1_3. Ok, on metalforge it's "ElectricHatchery", but that's only because "Flank" is camping there all the time. Other player hardly gets the chance to do this quest. So maps where player could easily gain exp are prefered. It's important to keep / create some hack and slay maps. Or maps with easy treasure are also very popular. I guess intwell is played so often because of the easy to get glowing crystal... > - it may be more that we need to better work on categorizing the > maps or something - that's a puzzle dungeon, that is hack and slash, > etc, and somehow have those tags on the exits themselves, so if you > wander accross a map, you could know the type of map (plus perhaps > other information, like level range?) Because that is certainly > another annoying point - finding some map and then finding it is way > too easy or too hard - because many maps mix monsters, you can't > necessary look at the first few monsters to know. Another point, the mix of monsters. Should also be coherent. Maybe we need some more monster types, to avoid a bad mix of monsters without having just one or two monster types in the map. First try, just some catchwords, because I don't know if you like the idea... MAP DESIGN GUIDELINE - Every map has to be coherent and harmonious. - The map needs to have a clear story, a goal, a purpose. - Don't mix up monsters without a relationship or a story. - Don't trap big monsters. Add a way to let them [theoretically] enter or leave the map. - Let powerful items be the reward of a quest, not just an item on a map. - Avoid hack and slay style maps. - ... There's also some coding stuff missing. Don't let players solve a quest more than once. Flag a player who started a quest and only let players enter the quest map with this flag and without the "quest finished flag". Also let a second player know, that there was someone faster starting a quest. For example, you have to go to the "Tower of Ordeal". The receptionist tells you "here is the key" for the tower, but you don't get a key, because another player already has it. Let him say "Sorry, someone is already doing the test. Come back later." instead. And for the hack and slay part, I've an idea. Let the training company sell special weapons which are able to catch monsters. Those monsters are counted and sold to other players who like to train. There can't be sold more monsters than catched. The less monsters the company has of a special type, the more they're willing to pay for them and vice versa. This could be extended with a trading system. The monsters also needs to be equiped, but as long no player has sold the correct stuff, the monsters are not ready to fight... There needs to be a rewarding system to have high level player catching enough monsters. J?rgen From nicolas.weeger at laposte.net Sat Jun 9 07:51:58 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jun 2007 14:51:58 +0200 Subject: [crossfire] Materials Message-ID: <200706091452.02194.nicolas.weeger@laposte.net> Hello. I'd dug some in the material code, and it is quite messy. But I'm not sure how to fix/change it. Here is how it works. Material is used for saving throws against attacktypes (against fire, ice, ...). When NEW_MATERIAL_CODE is defined, material will also affect an item's resistances, damage, speed, wc, ac. There are 2 related fields, "material" which is a bitmask and "materialname" which is a string. lib/materials contains a list of materials, first "regular" materials (which all got neutral resistances / modifiers), then special ones (with special resistances / modifiers). Each material type (metal, dragonscale, ...) corresponds to a type, check include/material.h (M_xxx) for their values. If "materialname" is NULL, it is initialized with a material matching "material"'s bitmask. When NEW_MATERIAL_CODE is defined, this material "incarnation" is chosen randomly based on map's difficulty and item's magic (thus having a material of 2 can translate to iron, silver, gold, lead, steel, ...). When NEW_MATERIAL_CODE is not set, the first matching material is used (thus 2 will always do iron). materialname is used when doing saving throws, pointing to the material's intrinsic resistances. It is also used when describing the item - thus gold coins have a "it is made of: gold" even when its material value is 2 (iron) in the archetype. Consequently also, gold coins will use the 'gold' values for saving throws. There are some issues with the current implementation: * when NEW_MATERIAL_CODE is defined, objects have modified resistances / stats based on their material and also random materials, thus leading to massive non merging things * materialname only reflects one material - if I set "material 3" in the archetypes, it will only be "paper", not "paper and iron". This also influences the saving throw, which will only be paper, not iron. * if material name is set to a special value (paper and glass - anything not listed in lib/materials), the item is then indestructible. * material is effectively useless when materialname is set, even to an "invalid" value So the plan is obviously to fix multi material handling - and for instance use a random material for saving throws, the hit can be on a "random" part of the item. Keeping specific saving throws seems logical, since gold doesn't behave like iron for instance (but they got the same "material" value, 2). The 2 things I'm wondering whether to keep (and maybe enable?) or remove totally are: * random material choice if not set. * resistances / stats modifier Activating this could lead to more random items, and interesting combinations. Current eg resistance modifiers in the lib/material aren't that important (around -5 to 5), but could add variety to items. On the other hand, it would introduce quite many different items, non merging, things like that. If I were to decide right now (but that may change), I'd probably keep/enable modifiers and random materials. But I would link that to "loot diminution", ie reduce the junk players find. Thus less items, but more varied. I would also add materials with higher modifiers and penalties (eg: +20 fire, -20 cold - you get a bracers of that type, keep it?). And maybe even add other modifiers (reduce/increase hp regen, ...) Of course, that would mean more time required to sort/test all the junk :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070609/07de6497/attachment.pgp From nicolas.weeger at laposte.net Sat Jun 9 11:21:20 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jun 2007 18:21:20 +0200 Subject: [crossfire] map design guideline (was: Summary) In-Reply-To: <20070609125225.GA1316@cthulhu.desy.de> References: <20070609125225.GA1316@cthulhu.desy.de> Message-ID: <200706091821.24040.nicolas.weeger@laposte.net> > introduce a "map design guideline". Only maps which won't violate the > policy are allowed to add / stay. Yes. I'd be slightly less restrictive, though - you'd be allowed to commit part of a quest, adding other elements later on, provided you document somewhere what you plan to add / you commit not too long after. > A map should make sense. It has to be harmonious and coherent. For > example, if you slay a dragon and reach the dragon hoard, you'll find > some random_treasure, like a hauberk, dagger, water, cake, ... Wow, this > dragon was able to collect real valuable stuff... But usually the dragon > will burn the hoard with fire. No treasure at all. > > So a dragon should have a cave, with an entrance where you can fight and > hopefully slay it and at the end of the cave the dragon hoard. Don't let > the dragon burn it's own treasure. Well, you could argue the player should be smart enough to figure a way to have the dragon don't burn his treasure :) > What's the idea of this map? Why there are lot of trapped monsters. Who > trapped the dragons there? For which purpose? Why they're not famished or > who fed them and how? Or how do they come in and out? What's making a > titan there? Having some vampires in the underground town seems > reasonable, but what about the titan and the dragons? I don't understand > this map. And there are lot of maps like this. Well, IMO we shouldn't try to explain *all* maps and *everything*. Overall story, then small hints, whatever. For instance, from the wiki, why the world evolved this way. Trying to justify the existence of all and every maps is an exercice in futility imo - but that doesn't mean we shouldn't try to harmonize maps. (and if you start in this way: what is a Bed to Reality? why do you return there when you die? why do maps reset? :)) > Indeed, the most popular map is raffle1_3. > > > Ok, on metalforge it's "ElectricHatchery", but that's only because > "Flank" is camping there all the time. Other player hardly gets the > chance to do this quest. > > > So maps where player could easily gain exp are prefered. It's important > to keep / create some hack and slay maps. > > Or maps with easy treasure are also very popular. I guess intwell is > played so often because of the easy to get glowing crystal... This is more a map balance issue. Arguably raffle gives enough benefits to be always claimed. So either reduce those benefits, or add more maps. This is also server dependant, btw - I don't know if all servers have map claims. > Another point, the mix of monsters. Should also be coherent. Maybe we > need some more monster types, to avoid a bad mix of monsters without > having just one or two monster types in the map. Yes. And describe what monsters can coexist with what monsters. > There's also some coding stuff missing. Don't let players solve a quest > more than once. Flag a player who started a quest and only let players > enter the quest map with this flag and without the "quest finished flag". This is really a map design issue. Using existing archetypes, or scripting, it should be the map maker's decision to implement such a restriction. At some point common functions could be added, or examples written to help map makers. As I said in another mail, I'm ready to script functions map makers need :) About the "catching" part, that could be part of the game, but remember that having a player-managed economy (in this case monsters trading) is hard to maintain. Also I don't really want players to need to catch monsters sometimes to train just because no one did it. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070609/005afa66/attachment-0001.pgp From nicolas.weeger at laposte.net Sat Jun 9 15:40:32 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jun 2007 22:40:32 +0200 Subject: [crossfire] Client cleaning Message-ID: <200706092240.36830.nicolas.weeger@laposte.net> Hello. In client trunk, I'd like to clean the following: * map1/1a commands * item, face, face1 - all things I removed from server * gnome client. Not even sure it builds, probably not updated for years. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070609/c989fe6a/attachment.pgp From nicolas.weeger at laposte.net Sat Jun 9 15:43:54 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 9 Jun 2007 22:43:54 +0200 Subject: [crossfire] Protocol version Message-ID: <200706092243.54419.nicolas.weeger@laposte.net> Hello. (this only concerns trunk) I bumped server-side s->c version to 1028 (was 1027), to denote massive removal. But it was suggested on the list to change s->c et c->s versions to 2000, to have a nice version. This would enable to remove some non required commands, or commands that are always on (smoothing info, for instance) Also, support for old servers could probably be phased out - change both branch and trunk to recognize 2000 version, and in trunk server remove support for pre 2000 clients. Assuming we do another version of branch client, and enough time (6 months) elapses before we release 2.0, it would make sense (given current plans, it seems 2.0 is many months, even years, ago, so well...) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] From mwedel at sonic.net Sat Jun 9 16:21:59 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jun 2007 14:21:59 -0700 Subject: [crossfire] map design guideline (was: Summary) In-Reply-To: <200706091821.24040.nicolas.weeger@laposte.net> References: <20070609125225.GA1316@cthulhu.desy.de> <200706091821.24040.nicolas.weeger@laposte.net> Message-ID: <466B19F7.5040705@sonic.net> There is already a map guide document that more or less describes good vs bad maps. However, a lot of maps predate that. Not trapping big monsters is difficult - unless you have a completely empty room, it is hard for something like a big demon not to be 'trapped' in some way. and if you have a big empty room that the entrance leads to, you now get the problem you come down the exit on top of a monster which doesn't work very well (yes, the monster may not be there initially, but say you go down, blast the monster a bit, then pop back up to heal/whatever - it is possible that at that time, the monster is on top of the exit next time you go down. I also don't have too big an issue with a group of monsters without a big plot behind them. Seems perfectly reasonable for me for a tribe of orcs to being living in a cave. Or for that matter, the dragon cave makes a similar amount of sense - dragons have to live someplace. I don't think that every map also has to be part of a quest or have special/good completion items - having some maps just be places to go and kill things, get random loot and some exp seems perfectly fine. I agree that there probably is not enough different difficulty monsters. I don't necessarily think we need more monsters, but rather variations on what we have. If we follow from other games, monsters can get more difficult - just as a human character is more difficult as it gains level, there isn't anything to say we couldn't have level 10 orc barbarians around in dungeons - orcs should be able to gain exp also. I suspect some maps are really popular not as much because of the treasure (you do it once you're probably not going to see much different treasure - and in fact, if you want diverse treasure, random maps can be pretty good as quality of treasure goes up as you get deeper), but rather players are looking for specific monsters. If you're at the right level, hill giants provide good exp for killing them. Likewise, if you're a dragon, you're looking for creatures that drop the right flesh, and in many cases, your choices are limited - turns out being a cannibal is a pretty good approach. While perhaps not really a way to make better maps, a way to offload this may be more random dungeons with specific types of monsters - one could imagine a hill giant cave, say 10 levels deep - a good place to go kill hill giants instead of raffle. Likewise, an alternative dragon cave, etc. I'm wary of limiting players from only doing a quest map once - a few reasons. First - it can limit play options to the point where a player doesn't have a lot of places to go. Second, it can be hard to enforce - how do you really note they completed the quest? This could lead to a case where the player wants to go to the dungeon for exp/whatever, so just skips the last phase that marks the quest as being completed (doesn't turn the item in, kills everything but the boss, etc). So in that regard, doesn't really help things out. From mwedel at sonic.net Sat Jun 9 16:35:01 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jun 2007 14:35:01 -0700 Subject: [crossfire] Materials In-Reply-To: <200706091452.02194.nicolas.weeger@laposte.net> References: <200706091452.02194.nicolas.weeger@laposte.net> Message-ID: <466B1D05.3080606@sonic.net> Nicolas Weeger wrote: > Hello. > > I'd dug some in the material code, and it is quite messy. But I'm not sure how > to fix/change it. > > Here is how it works. > > Material is used for saving throws against attacktypes (against fire, > ice, ...). > When NEW_MATERIAL_CODE is defined, material will also affect an item's > resistances, damage, speed, wc, ac. > > There are 2 related fields, "material" which is a bitmask and "materialname" > which is a string. Yes - the bitmask is the old/original code, and materialname came later as a more flexible material system. > > lib/materials contains a list of materials, first "regular" materials (which > all got neutral resistances / modifiers), then special ones (with special > resistances / modifiers). > Each material type (metal, dragonscale, ...) corresponds to a type, check > include/material.h (M_xxx) for their values. > > If "materialname" is NULL, it is initialized with a material > matching "material"'s bitmask. > When NEW_MATERIAL_CODE is defined, this material "incarnation" is chosen > randomly based on map's difficulty and item's magic (thus having a material > of 2 can translate to iron, silver, gold, lead, steel, ...). > When NEW_MATERIAL_CODE is not set, the first matching material is used (thus 2 > will always do iron). Yes - the reason this was added is that having a huge number of different materials really got annoying. Instead of having say 6 shortswords non merging shortswords like you do now if you clear out a dungeon (those six being different in some way - a couple may be cursed, 1 would be normal, a few magical of different ways, etc), you'd have like 20, because in addition to those 6 types above, you'd get bronze, steel, iron, etc. And so now you got really long list of items and it just proved more annoying. > > So the plan is obviously to fix multi material handling - and for instance use > a random material for saving throws, the hit can be on a "random" part of the > item. > Keeping specific saving throws seems logical, since gold doesn't behave like > iron for instance (but they got the same "material" value, 2). > > > The 2 things I'm wondering whether to keep (and maybe enable?) or remove > totally are: > * random material choice if not set. > * resistances / stats modifier > > > Activating this could lead to more random items, and interesting combinations. > Current eg resistance modifiers in the lib/material aren't that important > (around -5 to 5), but could add variety to items. > On the other hand, it would introduce quite many different items, non merging, > things like that. Which is why in most cases it is turned off. I think different materials are interesting, but I also think some better for of what gets created is needed. Having a pine arrow and oak arrow is fine, but if the only difference is that the pine arrow is 5 grams lighter, who really cares - in that case, it becomes a bother. And that is generally what is was with the material system in place. A problem is that material can apply to everything - thus, anything made of iron could now become made of any of the 'metal like' materials - that is fine in one way, but for some items, it makes no effective difference, because the adjustments don't apply (a material that gives extra armor benefit I believe has no effect if applied to an item that doesn't have any armor value in the first place, like a sword). I think in the past there was some thought to basically add material transmutation into the artifacts file, since that does provide a good level of control. Thus, you could limit it to things that make sense (that steel sword does 1 more point of damage than that iron one). Doing that in itself isn't hard - I think the slightly harder part was some logic about having it be too pass or reentrant was need - you should be able to get a steel sword of lythander for example, but right now, the artifact processing will only do one artifact type. IT may be to do something like this in the material file - similar format (which is nice - you can then dictate what steel armor gives vs steel weapons) - it could perhaps even use the same parsing/naming structure, as well as odds, but put the data into a seperate array. So basically, it does a treasure. First, it calls the material code to see if it should change material, and after that (regardless of any change), it then calls normal artifact processing. From mwedel at sonic.net Sat Jun 9 16:42:47 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jun 2007 14:42:47 -0700 Subject: [crossfire] Protocol version In-Reply-To: <200706092243.54419.nicolas.weeger@laposte.net> References: <200706092243.54419.nicolas.weeger@laposte.net> Message-ID: <466B1ED7.2000302@sonic.net> Nicolas Weeger wrote: > Hello. > > (this only concerns trunk) > > I bumped server-side s->c version to 1028 (was 1027), to denote massive > removal. > > But it was suggested on the list to change s->c et c->s versions to 2000, to > have a nice version. This would enable to remove some non required commands, > or commands that are always on (smoothing info, for instance) > > Also, support for old servers could probably be phased out - change both > branch and trunk to recognize 2000 version, and in trunk server remove > support for pre 2000 clients. Assuming we do another version of branch > client, and enough time (6 months) elapses before we release 2.0, it would > make sense (given current plans, it seems 2.0 is many months, even years, > ago, so well...) My personal thought is that the trunk gets bumped to 2000. All additional changes in protocol between now and 2.0 release (or near by) result in changing of the protocol version, and having the client/server both require they have the same version (note that clients are of course free to lie about what version they support, so 1.x clients could claim to be 2000). In this way, we can make adjustments to the protocol, etc, without having to put in new setup commands (for example, if we come up with some new sound scheme, we bump up the protocol version instead of the client having to do something like newsoundsystem 1 setup). I'd also say that all the setup stuff that is protocol version related should be assumed to be true for 2000 version, and that get removed from the server and client. (trunk side only of course). There are still some setup commands that are needed - related to map size, I think if the client wants sound info at all, etc, but there are a fair number related to protocol I think. From mwedel at sonic.net Sat Jun 9 16:45:42 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jun 2007 14:45:42 -0700 Subject: [crossfire] Client cleaning In-Reply-To: <200706092240.36830.nicolas.weeger@laposte.net> References: <200706092240.36830.nicolas.weeger@laposte.net> Message-ID: <466B1F86.4000608@sonic.net> Nicolas Weeger wrote: > Hello. > > In client trunk, I'd like to clean the following: > * map1/1a commands > * item, face, face1 - all things I removed from server fine by me. > * gnome client. Not even sure it builds, probably not updated for years. Probably no for both cases. At one point it was there for historical interest. However, a svn delete (or whatever) could be done, and if someone really wants to look at it, it can be pulled out even if deleted. So there probably isn't any reason for the code to normally be checked out. From lalo.martins at gmail.com Sat Jun 9 16:49:38 2007 From: lalo.martins at gmail.com (Lalo Martins) Date: Sat, 9 Jun 2007 21:49:38 +0000 (UTC) Subject: [crossfire] Materials References: <200706091452.02194.nicolas.weeger@laposte.net> Message-ID: what about... keep "materialname" and lib/materials, and kill the "material" field? best, Lalo Martins -- So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From nicolas.weeger at laposte.net Sat Jun 9 17:16:29 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 10 Jun 2007 00:16:29 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers Message-ID: <200706100016.32359.nicolas.weeger@laposte.net> Hello. The doc subdirectory (apart hopefully Developers) is a slight mess, with many many non working or obsolete things. Currently, there following documentations are defined: * spoiler book * player book * spell list * handbook The generation is broken for many things, so we should either fix or remove :) Ideally, we should almost be able to generate the spoilers at http://crossfire.real-time.com/spoiler/index.html And probably some handbooks or guides. Maybe not everything, but probably things that depend on server settings/archetypes/artifacts. I'd be partisan to fix, because (game) documentation is important. Here are different things that can be generated automatically: * standard item list (monsters, artifacts, alchemy formulae, ...) * basically, anything that can be extracted, from server or maps (mapper could list items in the maps themselves if needed - of course, that would documentation would be for "standard" maps) Here are things we can't generate automatically: * advice * all texts, except those parts of items * document structure Also, there is the question of formats. We have broken support for html and .tex / .ps. IMO, either html or .pdf/.ps are fine. What do you think? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070610/c1ba6e07/attachment.pgp From nicolas.weeger at laposte.net Sat Jun 9 17:18:50 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 10 Jun 2007 00:18:50 +0200 Subject: [crossfire] Materials In-Reply-To: References: <200706091452.02194.nicolas.weeger@laposte.net> Message-ID: <200706100018.50240.nicolas.weeger@laposte.net> Le samedi 09 juin 2007 23:49, Lalo Martins a ?crit?: > what about... keep "materialname" and lib/materials, and kill the > "material" field? Err, can't for now, Gridarta (which is hopefully the "official" editor doesn't handle this materialname field :) Also, you run into parsing issues - need to rebuild material list from the string, things like that. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070610/34a5fcf8/attachment.pgp From nicolas.weeger at laposte.net Sat Jun 9 17:22:58 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 10 Jun 2007 00:22:58 +0200 Subject: [crossfire] Protocol version In-Reply-To: <466B1ED7.2000302@sonic.net> References: <200706092243.54419.nicolas.weeger@laposte.net> <466B1ED7.2000302@sonic.net> Message-ID: <200706100022.58109.nicolas.weeger@laposte.net> > My personal thought is that the trunk gets bumped to 2000. All > additional changes in protocol between now and 2.0 release (or near by) > result in changing of the protocol version, and having the client/server > both require they have the same version (note that clients are of course > free to lie about what version they support, so 1.x clients could claim to > be 2000). Well, to have "nice" things, what about: we set protocol version to 1900 for now, and when we release 2.0 we fix to 2000. This gives us 100 revisions to fix things (including setup commands), which should be reaaaaaaaaaaally enough. IMO having 2.0 <=> 2000 is simple to check, and is symbolically strong :) Of course, after 2.0 release, we'll go back to small increments when needed, or setup commands. Agreed on the rest, but I'd keep the framework for those additional things (eg: I kept "mapmode" even if it is always map2cmd, so that when we need it again, well, it's there). Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070610/2193273e/attachment.pgp From mail-lists+cfdev at dogphilosophy.net Sat Jun 9 19:54:29 2007 From: mail-lists+cfdev at dogphilosophy.net (mail-lists+cfdev at dogphilosophy.net) Date: Sat, 9 Jun 2007 18:54:29 -0600 Subject: [crossfire] Ability of inventory checker to check for specifics? Message-ID: <200706091854.29613.mail-lists+cfdev@dogphilosophy.net> Here's a hypothetical situation - say I want an area which is only accessible to devotees of, say, Sorig. If I'm reading the wiki entry on inventory checkers correctly, it looks as though I can have an inventory checker check for a specific skill (e.g. "skill_praying") just as easily as a physical object. However, it doesn't appear to be possible to check for (in this example) "title Sorig". Similarly, I would assume it's not possible to check for a minimum level (for example, if I wanted an area accessible only to "worshippers who have proven themselves", translating to a minimum skill_praying level of 5)? Feature request, or am I just missing how this kind of thing can already be done? On a related note, is there any way to check other player attributes e.g. current str,dex,hp,etc with a detector/inventory checker/pedestal type object? From mwedel at sonic.net Sun Jun 10 01:08:20 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jun 2007 23:08:20 -0700 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <200706100016.32359.nicolas.weeger@laposte.net> References: <200706100016.32359.nicolas.weeger@laposte.net> Message-ID: <466B9554.4070905@sonic.net> Nicolas Weeger wrote: > Hello. > > The doc subdirectory (apart hopefully Developers) is a slight mess, with many > many non working or obsolete things. > > Currently, there following documentations are defined: > * spoiler book > * player book > * spell list > * handbook > > The generation is broken for many things, so we should either fix or remove :) > Ideally, we should almost be able to generate the spoilers at > http://crossfire.real-time.com/spoiler/index.html > And probably some handbooks or guides. Maybe not everything, but probably > things that depend on server settings/archetypes/artifacts. At one point the spoiler and handbook generation did work. That said, the non html version required other various tools, notably I think latex and dvi2ps or something. IMO, the non html versions could probably go away - while the latex ones generate nicer versions to print out (table spanning pages is better done, etc), I really can't see many people printing that data out. Or maybe to the point, I don't see the format being that much nicer to have the effort of two versions of basically the same thing (for the rare occasion someone does want to print it out, they can still do the html version). Taking a very quick link at the URL provided, I note that some of that data appears to be data from the spoiler, but better formatted. It certainly wouldn't be hard to change the spoiler layout, but probably more important to get it to build. > I'd be partisan to fix, because (game) documentation is important. > > Here are different things that can be generated automatically: > * standard item list (monsters, artifacts, alchemy formulae, ...) > * basically, anything that can be extracted, from server or maps (mapper could > list items in the maps themselves if needed - of course, that would > documentation would be for "standard" maps) Extracting from maps gets to be more a problem - the current spoiler basically pulls data from the archetype or other data files, because that is easy/quick to do. Pulling data from all maps is more a problem because it would require going through all the maps, a bit more time consuming (and something that the server can't do by default - the server obviously knows how to read the archetypes and other files, and thus spit out the data in a format that the generation scripts want - there isn't any logic right now for the server to traverse all the maps and trying to pull out useful information. It looks like some of the problem with the generation code is hardcoded server name (../../server/crossfire) - that probably also breaks in the case of compiling in seperate directory - don't know for sure. Hopefully that isn't too hard to fix. From mwedel at sonic.net Sun Jun 10 01:11:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 09 Jun 2007 23:11:14 -0700 Subject: [crossfire] Protocol version In-Reply-To: <200706100022.58109.nicolas.weeger@laposte.net> References: <200706092243.54419.nicolas.weeger@laposte.net> <466B1ED7.2000302@sonic.net> <200706100022.58109.nicolas.weeger@laposte.net> Message-ID: <466B9602.7050006@sonic.net> Nicolas Weeger wrote: >> My personal thought is that the trunk gets bumped to 2000. All >> additional changes in protocol between now and 2.0 release (or near by) >> result in changing of the protocol version, and having the client/server >> both require they have the same version (note that clients are of course >> free to lie about what version they support, so 1.x clients could claim to >> be 2000). > > > Well, to have "nice" things, what about: we set protocol version to 1900 for > now, and when we release 2.0 we fix to 2000. > This gives us 100 revisions to fix things (including setup commands), which > should be reaaaaaaaaaaally enough. > IMO having 2.0 <=> 2000 is simple to check, and is symbolically strong :) Yes - that is fine. > > Of course, after 2.0 release, we'll go back to small increments when needed, > or setup commands. Right - setup works fine for minor changes - and in fact is what has been used for quite a while instead of changing the protocol versions. It is just nice, on both client and server side, if changes can be made to the protocol without having to worry about setup commands, if version is not this, do this, else that type of logic. > > > Agreed on the rest, but I'd keep the framework for those additional things > (eg: I kept "mapmode" even if it is always map2cmd, so that when we need it > again, well, it's there). right - setup is nice, and still useful for config things. What can go away are all the standard things - eg, a 2.0 client is going to use map2, item.., ncom, etc, so there is no need for it to negotiate that as part of the setup logic. > > From alex_sch at telus.net Sun Jun 10 01:30:29 2007 From: alex_sch at telus.net (Alex Schultz) Date: Sun, 10 Jun 2007 00:30:29 -0600 Subject: [crossfire] Ability of inventory checker to check for specifics? In-Reply-To: <200706091854.29613.mail-lists+cfdev@dogphilosophy.net> References: <200706091854.29613.mail-lists+cfdev@dogphilosophy.net> Message-ID: <466B9A85.90904@telus.net> mail-lists+cfdev at dogphilosophy.net wrote: > Here's a hypothetical situation - say I want an area which is only accessible > to devotees of, say, Sorig. > > If I'm reading the wiki entry on inventory checkers correctly, it looks as > though I can have an inventory checker check for a specific skill > (e.g. "skill_praying") just as easily as a physical object. However, it > doesn't appear to be possible to check for (in this example) "title Sorig". > Similarly, I would assume it's not possible to check for a minimum level (for > example, if I wanted an area accessible only to "worshippers who have proven > themselves", translating to a minimum skill_praying level of 5)? > > Feature request, or am I just missing how this kind of thing can already be > done? > > On a related note, is there any way to check other player attributes e.g. > current str,dex,hp,etc with a detector/inventory checker/pedestal type > object? Nope, you're not missing anything. Currently, the only inventory checks possible are by name or by archetype I believe. You can however use python scripting to check other things currently. IMHO it would be nice to be able to check arbitrary attributes as such, however that would almost be getting to the point of adding a miniature scripting system in the rules to check with and would certainly be non-trivial to code. Of course it would be possible easily to implement checkers specific to things like what god they follow, though that does feel a bit too specific to me to be nice. Alex Schultz From nicolas.weeger at laposte.net Sun Jun 10 04:42:12 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 10 Jun 2007 11:42:12 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <20070605200842.GA27233@cthulhu.desy.de> References: <20070605200842.GA27233@cthulhu.desy.de> Message-ID: <200706101142.16413.nicolas.weeger@laposte.net> > Check out FIXME_name. They play with only two spells and two prayers > (magic bullet, probe, Cause Light Wounds and Minor Healing since years) > but they have more players than CF. I assume you mean Daimonin? It's actually a Crossfire fork, for your info :) (many years ago). Apart that, I don't play it, so I can't comment. > The people like good graphics. The gameplay / deep isn't that important > against a pretty look and feel. I think both are important. > You could focus on gameplay, maps and features without improving the > garphics. Ok, will be a nice game for a few players who also like to > play [for example] nethack. And it will be fun for the developers, too. :) > > But you won't reach much players. If you got ideas to find graphists, feel free to express yourself :) IMO, a way to attract graphists is either other graphists, or good gameplay. > That's the point. A 3D game is much more work than 2D - in any cases. > And you have to make a decision, which way you like to go. > > 1) Stay with 2D and improve gameplay / deep. > > 2) 3D game, lot of coding work, and also a lot of design work, new maps > are harder to create, ... I think Crossfire is a 2D game, with a weird perspective :) I'd rather see nice 2D graphism, and maybe an isometric 3d faceset - but we need graphists :) > So you like to stay on a 2D map? For 3D you need to change every map > anyway... > > If you ask me, I would say the first question of all should be: Stay > with 2D or implement 3D? See previous comment :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070610/2a6e7f37/attachment.pgp From fuchs.andy at gmail.com Sun Jun 10 11:48:39 2007 From: fuchs.andy at gmail.com (Andrew Fuchs) Date: Sun, 10 Jun 2007 12:48:39 -0400 Subject: [crossfire] Vertical map-tiling In-Reply-To: <46635474.5020500@sonic.net> References: <200706032330.28127.nicolas.weeger@laposte.net> <46635474.5020500@sonic.net> Message-ID: On 6/3/07, Mark Wedel wrote: > Nicolas Weeger wrote: > > Hello. > > > > I remember, quite a long time ago, discussion about "vertical" map-tiling, > > that is from eg the top of a tower see the ground below, belonging to another > > map. > > Anyone remember that, and how it was implemented? > > > > I think it was like the 4 other map tiles, except used in a different way. > > Don't know if it was ever really done, but I know it was theoretically possible. > > If we presume a square building with an interior courtyard, your first level > would have to consist of at least 5 maps: > > 123 > 456 > 789 > > With the 5 map being common to all levels. You have to use 9 maps, because > when tiling, the map has to tile with a map the same size, and can only tile to > 1 map in each direction. > > So for second level, you would do something like: > ABC > D5E > FGH > > And so on as you go up. Note that you have the layers below visbile to the > next layer - perhaps the next layer, the main building doesn't go up, just > towers at the corners, so could do something like: > IBJ > D5E > KGL > > Note that you would basically use the inverse for layers 1 and 2 if you wanted > a central tower that could see the terrain around it. and I believe I have a > simple example in the test directory of a two store house which is done as: > 12 and 13, where 1 is the common front yard, with 2 and 3 being the floors. Anyone want to do this to the balcony on variel's church in scorn? -- Andrew Fuchs From mwedel at sonic.net Mon Jun 11 00:11:57 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 10 Jun 2007 22:11:57 -0700 Subject: [crossfire] Ability of inventory checker to check for specifics? In-Reply-To: <466B9A85.90904@telus.net> References: <200706091854.29613.mail-lists+cfdev@dogphilosophy.net> <466B9A85.90904@telus.net> Message-ID: <466CD99D.9010502@sonic.net> Alex Schultz wrote: > mail-lists+cfdev at dogphilosophy.net wrote: >> Here's a hypothetical situation - say I want an area which is only accessible >> to devotees of, say, Sorig. >> >> If I'm reading the wiki entry on inventory checkers correctly, it looks as >> though I can have an inventory checker check for a specific skill >> (e.g. "skill_praying") just as easily as a physical object. However, it >> doesn't appear to be possible to check for (in this example) "title Sorig". >> Similarly, I would assume it's not possible to check for a minimum level (for >> example, if I wanted an area accessible only to "worshippers who have proven >> themselves", translating to a minimum skill_praying level of 5)? >> >> Feature request, or am I just missing how this kind of thing can already be >> done? >> >> On a related note, is there any way to check other player attributes e.g. >> current str,dex,hp,etc with a detector/inventory checker/pedestal type >> object? > Nope, you're not missing anything. Currently, the only inventory checks > possible are by name or by archetype I believe. You can however use > python scripting to check other things currently. IMHO it would be nice > to be able to check arbitrary attributes as such, however that would > almost be getting to the point of adding a miniature scripting system in > the rules to check with and would certainly be non-trivial to code. Of > course it would be possible easily to implement checkers specific to > things like what god they follow, though that does feel a bit too > specific to me to be nice. Pretty much agree - trying to add a checker for all these things with an archetype would be pretty complicated (only clean way I could think to do it is that the inventory checker has an inventory object that it uses to check against - anything in the inventory object that is not zero/null is considered to be something to be compared against in the object itself. However, this would make for a really long function, as you'd basically have something like: if (checker->inv->foo && checker->inv->foo != ob->foo) continue // not a match For every field in the object. And non zero even gets odd - maybe you want to check that the field in the object you are checking against is zero/null, etc. I think python is the way to go. Maybe this is a case where a sample plugin would be appreciated. From nicolas.weeger at laposte.net Mon Jun 11 11:39:37 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 11 Jun 2007 18:39:37 +0200 Subject: [crossfire] Ability of inventory checker to check for specifics? In-Reply-To: <466CD99D.9010502@sonic.net> References: <200706091854.29613.mail-lists+cfdev@dogphilosophy.net> <466B9A85.90904@telus.net> <466CD99D.9010502@sonic.net> Message-ID: <200706111839.41311.nicolas.weeger@laposte.net> Agreed on the really long function part. IMO, your check is so specific you should do a script - also easy to test, no recompile whatsoever. > I think python is the way to go. Maybe this is a case where a sample > plugin would be appreciated. You mean a sample Python script? Or a plugin? If script, well, the documentation at http://wiki.metalforge.net/doku.php/cfpython should give needed info, as well as scripts the game already has - of course asking on the list or IRC works too ;) For a plugin, there should (in trunk) a .sh to make a plugin, see http://wiki.metalforge.net/doku.php/server_plugin#creating_a_plugin for more info. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070611/68a6347e/attachment.pgp From crossfire at kahnert.de Mon Jun 11 14:37:42 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 11 Jun 2007 21:37:42 +0200 Subject: [crossfire] map design guideline In-Reply-To: <200706091821.24040.nicolas.weeger@laposte.net> Message-ID: <20070611193742.GA1741@cthulhu.desy.de> On Sat, Jun 09, 2007 at 06:21:20PM +0200, Nicolas Weeger wrote: > > introduce a "map design guideline". Only maps which won't violate > > the policy are allowed to add / stay. > > Yes. I'd be slightly less restrictive, Think the other way. Don't make the policy to be to restrictive. ;-) > Well, you could argue the player should be smart enough to figure a > way to have the dragon don't burn his treasure :) I could also argue that the monster has to be smart enough to not destroy its treasure. Why should the monster hoard treasure if every treasure hunter will be killed by suffering the hoard? ;-) So having player take care about the treasure and having maps which help to reach this goal would be better. :) Having monster also taking care about that would be the best. :p > Well, IMO we shouldn't try to explain *all* maps and *everything*. > Overall story, then small hints, whatever. There don't need to be hints everywhere. But the map should be coherent without logic errors. > Trying to justify the existence of all and every maps is an exercice in > futility imo - but that doesn't mean we shouldn't try to harmonize maps. Getting harmonic maps is the goal, not the way to them. > > need some more monster types, to avoid a bad mix of monsters without > > having just one or two monster types in the map. > > Yes. And describe what monsters can coexist with what monsters. Easy and most obvious is to not mix the enemy races like angels with devils, faeries and goblins / trolls, ... But indeed, we need a list of coexisting monster types. > > There's also some coding stuff missing. Don't let players solve a > > quest more than once. Flag a player who started a quest and only let > > players enter the quest map with this flag and without the "quest > > finished flag". > > This is really a map design issue. Using existing archetypes, or > scripting, it should be the map maker's decision to implement such a > restriction. Is there just a single map implementing such a restriction? Anyway, I would say it should be part of policy. Maybe with coding support to clear the quest map if someone enters who already solved the quest. It's already a confession to the game that every player is able to do the same quest. How often needs someone to be rescued, or a chief be killed, ...? But the same player shouldn't be able to collect uniq quest items more than once. Wouldn't make much sense. Sure, there could be quests which may be made multiple times, but in general it's not logical. It's a role playing game, right? What's wrong on having a focus on role playing instead of monster slaying? > About the "catching" part, that could be part of the game, but > remember that having a player-managed economy (in this case monsters > trading) is hard to maintain. Also I don't really want players to need > to catch monsters sometimes to train just because no one did it. It's all about rewards. If you get better and better catching weapons, which are more and more effective against monsters, you'll have a lot of players catching monsters. ;-) Or just hard to get ingredients for formulae as a payment for monsters. But you're right, would be hard to balance. Anyway, wouldn't it a way to improve gameplay? I think this is better than having lots of generators like in raffle? What's that for a world where such things are common? Try to avoid visible generators. Or make them look like a cave which could be made to collapse (destroy generator). Make the world look more consistent instead of having all over hack and slay computer game parts. On Sat, Jun 09, 2007 at 02:21:59PM -0700, Mark Wedel wrote: > There is already a map guide document that more or less describes good > vs bad maps. Didn't remind that. After reading it right now, I realized, that I've read it in the past. > However, a lot of maps predate that. That explains why so much maps violates this guide... > Not trapping big monsters is difficult - unless you have a completely > empty room, it is hard for something like a big demon not to be > 'trapped' in some way. Yep, but most maps shouldn't contain a big demon... > and if you have a big empty room that the entrance leads to, you now > get the problem you come down the exit on top of a monster which > doesn't work very well Place an invisible director in front of or under the exit. Should avoid such situations. > I also don't have too big an issue with a group of monsters without a > big plot behind them. Seems perfectly reasonable for me for a tribe > of orcs to being living in a cave. Or for that matter, the dragon > cave makes a similar amount of sense - dragons have to live someplace. As long as it's self explaining, you don't need to place a single written hint. Just should be logical and consistent. > I don't think that every map also has to be part of a quest or have > special/good completion items - having some maps just be places to go > and kill things, get random loot and some exp seems perfectly fine. Sure, did I said anything else? I said: "It's important to keep / create some hack and slay maps." Player like those maps to level up their characters. But not every map, just a few, well balanced ones. > I agree that there probably is not enough different difficulty > monsters. I don't necessarily think we need more monsters, but rather > variations on what we have. Correct, far better than mixing monsters without sense. > orcs should be able to gain exp also. Maybe built-in support. Would help map makers a lot to just alter the level of a monster to get a stronger version of the same type. > I'm wary of limiting players from only doing a quest map once - a few > reasons. First - it can limit play options to the point where a > player doesn't have a lot of places to go. Keep enough random maps for leveling. > Second, it can be hard to enforce - how do you really note they > completed the quest? Not really, after you gave the quest item to the one who has sent you, you finished the quest. Or if nobody has sent you, after you got the quest item. There are ways to define the end of a quest. I don't think this would be a problem at all. > This could lead to a case where the player wants to go to the dungeon > for exp/whatever, so just skips the last phase that marks the quest as > being completed (doesn't turn the item in, kills everything but the > boss, etc). So in that regard, doesn't really help things out. Sure, may happen. But if the item is valuable enough, this wouldn't happen to often. I don't consider that as a big problem. But just having hack and slay without role playing, that's a bigger problem for a RPG. Just my opinion. J?rgen From crossfire at kahnert.de Mon Jun 11 15:18:37 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 11 Jun 2007 22:18:37 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <200706101142.16413.nicolas.weeger@laposte.net> Message-ID: <20070611201837.GB1741@cthulhu.desy.de> On Sun, Jun 10, 2007 at 11:42:12AM +0200, Nicolas Weeger wrote: > > Check out FIXME_name. They play with only two spells and two prayers > > (magic bullet, probe, Cause Light Wounds and Minor Healing since years) > > but they have more players than CF. > > I assume you mean Daimonin? How embarrassing, just wanted to replace this FIXME with Daimonin before sending. > Apart that, I don't play it, so I can't comment. Me neither. Just read the docu and stats. > > The people like good graphics. The gameplay / deep isn't that > > important against a pretty look and feel. > > I think both are important. But graphics first. Check out this list: http://play-free-online-games.com/games/games_rpg.html Imagine you don't know anything about this games. Which one would you try first, second, third, ... and when would you try crossfire? You'll never find out how deep crossfire is, if you never try it out, right? > If you got ideas to find graphists, feel free to express yourself :) Those I know always want money for their work... > IMO, a way to attract graphists is either other graphists, or good > gameplay. See above, hard to make it over gameplay. :( So you need a really good gameplay, far better than most games and anything else than lot of hack and slay maps... > I think Crossfire is a 2D game, with a weird perspective :) It's nothing to say against 2D. Just nice looking 2D is better. ;o) J?rgen From crossfire at kahnert.de Mon Jun 11 15:54:03 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 11 Jun 2007 22:54:03 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <466B9554.4070905@sonic.net> Message-ID: <20070611205403.GC1741@cthulhu.desy.de> On Sat, Jun 09, 2007 at 11:08:20PM -0700, Mark Wedel wrote: > Nicolas Weeger wrote: > > Here are different things that can be generated automatically: > > * standard item list (monsters, artifacts, alchemy formulae, ...) > > * basically, anything that can be extracted, from server or maps > > Extracting from maps gets to be more a problem I'm working on a script walking through all maps. I also read out archetypes, formulae, ... I also like to automatically categorize the maps this way. I could combine it all together to create a big spoiler section. It's not finished yet, just working for me in my environment. Neither comfortable nor complete at the moment. I'll make it public as soon as it's usable in other environment than mine. J?rgen From nicolas.weeger at laposte.net Mon Jun 11 16:06:47 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 11 Jun 2007 23:06:47 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <20070611205403.GC1741@cthulhu.desy.de> References: <20070611205403.GC1741@cthulhu.desy.de> Message-ID: <200706112306.50446.nicolas.weeger@laposte.net> > I'm working on a script walking through all maps. I also read out > archetypes, formulae, ... If possible, could that be integrated to crossfire-mapper? utils/mapper.c (in trunk only, I think), isn't part of the build process though ("gcc -g -pg -O0 mapper.c -I../include ../common/libcross.a ../socket/libsocket.a -o mapper -lm -lgd" to build). This program generates a map pic for all maps, and exit list, and a world map, things like that. IMO we should try to minimize the number of programs :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070611/21c77a99/attachment.pgp From crossfire at kahnert.de Mon Jun 11 16:24:26 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 11 Jun 2007 23:24:26 +0200 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <200706112306.50446.nicolas.weeger@laposte.net> Message-ID: <20070611212426.GA2071@cthulhu.desy.de> On Mon, Jun 11, 2007 at 11:06:47PM +0200, Nicolas Weeger wrote: > If possible, could that be integrated to crossfire-mapper? It's a pure python script. The script already generates maps with information (context sensitive) over the archetypes. > This program generates a map pic for all maps, and exit list, and a > world map, things like that. I know, you already gave me the tip and link to the mapper. > IMO we should try to minimize the number of programs :) I understand your point. But my script is part of a bot I'm working on, not an utility to generate documentation. I'll extend it to spit out html spoilers, but it's not the main purpose. So, it won't naturally fit into mapper.c, sorry. J?rgen From nicolas.weeger at laposte.net Mon Jun 11 16:34:46 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 11 Jun 2007 23:34:46 +0200 Subject: [crossfire] Items blocking view Message-ID: <200706112334.49514.nicolas.weeger@laposte.net> Hello. Related to bug http://sourceforge.net/tracker/index.php?func=detail&aid=1735283&group_id=13833&atid=113833 there's an interesting issue. In insert_ob_in_map objects will preferable be inserted *below* other items blocking view. For some reason, the amulet in the bug report has blockview set. Consequently the player (and other monsters probably) will be *above* the amulet in the stack list. Pickup mode only considers items below the player, thus amulet is never auto-picked up. I'm wondering the reason of the blockview behaviour. Is there a compelling reason for that? If yes, probably autopickup should check all items, including those above the player ;) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070611/c107870c/attachment-0001.pgp From mwedel at sonic.net Mon Jun 11 22:14:14 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 11 Jun 2007 20:14:14 -0700 Subject: [crossfire] Documentation / handbook / playbook / spoilers In-Reply-To: <20070611205403.GC1741@cthulhu.desy.de> References: <20070611205403.GC1741@cthulhu.desy.de> Message-ID: <466E0F86.4010606@sonic.net> Juergen Kahnert wrote: > On Sat, Jun 09, 2007 at 11:08:20PM -0700, Mark Wedel wrote: >> Nicolas Weeger wrote: >>> Here are different things that can be generated automatically: >>> * standard item list (monsters, artifacts, alchemy formulae, ...) >>> * basically, anything that can be extracted, from server or maps >> Extracting from maps gets to be more a problem > > I'm working on a script walking through all maps. I also read out > archetypes, formulae, ... > > I also like to automatically categorize the maps this way. > > I could combine it all together to create a big spoiler section. > > It's not finished yet, just working for me in my environment. Neither > comfortable nor complete at the moment. > > I'll make it public as soon as it's usable in other environment than > mine. Note that there are already perl scripts that walk the entire map tree, looking for errors, noting how often different objects are used (and thus notes unused archetypes), etc. This is in the lib/scripts directory. May still not do what is needed, but I thought it worth mentioning that there is already some scripts out there that do this. From tchize at myrealbox.com Wed Jun 13 06:55:55 2007 From: tchize at myrealbox.com (tchize) Date: Wed, 13 Jun 2007 13:55:55 +0200 Subject: [crossfire] Vertical map-tiling In-Reply-To: References: <200706032330.28127.nicolas.weeger@laposte.net> <46635474.5020500@sonic.net> Message-ID: <466FDB4B.7080700@myrealbox.com> Did not post for long, but i was one of the devs who played along with this kind of thing: 1) There was a 'top' and 'bottom' map for each map, (tiles[4] and tiles[5]), this part is easy to do. Even the handling of empty space that would allow you to see ground bottom. Even handling loops in perspective was easy. I tried a few ways to implement this. Here are some highlight on why this wasn't done 1) to give correct perspective, client must shift bottom-right rendering of 'below' map, even more for below-below, etc. It's impossible to do it properly using the current used pseudo perspective, especially to match ground of level x+1 to walls of level X. The layering system used at that time made it even more difficult. 2) there is a problem with giant monster, they look strange in this laying out. 3) There was the technical problem of the falling and jump/levitate spell to handle (can levitate or fly allow you to go higher of one level above map? how?) 4) There was the general problem of line of sight. Can a player/monster see someone on on level higher if he is distant engouh? 5) There was the problem of aiming monsters / player below you using you spell? (Can be forbidden but doens't look natural) To make it short, i tried several thing, i always got stucked by point (1). Current wall displays does not stack properly in crossfire with the tiles system. Maybe that now there are more than 3 layers visible to client, we could mark some layers as needing shifting, then we could solve problem. I would recommand first your draw 2 levels in editor, then you use gimp or alike to see how client should stack them. Be aware anyway that you can't do this without altering map client protocol. PS: Hello everyone. En l'instant pr?cis du 10/06/07 18:48, Andrew Fuchs s'exprimait en ces termes: > On 6/3/07, Mark Wedel wrote: > >> Nicolas Weeger wrote: >> >>> Hello. >>> >>> I remember, quite a long time ago, discussion about "vertical" map-tiling, >>> that is from eg the top of a tower see the ground below, belonging to another >>> map. >>> Anyone remember that, and how it was implemented? >>> >>> I think it was like the 4 other map tiles, except used in a different way. >>> >> Don't know if it was ever really done, but I know it was theoretically possible. >> >> If we presume a square building with an interior courtyard, your first level >> would have to consist of at least 5 maps: >> >> 123 >> 456 >> 789 >> >> With the 5 map being common to all levels. You have to use 9 maps, because >> when tiling, the map has to tile with a map the same size, and can only tile to >> 1 map in each direction. >> >> So for second level, you would do something like: >> ABC >> D5E >> FGH >> >> And so on as you go up. Note that you have the layers below visbile to the >> next layer - perhaps the next layer, the main building doesn't go up, just >> towers at the corners, so could do something like: >> IBJ >> D5E >> KGL >> >> Note that you would basically use the inverse for layers 1 and 2 if you wanted >> a central tower that could see the terrain around it. and I believe I have a >> simple example in the test directory of a two store house which is done as: >> 12 and 13, where 1 is the common front yard, with 2 and 3 being the floors. >> > > Anyone want to do this to the balcony on variel's church in scorn? > > From nicolas.weeger at laposte.net Wed Jun 13 12:25:20 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Jun 2007 19:25:20 +0200 Subject: [crossfire] map design guideline In-Reply-To: <20070611193742.GA1741@cthulhu.desy.de> References: <20070611193742.GA1741@cthulhu.desy.de> Message-ID: <200706131925.23889.nicolas.weeger@laposte.net> > I could also argue that the monster has to be smart enough to not > destroy its treasure. Why should the monster hoard treasure if every > treasure hunter will be killed by suffering the hoard? ;-) Because the monster prefers destroying its treasure than seeing it fall into other's hands/claws? :) But yes, improving monster intelligence, in general, is a task to do someday. > Easy and most obvious is to not mix the enemy races like angels with > devils, faeries and goblins / trolls, ... > > But indeed, we need a list of coexisting monster types. Yep. *points to the wiki* feel free to start writing ;) > Is there just a single map implementing such a restriction? > > Anyway, I would say it should be part of policy. Maybe with coding > support to clear the quest map if someone enters who already solved the > quest. It's already a confession to the game that every player is able > to do the same quest. How often needs someone to be rescued, or a chief > be killed, ...? But then you run into content issues. That would require way much content that we had if only one player could do a quest (unless I'm wrong, that's what you are suggesting?). That would also cause space issues - all finished dungeons still exist, in their "completed" form, taking space (granted, we have quite free space for now). I'm not aware of maps implementing this, but you could possibly by two ways. Have the treasure map unique, so a player can get items only once (beware creation of dummy characters that'll get town portaled to the treasure entrance). Or set the final quest item on a 'unique' ground tile. This ensures only one player can get the item. Or set the 'unique' flag on the item, too, that'd work (but please note currently such items can possibly be lost by various means, like alchemy, destruction, ...) > It's a role playing game, right? What's wrong on having a focus on role > playing instead of monster slaying? Well, IMO we need both. You're right we've been mostly focused on the monster slaying part - probably because it's easier than adding complex interaction mechanisms. > It's all about rewards. If you get better and better catching weapons, > which are more and more effective against monsters, you'll have a lot of > players catching monsters. ;-) > > Or just hard to get ingredients for formulae as a payment for monsters. > But you're right, would be hard to balance. Anyway, wouldn't it a way to > improve gameplay? Maybe. I'd say we have enough room in the world to have some maps with that idea implemented :) > Yep, but most maps shouldn't contain a big demon... Why? Didn't you hear of the Other Dimension, where fire monster roam the plains of the devasted world? :) > Not really, after you gave the quest item to the one who has sent you, > you finished the quest. > > Or if nobody has sent you, after you got the quest item. There are ways > to define the end of a quest. I don't think this would be a problem at > all. Yes, but workarounds are always possible - create a junk char to get the item instead of your regular char, and so on. Please note that I'm not saying your ideas aren't worth trying :) Just that so far no one tried, I guess ^_- Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070613/8e415a66/attachment.pgp From nicolas.weeger at laposte.net Wed Jun 13 12:35:03 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 13 Jun 2007 19:35:03 +0200 Subject: [crossfire] The future of Crossfire In-Reply-To: <20070611201837.GB1741@cthulhu.desy.de> References: <20070611201837.GB1741@cthulhu.desy.de> Message-ID: <200706131935.03580.nicolas.weeger@laposte.net> > > I think both are important. > > But graphics first. Check out this list: > > http://play-free-online-games.com/games/games_rpg.html > > Imagine you don't know anything about this games. Which one would you > try first, second, third, ... and when would you try crossfire? The list is pretty old, no? Daimonin's URL is plain wrong. > You'll never find out how deep crossfire is, if you never try it out, > right? Yes, but we can't force people to try :) > > If you got ideas to find graphists, feel free to express yourself :) > > Those I know always want money for their work... > > > IMO, a way to attract graphists is either other graphists, or good > > gameplay. > > See above, hard to make it over gameplay. :( > > So you need a really good gameplay, far better than most games and > anything else than lot of hack and slay maps.. As I said in another mail, gameplay / role play is hard - and maybe we focused too much on h&s, yes, which is why some people are trying to do content :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070613/28103555/attachment.pgp From crossfire at kahnert.de Thu Jun 14 12:40:07 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 14 Jun 2007 19:40:07 +0200 Subject: [crossfire] map design guideline In-Reply-To: <200706131925.23889.nicolas.weeger@laposte.net> Message-ID: <20070614174007.GC11133@cthulhu.desy.de> On Wed, Jun 13, 2007 at 07:25:20PM +0200, Nicolas Weeger wrote: > > Anyway, I would say it should be part of policy. Maybe with coding > > support to clear the quest map if someone enters who already solved > > the quest. It's already a confession to the game that every player > > is able to do the same quest. How often needs someone to be rescued, > > or a chief be killed, ...? > > But then you run into content issues. That would require way much > content that we had if only one player could do a quest (unless I'm > wrong, that's what you are suggesting?). It looks like I didn't expressed myself clear enough. Every player should be able to do every quest exactly once. It's a multi player computer game, so we can't deny other player for example to do the pup_land quest because another player already made it. But after you made it, it's over for this character. Let it at least be logical for a single player. > That would also cause space issues - all finished dungeons still > exist, in their "completed" form, taking space (granted, we have quite > free space for now). That's not what I meant. For example you solve a quest where you have to slay a dragon and rescue a princess. If you leave the dragon hoard behind and you enter the dragon cave a second time (after map reset), you shouldn't find treasure nor the princess there. The left behind treasure vanished, because others took it after the dragon is dead and the princess, because you rescued her. This could be done by a new function which removes all the stuff if you enter again, or by a second [empty] map, or by teleporters (not the best choice because the player is able to charm the monsters "outside" of the map) or whatever. > > Not really, after you gave the quest item to the one who has sent > > you, you finished the quest. > > > Or if nobody has sent you, after you got the quest item. There are > > ways to define the end of a quest. I don't think this would be a > > problem at all. > > Yes, but workarounds are always possible - create a junk char to get > the item instead of your regular char, and so on. Sure, but I like the idea of a storyline. You have to finish a quest before you're able to start the next one, like it's made in the scorn castle. If those quests just let you finish them once, it would be even better. :) And you can always set up a trap. If you take the quest item, you're hit by a trap which causes enough damage to kill a junk character but not the high level hero who really solved the quest. Whatever, the storyline option would prevent players to abuse it to often. Or let all players get the "quest solved flag" as soon as they touch the quest item. :p There are ways to prevent such things. And once again. This doesn't mean that every map has to be part of a quest. Random maps for treasure and levels are still welcome. Regards, J?rgen From crossfire at kahnert.de Thu Jun 14 14:18:22 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Thu, 14 Jun 2007 21:18:22 +0200 Subject: [crossfire] reorganizing the entire world Message-ID: <20070614191822.GD11133@cthulhu.desy.de> What do you think about reorganizing the entire world to get regions for characters in a range of levels? For example the starting region has maps for character with level 1-5, than move over to a region for level 6-10 character, ... Every region should have a storyline quest which leads through this area. After the quest is solved, you're able to enter the next region and so on. One of the annoying parts of crossfire is to enter a high level map dying pretty fast or to slay through tons of low level monsters as a high level character before you reach the big boss. Take the quest to face "Lorkas the fallen" (lvl 125 destroying_angel). You have to start with ants, spiders, kobolds, orcs, goblins and a single ogre. After that you have to deal with zombies, skeletons, ghosts and a single wraith. You got the picture? If you're able to face Lorkas, you're able to sleep surrounded by an angry mob of trolls smashing on you with their large clubs and you neither wake up nor getting a bump. As a high level character I don't like to face those critters. To avoid this, we need to have separated regions with an increasing degree of difficulty. I think having this would dramatically improve the fun and gameplay. And this is probably worth doing it even if it's a lot of work. J?rgen From nicolas.weeger at laposte.net Fri Jun 15 12:29:39 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 15 Jun 2007 19:29:39 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070614191822.GD11133@cthulhu.desy.de> References: <20070614191822.GD11133@cthulhu.desy.de> Message-ID: <200706151929.44668.nicolas.weeger@laposte.net> Hello. > What do you think about reorganizing the entire world to get regions > for characters in a range of levels? > > For example the starting region has maps for character with level 1-5, > than move over to a region for level 6-10 character, ... Note that, I think, Brest is already intended for higher level characters (getting there from Scorn or Navar is quite dangerous). What about giving hints as to the map level of a quest? I don't mean to have a char at the entrance saying 'this is for levels 50+ only', but things more subtle - "it is said the entrance to the castle is guarded by powerful cyclops, but no one ever came back to confirm this rumour". If you know you can kill cyclops, then you can try. Also, this should be considered in the context of "speed rethinking" that was mentioned on the list. If we change the overall combat speed, this issue becomes slightly less important - enter a map, spot the big red dragon, flee before it fries you. The issues you point for Lorkas about starting with mice and such is really a map design one, which can and should be fixed for the reasons you give :) I'm not totally sure about forcing to solve quests to go in another region. Arguably, the fun is to be able to visit for instance Lake Country, even if you can't do the quests - it would be strange to be told "you're not powerful enough for that", or "you need to solve something", no? This of course doesn't preclude for instance having a town in which you can only enter after doing some quest (think an isolated town, or a hidden town, something like that). IMO, we should write all those ideas (I mean maps, speed, quests, ...) on the wiki (I'll do that when I have some time if no one does it before), mix'em, comment'em, think about'em. Seeing the "bigger" picture is always nice :) Having a global concept before implementing is better :) Thanks for all your ideas and suggestions, btw ^_- Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070615/494cd66c/attachment.pgp From nicolas.weeger at laposte.net Fri Jun 15 12:34:45 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Fri, 15 Jun 2007 19:34:45 +0200 Subject: [crossfire] map design guideline In-Reply-To: <20070614174007.GC11133@cthulhu.desy.de> References: <20070614174007.GC11133@cthulhu.desy.de> Message-ID: <200706151934.45865.nicolas.weeger@laposte.net> > It looks like I didn't expressed myself clear enough. > > Every player should be able to do every quest exactly once. It's a multi > player computer game, so we can't deny other player for example to do > the pup_land quest because another player already made it. > > But after you made it, it's over for this character. Let it at least be > logical for a single player. Ok, I indeed didn't get what you meant :) > That's not what I meant. For example you solve a quest where you have to > slay a dragon and rescue a princess. If you leave the dragon hoard > behind and you enter the dragon cave a second time (after map reset), > you shouldn't find treasure nor the princess there. The left behind > treasure vanished, because others took it after the dragon is dead and > the princess, because you rescued her. But then how do you handle parties? Player 'dragon' does the quest, then later parties with 'dwarf' who didn't yet do the quest - what happens? > This could be done by a new function which removes all the stuff if you > enter again, or by a second [empty] map, or by teleporters (not the best > choice because the player is able to charm the monsters "outside" of the > map) or whatever. Code, that's boring, let's first define what we want ;) > Sure, but I like the idea of a storyline. You have to finish a quest > before you're able to start the next one, like it's made in the scorn > castle. If those quests just let you finish them once, it would be even > better. :) Having "chained" quests, like Scorn royalty, sure. Ideally, we'd have many many quests, influencing each other - if you get back some item for someone, you can't do another quest requiring you to have destroyed the item. But this requires much content writing :) > And once again. This doesn't mean that every map has to be part of a > quest. Random maps for treasure and levels are still welcome. *nods* Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070615/f987367f/attachment.pgp From crossfire at kahnert.de Fri Jun 15 15:13:18 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 15 Jun 2007 22:13:18 +0200 Subject: [crossfire] map design guideline In-Reply-To: <200706151934.45865.nicolas.weeger@laposte.net> Message-ID: <20070615201318.GA7453@cthulhu.desy.de> On Fri, Jun 15, 2007 at 07:34:45PM +0200, Nicolas Weeger wrote: > > For example you solve a quest where you have to slay a dragon and > > rescue a princess. If you leave the dragon hoard behind and you > > enter the dragon cave a second time (after map reset), you shouldn't > > find treasure nor the princess there. The left behind treasure > > vanished, because others took it after the dragon is dead and the > > princess, because you rescued her. > > But then how do you handle parties? > Player 'dragon' does the quest, then later parties with 'dwarf' who > didn't yet do the quest - what happens? Good question, I don't know. Depends on the implementation. The most logical way would be to clear the map for 'dwarf', because 'dragon' already solved it. But you can't avoid that 'dwarf' enters the map first, and after that let 'dragon' join the party. Because we don't have an infinite number of quests, we have to allow every player to do every quest. This is just a technical aspect of the game, no chance to solve it. A solution could be somthing like that. If 'dragon' enters first, 'dwarf' also gets the empty map [until map reset and without 'dragon']. If 'dwarf' enters first, deny 'dragon' to enter with 'cave closed' or something like that. I admit it's not all over satisfying, but at the moment I don't know a better solution. We have to life with that paradox because we reuse the quests for different characters. But it's not a bigger paradox than having a characater doing the same quest over and over again... > Code, that's boring, let's first define what we want ;) We're not coding anything like that right in the moment, don't we? We're still defining what we want, isn't it? ;) > Having "chained" quests, like Scorn royalty, sure. > Ideally, we'd have many many quests, influencing each other - if you > get back some item for someone, you can't do another quest requiring > you to have destroyed the item. > But this requires much content writing :) Wow, I didn't thought that deep to have different strands of a story mutually excluding each other. So far I just thought about having each quest being playable by everyone exactly once. Influencing the storyline by individual choices, yes, nice idea. Having for example a quest to get a powerful life sucking artefact. You could either bring it to a follower of Gaea and destroy it or to a minion of Devourers who likes to use it. Maybe for CF3 or CF4. ;-) For the beginning I would be happy to see more role playing coming to CF. It doesn't need to be a full featured mega plot. :) J?rgen From crossfire at kahnert.de Fri Jun 15 15:56:46 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 15 Jun 2007 22:56:46 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <200706151929.44668.nicolas.weeger@laposte.net> Message-ID: <20070615205646.GB7453@cthulhu.desy.de> On Fri, Jun 15, 2007 at 07:29:39PM +0200, Nicolas Weeger wrote: > > For example the starting region has maps for character with level > > 1-5, than move over to a region for level 6-10 character, ... > > Note that, I think, Brest is already intended for higher level > characters (getting there from Scorn or Navar is quite dangerous). But even in Brest you're able to find kobold generators, mice, goblins, etc. Just having a lot of higher level monsters lined up in a narrow corridor isn't exactly what I meant. Anyway, kind of, yes. > What about giving hints as to the map level of a quest? > I don't mean to have a char at the entrance saying 'this is for levels > 50+ only', but things more subtle - "it is said the entrance to the > castle is guarded by powerful cyclops, but no one ever came back to > confirm this rumour". If you know you can kill cyclops, then you can > try. Yes, that's nice. :) Having signs like "Very high level area Be careful!" for just having a few trapped dragons there, won't help at all. And what about an inner voice saying a level 30 character staying in front of a level 50 map something like: "You have a really bad feeling about this place.". This could even be a skill "sixth sense" or so. ;) > I'm not totally sure about forcing to solve quests to go in another > region. Arguably, the fun is to be able to visit for instance Lake > Country, even if you can't do the quests But that's a matter of map design, right? If you don't find anything suitable for your level, it's no fun to die there. Don't create high level regions which may be attractive for low level characters. > - it would be strange to be told "you're not powerful enough for > that", or "you need to solve something", no? Indeed, not very elegant to deny a path this way. But what about things like guardians which don't allow you the pass, because the governor don't allow it? Or a gate pass, port pass, passport, ...? ;) Or you're invited by the king of an island because he heard about your heroic deeds and has a job for you. ;) There are many ways to do it in a role playing style. > This of course doesn't preclude for instance having a town in which > you can only enter after doing some quest (think an isolated town, or > a hidden town, something like that). Yes, something like that. You could also have a secret path with a password which would allow you the enter the region (for player who already did the quests and don't like to do it again with their second character). J?rgen From brenlally at gmail.com Sun Jun 17 18:48:29 2007 From: brenlally at gmail.com (Brendan Lally) Date: Mon, 18 Jun 2007 00:48:29 +0100 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070614191822.GD11133@cthulhu.desy.de> References: <20070614191822.GD11133@cthulhu.desy.de> Message-ID: <200706180048.29176.brenlally@gmail.com> Been a while since I played cf, so I will be commenting on the game as it played a year ago; but this is a subject I've touched on before in #crossfire, so I hope the following is helpful. On Thursday 14 June 2007 20:18:22 Juergen Kahnert wrote: > What do you think about reorganizing the entire world to get regions > for characters in a range of levels? > > For example the starting region has maps for character with level 1-5, > than move over to a region for level 6-10 character, ... > > Every region should have a storyline quest which leads through this > area. After the quest is solved, you're able to enter the next region > and so on. The way I had thought of this before was in terms of a 'home town', that being the place where a character would store most of their items, and set out to quest from. In order to have a progression in the difficulty in maps, it is useful to also have a progression in 'home town'. For example: a player should start out in scorn, hang around there for a bit, visiting the other nearby villages before heading to navar, at high level establishing themselves in brest, before finally (maybe) moving into a guild hall. In order for that to work, there should be three things that are true. 1) it should be more useful to a mid-level character to live in navar than scorn 2) it should not be distinctly more useful (nor obviously enticing) for a low-level character to leave scorn (although they should be free to do so if they want) 3) the degree to which a character can be 'locked in' to having scorn as a home town, and thereby be discouraged from moving should be limited (probably there needs to be some kind of python-based house moving support to help there) The reasons why this didn't work last time I played; navar had a worse apartment than scorn, with less useful portals scorn had plenty of high level maps easily accessible. Brest had a portal leading directly there from scorn, making the approach quest meaningless (I don't see any changes to scorn apartment, suggesting this is still the case) In order to fix this then; Define the 3 major home cities (allow others, but assume the natural progression of scorn->navar->brest) in each city, have portals which go back but not forwards, (so navar to scorn, but not scorn to navar). Move some of the very high level maps from scorn and its nearby cities to navar (or brest) - for example, the entrance to pupland would probably move. Make the other apartments available at least as good as the one in scorn (changing the portal layout probably achieves most of that anyway). Move the guild hall purchasing place to Brest. From what I remember the game world looking like then, you would have a structure like Scorn -------------------Navar---------------Brest--------Guilds (maybe) | | Euthville Wolfsburg Santo Dominion pupland (moved) darcap (hopefully that's vaguely readable to most people) So in this case then, a low level character could go straight to navar (they could try to go to brest and get killed en route as well....), but they would find there wouldn't be much to interest them, that they couldn't afford an apartment, and they would probably leave to go back to scorn for a bit. The quest based progression could be interesting, for example if the reward for some intermediate stage of the scorn royalty quest was an invitation to see the mayor (or whatever it is, I forget the backstory) of navar (write it as a diplomatic visit or some such), who would send his own dragon to give a free ride there, then you get a strong indication that maybe your character is 'ready' to move From nicolas.weeger at laposte.net Mon Jun 18 11:46:12 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jun 2007 18:46:12 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070615205646.GB7453@cthulhu.desy.de> References: <20070615205646.GB7453@cthulhu.desy.de> Message-ID: <200706181846.16423.nicolas.weeger@laposte.net> > Indeed, not very elegant to deny a path this way. But what about things > like guardians which don't allow you the pass, because the governor > don't allow it? Or a gate pass, port pass, passport, ...? ;) > > Or you're invited by the king of an island because he heard about your > heroic deeds and has a job for you. ;) > > There are many ways to do it in a role playing style. Indeed, that can be part of the fun :) As usual, need to define a reason why you must wait for invitation before coming ;) > Yes, something like that. You could also have a secret path with a > password which would allow you the enter the region (for player who > already did the quests and don't like to do it again with their second > character). Maybe, that's just a design issue, I guess. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070618/c5e02bbe/attachment.pgp From nicolas.weeger at laposte.net Mon Jun 18 11:49:10 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jun 2007 18:49:10 +0200 Subject: [crossfire] map design guideline In-Reply-To: <20070615201318.GA7453@cthulhu.desy.de> References: <20070615201318.GA7453@cthulhu.desy.de> Message-ID: <200706181849.10543.nicolas.weeger@laposte.net> > Wow, I didn't thought that deep to have different strands of a story > mutually excluding each other. > > So far I just thought about having each quest being playable by everyone > exactly once. > > Influencing the storyline by individual choices, yes, nice idea. Having > for example a quest to get a powerful life sucking artefact. You could > either bring it to a follower of Gaea and destroy it or to a minion of > Devourers who likes to use it. > > Maybe for CF3 or CF4. ;-) > > For the beginning I would be happy to see more role playing coming to > CF. It doesn't need to be a full featured mega plot. :) Bah, CF2 is still months away, so plenty of time to do things :) So IMO we should write all those ideas somewhere on the wiki, and start working on map design :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070618/fd5b36a7/attachment.pgp From crossfire at kahnert.de Mon Jun 18 15:33:52 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 18 Jun 2007 22:33:52 +0200 Subject: [crossfire] map design guideline In-Reply-To: <200706181849.10543.nicolas.weeger@laposte.net> Message-ID: <20070618203352.GA3646@cthulhu.desy.de> On Mon, Jun 18, 2007 at 06:49:10PM +0200, Nicolas Weeger wrote: > So IMO we should write all those ideas somewhere on the wiki, and > start working on map design :) The map guide is not part of the wiki: http://crossfire.real-time.com/guides/map/map_guide.html And is this just an idea or the goal? J?rgen From crossfire at kahnert.de Mon Jun 18 15:38:55 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Mon, 18 Jun 2007 22:38:55 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <200706180048.29176.brenlally@gmail.com> Message-ID: <20070618203855.GB3646@cthulhu.desy.de> On Mon, Jun 18, 2007 at 12:48:29AM +0100, Brendan Lally wrote: > The way I had thought of this before was in terms of a 'home town', > that being the place where a character would store most of their > items, and set out to quest from. Having a central city as a base for the players has some advantages. Especially as a meeting place for players. > navar had a worse apartment than scorn, with less useful portals > scorn had plenty of high level maps easily accessible. > Brest had a portal leading directly there from scorn, making the approach > quest meaningless (I don't see any changes to scorn apartment, suggesting > this is still the case) The apartments should have better connected portals, I agree. This navar apartment is just useless. > Define the 3 major home cities (allow others, but assume the natural > progression of scorn->navar->brest) I wouldn't fix it to three, but it's always extendable. ;) > in each city, have portals which go back but not forwards, (so navar > to scorn, but not scorn to navar). This will help to connect the apartments. And word of recall will always take you back. It gives you a real benefit to move to the next region, because you're able to come back easily. So it's not that important to have a central place. Having the home in the highest accessible region always offers quick travels back to lower level ones. > Move some of the very high level maps from scorn and its nearby cities > to navar (or brest) - for example, the entrance to pupland would > probably move. As the subject says, I would reorganize it all. Not just a few maps, really every map which won't fit into the region for the specified levels. > Make the other apartments available at least as good as the one in > scorn (changing the portal layout probably achieves most of that > anyway). Make the apartments better and better, the higher the region become. > Move the guild hall purchasing place to Brest. Why just one guild hall and why should every guild looks like the same? Having a guild in a low level region don't need the same features as a guild in a higher level region. > So in this case then, a low level character could go straight to navar > (they could try to go to brest and get killed en route as well....), > but they would find there wouldn't be much to interest them, that they > couldn't afford an apartment, and they would probably leave to go back > to scorn for a bit. Make the travel to higher level regions dangerous, so low level players aren't able to reach them anyway. And if they arrive, they won't find a single map they could survive in. But I still think a storyline which give you access to higher level regions only after you solved some key quests of the former area is better. This will prevent players from leveling up at raffle without getting any good stuff nor having even the knowlegde where to get it. Having a storyline which leads the player through all the fine maps to equip the character step by step is much more fun than begging for good items from high level characters. And the quest rewards should take care of the race and class. Being a fireborn and getting a girdle of damage is just useless; getting a good weapon as a monk, too. J?rgen From nicolas.weeger at laposte.net Mon Jun 18 15:47:22 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 18 Jun 2007 22:47:22 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070618203855.GB3646@cthulhu.desy.de> References: <20070618203855.GB3646@cthulhu.desy.de> Message-ID: <200706182247.26045.nicolas.weeger@laposte.net> > The apartments should have better connected portals, I agree. This navar > apartment is just useless. If someone writes a nice quest (probably medium level), I have a nice quest reward that will help for that :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070618/0c35cbe9/attachment.pgp From leaf at real-time.com Wed Jun 20 12:30:10 2007 From: leaf at real-time.com (Rick Tanner) Date: Wed, 20 Jun 2007 12:30:10 -0500 Subject: [crossfire] map design guideline In-Reply-To: <20070618203352.GA3646@cthulhu.desy.de> References: <20070618203352.GA3646@cthulhu.desy.de> Message-ID: <46796422.7040306@real-time.com> Juergen Kahnert wrote: > On Mon, Jun 18, 2007 at 06:49:10PM +0200, Nicolas Weeger wrote: >> So IMO we should write all those ideas somewhere on the wiki, and >> start working on map design :) > > The map guide is not part of the wiki: > > http://crossfire.real-time.com/guides/map/map_guide.html > > And is this just an idea or the goal? It's on the wiki, just formatted (numbered) a little differently. http://wiki.metalforge.net/doku.php/map_making -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070620/cce3eac4/attachment.pgp From leaf at real-time.com Wed Jun 20 19:00:17 2007 From: leaf at real-time.com (Rick Tanner) Date: Wed, 20 Jun 2007 19:00:17 -0500 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070618203855.GB3646@cthulhu.desy.de> References: <20070618203855.GB3646@cthulhu.desy.de> Message-ID: <4679BF91.7090403@real-time.com> Juergen Kahnert wrote: > On Mon, Jun 18, 2007 at 12:48:29AM +0100, Brendan Lally wrote: >> >> Make the other apartments available at least as good as the one in >> scorn (changing the portal layout probably achieves most of that >> anyway). > > Make the apartments better and better, the higher the region become. Because of how apartment(s) and apartment files are stored - how would someone with the old/original apartment "upgrade" to a new or revamped apartment? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070620/4e1c8a33/attachment.pgp From mwedel at sonic.net Wed Jun 20 23:52:40 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 20 Jun 2007 21:52:40 -0700 Subject: [crossfire] reorganizing the entire world In-Reply-To: <4679BF91.7090403@real-time.com> References: <20070618203855.GB3646@cthulhu.desy.de> <4679BF91.7090403@real-time.com> Message-ID: <467A0418.6000007@sonic.net> Rick Tanner wrote: > Juergen Kahnert wrote: >> On Mon, Jun 18, 2007 at 12:48:29AM +0100, Brendan Lally wrote: >>> Make the other apartments available at least as good as the one in >>> scorn (changing the portal layout probably achieves most of that >>> anyway). >> Make the apartments better and better, the higher the region become. > > Because of how apartment(s) and apartment files are stored - how would > someone with the old/original apartment "upgrade" to a new or revamped > apartment? Presumably, that is less an issue if that or other changes requires starting characters from scratch. Some discussions about skills would suggest that may be needed. Alternatively, it probably wouldn't be hard to allow players to reset per player maps (apartments) they may own. They'd have to do the work of taking everything out, etc. But really, the only code needed to implement that is flush out the map, if in memory, and do an unlink of the pathname From green_scene88 at hotmail.com Fri Jun 22 16:18:40 2007 From: green_scene88 at hotmail.com (David Safir) Date: Fri, 22 Jun 2007 21:18:40 +0000 Subject: [crossfire] New Quests Message-ID: Hi, I'm MoonWhisper, a fairly long time player of crossfire, slowly working my way into the highscores I became concerned of something. The new maps. A couple players who have only been around for a couple months worl their way into the highscores easaly, it makes the game obsolete, it seems the newer the map is the less the rest of the game matters. The new quests have nothing to them, nothing to figure out, you just kill the big monster and the treasure is yours. Not only that but the items have become out of wac, this girdle of valriel a very new item, it out does the girdle of the firegod an older quest, with it's stats alone, but the firegod one is harder to get and takes some puzzle solving, it's not easy to access, nor is it in scorn, the central city. Never the less the valriel girdle is much much stronger. It's not just that, but the item power is a whopping only 1, thats rediculous, how can you make an item with str +3, and con +2 and many resistances and give it item power 1? the other girdle has 2 item power, and it doesn't compare, bare in mind how easy it is to get the valriel girdle. In addition to this there are other problems. Like dragon food. It took woo, an old player, no longer on, a looong time to get his resistances past 90. Now new dragons have it much easier to get resistances up. the result is 1/2 the people playing are dragons, because it's too easy now to get resistances up. That has to slow down. Lastly The monster experience. Take the zorn quest, a perfect place to level up, because the monsters give away so many points after their killed, the newbies level up in to 100 in weeks. weeks is a short time to level playing at no more than two 1/2 hours a day -and even thats long time to play for one day. The shopkeeper alon gives 2 mil. that guy takes about 3 seconds to kill. That's not right. Between Hell, Heaven, and Zorn's quest. the only old map people step into is Chaos lair and mage tower. Not right, making the old game obsolete with the maps that are easy and have literally the best items in it is dumb, and pointless, now it's easy for new players to take highscores and destroy old player, come on we've been playing longer, we deserve it. If all this could change that would be great, i want heaven to be remodified so it's fair, more itempower, more puzzles, more game. Thank You. _________________________________________________________________ Need a break? Find your escape route with Live Search Maps. http://maps.live.com/default.aspx?ss=Restaurants~Hotels~Amusement%20Park&cp=33.832922~-117.915659&style=r&lvl=13&tilt=-90&dir=0&alt=-1000&scene=1118863&encType=1&FORM=MGAC01 From nicolas.weeger at laposte.net Sat Jun 23 09:26:06 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 23 Jun 2007 16:26:06 +0200 Subject: [crossfire] map design guideline (was: Summary) In-Reply-To: <20070609125225.GA1316@cthulhu.desy.de> References: <20070609125225.GA1316@cthulhu.desy.de> Message-ID: <200706231626.09711.nicolas.weeger@laposte.net> So, no one has any opinion on what was said on the thread? No one cares? No one has any idea? No one agrees? No one rejects? What do you people on the list expect of Crossfire? Are you ready to help? Or is the project so dead no one contributes in any way? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070623/c141bfb0/attachment.pgp From nicolas.weeger at laposte.net Sun Jun 24 05:14:24 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sun, 24 Jun 2007 12:14:24 +0200 Subject: [crossfire] Code cleaning, part 2 In-Reply-To: <200706071929.39369.nicolas.weeger@laposte.net> References: <200706071929.39369.nicolas.weeger@laposte.net> Message-ID: <200706241214.27480.nicolas.weeger@laposte.net> Hello. > Here are more things I'd like to remove from trunk: > > Obsolete/old protocol things: > * item1 support, map0 / map1 / map1a, and related things map2 makes > obsolete (map_scroll, mapredraw, i think). Map2 is over one year old on the > client side, so no excuse no not support that Actually, I merged (trivial one) the cleaning to branch too, thus removing those obsolete things. This means the next client release will render old servers incompatible with client. On the tracker there is a 1.5.0 server, I'm not sure whether it will be compatible or not. The 1.9 (branch) and 2.0 (trunk) servers should be compatible. As for the trt fork, it uses the map1acmd for our client, thus it will be incompatible. Unless someone write a patch to fix this issue, its servers should in my opinion be unlisted from metaserver the next time we do a client release. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070624/901050fb/attachment.pgp From yann.chachkoff at myrealbox.com Sun Jun 24 05:29:04 2007 From: yann.chachkoff at myrealbox.com (Yann Chachkoff) Date: Sun, 24 Jun 2007 12:29:04 +0200 Subject: [crossfire] map design guideline (was: Summary) Message-ID: <1182680944.c7e16f1cyann.chachkoff@myrealbox.com> > So, no one has any opinion on what was said on the thread? > Ok, if you insist... My opinion is that regardless of the design guidelines, Crossfire maps will stay at best "average", because the fighting/damage system used forces fast and brutal combat. This is perfectly suitable with the original concept of a "hack'n'slash" game - but I do not think it fits the role of a more RPG-oriented game. Neither does it with the idea of multiplayer gaming. There is also the content problem, of course: too few content written, and fewer actually used in maps. > No one cares? > I stopped caring after it was obvious that better content was not map-making's top priority. > No one has any idea? > Write content. Use what's already written. Change the pace of combat to give a meaning to multiplaying. Then, maybe it would be time to set some design rules for maps. > No one agrees? No one rejects? What do you people on the list expect of Crossfire? > I expect it to focus less on code, and more on everything else. It doesn't seem to be the case. > Are you ready to help? > For teamwork ? Sure. For single-handed development, no. > Or is the project so dead no one contributes in any way? > A better question would be to ask why people don't contribute more. From mwedel at sonic.net Mon Jun 25 00:17:47 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 24 Jun 2007 22:17:47 -0700 Subject: [crossfire] safe/common item stack/inventory iteration? Message-ID: <467F4FFB.1000905@sonic.net> Looking at a crash on metalforge, and it is in a loop like: for (tmp = op->inv; tmp != NULL; tmp = next) { next = tmp->below; { do some work } } Now this construct is used to cover the case where the current object (tmp) goes away - we have a pointer to the next object. Such operations are not that uncommon, as the {do some work} block is more likely to destroy tmp. However, in this case, it appears that next was destroyed, so after {do some work} completed, tmp became next, and next (tmp->below) pointed to garbage, so the iteration after that crashed. In fact, in that second iteration, all of tmp was probably garbage, but perhaps didn't crash on that because the checks done (in this case, in the plugin.c file) probably didn't match - tmp->type and tmp->subtype did not match what was being looked for. At some level, handling this becomes difficult - it doesn't make sense to have a next_next pointer, as there could probably be cases where the next two objects get destoryed. The easiest thing in this case is to probably store something like next_count, and see if that differs (suggesting the item was destroyed), and if so, just bail out of the loop. This could perhaps cause some small inconsistencies (loop didn't do all the processing it should), but that is probably better than a crash. However, I know there are loops like that all throughout the code, so I wonder if it would be better to macroize that in some way. The correct code block is something like: next_count=op->inv?op->inv->count:0 for (tmp = op->inv; tmp != NULL; tmp = next) { /* May want to set tmp to null before the break, so that if * anything after the for loop tries to use it, it won't be * able to */ if (tmp->count != next_count) break; next = tmp->below; /* if next is NULL, this won't process again in any case */ if (next) next_count=next->count; { do some work } } I wonder if that could be put in a macro. Well, I know it could, but the problem is really that { at the end of the for line - ideally you want to be able to do something like: FOR_BELOW_OB(op, tmp) { {do some work } } With the macro taking care of declaring declaring the variables to handle the checking of destroyed status, etc. But you really want that opening brace to be in the code segment with the loop, simply because most editors key on that for indentation and other factors. A possibility is to have two macros, so something like: FOR_BELOW_OB(op, tmp, next, tmp_tag) { CHECK_BELOW_OB_STATUS(op, tmp, next, tmp_tag); {do some work } } So that at least the braces line up. Thoughts? It would seem good to try to make this standard, since it seems this is fairly common, and a crash seen one place could occur almost anyplace. From mwedel at sonic.net Mon Jun 25 01:54:47 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sun, 24 Jun 2007 23:54:47 -0700 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates Message-ID: <467F66B7.7080406@sonic.net> I looked at this bug a little. At some level, it is very easy to fix - if player is on a space, and anything (including face) on that space change, we just send all the contents of that space again to the player. That works fine, but is also somewhat bandwidth inefficient - if there are 30 items on that space, it has to send all 30, because as of now, stacking order is important. We should probably fix things so that stacking order isn't important, but there are still lots of things that assume will operate in the order the player sees (like apply below). A bad case example here is standing on a pile of treasure with say some rubies in it. Rubies are animated, so that entire pile would have to get sent again. Now a simple answer could be we don't really care about bandwidth, and I can put in my fix. I'm not sure if that is really the right answer. A better solution is to see if there is a player on the space of the changed item, and if so, just send an update item command for the changed face. That could still waste some bandwidth (we send that update, but then the player moves off that same tick, so never really sees that change). But updating just the face for a single object doesn't use much bandwidth. The problem here is that more extensive changes are needed to be able to quickly find out if there is a player on the space, since traversing all the objects each time a face changes looking for a player would be pretty costly. Since normally, only 1 player can be on a space, putting a pointer in the mapspace to point to the player would be a fast way to do that. But going further, the client has some level of animation support - for whatever reason, the code to animate the ground was never put in. I just wrote that, and it works for some cases - namely, those animations we let the client do (continuous animations like fountains, dragon transports, or rubies). But it doesn't handle the cases for things like handles (not really an animation, but a change of state), or gates (animate once, then stop). I'm thinking that the correct answer is a mix of the last two: If it is an animation the client can handle, server sends nothing. If it is a change of face that the client can't handle, then servers send an updateitem for a new face. And a *player pointer to maplook to make easy lookups to the player should be relatively straightforward. But thought I'd send this out to see if anyone else has clever ideas on a fix. From Juergen at Kahnert.de Mon Jun 25 11:48:38 2007 From: Juergen at Kahnert.de (Juergen Kahnert) Date: Mon, 25 Jun 2007 18:48:38 +0200 Subject: [crossfire] New Quests In-Reply-To: Message-ID: <20070625164838.GC11664@cthulhu.desy.de> Hi, On Fri, Jun 22, 2007 at 09:18:40PM +0000, David Safir wrote: > Hi, I'm MoonWhisper, a fairly long time player of crossfire, slowly > working my way into the highscores every player having xp who saved the character is in the highscore list: 'hiscore MoonWhisper There are only 26 player listed with the "hiscore" command without parameters. And it's part of every highscore, that there are only n player in the first n places. ;-) I don't think that the highscore is a central part of the game. It's not even important because you won't gain any advantages out of being on place x instead of y. > I became concerned of something. The new maps. It's not only the new maps, there is a lot of unbalanced stuff. :( That's the real problem. Did you read the "map design guideline" and the "reorganizing the entire world" thread? And are you willing to help to fix this? > A couple players who have only been around for a couple months worl > their way into the highscores easaly, It's always the same. If a high level player giving a low level player a rod of banishment lvl 110, this low level player will jump from level 1 to level 50 within 2 hours. Or a newbie asking for "leveling help in ...". You can play for weeks to reach level 20 and this dude will get the same xp within minutes... > it makes the game obsolete, I don't get it. If the game is fun, great. If the game is boring, stop playing it. If you play for highscore, do the same the others are doing to get a high score. > it seems the newer the map is the less the rest of the game matters. Maybe, I didn't checked the history of all the maps. But anyway, the entire world needs changes. Feel free to help. > The new quests have nothing to them, nothing to figure out, you just > kill the big monster and the treasure is yours. Most of the maps are like this; regardless of the age of the map. Re: valriel girdle Oh, item power of 1? Never realized that, I would expect 40, the same as for the ring and amulet. Looks like a bug. Re. dragon food > it's too easy now to get resistances up. That has to slow down. I think this fits into the part of reorganizing the entire world. > Lastly The monster experience. Take the zorn quest, Same as valriel, lots of xp. See above, I consider changing maps as part of the reorganization of the world, too. > Not right, making the old game obsolete with the maps that are easy > and have literally the best items in it is dumb, and pointless, Now I get it. Not the entire game, but the old maps are obsolete. Not all, but in fact, they're less favoured. Some high level player (but new / young) don't even know where to get some items, because they level up in just a few dungeons... Part of the idea of having chained quests to offer a more guided tour through the crossfire world. > now it's easy for new players to take highscores and destroy old > player, come on we've been playing longer, we deserve it. I wouldn't agree with this. Anyway, you gave good points and I understand you. > If all this could change that would be great, i want heaven to be > remodified so it's fair, more itempower, more puzzles, more game. Are you also willing to help by yourself? Creating / modifying maps, adding puzzles, quests, ...? I can't reorganize the world alone. And so far I'm not even sure if this would be desired. There aren't much comments about this issue. Regards, J?rgen From edler at heydernet.de Mon Jun 25 11:52:40 2007 From: edler at heydernet.de (Bernd Edler) Date: Mon, 25 Jun 2007 18:52:40 +0200 (CEST) Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: <467F4FFB.1000905@sonic.net> References: <467F4FFB.1000905@sonic.net> Message-ID: On Sun, 24 Jun 2007, Mark Wedel wrote: > > Looking at a crash on metalforge, and it is in a loop like: > > for (tmp = op->inv; tmp != NULL; tmp = next) { > next = tmp->below; > { do some work } > } > > Now this construct is used to cover the case where the current object (tmp) > goes away - we have a pointer to the next object. Such operations are not that > uncommon, as the {do some work} block is more likely to destroy tmp. > > However, in this case, it appears that next was destroyed, so after {do some > work} completed, tmp became next, and next (tmp->below) pointed to garbage, so > the iteration after that crashed. ... > The easiest thing in this case is to probably store something > like next_count, and see if that differs (suggesting the item was destroyed), > and if so, just bail out of the loop. > If we are sure tmp will not be destroyed in some uncontrollable recursive calls we can avoid bailing out altogether: for (tmp = op->inv;tmp != NULL;;) { destroy_me = NULL; { do some work replace destroy_obj(tmp) with destroy_me = tmp; do more work } tmp = tmp->below; if { destroy_me } then destroy_obj(destroy_me); } If we want the big and clean solution, we only really kill objects afterwards. This costs us one extra pointer per object. like ob->destroy_list, plus two variables: Destroy_list_first,Destroy_list_last As in: void mark_for_destruction(object ob) { if ( ob->destroy_list != null ) then return; /* this one is dead already */ if ( Destroy_list_first == NULL ) then { Destroy_list_first = ob; Destroy_list_last = ob; } Destroy_list_last->destroy_list = ob; ob->destroy_list = ob; /* self-reference marks end of list */ Destroy_list_last = ob; { remove the object from lists like active,below etc. } } void destroy_marked_objects() { for (tmp = Destroy_list_first; tmp != NULL; tmp = next) { next = tmp->destroy_list; free(tmp); /* the object should already be removed from all lists */ /* save this destruction list */ if (next == tmp) then last; /* self-reference marks end of list * } Destroy_list_first = NULL; Destroy_list_last = NULL; } From nicolas.weeger at laposte.net Mon Jun 25 14:17:54 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Mon, 25 Jun 2007 21:17:54 +0200 Subject: [crossfire] New Quests In-Reply-To: <20070625164838.GC11664@cthulhu.desy.de> References: <20070625164838.GC11664@cthulhu.desy.de> Message-ID: <200706252117.56879.nicolas.weeger@laposte.net> Hello. (David is not on the list, thus replying to him directly too - also forwarded the mail from J?rgen). As J?rgen said, we are currently having a discussion about game balance, world reorganization, things like that. The following threads are related to this: * http://mailman.metalforge.org/pipermail/crossfire/2007-June/011467.html on the future of Crossfire * http://mailman.metalforge.org/pipermail/crossfire/2007-June/011500.html on map design guidelines * http://mailman.metalforge.org/pipermail/crossfire/2007-June/011532.html on reorganizing the whole world All point of view are of course welcome :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070625/a04faa08/attachment.pgp From mwedel at sonic.net Mon Jun 25 23:07:54 2007 From: mwedel at sonic.net (Mark Wedel) Date: Mon, 25 Jun 2007 21:07:54 -0700 Subject: [crossfire] safe/common item stack/inventory iteration? In-Reply-To: References: <467F4FFB.1000905@sonic.net> Message-ID: <4680911A.2050104@sonic.net> Bernd Edler wrote: > > If we are sure tmp will not be destroyed in some uncontrollable recursive > calls we can avoid bailing out altogether: We can't be sure that tmp won't get destroyed. In the general case, one has no real clue what may or may not get destroyed. And in almost all cases, it is a function that is called (or function of a function) that destroys tmp, not the function where the for loop itself exists, so the code snippet below won't work. > > > for (tmp = op->inv;tmp != NULL;;) { > destroy_me = NULL; > { > do some work > replace destroy_obj(tmp) with destroy_me = tmp; > do more work > } > tmp = tmp->below; > if { destroy_me } then destroy_obj(destroy_me); > } > > If we want the big and clean solution, we only really kill objects > afterwards. This costs us one extra pointer per > object. like ob->destroy_list, > plus two variables: Destroy_list_first,Destroy_list_last > As in: > > void mark_for_destruction(object ob) { > if ( ob->destroy_list != null ) then return; > /* this one is dead already */ > if ( Destroy_list_first == NULL ) then { > Destroy_list_first = ob; > Destroy_list_last = ob; > } > Destroy_list_last->destroy_list = ob; > ob->destroy_list = ob; > /* self-reference marks end of list */ > Destroy_list_last = ob; > { remove the object from lists like active,below etc. } > } The problem is that when the object is removed from the active and below lists, that is what screws up the pointers. In the simple case, something like: for (tmp=op->inv; tmp; tmp=tmp->below) { ... } Fails in the above case if tmp is put on a destroy list, because tmp->below now doesn't point to anything meaningful (well, it points to null, which would then result in that for loop terminating, which isn't really different than my described change). This isn't a real simple problem. As said, the use of the: for (tmp=op->inv; tmp; tmp=next) { next = tmp->below .... } Covers the case just fine when tmp is destroyed in the processing. It doesn't cover the case when next is destroyed in the processing, which is what I observed in the bug. and I could even see in some rare cases where both tmp and next are destroyed in the processing, leaving one with really nothing to work with. Under any situation, I can come up with some method that could potentially result in things not working. Storing a pointer to the last object processed, and if something is destroyed, walk the last until you get to that object, and then resume, doesn't work, because that last processed object could be destroyed. Such wide spread changes to objects is much more likely to happen for ground spaces than inventory (a spell could in theory destroy 50% of the objects on a space for example). The only really foolproof way would be to add some flag - something like 'FLAG_NEEDS_TO_BE_DESTROYED'. Instead of the object actually getting destroyed, that flag is set, and then there is some other function later that goes through and cleans these objects up. However, that would add a lot of processing time. It would also require a pretty major rewrite. That is because the logic is generally like: remove_object(op) - this removes it from the map/inventory, and clears the above/below pointers, etc, so this has to be modified not to actually remove the object in question, but instead state it has to be removed. free_object(op) - this is what actually returns the memory to the system - this can't happen as long as op hasn't been removed. So the usual case of: remove_op(op); free_object(op); Wouldn't really work - remove_ob would have to mark that the object needs to be removed, free_object would have to mark that that object should be freed, and then elsewhere, the actual work of removing/freeing those objects would have to happen (probably called from the main loop, where we can know that nothing else will be messing with those objects). But even that gets tricky - if an object is on top of a button, when that object is removed, button is now triggered, which could result in other objects getting destroyed. But because those calls are used everywhere, that cleanup routine would have to examine _all_ of the objects - and lots of other code would have to be modified to be aware of these pending objects (in the for loops above, it would need to skip over these, etc). In any case, what I was thinking about was more trying to make macros so that when we find cases of that loop needing different/better processing, it is just a matter of updating the macros, not of updating 50 different for loops in the code. From crossfire at kahnert.de Tue Jun 26 06:22:32 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Tue, 26 Jun 2007 13:22:32 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070614191822.GD11133@cthulhu.desy.de> Message-ID: <20070626112232.GB29658@cthulhu.desy.de> I have the following idea for the new world: After character generation, you have to chose your class. As soon as you have chosen your class, you won't enter "start/Nexus", but the guild of that class. This guild will be a combination out of the newbieshouse and the beginners maps to teach new people how to play this game. And there you learn the abilities of your class. So you won't get a bunch of class specific items. Instead of this you're guided through maps where you learn your abilities and where you're teached how to use them. Parts of the guided tour could be shared between different guilds. This will reduce the map making work. After the tour, the guild master will give you your first quest. This will be a chained quest. You will get better and better class items from your guild master for solving the quests or as a quest treasure. For more class like role playing, the guild is able to ostracize players by checking for example if a sorcerer uses close combat skills instead of magic. If the sum of the close combat skills exceed the sum of magic skills by a defined limit (e.g. > 10%) the sorcerer isn't allowed to enter the guild. This also means this sorcerer won't get additional high level spells because they are rewards from the guild master for solving quests. It's also possible that you change the class. For example a warrior using a lot of magic skills will be ostracized by the warrior guild and may be accepted by the warlock guild. Or a sorcerer using physical combat skills may become for example a wizard. We have to define which class has which fingerprint. And also if a ostracized player will ever be able to rejoin the guild. And if there is a guild taking them all. This guilds would be placed in a central place from where you reach the different regions, depending on your level. Scorn will be placed in the beginning region, but the guilds don't need to be there. The vision is, to have chained quests leading through all the maps. You don't need to visit every single map, because some of them could be part of a side quest. But you should be able see them all by just following the storyline. And the famous hack and slay random maps could become a quest reward, too. For example, you solved a quest and the reward is a key (for unlimited use) to a hack and slay random map. Those random maps can be used to level up the character to be able to solve harder quests or to become ready for the next [harder] region. What do you think? And yes, this changes are substantial which makes it necessary to abandon old characters and start from scratch. I know, the developers of CF have set their focus on coding. And this is almost gameplay. But without feedback of the core developers there won't be any changes of gameplay at all. Regards, J?rgen From leaf at real-time.com Tue Jun 26 10:30:56 2007 From: leaf at real-time.com (Rick Tanner) Date: Tue, 26 Jun 2007 10:30:56 -0500 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070626112232.GB29658@cthulhu.desy.de> References: <20070626112232.GB29658@cthulhu.desy.de> Message-ID: <46813130.4050206@real-time.com> Juergen Kahnert wrote: > I have the following idea for the new world: > > After character generation, you have to chose your class. As soon as you > have chosen your class, you won't enter "start/Nexus", but the guild of > that class. > > This guild will be a combination out of the newbieshouse and the > beginners maps to teach new people how to play this game. And there you > learn the abilities of your class. So you won't get a bunch of class > specific items. Instead of this you're guided through maps where you > learn your abilities and where you're teached how to use them. > > Parts of the guided tour could be shared between different guilds. This > will reduce the map making work. Good ideas. ;-) Is this the right or appropriate thread to start listing what one should learn in the guild map? And the shared maps? For instance: movement (walking, running, attacking), applying/removing and (un)locking inventory items, buying and selling from a shop, using money conversion and detect magic/curse altars, learning spells, learning new skills and so on. > For more class like role playing, the guild is able to ostracize players > by checking for example if a sorcerer uses close combat skills instead > of magic. If the sum of the close combat skills exceed the sum of magic > skills by a defined limit (e.g. > 10%) the sorcerer isn't allowed to > enter the guild. This also means this sorcerer won't get additional high > level spells because they are rewards from the guild master for solving > quests. AFAIK, at this time - such a check is not possible. This will require some developer/coding updates. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070626/d7c46755/attachment.pgp From mwedel at sonic.net Tue Jun 26 23:46:16 2007 From: mwedel at sonic.net (Mark Wedel) Date: Tue, 26 Jun 2007 21:46:16 -0700 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070626112232.GB29658@cthulhu.desy.de> References: <20070626112232.GB29658@cthulhu.desy.de> Message-ID: <4681EB98.90103@sonic.net> Juergen Kahnert wrote: > I have the following idea for the new world: > > After character generation, you have to chose your class. As soon as you > have chosen your class, you won't enter "start/Nexus", but the guild of > that class. > > This guild will be a combination out of the newbieshouse and the > beginners maps to teach new people how to play this game. And there you > learn the abilities of your class. So you won't get a bunch of class > specific items. Instead of this you're guided through maps where you > learn your abilities and where you're teached how to use them. Sounds reasonable. I'd also presume that players could basically skip this (just leave the guild and go out on their own) if they decided to do that. > After the tour, the guild master will give you your first quest. This > will be a chained quest. You will get better and better class items from > your guild master for solving the quests or as a quest treasure. Also seems reasonable. > > For more class like role playing, the guild is able to ostracize players > by checking for example if a sorcerer uses close combat skills instead > of magic. If the sum of the close combat skills exceed the sum of magic > skills by a defined limit (e.g. > 10%) the sorcerer isn't allowed to > enter the guild. This also means this sorcerer won't get additional high > level spells because they are rewards from the guild master for solving > quests. > > It's also possible that you change the class. For example a warrior > using a lot of magic skills will be ostracized by the warrior guild and > may be accepted by the warlock guild. > > Or a sorcerer using physical combat skills may become for example a > wizard. With what you're saying there, are you equating class=guild, or is their a distinction? For example, right now, the only meaning a characters class has is what skills they start out with, and some stat bonuses. So changing class isn't really necessary, as it doesn't mean a whole bunch after first level. So if the guild says "we don't like you, maybe you should go to the wizards", in a sense that is very easy to do. However, there has been talk about making classes have more distinction. For example, a fighter gets exp in the fighter skills faster, and harder to gain in magic skills, etc. If you're talking about changing the characters class as it relates to that, it gets much trickier. But its unclear to me if it is really the right thing to limit all characters to one guild. Right now, we have something like a dozen classes - it strikes me that a dozen guilds would be overkill. You could generalize them to some degree - combat guild, cleric guild, mage guild, thief guild, maybe a few more. Some classes are basically hybrids between a couple of those - paladin being a fighter/cleric for example. In that case, one would think those two guilds wouldn't care much, and it also simplifies the number of guilds. A more complex thing is that there really shouldn't be a cleric (praying) guild - or at least not one, but really one for each god. But that also adds lot of guilds. I also like the idea more where the quests should be more related to the characters skills. For example, perhaps the fighter guild won't send you on some quest until your fighting skill is at least level 10 - this is good in the sense it won't send characters where they might get killed, but also effectively bars non fighters from that quest - or at least not until they have a good amount of experience. If one envisions quests requiring skill level 90, that could effectively bar other classes from those quests > > > The vision is, to have chained quests leading through all the maps. You > don't need to visit every single map, because some of them could be part > of a side quest. But you should be able see them all by just following > the storyline. do you literally mean every map in the game? If so, I don't really like that idea. First, that is a huge number of maps, and thus a huge number of quests. For repeat players, it would seem pretty pointless (fighter guild and mage guild having the same maps you quest to?). It also gets tricky adding new maps - have to update all those quests, and at some point, you'd probably get the case of too many maps for a certain level (eg, you might have 30 maps for level 5-10, where as it might only take 10 maps to go from 5 to 10). I don't have any issue with a set of maps, perhaps a fairly large set, being used for these guild quests. And different guilds may send players to different maps. But at some point, I think the players should be out talking to NPCs, finding out about dungeons that way, exploring, etc. I can understand the desire for some players to perhaps see every map. But for those players, which I think would be a minority, I'd rather point them at a web page that is the map page walkthrough, listing all the maps, suggested level, etc, vs trying to put that in game. From daniel.daxler at vbsbowl.com Wed Jun 27 07:52:11 2007 From: daniel.daxler at vbsbowl.com (Daniel Daxler) Date: Wed, 27 Jun 2007 14:52:11 +0200 Subject: [crossfire] New Quests In-Reply-To: Message-ID: <20070627125334.B6401B3EB@smtpgrey-2.real-time.com> Balance is the key! Itempower: Itempower 1 for Girdle of Valriel is just a Map abuse I have seen before, there use to be a wizard in a pub with 1 hp and 3 million exp. He is gone now, thank god. There use to be big wizards in Brest that stood in No magic zone. That was very easy experience and gear. They are still there but a lot more dangerous as they are not affected by the no-magic zone. Come to think of it I belive this was the intended reward after a good map, a Great wizard providing great gear and exp freely. We cannot reward players with something that spoils the game. If this girdle was god given ( not droppable ) then you might get away with a little abuse, but not this much. As it is now you can give it to a level 1 player. Girdle of Valriel = Str+3,Dex+3,Con+3,Wis+5,Cha+2,grace+3,ac+2 The girdle is just an example, and the next best one "of the fire god" is an abuse as well I think. I say Do not fix the Map, fix the game. Use the existing function: (item.c) int calc_item_power(const object *op, int flag) AND do it always, no matter what the map/item suggests. calc_item_power(Girdle of Valriel) = 21 I think. We do want to improve the function to distinguish between resist slow and resist fire. Slay Dragon and Ant as well. Resists 80% is much better than 20% and not by a factor 4. I have sketched up a suggestion if someone wants. An advantage is that when you enchant some armour you don't triple the itempower of the item as you might today. A disadvantage apart from everyone wearing too much itempower is branding a weapon to some god, will make it impossible to wield. Experience: Why not calculate the exp generated by each monster by assessing how big/dangerous/hard to kill it is. int calc_exp_for_monster With both of these functions you will not see any more item or experience abuse like these. If a rod of burning hands level 80 resists proper usage 79 times of 80 for a level 1 player, we might be in business. Regards Daniel (Player off and on since 1991) From nicolas.weeger at laposte.net Wed Jun 27 12:22:13 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 27 Jun 2007 19:22:13 +0200 Subject: [crossfire] Bug [ 1735459 ] Ground view missing face updates In-Reply-To: <467F66B7.7080406@sonic.net> References: <467F66B7.7080406@sonic.net> Message-ID: <200706271922.17735.nicolas.weeger@laposte.net> Hello. > At some level, it is very easy to fix - if player is on a space, and > anything (including face) on that space change, we just send all the > contents of that space again to the player. Why all items? Don't items on a space get a tag, that can be used to simply send this item's update to clients? > Now a simple answer could be we don't really care about bandwidth, and I > can put in my fix. I'm not sure if that is really the right answer. If it is really that costly, I'd say no. The bug isn't important enough to warrant the fix. > But going further, the client has some level of animation support - for > whatever reason, the code to animate the ground was never put in. I just > wrote that, and it works for some cases - namely, those animations we let > the client do (continuous animations like fountains, dragon transports, or > rubies). But it doesn't handle the cases for things like handles (not > really an animation, but a change of state), or gates (animate once, then > stop). > > I'm thinking that the correct answer is a mix of the last two: If it is > an animation the client can handle, server sends nothing. If it is a > change of face that the client can't handle, then servers send an > updateitem for a new face. And a *player pointer to maplook to make easy > lookups to the player should be relatively straightforward. Yes, client should handle all animation it can. Would simplify the server code, and save some bandwidth. Also, one should consider the case where the modified face is not visible because the map layer is full (can happen if many objects). Just my 2 cents of ? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070627/d7faff7b/attachment.pgp From nicolas.weeger at laposte.net Wed Jun 27 12:31:32 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 27 Jun 2007 19:31:32 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070626112232.GB29658@cthulhu.desy.de> References: <20070626112232.GB29658@cthulhu.desy.de> Message-ID: <200706271931.33049.nicolas.weeger@laposte.net> Hello. > After character generation, you have to chose your class. As soon as you > have chosen your class, you won't enter "start/Nexus", but the guild of > that class. Sounds interesting, but isn't the race meaningful also, especially for "special" races like wraith, dragon, fireborn? > For more class like role playing, the guild is able to ostracize players > by checking for example if a sorcerer uses close combat skills instead > of magic. If the sum of the close combat skills exceed the sum of magic > skills by a defined limit (e.g. > 10%) the sorcerer isn't allowed to > enter the guild. This also means this sorcerer won't get additional high > level spells because they are rewards from the guild master for solving > quests. > > It's also possible that you change the class. For example a warrior > using a lot of magic skills will be ostracized by the warrior guild and > may be accepted by the warlock guild. The question I have is what the purpose of the guild would be, game-wise. Have players of the same race/class get together? Point to maps to solve? I think quite many guilds can coexist: race-based guilds, class-based (whether start class or matching how you play) guilds, free guilds (like we have now), things like that. So a player could be a member of the cooking guild because she has enough exp, and also a member of the Smoking Cauldron guild. > The vision is, to have chained quests leading through all the maps. You > don't need to visit every single map, because some of them could be part > of a side quest. But you should be able see them all by just following > the storyline. But then when you reach the "last" map, do you get a special treasure? A reward? Rather than "chained" quests, I'd have a "graph of quests". Quests you can do anytime, quests you can't do before you do another one, quests you can't do if you did another one, and such. > And the famous hack and slay random maps could become a quest reward, > too. For example, you solved a quest and the reward is a key (for > unlimited use) to a hack and slay random map. Those random maps can be > used to level up the character to be able to solve harder quests or to > become ready for the next [harder] region. As Mark pointed, you should still be able to go to random maps by yourself. I think that all maps should be reachable by all players, with some justified exceptions. Comes to mind: a Valriel priest shouldn't go kill Valriel's Ascended Avater, or pay a big price for that (heretic!). Maybe undead can't enter Navar (because in the past there was an invasion of undead which was barely contained?). Things like that :) > What do you think? And yes, this changes are substantial which makes it > necessary to abandon old characters and start from scratch. Not necessarily. Most of what you suggest doesn't change anything to the existing skill system, but merely adds guild checks - unless I'm getting something wrong ^_- Thanks for helping the brainstorming :) Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070627/f31ea508/attachment.pgp From nicolas.weeger at laposte.net Wed Jun 27 12:35:21 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Wed, 27 Jun 2007 19:35:21 +0200 Subject: [crossfire] Vertical map-tiling In-Reply-To: <466FDB4B.7080700@myrealbox.com> References: <200706032330.28127.nicolas.weeger@laposte.net> <466FDB4B.7080700@myrealbox.com> Message-ID: <200706271935.21072.nicolas.weeger@laposte.net> > Did not post for long, but i was one of the devs who played along with > this kind of thing: Long time no see, glad to see you alive :) > 1) There was a 'top' and 'bottom' map for each map, (tiles[4] and > tiles[5]), this part is easy to do. Even the handling of empty space > that would allow you to see ground bottom. Even handling loops in > perspective was easy. Some maps even have those linked maps, still. > 1) to give correct perspective, client must shift bottom-right rendering > of 'below' map, even more for below-below, etc. It's impossible to do it > properly using the current used pseudo perspective, especially to match > ground of level x+1 to walls of level X. The layering system used at > that time made it even more difficult. Maybe move 2 pixels top/left? Or some shifting effect? Map2 has unused bits, that could be used for that. > 2) there is a problem with giant monster, they look strange in this > laying out. Can be fixed. > 3) There was the technical problem of the falling and jump/levitate > spell to handle (can levitate or fly allow you to go higher of one level > above map? how?) Then don't handle the case? Force mapmakers to have a barrier so the player can't fall? Note that this can be changed later to allow fall/jump/levitate. > 4) There was the general problem of line of sight. Can a player/monster > see someone on on level higher if he is distant engouh? Can be decided after seeing what can be implemented :) > 5) There was the problem of aiming monsters / player below you using you > spell? (Can be forbidden but doens't look natural) In a first step forbid that/don't handle that (regular "out of map" stuff)? Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070627/da96d5d5/attachment.pgp From mwedel at sonic.net Wed Jun 27 23:53:56 2007 From: mwedel at sonic.net (Mark Wedel) Date: Wed, 27 Jun 2007 21:53:56 -0700 Subject: [crossfire] New Quests In-Reply-To: <20070627125334.B6401B3EB@smtpgrey-2.real-time.com> References: <20070627125334.B6401B3EB@smtpgrey-2.real-time.com> Message-ID: <46833EE4.4020005@sonic.net> Daniel Daxler wrote: > Balance is the key! Much about using built in functions (and not map values) to calculate exp and item power removed... IMO, trying to enforce this in the code is not the right way to go. In terms of experience, if map makers are intentionally trying to provide these loopholes, they'll still find ways. They can read those functions just as well as we can. Past experience has shown that trying to enforce it by code will pretty much always come back to bite us - the first time a map maker comes up with some method to work around the function, if you go and modify the function, then it becomes difficult to know how much other stuff you break (item power for existing objects could all change, both up and down, etc, really screwing things up). The difficulty field of maps is a perfect case - it becomes hard to make a function that can really say how difficult a map is, hence why it is a field the map makers can set. And in fact, there is a bug right now saying that lots of maps are not setting it, with the fix (which I agree with) being to update the maps, not try to write better code to deal with this. No matter how good code we write, it will never be as good as someone looking at the map/item/creature and saying these are fair values. So I really think the correct fix here is in the maps. Such map abuses should be fixed. After all, crossfire is distributed with a fixed set of maps - we control that content, and can fix it. If some servers run their own map sets with bad items, that is their choice. Right now, there are various scripts that check maps for certain things. I think the better approach is to modify those scripts to check for apparent abuses (exp for monsters, item power in objects, perhaps other things like a large amount of treasure in general, etc). Before any new map is added, it gets run through these scripts - if the scripts find problems, they either get corrected, or a knowledgeable person says those values seem fair, given the specifics of the map. Lastly, I'll note that people often talk about these abuses, but seldom do they get officially recorded. These abusive items/creatures are not there because the developers don't care, but more likely because the developers were never informed of them. From crossfire at kahnert.de Fri Jun 29 00:49:56 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 29 Jun 2007 07:49:56 +0200 Subject: [crossfire] map design guideline In-Reply-To: <46796422.7040306@real-time.com> Message-ID: <20070629054956.GA11217@cthulhu.desy.de> On Wed, Jun 20, 2007 at 12:30:10PM -0500, Rick Tanner wrote: > Juergen Kahnert wrote: > > On Mon, Jun 18, 2007 at 06:49:10PM +0200, Nicolas Weeger wrote: > > > So IMO we should write all those ideas somewhere on the wiki, and > > > start working on map design :) > > > > The map guide is not part of the wiki: > > > > http://crossfire.real-time.com/guides/map/map_guide.html > > > > And is this just an idea or the goal? > > It's on the wiki, just formatted (numbered) a little differently. > > http://wiki.metalforge.net/doku.php/map_making Fine, thanks. The main question, how the world should look like (see thread "reorganizing the entire world") is still open. Making rules without knowing the goal is kind of strange. Let us discuss what we want and than we define the rules before we start to change the world. :) J?rgen From crossfire at kahnert.de Fri Jun 29 00:50:20 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 29 Jun 2007 07:50:20 +0200 Subject: [crossfire] class guild map (was: reorganizing the entire world) Message-ID: <20070629055020.GB11217@cthulhu.desy.de> On Tue, Jun 26, 2007 at 10:30:56AM -0500, Rick Tanner wrote: > Is this the right or appropriate thread to start listing what one > should learn in the guild map? And the shared maps? The class guild map is useful even without the reorganization of the entire world, so talking about the appearance of them is better made in a different thread. > For instance: movement (walking, running, attacking), applying/removing > and (un)locking inventory items, buying and selling from a shop, using > money conversion and detect magic/curse altars, learning spells, > learning new skills and so on. Yes, thinks like that. Also binding keys, getting a cult, ... Almost all the newbies like to ask after they just started. ;) It could be one corridor for the general stuff and another one to learn the class specific skills. Players should be free to skip the parts they don't like to learn or they already know. But if they skip the lessons, because they don't like to learn it right now, we should keep it open for them to return, if they want to learn it later. Maybe it's possible to place the one handed weapon skill in the chamber where you learn how to use it. You read the scroll, you get your weapon and than you have to show your ability to use it. The skill scroll should be non pickable, just readable. And as soon as it's read, there should appear a new one for the next player. Same for the weapon. An experienced player just needs to read the scroll, pick up the weapon and skips the "how to handle" part. This scene could look like this. You have a NPC behind a table and in front of an armory. The player isn't able to enter the armory. It's just nice looking to explain where the weapons are coming from. After the player took the weapon he/she should be told to enter the next room to learn how to use the weapon. Something like that and for every skill which belongs to the class. J?rgen From crossfire at kahnert.de Fri Jun 29 01:06:13 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 29 Jun 2007 08:06:13 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <4681EB98.90103@sonic.net> Message-ID: <20070629060613.GC11217@cthulhu.desy.de> On Tue, Jun 26, 2007 at 09:46:16PM -0700, Mark Wedel wrote: > > Or a sorcerer using physical combat skills may become for example a > > wizard. > > With what you're saying there, are you equating class=guild, or is > their a distinction? Good question, I don't know how to handle it best. But yes, maybe we just abandon the class thingy and replace it by a membership of a guild. > For example, right now, the only meaning a characters class has is > what skills they start out with, and some stat bonuses. Yes, and for my understanding of a role playing class, this is far to less. > So changing class isn't really necessary, as it doesn't mean a whole > bunch after first level. Correct, so choosing a class is pointless. Those small grey dressed wight (called sorcerer) could be played as a muscular fighter which is able to strangle a troll. This won't fit into the class description: "[...] Barbarians used to push you around on the street [...]" The classes have effectivly no impact for the role. That's bad. This way they're just used for the dressing. But this could be done by a dressing room as well. ;) > However, there has been talk about making classes have more distinction. And having such guilds will offer a way to make them more distinctive. I don't say it has to be right this, just it could be made like this. > For example, a fighter gets exp in the fighter skills faster, and > harder to gain in magic skills, etc. If you're talking about changing > the characters class as it relates to that, it gets much trickier. Maybe we could have both of it. The initial class will stay. If you choose to be a fighter you will gain xp in fighting skills much easier than in spell casting skills. And if this fighter prefers to cast spells, fine, it's just harder to gain xp there AND will lose the membership of the fighter guild. > But its unclear to me if it is really the right thing to limit all > characters to one guild. I never said that they should be limited to one guild. It's just a point to discuss how to handle it best, if ever. > Right now, we have something like a dozen classes - it strikes me that > a dozen guilds would be overkill. Maybe the dozen classes are overkill if there aren't any real distiction between them. > You could generalize them to some degree - combat guild, cleric guild, > mage guild, thief guild, maybe a few more. Same for the classes, don't you think so? > Some classes are basically hybrids between a couple of those - paladin > being a fighter/cleric for example. I think it's ok having hybrid classes. But it has to be clear what it means and how to play such a class. > In that case, one would think those two guilds wouldn't care much, and > it also simplifies the number of guilds. If you could become a member of more than one of those guilds, why should someone play anything else than a wizard: You're the generalist of the spellcasters. You've emphasized the use of magic and studied all its areas equally. You've learned something about the gods and religious devotion as well. To a much lesser extent, you've studied weaponry, but you've not had much physical training: you're mostly sedentary, and so you're not nearly so strong and healthy as you could be. This means, this dude will be in every guild. No limitations at all. I think it's better to reduce the amount of classes and have a guild for every class of them, if you don't like to have so much guilds in the beginning. > A more complex thing is that there really shouldn't be a cleric > (praying) guild - or at least not one, but really one for each god. > But that also adds lot of guilds. Yes, in fact, to make it real role playing like, you need a "guild" for each cult. But I would call them "abbey" or something like that instead of "guild" in that case. That's one of the reason why I said the guilds needs to share some maps to reduce the map making work. > I also like the idea more where the quests should be more related to > the characters skills. For example, perhaps the fighter guild won't > send you on some quest until your fighting skill is at least level 10 > - this is good in the sense it won't send characters where they might > get killed, but also effectively bars non fighters from that quest - > or at least not until they have a good amount of experience. If one > envisions quests requiring skill level 90, that could effectively bar > other classes from those quests Having more class based quests is definitely benefit. Maybe the location where you get the quest should be more neutral than a guild. Why should the guild master of the fighter guild give a quest to someone not being part of this guild? Maybe the lord of the town or something like that would make it more consistent. Re: Visiting every single map by following the storyline > do you literally mean every map in the game? Yes, but not in a way that the player has to visit them all. For example, you have a storyline with chained quests to visit maps A, C, E, H, ... In map A the player is able to find a hint for a side quest B, in map C a tip for a random map D, in map E for F pointing to G, and so on. > If so, I don't really like that idea. Basically it's just a discussion about how to offer the players an ingame solution to find all the maps without using the spoiler pages. > First, that is a huge number of maps, and thus a huge number of > quests. Having a lot of maps and quests is good, not bad. :) > For repeat players, it would seem pretty pointless (fighter guild and > mage guild having the same maps you quest to?). As long as there are no specialized maps for a guild, yes, why not? It doesn't matter how you rescue the princess, the result counts, that she will be rescued. ;-) And just because I started a new character doesn't mean that I will skip for example the dragon quest. It's just a new way to solve it. > It also gets tricky adding new maps - have to update all those quests, > and at some point, you'd probably get the case of too many maps for a > certain level (eg, you might have 30 maps for level 5-10, where as it > might only take 10 maps to go from 5 to 10). If you leave a note in an older (already connected) map for that level pointing to the new one, it's fine for me. > I don't have any issue with a set of maps, perhaps a fairly large > set, being used for these guild quests. And different guilds may send > players to different maps. But at some point, I think the players > should be out talking to NPCs, finding out about dungeons that way, > exploring, etc. Sure, that's what I called a side quest. But I don't like to talk to NPC at the moment. Doing this is really annoying because of the lack of intelligent talk control. And talking to every NPC around there is much more unedifying. Place the hint for a side quest in a treasure box of a key quest as long as talking to NPC is nothing else than wasted time. > I can understand the desire for some players to perhaps see every map. > But for those players, which I think would be a minority, I'd rather > point them at a web page that is the map page walkthrough, listing all > the maps, suggested level, etc, vs trying to put that in game. It's something completely different to be able to explore every map in the game because of hints and notes I got while following the storyline or if I have to read spoilers to find new maps... I prefer the first option. J?rgen From crossfire at kahnert.de Fri Jun 29 01:17:37 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 29 Jun 2007 08:17:37 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <200706271931.33049.nicolas.weeger@laposte.net> Message-ID: <20070629061737.GD11217@cthulhu.desy.de> On Wed, Jun 27, 2007 at 07:31:32PM +0200, Nicolas Weeger wrote: > > After character generation, you have to chose your class. As soon as > > you have chosen your class, you won't enter "start/Nexus", but the > > guild of that class. > > Sounds interesting, but isn't the race meaningful also, especially for > "special" races like wraith, dragon, fireborn? Yes, the character could be a member of a race guild, too. Or the "special" races won't get a class, just being this race is the class itself. Those races don't change the outfit to show which class they belong to, so why should they be part of a class specific guild? If you prefer the first option, should there be a guild for every race? What's the benefit of being member in the human guild? > The question I have is what the purpose of the guild would be, > game-wise. Have players of the same race/class get together? Nope, I've no idea what benefit this would give. ;) > Point to maps to solve? A guid through the world, yes, one purpose, but that's not all. The main reason why I got this idea is, that the classes are pointless at the moment. And the fantasy role playing games I know, make it easy for a fighter in the beginning and easier for a mage later on. The challenge for the spellcaster is to survive the lower levels. And for the fighter to collect good equipment to survive the higher levels. If I have just a generic class, than I concentrate first on physical combat and later on spell casting. No challenge at all. And now the guilds will do the job. If you're a spell caster and rise in levels, you will get powerful spells, but only if you manage to stay in the guild (following the guild rules). If you're a fighter, you won't get a chance to learn the powerfull spells, maybe not even any spells. But on the other hand the fighter will get powerful weapons to strike down big monsters in short time. > I think quite many guilds can coexist: race-based guilds, class-based > (whether start class or matching how you play) guilds, free guilds > (like we have now), things like that. So a player could be a member of > the cooking guild because she has enough exp, and also a member of the > Smoking Cauldron guild. Sure, just because you get your class depending stuff from your class guild doesn't mean that you can't be a member of another guild. But a barbarians in a sorcerer guild or vice versa is more than strange and I wouldn't like to see it. Keep the class guilds clean from other classes and even from members who don't like to "play class like". > > The vision is, to have chained quests leading through all the maps. > But then when you reach the "last" map, do you get a special treasure? > A reward? There shouldn't be a "last" map. Hopefully we get more and more good maps following the guidelines. ;) And no, just make sure that there are enough random maps for hack and slay style playing. > Rather than "chained" quests, I'd have a "graph of quests". Quests you > can do anytime, quests you can't do before you do another one, quests > you can't do if you did another one, and such. That's for the spoiler page, yes. See my previous mails what I mean with "chained quests" and "side quests". > As Mark pointed, you should still be able to go to random maps by > yourself. I think that all maps should be reachable by all players, > with some justified exceptions. Sure, just because you get some hints and notes while following the storyline doesn't mean that you're unable to visit such maps without these pointer. > Comes to mind: a Valriel priest shouldn't go kill Valriel's Ascended > Avater, or pay a big price for that (heretic!). The big price a priest has to pay for doing such things is to become ostracized. No more granted prayers of this god, never again. A priest should suffer from killing races of his/her cult. Maybe just subtract praying level of the player multiplied with the xp of the killed cult monster from the players praying skill. Maybe it's possible to make an extra counter for the killed cult monsters and the enemy races. Killing enemies will increase it and killing cult monsters will decrease it. If the player drops below 0 he/she become excommunicated. > Maybe undead can't enter Navar (because in the past there was an > invasion of undead which was barely contained?). Things like that :) Sounds good. And also a little bit tricky to keep that in mind for key quests. No key quest should have such limitations, but side quests is ok. > > What do you think? And yes, this changes are substantial which makes > > it necessary to abandon old characters and start from scratch. > > Not necessarily. Most of what you suggest doesn't change anything to > the existing skill system, but merely adds guild checks - unless I'm > getting something wrong ^_- The "cheap version" of this guild idea, yes, won't change the existing system. But I prefer more the extensive version of the guilds. That's why the subject is "reorganizing the entire world". ;) For the "cheap version" I started a new thread "class guild map". They could be implemented into the current system. But for more class like role playing, we need the big change and this will be incompatible with existing characters. J?rgen From mwedel at sonic.net Fri Jun 29 02:39:10 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 29 Jun 2007 00:39:10 -0700 Subject: [crossfire] reorganizing the entire world In-Reply-To: <20070629060613.GC11217@cthulhu.desy.de> References: <20070629060613.GC11217@cthulhu.desy.de> Message-ID: <4684B71E.90103@sonic.net> Juergen Kahnert wrote: >> However, there has been talk about making classes have more distinction. > > And having such guilds will offer a way to make them more distinctive. > I don't say it has to be right this, just it could be made like this. > > >> For example, a fighter gets exp in the fighter skills faster, and >> harder to gain in magic skills, etc. If you're talking about changing >> the characters class as it relates to that, it gets much trickier. > > Maybe we could have both of it. The initial class will stay. If you > choose to be a fighter you will gain xp in fighting skills much easier > than in spell casting skills. And if this fighter prefers to cast > spells, fine, it's just harder to gain xp there AND will lose the > membership of the fighter guild. Yes - that may be doable. Have to be careful however - if I can start as a fighter, and thus get my melee skills up easily, and then switch to wizardry and get my spell casting skills up easily, classes once again loose some meaning. some of the point about a revamp was that classes would have real distinction, and that distinction last the entire lifetime of that character (some of it may be in form of level caps - if you're a fighter, fighting type skills have no cap, but spellcasting skills have a cap at level 50 or something). A lot of what different classes mean, and effects, would still need to be sorted out. But it would probably be bad for players to be able to switch classes at some point. >> Right now, we have something like a dozen classes - it strikes me that >> a dozen guilds would be overkill. > > Maybe the dozen classes are overkill if there aren't any real distiction > between them. Yes - there are probably too many classes right now. However, even if it is redone, I could still see a 6-8 different classes. Lets take the main spellcasting ones - sorcery, evocation, pyromancy, summoning. I could certainly see a class for each of those, and if we take the idea above, the appropriate class has unlimited level for the skill that matches the class, but maybe 75 in a couple of the other magic skills, and 50 for the 4th. So each of those effectively becomes a different class, but in terms of playing, are largely the same (summoning a bit different, but evocation and pyromancy share a lot of spell characteristics in common, what differs is the specific spells (burning hands vs cone of cold, etc). > > >> You could generalize them to some degree - combat guild, cleric guild, >> mage guild, thief guild, maybe a few more. > > Same for the classes, don't you think so? See note above. >> In that case, one would think those two guilds wouldn't care much, and >> it also simplifies the number of guilds. > > If you could become a member of more than one of those guilds, why > should someone play anything else than a wizard: > > You're the generalist of the spellcasters. You've emphasized the > use of magic and studied all its areas equally. You've learned > something about the gods and religious devotion as well. To a much > lesser extent, you've studied weaponry, but you've not had much > physical training: you're mostly sedentary, and so you're not nearly > so strong and healthy as you could be. > > This means, this dude will be in every guild. No limitations at all. Because if the classes are redone, not being a fighter has real limitations - max level in fighting is level 50 (or maybe even lower), etc. A lot of this does depend on how changes are made to classes and skills. If things remain as they are now, then yes, what class you start with makes no difference. But if your starting class determines your skills, how fast they advance, and max level, then your class is important. If that guy wants to join the fighter guild, I don't see a real problem with it. Now there may be fighter guild quests that are not given out if your combat skill isn't level 60, so there may be quests unavailable to him. That said, prohibiting some classes/combos from guilds is OK. But this can also get tricky - there are perhaps way players can try and get around things like this (player friend in a guild uses town portal so other characters can bypass the entrance checks, etc) > I think it's better to reduce the amount of classes and have a guild for > every class of them, if you don't like to have so much guilds in the > beginning. Just to throw more complexity in the mix, in the suggestions about redoing skills/classes, it has been suggested that for advanced players, they basically be able to make their own class (choose what skills they want, stat adjustments, etc - there would of course be certain limits and checks, as some skills are more valuable then others). But how do you handle those cases where a character doesn't have any predefined class? This is another reason why I'm suggesting that specific classes shouldn't be what counts, but rather the characters skills, proficiency in those skills, and perhaps difference in levels. For example, a character with level 50 in evocation and level 5 in 1 handed weapons (that being his best fighter type skill) could get rejected from the fighters guild with something like "you've already decided your path in life is a wizard, and the fighters won't let you join". but if a character has level 5 evocation and level 5 1 handed weapons, then they should probably let him join. Now it may be that membership is reviewed, so if he then goes off and becomes a pure wizard, at some point the fighters reject him, saying they haven't met his ideals, etc. > >> I also like the idea more where the quests should be more related to >> the characters skills. For example, perhaps the fighter guild won't >> send you on some quest until your fighting skill is at least level 10 >> - this is good in the sense it won't send characters where they might >> get killed, but also effectively bars non fighters from that quest - >> or at least not until they have a good amount of experience. If one >> envisions quests requiring skill level 90, that could effectively bar >> other classes from those quests > > Having more class based quests is definitely benefit. Maybe the location > where you get the quest should be more neutral than a guild. > > Why should the guild master of the fighter guild give a quest to someone > not being part of this guild? Maybe the lord of the town or something > like that would make it more consistent. I certainly don't mind some guild masters handing out some quests. I'm just not sure they should be handing out all the quests. And some quests/maps could be used for different guilds. For example, there could be animosity between the cleric and wizards guild. The cleric guild wants an item retrieved because it is powerful relic that is useful in their religion. The wizard guild wants it retrieved so the cleric can't get it. > >> I don't have any issue with a set of maps, perhaps a fairly large >> set, being used for these guild quests. And different guilds may send >> players to different maps. But at some point, I think the players >> should be out talking to NPCs, finding out about dungeons that way, >> exploring, etc. > > Sure, that's what I called a side quest. But I don't like to talk to > NPC at the moment. Doing this is really annoying because of the lack of > intelligent talk control. > > And talking to every NPC around there is much more unedifying. Place > the hint for a side quest in a treasure box of a key quest as long as > talking to NPC is nothing else than wasted time. I'd saying fixing the NPC conversation is one of those things to do. There are lots of ways it could be made better (the current way really does leave a lot to be desired). I'd really like it so that talking to NPC's would be rewarding and something players want to do. > > >> I can understand the desire for some players to perhaps see every map. >> But for those players, which I think would be a minority, I'd rather >> point them at a web page that is the map page walkthrough, listing all >> the maps, suggested level, etc, vs trying to put that in game. > > It's something completely different to be able to explore every map in > the game because of hints and notes I got while following the storyline > or if I have to read spoilers to find new maps... > > I prefer the first option. I suppose this is really a matter of personal taste, with no right or wrong answer. Me personally, I'd get the feeling that if I'm finding clues to all the different maps that I'm really being led by the nose - I'd much rather go out and find some of those things on my own (or by talking to npcs, whatever) than just being pointed at everything. but there are certainly some maps which really don't have any clues, and should have some. A few thoughts on this to make things better, but not go quite as far as you are saying: 1) Include information about various maps (side quests as you put it, but I'd not really call them quests) in random messages, and have those show up more in treasure. So you go into a dungeon, and may find a scroll that talks about goblins near town. Another time you do that dungeon, may not find that, but find info about some other dungeon, etc. And you could of course get some duplicate information on this (may find information about those goblins in several different maps/locations). This isn't that hard - basically need some way to more easily gather the data, and increase the frequency of it showing up. Ideally it should be tied by region, so scorn area would contain information about other scorn maps, etc. 2) Improve NPC conversation so it is worth it to talk to them. 3) Like point #1 for scrolls in maps, also extend it to NPCs. So the various NPCs in scorn could also talk about the goblins around the area, and perhaps other things. From alex_sch at telus.net Fri Jun 29 14:38:00 2007 From: alex_sch at telus.net (Alex Schultz) Date: Fri, 29 Jun 2007 13:38:00 -0600 Subject: [crossfire] Project: New Intro Message-ID: <46855F98.1090908@telus.net> (Note: This is related to the "reorganizing the world" thread, but is for a specific plan/proposal/plot) Hi, One thing we are lacking is a focus on much, and often such focuses we have are code oriented. Much of the mapping and content creation (what there is...) is done as a series of one-man-jobs. I feel that if we are to get anything of significance done on content creation besides new quests here and there, that it is imperative that we attempt a concentrated team effort on one specific thing until it is complete. I hope that the success of organization of the decision-making of the switch from CVS can be repeated on a larger scale. Hopefully I do not seem silly in this attempt to rally an effort but I feel that I must try. So there's the question of, what do we try to focus our efforts on to complete? I propose that we focus on what content the player sees first in the game because after all, it not only is the first part to leave an impression, but also how effective it is at teaching the player impacts all of their other experiences while new to the game. I believe we should redesign the intro of crossfire, and expand it beyond the newbie house and such we have now, I believe into it's own island or walled town. Scorn was in some ways intended to be a newbie town, but really many areas of it require level 10 or higher to be effective and it has become a transportation nexus. Scorn certainly needs reorganization, but instead of turning it into a newbie town I believe it would be more effective to make a brand new one of the first two or three levels in which the player would be taught alot about how the world works and how to play. On the maps mailing list one new newbie house was created though didn't really finish being polished: This could be used as part of it but much more would certainly be needed. We should create a checklist of things to do for this new introduction to CF and should have a clear listing of who is working on what. Teamwork and organization would be key in achieving this. I propose the following as a checklist to start with though it would be expanded as things go along: -Decide on what newbies need to learn before getting into the game -Decide how to sort this into the different maps, and add each of these maps to the checklist -Decide how to lay the maps out in a small isolated (island or walled) town -Integrate with the CF world. It is important to remember that organization and focus of effort are key. If we work hard on this and are organized, it and are focused this could be completed by the end of August with ease and could help the experience of new players greatly. So who would be willing to help with this team effort of content creation? Thanks, Alex Schultz From crossfire at kahnert.de Fri Jun 29 14:49:24 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Fri, 29 Jun 2007 21:49:24 +0200 Subject: [crossfire] reorganizing the entire world In-Reply-To: <4684B71E.90103@sonic.net> Message-ID: <20070629194924.GE11217@cthulhu.desy.de> On Fri, Jun 29, 2007 at 12:39:10AM -0700, Mark Wedel wrote: > Have to be careful however - if I can start as a fighter, and thus get > my melee skills up easily, and then switch to wizardry and get my > spell casting skills up easily, classes once again loose some meaning. Indeed, that's why I would prefer strict classes with all their advantages and disadvantages. Offering the possibility to change the class guild will keep the CF classless style more than restrict them to one class guild. > some of the point about a revamp was that classes would have real > distinction, and that distinction last the entire lifetime of that > character More the classic role playing style. > (some of it may be in form of level caps - if you're a fighter, > fighting type skills have no cap, but spellcasting skills have a cap > at level 50 or something). I don't like the idea of having such a maximum level. I don't even like the maximum level of 115 (which doesn't mean that I ever reached it). Just make it harder to gain xp in skills not related to the class. > A lot of what different classes mean, and effects, would still need to > be sorted out. But it would probably be bad for players to be able to > switch classes at some point. I agree with that. > However, even if it is redone, I could still see a 6-8 different > classes. Lets take the main spellcasting ones - sorcery, evocation, > pyromancy, summoning. That's funny, I'd made a "mage" class out of those four classes. Anyway, it depends on how the classes should look like. There are different styles possible: 1. Hard restrictions of the classes, fighter unable to use magic, mages unable to use heavy armour / weapons, ... This is nice and preferred for team based games. But CF is not and parties are only used to level up a character fast. That could be changed by such limitations. 2. Totally open, everybody is able to learn everything. That's what CF almost implemented with very few exceptions. Players will play for their own most of the time. 3. Combination out of those both. a) Hard level limits on non class skills. For example, a fighter is only able to learn magic skills up to level n. b) Skill capabilities, some skills are learnt easier than others. This could be given by a class or by free choice of the player depending on the character generation. c) Dynamic skill adjustment, those skills you're using are learnt easier, unused harder, maybe even unlearnt. We already use style 2 and want to change it. I would say that style 1 is a bit to hard for the core players of CF. This will change the entire gameplay and players. I wouldn't make this experiment with CF. Style 3a is fanciless. The worst option of style 3 from my point of view. I would prefer 3c, but this is more coding work and harder to balance than 3b, so 3b looks like a good choice. But 3c will also work for new skills, which are added after the player created the character. So 3c could also be worth to implement it. > That said, prohibiting some classes/combos from guilds is OK. Yes, same for me. > But this can also get tricky - there are perhaps way players can try > and get around things like this (player friend in a guild uses town > portal so other characters can bypass the entrance checks, etc) Maybe, depends on the situation. For example the Navar - Undead situation could be solved by guards hunting the undead player if bypassed the entrance checks. I think we should try it. If checks are bypassed there will be ways to add some more checks or let the player exploit it. Again, this will depend on the situation. > Just to throw more complexity in the mix, in the suggestions about > redoing skills/classes, it has been suggested that for advanced > players, they basically be able to make their own class (choose what > skills they want, stat adjustments, etc - there would of course be > certain limits and checks, as some skills are more valuable then > others). But how do you handle those cases where a character doesn't > have any predefined class? The character generation could look like this for everybody, not only for experienced players. Just offer some predefined classes for the newbies with characteristic class settings. This may be tuned or not, whatever the player likes. The rest will be done by the guild the player likes to join. > This is another reason why I'm suggesting that specific classes > shouldn't be what counts, but rather the characters skills, > proficiency in those skills, and perhaps difference in levels. Yes, I think this style will better fit for CF than the classic class based style. > For example, a character with level 50 in evocation and level 5 in 1 > handed weapons (that being his best fighter type skill) could get > rejected from the fighters guild with something like "you've already > decided your path in life is a wizard, and the fighters won't let you > join". > > but if a character has level 5 evocation and level 5 1 handed weapons, > then they should probably let him join. Now it may be that membership > is reviewed, so if he then goes off and becomes a pure wizard, at some > point the fighters reject him, saying they haven't met his ideals, > etc. Sounds reasonable, we just need to define the guild rules and what the player likes to do with it, is his / her choice. If there are ways to become a member of more than one class guild, fine, but this should be an exception and not the regular case. > I certainly don't mind some guild masters handing out some quests. > I'm just not sure they should be handing out all the quests. Neither I do. The key quests for the class, yes, but definitely not all quests. Also not in a row. I mean, the guild master will check your level and if you reached a certain level, he offers you the next quest. > And some quests/maps could be used for different guilds. For example, > there could be animosity between the cleric and wizards guild. The > cleric guild wants an item retrieved because it is powerful relic that > is useful in their religion. The wizard guild wants it retrieved so > the cleric can't get it. I like this idea; could be real fun. :) Maybe offers even the chance for a guild war. >;-) > I'd saying fixing the NPC conversation is one of those things to do. > There are lots of ways it could be made better (the current way really > does leave a lot to be desired). Long time ago, I was new to CF, I tried to get quests from NPCs. I talked to every(!) NPC I found on the maps. That was a really humbling experience. Maybe all NPCs should share some basic knowledge about the world. And offering you directly some keywords you could use to get the specific part instead of the general world database. > I'd really like it so that talking to NPC's would be rewarding and > something players want to do. Yes, I would like to see that, too. ;) Re: Map Visiting > Me personally, I'd get the feeling that if I'm finding clues to all > the different maps that I'm really being led by the nose - I'd much > rather go out and find some of those things on my own (or by talking > to npcs, whatever) than just being pointed at everything. Don't make the notes so obvious like: You have to go to Darcap, enter the second house on the east to start a new quest. For example you could find a diary which says: "I regret that I didn't asked the crazy old man in the pub in Darcap where to find the treasure he was talking about." Something like that. It's up to you if you like to visit Darcap and talk to the crazy old man or not. Maybe he will drivel about another dude in the pub who knows about another quest. You'll never know if you don't talk to him, right? ;) > 1) Include information about various maps (side quests as you put it, > but I'd not really call them quests) in random messages, and have > those show up more in treasure. So you go into a dungeon, and may > find a scroll that talks about goblins near town. Another time you do > that dungeon, may not find that, but find info about some other > dungeon, etc. And you could of course get some duplicate information > on this (may find information about those goblins in several different > maps/locations). This isn't that hard - basically need some way to > more easily gather the data, and increase the frequency of it showing > up. Ideally it should be tied by region, so scorn area would contain > information about other scorn maps, etc. Most of those informations should belong to the region the player found it. In some rare cases there could be also a hint about another region, but really seldom. Also a ingame player "diary" would help. Anything you ever read in dungeons will be written and sorted into the personal diary. Notes belonging to each other should be stored on the same page of the diary. This will allow you to make smaller notes which only makes sense if you have them all. > 2) Improve NPC conversation so it is worth it to talk to them. I would appreciate that. > 3) Like point #1 for scrolls in maps, also extend it to NPCs. So the > various NPCs in scorn could also talk about the goblins around the > area, and perhaps other things. Yes, similar to my idea of giving every NPC knowledge about the world. Give them extra knowledge about the region, and this will be perfect. J?rgen From mwedel at sonic.net Fri Jun 29 21:34:58 2007 From: mwedel at sonic.net (Mark Wedel) Date: Fri, 29 Jun 2007 19:34:58 -0700 Subject: [crossfire] classes & guilds, was Re: class guild map (was: reorganizing the entire world) In-Reply-To: <20070629055020.GB11217@cthulhu.desy.de> References: <20070629055020.GB11217@cthulhu.desy.de> Message-ID: <4685C152.6030900@sonic.net> It seems to some extent (could be wrong), that some amount of the motivation behind this new set of guilds was to add some meaning to the classes (maybe not the only motivation). However, it has been discussed (and is even on the 2.0 todo list) that classes get redone so skills are important. Various suggestions made - rather than copy them all, people can read them at: http://wiki.metalforge.net/doku.php/dev_todo:race_class_changes I'll note that some changes are very easy to make, and require little/no code changes. In particular, the skills do have self contained information about how much exp ones gets for the skill. So it is just a matter of creating some new archetypes with different values (basic/expert/master skills? But maybe a better name, as that suggests more how good you are in the skill, not how well you learn it - something like attuned/normal/repelled is almost better, but would be confusing with spells). But whatever - one could easily make up instances of the existing skills that have a difference in the exp gain rate. The treasurelist for the races/classes then just get modified to give the appropriate skills. Eg, the fighter gets the attuned version of the fighting skills, and repelled version of the magic skills). I'd almost think skillscrolls should get removed from the game (what skills you start with is what you have, but you'd just start with repelled versions, so would be sucky at them all). IF skillscrolls should remain, then they would only give the lowest quality (repelled) versions of the skills. And in fact, to make it easy to upgrade existing servers (and try and get players to start new characters), all the existing skills could become the repelled version. There may be a few rare quests which would update a repelled skill to a normal skill. IMO, there shouldn't be any way for a character to get an attuned skill once the game is started. Off the top of my head, only code changes that might be necessary: 1) Currently, races get skills, and classes get skills, and in some cases they overlap (the race has alchemy weapons, as does the class). I'd think the right approach here is that in the end, the character gets the better of the two. But some code changes would need to be made, as right now, the character code checks to see if a character has a skill, and if so, doesn't give it to them as part of the class selection. 2) This may not be an issue, but I'd have to look closely about how reading something like a skill scrolls sees if you know a skill - if it does it by archetype name, that would need to get changed, since we'd have karate_repelled, karate_normal, karate_attuned, and a character that has karate_attuned doesn't want it replaced by karate_repelled when they read a skill scroll. 3) Some code would be needed to update skills from repelled->normal, but that should be pretty easy also. From nicolas.weeger at laposte.net Sat Jun 30 03:32:08 2007 From: nicolas.weeger at laposte.net (Nicolas Weeger) Date: Sat, 30 Jun 2007 10:32:08 +0200 Subject: [crossfire] Project: New Intro In-Reply-To: <46855F98.1090908@telus.net> References: <46855F98.1090908@telus.net> Message-ID: <200706301032.12184.nicolas.weeger@laposte.net> Hello. > One thing we are lacking is a focus on much, and often such focuses we > have are code oriented. Much of the mapping and content creation (what > there is...) is done as a series of one-man-jobs. I feel that if we are > to get anything of significance done on content creation besides new > quests here and there, that it is imperative that we attempt a > concentrated team effort on one specific thing until it is complete. I > hope that the success of organization of the decision-making of the > switch from CVS can be repeated on a larger scale. Hopefully I do not > seem silly in this attempt to rally an effort but I feel that I must try. I agree we should coordinate our efforts, and I'll gladly help how I can :) As I see things, we have the following major things to concentrate on: * class/race modification. This includes balancing spells/skills, deciding how guilds work, making guilds, ... * map reorganisation. This includes creating new content, including the introduction you're talking about if we deem it relevant. This also includes adding lore to maps, moving/trashing/adding maps and/or quests * overall combat balance. This has been evoked on the list, and could include speed modifications, ac/wc/sp/hp/gr/weapons balance * new features for gameplay, like npc interaction, new character creation mechanism, ... * code maintenance - but this should be *to support* the previous steps, not an end in itself (except probably the bug cleaning ;p) Those tasks aren't totally unrelated, of course, and should probably be done in a coordinated manner. Nicolas -- http://nicolas.weeger.free.fr [Petit site d'images, de textes, de code, bref de l'al?atoire !] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070630/a6d96429/attachment.pgp From crossfire at kahnert.de Sat Jun 30 13:33:24 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sat, 30 Jun 2007 20:33:24 +0200 Subject: [crossfire] classes & guilds, was Re: class guild map In-Reply-To: <4685C152.6030900@sonic.net> Message-ID: <20070630183324.GA15855@cthulhu.desy.de> On Fri, Jun 29, 2007 at 07:34:58PM -0700, Mark Wedel wrote: > It seems to some extent (could be wrong), that some amount of the > motivation behind this new set of guilds was to add some meaning to > the classes (maybe not the only motivation). Basically, yes. Guilds offers a consistent way to implement class restrictions. > However, it has been discussed (and is even on the 2.0 todo list) that > classes get redone so skills are important. And guilds will help you to implement this in a logical way. > http://wiki.metalforge.net/doku.php/dev_todo:race_class_changes There are a lot of "may", "could", "would", ... Let us create a consistent race and class concept first, instead of implementing parts of the list, because they're easy to add. > I'll note that some changes are very easy to make, and require > little/no code changes. If you list those, we could take that into account while creating the new concept. > In particular, the skills do have self contained information about how > much exp ones gets for the skill. So it is just a matter of creating > some new archetypes with different values (basic/expert/master skills? Doesn't show the level itself the knowledge about a skill? Is having a "master level 1" better than "basic level 50"? > But maybe a better name, as that suggests more how good you are in the > skill, not how well you learn it - something like attuned/normal/repelled > is almost better, but would be confusing with spells). But whatever - > one could easily make up instances of the existing skills that have a > difference in the exp gain rate. What about a second value for skills. This could be called "disposition" or "affinity" or something like this. It would be a float value which is used to divide the xp gained by this skill. So having an "affinity" level of 2 means, you will get 50 xp out of a 100 xp monster. Having 0.5 "affinity" will give you 200 xp for the same monster. This "affinity" value could be changed with skill scrolls. You start with an affinity value of 4 or 5 (or whatever) and each scroll you read will reduce this value by 0.04 x affinity value. Make the bonus / malus symetric. If you start with an "affinity" value of 5, the lowest value will be 0.20. The class skills will start with lower values and maybe each level advance will reduce it automatically without skill scrolls (because of the master in the guild teaching the skills - as long as you manage to stay in the class guild). Every skill level you're able to read one skill scroll to decrease the "affinity" value. And make skill scrolls a rare item. Only the class skills will be allowed to decrease below 1. And skills unlikely to the class not below 2. This could be fine tuned if you like the idea. > The treasurelist for the races/classes then just get modified to give > the appropriate skills. Eg, the fighter gets the attuned version of > the fighting skills, and repelled version of the magic skills). I don't understand what you mean by this. Could you explain it a little bit more? > I'd almost think skillscrolls should get removed from the game (what > skills you start with is what you have, but you'd just start with > repelled versions, so would be sucky at them all). This means you have to add real party support to CF. Not only sharing xp, but assistance modes; group healing, archers able to fire from behind without hitting party members, ... I'm not sure if this will work well in the 2D square world we have. So stay with the concept to be able to learn every skill but powerful class items are only available through the class guild for members. For example the guild master has given you the hanuk quest. If you killed hanuk, you have to return for example the "scepter of hanuk". Now, depending on the guild, you'll get different rewards. Being a pyromancer, you'll receive meteor swarm. Being a fighter, you could get a powerful flamesword, or something like that. Than the flag for the solved hanuk quest will be set, so you're unable to receive for the same quest a different reward (if you managed to change the guild). > IF skillscrolls should remain, then they would only give the lowest > quality (repelled) versions of the skills. And in fact, to make it > easy to upgrade existing servers (and try and get players to start new > characters), all the existing skills could become the repelled version. If you ask me, just make a clean cut between CF 1.x characters and CF 2 ones. Don't try to keep them, they won't fit anymore. J?rgen -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3289 bytes Desc: not available Url : http://mailman.metalforge.org/pipermail/crossfire/attachments/20070630/7cf0cfe5/attachment.bin From crossfire at kahnert.de Sat Jun 30 13:49:45 2007 From: crossfire at kahnert.de (Juergen Kahnert) Date: Sat, 30 Jun 2007 20:49:45 +0200 Subject: [crossfire] Project: New Intro In-Reply-To: <46855F98.1090908@telus.net> Message-ID: <20070630184945.GB15855@cthulhu.desy.de> On Fri, Jun 29, 2007 at 01:38:00PM -0600, Alex Schultz wrote: > Much of the mapping and content creation (what there is...) is done as > a series of one-man-jobs. I feel that if we are to get anything of > significance done on content creation besides new quests here and > there, that it is imperative that we attempt a concentrated team > effort on one specific thing until it is complete. Yes, I think the same. > So there's the question of, what do we try to focus our efforts on to > complete? I propose that we focus on what content the player sees > first in the game because after all, it not only is the first part to > leave an impression, but also how effective it is at teaching the > player impacts all of their other experiences while new to the game. I totally agree with you. If we start over with CF 2 (everybody has to create a new character), we may be able to create the regions for specific levels, step by step. > I believe we should redesign the intro of crossfire, and expand it > beyond the newbie house and such we have now, I believe into it's own > island or walled town. An island sounds good. Place the class guilds on that island, too, and after you finished a few quests there, you'll get the ticket for the boat bringing you to the next region. > Scorn was in some ways intended to be a newbie town, but really many > areas of it require level 10 or higher to be effective and it has > become a transportation nexus. Scorn certainly needs reorganization, Not only Scorn, if you ask me, the entire world needs to be reorganized. > -Decide on what newbies need to learn before getting into the game > -Decide how to sort this into the different maps, and add each of these > maps to the checklist > -Decide how to lay the maps out in a small isolated (island or walled) town > -Integrate with the CF world. A few points of these are stated in the "class guild map" mail. So, we should create a small isolated island with class guilds and the integrated newbie house to learn how to play and use the skills. I also have some ideas for some low level quests. We're able to recycle old maps for that. J?rgen From mwedel at sonic.net Sat Jun 30 18:57:16 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 30 Jun 2007 16:57:16 -0700 Subject: [crossfire] classes & guilds, was Re: class guild map In-Reply-To: <20070630183324.GA15855@cthulhu.desy.de> References: <20070630183324.GA15855@cthulhu.desy.de> Message-ID: <4686EDDC.9060203@sonic.net> Juergen Kahnert wrote: >> In particular, the skills do have self contained information about how >> much exp ones gets for the skill. So it is just a matter of creating >> some new archetypes with different values (basic/expert/master skills? > > Doesn't show the level itself the knowledge about a skill? Is having a > "master level 1" better than "basic level 50"? No. If you are master level 10, and basic level 10, the skill operates the same. The difference is that it may take a character 4 times as much exp to get to basic level 10 as it takes a character to get to master level 10. I'd have to look at the skill code more closely to see if it checks by name for skill matching, but it could be very easy to have the skill names themselves be things like 'Basic 1 handed weapons', 'Intermediate 1 handed weapons' and 'Advanced 1 handed weapons'. Still not really happy with those names either, since they suggest more how good the character is in those, not how fast one advances. One nice thing about having basic level 10 = intermediate level 10, in terms of capabilities, is that it then makes it very easy to upgrade a skill from basic to intermediate - all that needs to be done is adjust how exp is gained. In comparison, if basic level 10 = intermediate level 2, it gets much messier - you would almost need a case by case basis to determine exactly how things get translated for each skill. And for some things, they are driven by overall level (like mana points), so a reduction of level 10 to level 2, even if a 'better' skill would result in the character having fewer mana points, etc. Also dealing with spell learning, etc, gets a lot more complicated. Reducing the exp gain is a very easy way to add some difference to the classes/skills. Level caps would be another way (I know that this may not be liked, but if you instead say 'this class just doesn't get a skill', that is basically the same as a level cap of 0). In some cases, you pretty much need to let all the classes have some skills (like ability to pick up a weapon and swing it), but I personally don't have a problem limiting how good a mage can get doing that. > > >> But maybe a better name, as that suggests more how good you are in the >> skill, not how well you learn it - something like attuned/normal/repelled >> is almost better, but would be confusing with spells). But whatever - >> one could easily make up instances of the existing skills that have a >> difference in the exp gain rate. > > What about a second value for skills. This could be called "disposition" > or "affinity" or something like this. It would be a float value which is > used to divide the xp gained by this skill. > > So having an "affinity" level of 2 means, you will get 50 xp out of a > 100 xp monster. Having 0.5 "affinity" will give you 200 xp for the same > monster. > > This "affinity" value could be changed with skill scrolls. You start > with an affinity value of 4 or 5 (or whatever) and each scroll you read > will reduce this value by 0.04 x affinity value. > > Make the bonus / malus symetric. If you start with an "affinity" value > of 5, the lowest value will be 0.20. > > The class skills will start with lower values and maybe each level > advance will reduce it automatically without skill scrolls (because of > the master in the guild teaching the skills - as long as you manage to > stay in the class guild). > > Every skill level you're able to read one skill scroll to decrease the > "affinity" value. And make skill scrolls a rare item. > > Only the class skills will be allowed to decrease below 1. And skills > unlikely to the class not below 2. > > This could be fine tuned if you like the idea. One problem with this approach is that skill scrolls now become value for all classes and all levels (until such point as you've minimized the affinity for all your skills). Which I'm not positive is a good thing - we've had things like this before (in particular, scrolls of identify) - the 'fix' for that was to add identify tables so that low level characters, or those not first to run to the mage shop after it reset, could identify their items. I have no problem with the general idea, but I think that any reduction in affinity should be done through quests (guildmaster teaches you something after completing quest, or some quest item reduces it). I don't think having it changed on the whim of random treasure showing is that good. > > >> The treasurelist for the races/classes then just get modified to give >> the appropriate skills. Eg, the fighter gets the attuned version of >> the fighting skills, and repelled version of the magic skills). > > I don't understand what you mean by this. Could you explain it a little > bit more? Treasurelists are used to determine a races/classes starting items, including spells and skills. So it is a matter of modify the treasurelists as needed to have different sets of skills for different classes. Right now, there is something like a 'basic skill' treasurelist, which contains all of the basic skill everyone starts with (search, disarm, melee weapons, etc). Those need to get altered, so fighters get good versions of the combat skills, and mages get the bad versions, instead of everyone getting the same. > > >> I'd almost think skillscrolls should get removed from the game (what >> skills you start with is what you have, but you'd just start with >> repelled versions, so would be sucky at them all). > > This means you have to add real party support to CF. Not only sharing > xp, but assistance modes; group healing, archers able to fire from > behind without hitting party members, ... > > I'm not sure if this will work well in the 2D square world we have. IMO, there should not requirement that every map be completed by every possible character. In fact, I think because that is largely the case, that is one reason a lot of the maps are hack and slash (everyone can fight, so everyone can do those). I don't see any reason that every character should be able to learn every skill. And in fact, right now there are a few special class limited skills (meditation comes to mind as one that can not be learned later) That said, there are certainly some skills everyone should have, like mentioned above - melee weapon skills, search, disarm traps, some others. However, for some classes, they may start with really bad versions of those skills. > > So stay with the concept to be able to learn every skill but powerful > class items are only available through the class guild for members. > > For example the guild master has given you the hanuk quest. If you > killed hanuk, you have to return for example the "scepter of hanuk". > Now, depending on the guild, you'll get different rewards. Being a > pyromancer, you'll receive meteor swarm. Being a fighter, you could get > a powerful flamesword, or something like that. Than the flag for the > solved hanuk quest will be set, so you're unable to receive for the same > quest a different reward (if you managed to change the guild). The idea of skill/class reform in terms of archetypes doesn't need/have to conflict with the idea of guilds. With all the changes above, there is nothing to prevent there from being fighters guild - but instead of it being based on class, it is really based on your skill level. From mwedel at sonic.net Sat Jun 30 19:49:24 2007 From: mwedel at sonic.net (Mark Wedel) Date: Sat, 30 Jun 2007 17:49:24 -0700 Subject: [crossfire] Organizing efforts, was Re: Project: New Intro In-Reply-To: <46855F98.1090908@telus.net> References: <46855F98.1090908@telus.net> Message-ID: <4686FA14.8020105@sonic.net> The original mail in question had what I really two different topics - one for the idea of redoing what players see when they connect, and a second about group efforts to get things done in a timely fashion. This mail more focuses on how to do group efforts - ideally to come up with some scheme that can be used as a model, because as Ryo pointed out, there are lots of big projects on the list beyond just a new starting village. Some projects/changes may have dependency issues (rebalancing spells should likely be done after redoing classes/races as an example). Those need to be identified and ordering sorted out. For other projects, there are some that are really too big for one person to complete in a reasonable time period. It really isn't enough that developers agree not to step on the toes of another, as that doesn't really help it gone done. Instead, as Alex says, a concerted effort of at least several developers is needed. But for any volunteer project, it is difficult to force people to do anything. My thought here is that each month (or maybe more/less frequently, based on how long it takes to do the different things), the developers should decide what is the most important thing to change/add/fix. My rationale here is that if the developers agree that some issue is most important, they are much more likely to help out. If the general developer response is 'that isn't very important', then you could pretty much figure they probably aren't going to put much effort in. Note it may be reasonable to do less frequent votes, on the basis that after the top priority is done, whatever was #2 probably makes sense to be the next top priority, etc. But new projects may pop up, or the completion of one may spawn a new one (before such and such feature was added, no one thought of something or it wasn't feasible). In this particular case, I agree that a new intro should be something at the top of the list. But going forward, I think we need some way to decide what is done. In the context above, developer is anyone that is willing to help out to get the project done - doesn't mean coder, could be map maker, artist, person writing documentation. but someone that just plays the game probably shouldn't be included, as that isn't going to help get the project done - my idea here is that you want the project decided on by those actually going to do the work. One the project is decided on, all are welcome to pitch in ideas, etc. So after the project is decided, there needs to be a project leader. Depending on the project, what that means may vary. But I would say that the leader should come up with a plan detailed enough that it can be divided into work by several people. An example would be maps - having broad outlines of what should be done is a good starting point, but having a 1 or 2 line description of what is needed on the maps then provides folks enough detail to work on it. For coordination, putting this chart on the wiki, and people signing up for parts of it is probably a good way to go. I tend to think that it is best of the project lead starts by sending out a fairly detailed document - the reason I say this is that a fair number of developers have been around a long time, and can probably come up with a fairly complete starting plan without a lot of input. They should still send that out and get input, but having a good starting point may trim a week or two off the discussion, and also provide a clearer picture to everyone what the idea is. Some of the basis here is also that some points have already been extensively discussed in the past - new points are welcome, but we don't necessarily need to fully discuss all the issues again. Once the plan is more or less agreed to (hard to get 100% agreement), people start working. In fact, work may start before this, as there may be some points which everyone is in agreement on, and it may be more adding new points/details to the plan. The role of the project lead/coordinator is to take the pieces and make sure they all work. In the case of the map example, look over the maps, make sure they meet various standards, basic idea behind the map, and link up the exits, etc (possible that some maps completed before the ones they link to). All projects should be worked on until fully done. If a new NPC speech method is done that requires modifying the NPCs, it isn't sufficient to put that new support in and modify the NPCs in scorn and say 'it is ready' - that project isn't done until all the NPC's on all the maps are updated. Otherwise, past experience shows that those other NPCs probably won't get updated. I don't mean to have draconian policies in place in the above - in fact, just the opposite. What I really want is something in place so that projects can be decided fast, what needs to be done decided fast, and that broken down into pieces so that it can be completed rapidly. That's not to mean without thought, but lots of things has been extensively discussed, and all the discussions in the world don't really make it so that the project gets done any faster. From bogus@does.not.exist.com Sun Jun 10 10:49:06 2007 From: bogus@does.not.exist.com () Date: Sun, 10 Jun 2007 15:49:06 -0000 Subject: No subject Message-ID: > I would like to see regions for players of the same level. You either > need much more of those regions (for every nationalty an own beginning > region) or stay with mixed maps. But mixed maps lead newbies into > death. Having a cave of goblins next to one with dragons won't urge > newbies recommending this game to others... Agreed. The starting towns shouldn't have maps that are too dangerous. =20 Maybe only one harder quest, with abundant warnings around it (in Scorn=20 I'd leave the Old City quest). >> I'd take that opportunity to "regionalize" the choices of gods. One >> possibility is that praying at an altar doesn't "convert" you, you nee= d >> be "converted" on that god's society >=20 > On the one hand you're saying, that you should be able to master every > skill by your own to the same level as others with a teacher. On the > other hand you deny that for the praying skill. I think that's > inconsistent. Er, no, I never said that, where did I? Besides, the two things aren't related at all. The choice of what god a=20 character worships has nothing to do with skills. I just think, for=20 flavor purposes, the choices of religion should be regional. That has no= =20 impact at all on how far and how fast a priest can advance, just on what=20 "kind" of priest she can be. >> New skills, at amateur level, should be IMO taught at a relevant >> society. >=20 > How do you learn magic skills if you're a warrior? Or are you allowed > to enter all societies? Or won't you ever get a chance to learn magic > skills as a warrior? Only by joining an "advanced" society as I described later, one that only= =20 admits you if you are a warrior and then teaches you some magic -- making= =20 you the equivalent of today's "warlock". >> It also, on a crowded server (which we hope to get if we make CF2 cool >> enough), facilitates characters meeting others of the same society and >> forming parties. Conversely, if you need one mage for you party of >> fighters, you know where to go; just stand in front of the Academy for >> a while. >=20 > Wouldn't it be much easier to use "chat" instead of camping in front of > a guild? ;) I thought that as I was writing. Then I thought, our current chat system= =20 is somewhat aberrant. We have channels and we have a "main" channel, and= =20 everybody joins the "main" channel; but that's because the servers aren't= =20 too full. If we make this cool enough and the servers get really full,=20 then I wouldn't expect people to be in the same chat channel anymore, or=20 actually playing the game will become impossible. > Besides that, I think CF needs much more party support to make this wor= k > well - if ever on a tiled 2D map. I don't see much parties going deepe= r > at raffle2 after the trolls are dead. A CF party is just used to level > up a character fast, nothing more. That is at least partially true, maybe completely. But I'm assuming=20 we'll address that for 2.0 as well. Even if we don't, it's worth making=20 it easier to party, if the cost isn't very high, because then we're more=20 encouraged to improve partying later, in 2.x :-) best, Lalo Martins best, Lalo Martins --=20 So many of our dreams at first seem impossible, then they seem improbable, and then, when we summon the will, they soon become inevitable. ----- personal: http://lalo.hystericalraisins.net/ technical: http://www.hystericalraisins.net/ GNU: never give up freedom http://www.gnu.org/ From bogus@does.not.exist.com Sun Jun 10 10:49:06 2007 From: bogus@does.not.exist.com () Date: Sun, 10 Jun 2007 15:49:06 -0000 Subject: No subject Message-ID: . Gameplay / balance is a topic which was neglected in the past. But this will improve the fun of the game much more than those "fix for A", "patch for B" or "new feature C" thingy. $0.02 On Tue, Jul 17, 2007 at 12:25:24PM +0300, Juha J=E4ykk=E4 wrote: > First, most quest-reward and artefact items are weapons. This makes > completing quests somewhat unrewarding for monks, fireborns and dragons Not just weapons, getting e.g. a girdle as a fireborn, or boots as a serpentman, or anything which won't be usable in any way is not really a quest-reward but a joke. > I'm not saying never reward a monk with a sword, but make it much less > likely than rewarding a fighter with a sword. No, why should I ever start / solve a quest if the payment is worthless for me? I don't want to get useless rubbish as a "reward". > There can be a quest with a story of the evil X, who stole King > Arthur's Excalibur and keeps it in his Luggage - it's pretty obvious > one's going to find an excalibur and a luggage on this quest. But Excalibur won't be the quest reward! King Arthur just wants it back. So you have give it to King Arthur to receive your quest reward. And this won't be Excalibur, isn't it? > Second, the race- and class-specific distinctions are all but lost at > levels around 30 and higher. see http://mailman.metalforge.org/pipermail/crossfire/2007-July/011596.ht= ml And the entire discussion about it. > but I personally like the idea of making more race-specific items; add > body parts like "dragon tail" and "fireborn tentacle" to the races and > create objects that consume these. I like that idea, too. :) > If I have a character Str +2 with respect to "baseline" and I go kill > 10000 goblins, I should still have an Str score 2 above the baseline > character who killed 10000 goblins. (Of course it may be the baseline > guy found Strength potion and I did not, See above link, maybe you like the idea of stat handling. > For the record: I dislike race- or class-based fixed stat or level > limits. I've hated them ever since D&D first edition... =3D) I've nothing against race based fixed stat limits. It prevents e.g. that a halfling would be able to win against a troll in arm wrestling... But I dislike level limits, I can't see any reasons for it. On Tue, Jul 17, 2007 at 08:07:36PM +0200, Nicolas Weeger wrote: > There will always be a maximum level. It can be 112, it can be 200, it > can be 1000000. But there will always be a maximum :) > My opinion: let's keep things as they are for level, but rebalance how > you gain experience, maybe. Sure, but you're able to make the limit unreachable as long as the player isn't immortal. ;-) Make level 100 very hard to reach (like 115 now), but don't set a hard cap. Make it all but impossible to reach. > Fourth, the spell system needs rebalancing. Indeed, needs big changes... > First, meteor swarm and frost nova kill almost anything (if you can > make the meteors or asteroids directly hit your opponent, even fire or > cold immune creatures will die). Sure, both do weapon magic damage, not fire or cold. That's why I've no idea why "fireborns with meteor swarm" is an issue for game balance... > Also, some god-speciality spells kill anything, like divine shock or > red death. Also for lower levels. Ever tried to level up praying as a level 1 Ruggilli priest? Can't be the rule to be forced to change the cult just to get some starting levels in praying. > Fifth, at high levels, spells are useless. It's almost always easier > and more effective to simply karate chop or weapon slash everything > you bump into. Not only on high levels, especially for low levels. Ever tried to play a sorcerer without using physical attack skills? You won't be able to kill some monsters because they regenerate their hp faster than you sp. A dragon player just run through them like they're out of air... If something is very hard in the beginning, you should get a reward for the hard start on higher levels. So magic is always hard on low levels but you get the chance to become a very powerful mage on high levels. Not so for CF. Being a high level mage won't give you enough power to kills some of the high level monsters where others just need to run into them. This is really annoying. > [1] It's easy to increase mana regen bonus with good weapons, arnour et= c > and while there are rings and amulets for fireborns to increase theirs, > it very quickly occurs that those who can use good armour and weapons, > surpass fireborns' mana regeneration ability. see http://mailman.metalforge.org/pipermail/crossfire/2007-July/011613.ht= ml On Tue, Jul 17, 2007 at 08:07:36PM +0200, Nicolas Weeger wrote: > My opinion is to totally rebalance combat / spells / speed. Reduce > speed, add more "strategic" elements to the game. Make it so you can > actually use rune/trap writing to lure monsters, and so on. If you rebalance the combat / spells / speed system, you need to check every single map if it still works. If not you have to change the map. And if this backfitting starts, I would like to remind to the "reorganizing the entire world" thread: http://mailman.metalforge.org/pipermail/crossfire/2007-June/011532.html On Tue, Jul 17, 2007 at 09:51:49PM +0300, Juha J=E4ykk=E4 wrote: > > My opinion: let's keep things as they are for level, but rebalance > > how you gain experience, maybe. > > That's otherwise ok, but what about old characters at 110th level? Don't make CF2 compatibel with CF1.x and everybody has to start with level 1. This is necessary after big changes in the system. On Tue, Jul 17, 2007 at 10:57:22PM -0700, Mark Wedel wrote: > I'm sort of mixed on the idea of having random quest rewards. Same for me. Quest rewards should be deterministic, but race / class specific. > And from the flip side, if you're a monk, looking for the good monk > item that quest gives out 10% of the time, it could be really > frustrating to do that quest 10 times to get that item (or more if > unlikely). I'm still a friend of having quests only solvable once for each character. No rerun possible. How often will King Arthurs Excalibur be stolen by the same crowd? > If we rebalance everything else (which includes have spells that go > all the way up to level 110 or so), and a server set max level to > 1000, once characters started getting to some point, they'd probably > start saying the game is too easy, that there is nothing more to do - > I've learned all the spells, etc And what do the player say after hitting the limit: "Great! So much new things to discover and the ability to form the character."? ;-) See "reorganizing the entire world" and add new regions for higher level characters. Extensions, it's all about extensions... You said it once yourself, what the commercial role playing games do to keep the game interesting. But don't mix up the regions. So you don't have to care about rebalance the system again, because you have well balanced lower level regions. If player with powerful items from high level regions are able to harvest on lower level regions the balance is gone... > When 2.0 is released, IMO characters from the 1.x series will not be > compatible, so characters will need to be started anew. This is > probably a good thing for many reasons. Yes! Thank you. :) > IMO, pretty much every generator could be removed from the game and > it would probably make things better. Yes, or make them run out of monsters. And hidden. Or how do you explain a "monster generator" in the real world? ;-) You could for example use the face of a cave entrance as a goblin generator (with limited amount of goblins inside). If the generator is destroyed before it runs out, don't make it disappear, but change the face to a collapsed cave entrance. Like weak walls, they also don't disappear. J=FCrgen