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 nee