Menu
▾
▴
arianne-devel
|
From: <Rag...@we...> - 2005-08-14 10:05:00
|
Hi, danter, > I went away and made a draft xml file for items. Good work! > What I want is some sugestions to what I might have forgotten, and how > it could be improved for a more flexible usage, since later the rules > may indeed be very complex. If we want to use an xml-based feed of the database, we should not only th= ink of what game we use this for, but also which function such an approach= should serve in general. And we have to make sure we understand which amount of work such an approa= ch produces - hardcoding in java-classes may look inflexible, but it sure = is efficient and effective none the less. The perfect database for a game = is not relational and SQL-based like MySQL, but object-relational, as it w= ould provide much more efficient with storing characters, items, assets an= d the like. So, my suggestion is to keep xml in mind, but not start with it right away= , as the time required for implementation may delay the implementation of = the engines ability to carry varying rulesystems. At first, I suggest to generally accept the concept of "engine - ruleset -= game". In a perfect world this could mean: engine - Marauroa, with plugin "tilebased rpg" (which is, at the moment, s= till a part of Stendhal) ruleset - i.e. legacy D&D, or "a gamedesigners homebrew" game - i.e. Stendhal, or Stendhal-GD Any xml-format should reflect this separation IMHO, so I took a look at yo= ur ideas from this point of view: > Keywords: I tried to assign wether this is engine-stuff, or rulesystem-specific. Dis= agreement is a failproof indicator the subject is rulesystem-specific, so = this is default... ;-) > ITEM: this keyword begins a new item, and must be closed with /item. engine > ID: The id keyword is the name of the item, this is what shud be engine > TYPE: This is the main field, the most item descriptions is here. rulesystem > STATS: The stats keyword is stats added to your current base stats, a rulesystem > EQUIP: The equip keyword describe a slot where you can put the item, so engine The basic inventory-system should be rulesystem-independant (at first), bu= t may be extended (later) with rulesystem-specific attributes. Funny as it= seems, the weight of items often seems to be rulesystem-specific... > DEPEND: The depend keyword is items needed for the item to work, a bow partly rulesystem, partly engine. If we can, we should implement engine-co= mponents first, but where we cannot agree, it should be made rulesystem-sp= ecific. > SPECIAL: The special keyword is special abileties that items might have.= rulesystem > COMMAND: This is commands that shud be added to the drop down menu, not sure... maybe both, depending on the command. > DOOR: Well, a Key usually only works on one door. This is a door id that= > is needed when dealing with a key object, the X'es shud be replaced with= > the ID the door has. This attribute is too specific. There might be other items than keys that = have a specific target. Maybe it should be "target-id" or something simila= r. > Some things I also had in mind is some path to the graphics the item > shud use, since two swords can look the same but has different names and= > different powers.=20 Yeah, I was thinking of this as well. But this should be an optional field= to be filled by a gamedesigner, as different designers may assign differe= nt meanings to different items, depending on background-story or such. Best solution would be, that items are independent from assets (aka sprite= s, icons and animations), so that each item can be assigned any asset for = display. Ragnar-GD =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Mit der Gruppen-SMS von WEB.DE FreeMail k=F6nnen Sie eine SMS an alle=20 Freunde gleichzeitig schicken: http://freemail.web.de/features/=3Fmc=3D021179 |
|
From: <Rag...@we...> - 2005-08-18 18:28:26
|
Hi, danter, > That may be true, but personally I want to move ALL data out of the sour= ce=20 > really, and thats what professionals writing game is suggesting you shud= do=20 > with the data aswell (ever read game programming gems=3F, I have read some= of=20 > it, and there they suggest you shud have all data outside the source). We must do it, yes, but not exactly now. I earned some solid money with da= tabase-programming, and know the progress of moving data and normalizing d= atabases all too welll... :-( ...and my experience tells me: It is bug-prone work, that is on due when w= e want to increase the number of assets. But now we don't have much assets= , and I would prefer to start with implementing functionality, and do the = database-work *later*. Besides, of "gems" I have issues #2 and #3, and ordered #4. Do you have #1= =3F > For=20 > peps having problems compiling the source (im one of them, bet im not th= e=20 > only one) moving the data out of the source would be a blessing aswell..= .=20 > not to mention the time we would save not needing to recompile the sourc= e=20 > every time you make a small change. At the moment compiling is taking < 1 minute, we could do this run-time, a= ctually. I had gaming-projects that took well over 20 minutes for *one* co= mpiling-run (in C++)... ;-( We should not wait that long, but still, the amount of code for database-a= ccess would be *much* more that the code we could transform into data righ= t now. And we had to redesign the classes too, as if we do not reduce the = number of involved classes and the depth of the class-tree, we don't gain = much anyway, so IMHO this must come first. > I agree here, but xml is an accepted standard, and the reason I made the= =20 > draft one is so that we can start with it somewhere, im prepared to rewr= ite=20 > the entire file if it turns out the approuch is entierly wrong. No, I think you are right with starting the xml-specifications right now, = as this takes time. Here I'm with you 100%, and will start working on it r= ight away. It's just the database-coding I want to delay. > It would be nice if you mentioned some of the ideas you had in mind, so = that=20 > we can try to adopt them into this file... or change it so that it will = work=20 > for both rulesets. There are only two things I have in mind right now, one is the complete el= imination of any level-progression, and the other is a hit-location-based = close-combat-system without hitpoints. This requires more attributes and s= kills on creatures, unifies all creatures, and requires only physical data= for items, as actual combat-properties must be computed runtime (weapons:= weight, length, type/balance, fitness for 1 or 2H-use; armor: "size" (S/M= /L/XL/XXL), weight, material, protected body-parts). > Well, what I had in mind was what shud be displayed in like the inventor= y,=20 > nothing like animations and such. It would be strange if you didnt defin= e=20 > any graphics for the item, cause in the game it would probably be a=20 > completely transparent object... Remember this file is descriptions for=20 > items alone, and not some quests or story segments, that naturally dosnt= =20 > have any graphics at all. Even if the designer didnt define any graphics= =20 > him/herself, it shud probably have some "dummy" graphics shown anyway. Yes, I get the point, you are right. This whole discussion gets along well. I'm curious what Miguel has to say = to this. As he will usually do the most work, I try to think of how to red= uce the amount of coding as much as possible, or what parts that I need ca= n be done by myself, so that there is no conflict of interest. Ragnar-GD =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F Mit der Gruppen-SMS von WEB.DE FreeMail k=F6nnen Sie eine SMS an alle=20 Freunde gleichzeitig schicken: http://freemail.web.de/features/=3Fmc=3D021179 |
|
From: Anders A. <and...@ho...> - 2005-08-18 23:57:14
|
Hello Ragnar-GD >...and my experience tells me: It is bug-prone work, that is on due when we >want to increase the number of assets. But now we don't have much assets, >and I would prefer to start with implementing functionality, and do the >database-work *later*. Well, thats a reason why this might be the real time to move it out of the source, since having few assets, removes alot of possibileties of getting big nasty bugs then if we did it when having tons of assets. >Besides, of "gems" I have issues #2 and #3, and ordered #4. Do you have #1? Well have and have is a matter of defenition... ;) I have #1 right now, and It's in that I found the "suggestion" about moving all data out of the source (Chapter 1.0: The Magic of Data-Driven Design, page 3), but it's not mine, it's borrowed from a friend who also have #2 and #3, and he was talking about ordering #4 aswell. > > I agree here, but xml is an accepted standard, and the reason I made the > > draft one is so that we can start with it somewhere, im prepared to >rewrite > > the entire file if it turns out the approuch is entierly wrong. > >No, I think you are right with starting the xml-specifications right now, >as this takes time. Here I'm with you 100%, and will start working on it >right away. It's just the database-coding I want to delay. Well, at the present time, the database coding will be delayed in any way we want, so no worries there... but for what I see miguel is still missing (shud be back anyday soon now thou I guess). But even so, I still want us to make a clear defenition on what we really want and what we really need, before implementing anyting, because that would just make alot of unnecessary coding... and having clear defenitions makes coding it rather easy, even if it's crazely complex. So... I guess we are rather much at the same opinion here... heh ;) > > It would be nice if you mentioned some of the ideas you had in mind, so >that > > we can try to adopt them into this file... or change it so that it will >work > > for both rulesets. > >There are only two things I have in mind right now, one is the complete >elimination of any level-progression, and the other is a hit-location-based >close-combat-system without hitpoints. This requires more attributes and >skills on creatures, unifies all creatures, and requires only physical data >for items, as actual combat-properties must be computed runtime (weapons: >weight, length, type/balance, fitness for 1 or 2H-use; armor: "size" >(S/M/L/XL/XXL), weight, material, protected body-parts). Ahh, yes I remember this discussion, since the old gladiator time... yes I was infact with arianne even at that time... thou the only work I made for the project was the 3D modell of the arena... wich I sent to miguel via IRC. Anyway, I think at the moment the item xml shud be complient enought for this... atleast after mtotz changes to it, the items just need a few other parameters. Im going to try making a defenition of a Katana, since thats the only weapon I do have some detailed geometric data on, body armor just have to wait, cause I don't know what segments of the body you really want to use in your RP rule defenition. Ragnar-GD xml defenition tryout ------------------------ <item name="katana"> <property name="equip" value="both_hands"/> <property name="weight" value="1191"/> <property name="hilt_lenght" value="22.86"/> <property name="blade_lenght" value="73.66"/> <property name="blade_thick" value="0.71"/> <property name="balance" value="??"/> </item> ------------------------ The weight is in grams, and the lenght is in centimeters (im from sweden so I prefer using SI units for lenght and weight, not to mention that it's way easier to do maths on them directly... without conversion... No offense all you US and GBR guys, but honestly... your pounds and inches sucks for maths, thats a fact ;) ) Well, im rather sattesfied with the result... offcourse I have no idea about how well balanced the Katana is, and I didnt find any on the great web... but my emediate thought about balance has alot of influence when calculating speedyness, and also the amount of "crash damage" that is the main damage type on morningstars and maces, where weight has a good deal to say aswell. To really define balance, we probably need more then one weight parameter, like say a weight parameter for the hilt, and a weight parameter for the blade. Hilt lenght and blade lenght is very interesting when calculating how much of a heave effect you get with the blade, wich can be used to calculate the amount of pressure the armor/body will take, and if the armor/body can sustain the heavy hit. Blade thickness is interested in situations when two people is fighting, and one of them makes a hit on the side of the oponents blade. If the pressure dealt on the blade is high enought, and the angle is right... it would end with the oponents blade either taking sewere damage changing the balance of the blade, or simply it brokes off, making it unusable as a katana anymore. It also has a great deal to say when calculating eventuall "crash damage" a blade might have. Offcourse I probably have way to few parameters for a battle system Ragnar-GD is talking about, and IMHO it's defently up to him to make the real parameter defenitions, since it's hes system after all. But as a conclusion, I think that the current item xml file is indeed good enought for even defining Ragnar-GD's RP system. Regards Anders Asplund aka danter @ irc.freenode.net #arianne _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From: Matthias T. <mt...@gm...> - 2005-08-20 15:07:10
|
Hi all, just a moment ago I committed the first part of the 'move all ruleset specific stuff out of the core code'-task. Moved all stuff in a rule subpackage. The main goal is to keep the status quo, or in other words, not to break too much. All enemies (which are called creatures) are the same now, only some properties are different. See: games.stendhal.server.rule.defaultruleset.DefaultCreature for a list. The next step is to simplify the item code. As with creatures there won't be any additional features for now, just move them out of the core. Note to Ragnar: When it's done you'll be able to specify the ruleset in the config file and simply add the ruleset jar to the classpath. You still have to recode the stuff in the 'stendhal.server.rule.defaultruleset.*' in java, but you don't need all those core sources. In netbeans you just add the stendhal-server.jar to the project. Is this ok for you? Note to danter: When the refactoring is done I think about a xml importer... Note2 to danter: > this... atleast after mtotz changes to it, the items just need a few mtotz is not my nickname...it is the first letter of my firstname and all of the lastname 8-) Just see the stuff I write under 'regards' :) Regards Matthias Anders Asplund schrieb: > Hello Ragnar-GD > >> ...and my experience tells me: It is bug-prone work, that is on due >> when we want to increase the number of assets. But now we don't have >> much assets, and I would prefer to start with implementing >> functionality, and do the database-work *later*. > > > Well, thats a reason why this might be the real time to move it out of > the source, since having few assets, removes alot of possibileties of > getting big nasty bugs then if we did it when having tons of assets. > > >> Besides, of "gems" I have issues #2 and #3, and ordered #4. Do you >> have #1? > > > Well have and have is a matter of defenition... ;) > I have #1 right now, and It's in that I found the "suggestion" about > moving all data out of the source (Chapter 1.0: The Magic of Data-Driven > Design, page 3), but it's not mine, it's borrowed from a friend who also > have #2 and #3, and he was talking about ordering #4 aswell. > > >> > I agree here, but xml is an accepted standard, and the reason I made >> the >> > draft one is so that we can start with it somewhere, im prepared to >> rewrite >> > the entire file if it turns out the approuch is entierly wrong. >> >> No, I think you are right with starting the xml-specifications right >> now, as this takes time. Here I'm with you 100%, and will start >> working on it right away. It's just the database-coding I want to delay. > > > Well, at the present time, the database coding will be delayed in any > way we want, so no worries there... but for what I see miguel is still > missing (shud be back anyday soon now thou I guess). > > But even so, I still want us to make a clear defenition on what we > really want and what we really need, before implementing anyting, > because that would just make alot of unnecessary coding... and having > clear defenitions makes coding it rather easy, even if it's crazely > complex. So... I guess we are rather much at the same opinion here... > heh ;) > > >> > It would be nice if you mentioned some of the ideas you had in mind, >> so that >> > we can try to adopt them into this file... or change it so that it >> will work >> > for both rulesets. >> >> There are only two things I have in mind right now, one is the >> complete elimination of any level-progression, and the other is a >> hit-location-based close-combat-system without hitpoints. This >> requires more attributes and skills on creatures, unifies all >> creatures, and requires only physical data for items, as actual >> combat-properties must be computed runtime (weapons: weight, length, >> type/balance, fitness for 1 or 2H-use; armor: "size" (S/M/L/XL/XXL), >> weight, material, protected body-parts). > > > Ahh, yes I remember this discussion, since the old gladiator time... yes > I was infact with arianne even at that time... thou the only work I made > for the project was the 3D modell of the arena... wich I sent to miguel > via IRC. > > Anyway, I think at the moment the item xml shud be complient enought for > this... atleast after mtotz changes to it, the items just need a few > other parameters. > > Im going to try making a defenition of a Katana, since thats the only > weapon I do have some detailed geometric data on, body armor just have > to wait, cause I don't know what segments of the body you really want to > use in your RP rule defenition. > > Ragnar-GD xml defenition tryout > ------------------------ > <item name="katana"> > <property name="equip" value="both_hands"/> > <property name="weight" value="1191"/> > <property name="hilt_lenght" value="22.86"/> > <property name="blade_lenght" value="73.66"/> > <property name="blade_thick" value="0.71"/> > <property name="balance" value="??"/> > </item> > ------------------------ > > The weight is in grams, and the lenght is in centimeters (im from sweden > so I prefer using SI units for lenght and weight, not to mention that > it's way easier to do maths on them directly... without conversion... No > offense all you US and GBR guys, but honestly... your pounds and inches > sucks for maths, thats a fact ;) ) > > Well, im rather sattesfied with the result... offcourse I have no idea > about how well balanced the Katana is, and I didnt find any on the great > web... but my emediate thought about balance has alot of influence when > calculating speedyness, and also the amount of "crash damage" that is > the main damage type on morningstars and maces, where weight has a good > deal to say aswell. > > To really define balance, we probably need more then one weight > parameter, like say a weight parameter for the hilt, and a weight > parameter for the blade. > > Hilt lenght and blade lenght is very interesting when calculating how > much of a heave effect you get with the blade, wich can be used to > calculate the amount of pressure the armor/body will take, and if the > armor/body can sustain the heavy hit. > > Blade thickness is interested in situations when two people is fighting, > and one of them makes a hit on the side of the oponents blade. If the > pressure dealt on the blade is high enought, and the angle is right... > it would end with the oponents blade either taking sewere damage > changing the balance of the blade, or simply it brokes off, making it > unusable as a katana anymore. It also has a great deal to say when > calculating eventuall "crash damage" a blade might have. > > > Offcourse I probably have way to few parameters for a battle system > Ragnar-GD is talking about, and IMHO it's defently up to him to make the > real parameter defenitions, since it's hes system after all. But as a > conclusion, I think that the current item xml file is indeed good > enought for even defining Ragnar-GD's RP system. > > > Regards > Anders Asplund aka danter @ irc.freenode.net #arianne > > _________________________________________________________________ > Express yourself instantly with MSN Messenger! Download today - it's > FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > Arianne-devel mailing list > Ari...@li... > https://lists.sourceforge.net/lists/listinfo/arianne-devel > |
|
From: Anders A. <and...@ho...> - 2005-08-20 17:10:28
|
Hi, Matthias >just a moment ago I committed the first part of the 'move all ruleset >specific stuff out of the core code'-task. Moved all stuff in a rule >subpackage. >The main goal is to keep the status quo, or in other words, not to break >too much. Wohow, great! >Note to danter: >When the refactoring is done I think about a xml importer... Very nice, think im going to sit down and create a new xml file for creatures now then, we already have some of it defined atleast, and as long as the more advanced keywords like logic is kept out, it shudnt be any problem right? >Note2 to danter: > > > this... atleast after mtotz changes to it, the items just need a few > >mtotz is not my nickname...it is the first letter of my firstname and all >of the lastname 8-) Just see the stuff I write under 'regards' :) Sorry, my mistake... but I thought "mtotz" is the nickname you wanted to use instead of your real name Matthias, just like "danter" is the nickname i use instead of my real name Anders, after all, you call yourself "mtotz" on sourceforge. On sourceforge im actually called damnter thou, but I changed my nickname since then. The nickname damnter got me flamed to much in games by GM's and such ;-/ (it had the word "damn" included... wich I personally hadnt realized until that point...! ) Regards Anders Asplund aka danter @ irc.freenode.net #arianne _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ |
|
From: Anders A. <and...@ho...> - 2005-08-20 17:29:59
|
Haha... I had totally forgottend. Monsters you can place out in the tiled editor, and they will come up in the game, without any other changes to code or whatsoever. The "tileid" is offcourse the id looked for in the mapfile, and then used to place an instance of that monster in the game. Regards Anders Asplund aka danter @ irc.freenode.net #arianne _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From: Miguel A. B. L. <mig...@ho...> - 2005-08-31 14:38:30
|
>just a moment ago I committed the first part of the 'move all ruleset >specific stuff out of the core code'-task. Moved all stuff in a rule >subpackage. >The main goal is to keep the status quo, or in other words, not to break >too much. > >All enemies (which are called creatures) are the same now, only some >properties are different. See: >games.stendhal.server.rule.defaultruleset.DefaultCreature for a list. > >The next step is to simplify the item code. As with creatures there won't >be any additional features for now, just move them out of the core. Good. I will read the code and try to get updated as soon as possible. Regards, Miguel |
|
From: Anders A. <and...@ho...> - 2005-08-18 18:55:03
Attachments:
item.xml
|
Hi mtotz. It's nice to have one of the coders view and modifications of the xml "script" aswell, matching it to code issues and parsing sollutions. >>[...] but personally I want to move ALL data out of the source really, > >This is my opinion too. In fact, this will save us a lot if trouble when >we try to use a scripting system for the rules (some time far in the >future). Exactly, and I get the feeling it's not really that far away, now when we have started this discussion ;) > >Your xml-file is a good start. More important is a description of the NPC's >(enemies and townpeople), as they are better implemented atm. Something >like this: Thank you, it defently served it's real purpose atleast, and that is to start a conversation about scripts and future data sollutions. >----8<---- ><?xml version="1.0" encoding="ISO-8859-1"?> ><data> > <npc> > <enemy name="wolf"> > <property name="tileid" value="4"/> > <property name="hp" value="20"/> > <property name="atk" value="2"/> > <property name="def" value="4"/> > <property name="speed" value="0.5"/> > <property name="size" value="1"/> > <property name="logic" value="patrol"/> > </enemy> > </npc> ></data> > >---->8---- I really considered doing an xml file for monsters/npc but the reason I didnt was cause I didnt know how It shud be made. What you have done is good, but I still see some stuff that is missing... and things that is a bit unclear, atleast in an editing view. Firstly, it seems like you have tryed to make an NPC (the ones running around in the city) with the <npc> keyword, but then put a monster (or creature as the directory on cvs is called) in it's data fields... what I was mainly wondering, shud we have those in the same file? or shud we put them in different files?. In either way, I think we shud add a parameter for creatures saying if it's hostile or not if that is'nt included in the logic field that is, wich I guess is the name of a script?. Still an Elk is'nt hostile in nature, but if you provoke it, it can get really dangerous!. For NPC's I was thinking about dialogs, is it a better sollution to make a dialogue script?, or shud we put that data in the xml file aswell?. If we did we would have to add alot of stuff to the xml file including tests of variables, different states and so on. But, not many NPC's say the same thing, exept vendor and shop NPC's, wich even in reality has about the same thing to say, "Hello there mister/missis, is there anything I can help you with? (...)". An idea could be that to shop NPC's we add the property shop, where the value is a shoplist and we also give them a dialoge script, In that way we can have standardised shop/vendors with standardised dialogues. Haha... I think I just answered my own questions. Anyways, in this way we can have monsters and NPC's in the same xml file, but that would mean that this xml file mainly would be an overview of what NPC's/creatures that exist, and what stats they have. As a last notation, I would like to know what the tileid value is used for?, is it some form of sprite id? and also... I miss the XP gain property that monsters... and even some NPC's shud give when you kill them. Here is a slightly modefied version of the xml snipet you made, it also includes my idea of an NPC we all know ;) --------------- <?xml version="1.0" encoding="ISO-8859-1"?> <data> <!-- I changed the enemy to creature, since an enemy is normally hostile on default --> <creature name="wolf"> <property name="tileid" value="4"/> <!-- Still wonder what this is for --> <property name="hp" value="20"/> <property name="atk" value="2"/> <property name="def" value="4"/> <property name="speed" value="0.5"/> <property name="xp" value="360"/> <property name="size" value="1"/> <property name="logic" value="patrol"/> <property name="hostile" value="yes"/> <property name="noise" value="Aooooooouuhhh!!"/> <!-- this is just an ascii string, showed above the creature sometimes ;) --> </creature> <npc name="Carmen"> <property name="tileid" value="?"/> <property name="hp" value="100"/> <property name="atk" value="0"/> <property name="def" value="0"/> <property name="speed" value="0.5"/> <property name="xp" value="0"/> <property name="size" value="1"/> <property name="logic" value="wander"/> <!-- well she wanders back and forth... must have a different logic then the wolf... --> <property name="dialouge" value="WelcomerNPC"/> <!-- Name on the dialogue script in use--> </npc> </data> ------------- > >I would prefer named properties instead of hardcoded attributes: > ><item name="spiked_shield"> > <property name="equip" value="left_hand"/> > <property name="equip" value="right_hand"/> > <property name="def" value="14"/> > <property name="atk" value="2"/> ></item> > >If we forward the properties to the rules they can even deal with >properties not known at compile time. The props of any entities are stored >in hashmaps anyway... > Some of the words has like the same meaning as the one I did. My type has the same meaning as your property, this method seems a bit more logica thou, and it's better code wise, even if it's way more to write. Anyway I changed the previous file to try and use this method. The file is attached to the message, and what i mostly want comments on is the way I solwed it for the bow and the key. _________________________________________________________________ Don't just search. Find. Check out the new MSN Search! http://search.msn.com/ |
|
From: Anders A. <and...@ho...> - 2005-08-18 18:59:52
Attachments:
item.xml
|
Hi mtotz. It's nice to have one of the coders view and modifications of the xml "script" aswell, matching it to code issues and parsing sollutions. >>[...] but personally I want to move ALL data out of the source really, > >This is my opinion too. In fact, this will save us a lot if trouble when >we try to use a scripting system for the rules (some time far in the >future). Exactly, and I get the feeling it's not really that far away, now when we have started this discussion ;) > >Your xml-file is a good start. More important is a description of the NPC's >(enemies and townpeople), as they are better implemented atm. Something >like this: Thank you, it defently served it's real purpose atleast, and that is to start a conversation about scripts and future data sollutions. >----8<---- ><?xml version="1.0" encoding="ISO-8859-1"?> ><data> > <npc> > <enemy name="wolf"> > <property name="tileid" value="4"/> > <property name="hp" value="20"/> > <property name="atk" value="2"/> > <property name="def" value="4"/> > <property name="speed" value="0.5"/> > <property name="size" value="1"/> > <property name="logic" value="patrol"/> > </enemy> > </npc> ></data> > >---->8---- I really considered doing an xml file for monsters/npc but the reason I didnt was cause I didnt know how It shud be made. What you have done is good, but I still see some stuff that is missing... and things that is a bit unclear, atleast in an editing view. Firstly, it seems like you have tryed to make an NPC (the ones running around in the city) with the <npc> keyword, but then put a monster (or creature as the directory on cvs is called) in it's data fields... what I was mainly wondering, shud we have those in the same file? or shud we put them in different files?. In either way, I think we shud add a parameter for creatures saying if it's hostile or not if that is'nt included in the logic field that is, wich I guess is the name of a script?. Still an Elk is'nt hostile in nature, but if you provoke it, it can get really dangerous!. For NPC's I was thinking about dialogs, is it a better sollution to make a dialogue script?, or shud we put that data in the xml file aswell?. If we did we would have to add alot of stuff to the xml file including tests of variables, different states and so on. But, not many NPC's say the same thing, exept vendor and shop NPC's, wich even in reality has about the same thing to say, "Hello there mister/missis, is there anything I can help you with? (...)". An idea could be that to shop NPC's we add the property shop, where the value is a shoplist and we also give them a dialoge script, In that way we can have standardised shop/vendors with standardised dialogues. Haha... I think I just answered my own questions. Anyways, in this way we can have monsters and NPC's in the same xml file, but that would mean that this xml file mainly would be an overview of what NPC's/creatures that exist, and what stats they have. As a last notation, I would like to know what the tileid value is used for?, is it some form of sprite id? and also... I miss the XP gain property that monsters... and even some NPC's shud give when you kill them. Here is a slightly modefied version of the xml snipet you made, it also includes my idea of an NPC we all know ;) --------------- <?xml version="1.0" encoding="ISO-8859-1"?> <data> <!-- I changed the enemy to creature, since an enemy is normally hostile on default --> <creature name="wolf"> <property name="tileid" value="4"/> <!-- Still wonder what this is for --> <property name="hp" value="20"/> <property name="atk" value="2"/> <property name="def" value="4"/> <property name="speed" value="0.5"/> <property name="xp" value="360"/> <property name="size" value="1"/> <property name="logic" value="patrol"/> <property name="hostile" value="yes"/> <property name="noise" value="Aooooooouuhhh!!"/> <!-- this is just an ascii string, showed above the creature sometimes ;) --> </creature> <npc name="Carmen"> <property name="tileid" value="?"/> <property name="hp" value="100"/> <property name="atk" value="0"/> <property name="def" value="0"/> <property name="speed" value="0.5"/> <property name="xp" value="0"/> <property name="size" value="1"/> <property name="logic" value="wander"/> <!-- well she wanders back and forth... must have a different logic then the wolf... --> <property name="dialouge" value="WelcomerNPC"/> <!-- Name on the dialogue script in use--> </npc> </data> ------------- > >I would prefer named properties instead of hardcoded attributes: > ><item name="spiked_shield"> > <property name="equip" value="left_hand"/> > <property name="equip" value="right_hand"/> > <property name="def" value="14"/> > <property name="atk" value="2"/> ></item> > >If we forward the properties to the rules they can even deal with >properties not known at compile time. The props of any entities are stored >in hashmaps anyway... > Some of the words has like the same meaning as the one I did. My type has the same meaning as your property, this method seems a bit more logica thou, and it's better code wise, even if it's way more to write. Anyway I changed the previous file to try and use this method. The file is attached to the message, and what i mostly want comments on is the way I solwed it for the bow and the key. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From: Anders A. <and...@ho...> - 2005-08-18 19:50:11
|
Sorry for all those duplicates of the same message... seems like sourceforge was down for a while or something, so I didnt get my own message back from the list and thought something had gone wrong when I first sent them... thus trying to send them again... Anders Asplund aka danter @ irc.freenode.net #arianne _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ |
|
From: <Rag...@we...> - 2005-08-19 21:42:57
|
hi, danter, > Well, thats a reason why this might be the real time to move it out of the > source, since having few assets, removes alot of possibileties of getting > big nasty bugs then if we did it when having tons of assets. My preferred order of tasks would be: 1. enable me to implement a second rule-system 2. enable data-driven design 3. produce assets I'm only interested in working on #1, as I don't see myself as a coder. If the order would be 2./1./3., I would have to wait some months before I could start working. 1. is work, but not too much of it. > Well, at the present time, the database coding will be delayed in any way we > want, so no worries there... but for what I see miguel is still missing > (shud be back anyday soon now thou I guess). He was already working on bugs, if not, someone was faking his nic in the [arianne-bugs] forum... :) > But even so, I still want us to make a clear defenition on what we really > want and what we really need, before implementing anyting, because that > would just make alot of unnecessary coding... and having clear defenitions > makes coding it rather easy, even if it's crazely complex. So... I guess we > are rather much at the same opinion here... heh ;) Nothing I want is more complex that what is already in the code, it's only different. And as I would code it on my own without any part of the engine depending on my coding, nobody would get delayed if my work would progress slow. > > complete elimination of any level-progression, and hit-location-based combat > > Ahh, yes I remember this discussion, since the old gladiator time... > Anyway, I think at the moment the item xml shud be complient enought for > this... atleast after mtotz changes to it, the items just need a few other > parameters. > Im going to try making a defenition of a Katana, since thats the only weapon > I do have some detailed geometric data on, body armor just have to wait, > cause I don't know what segments of the body you really want to use in your > RP rule defenition. Without being overly critic, without any real code, any too exact xml-definition is perhaps wasted disk-space on sourceforge... :) > Ragnar-GD xml defenition tryout > ------------------------ > <item name="katana"> > <property name="equip" value="both_hands"/> > <property name="weight" value="1191"/> > <property name="hilt_lenght" value="22.86"/> > <property name="blade_lenght" value="73.66"/> > <property name="blade_thick" value="0.71"/> > <property name="balance" value="??"/> > </item> > ------------------------ A realistic "equip"-value for any item would always be "any single hand, or both". This value is only limited by our assets: If we do have no two-handed swords as animations, we cannot have two-handed swords... :-) > The weight is in grams, and the lenght is in centimeters This value may vary with each item, that's why run-time calculation makes sense. > Well, im rather sattesfied with the result... offcourse I have no idea about > how well balanced the Katana is, and I didnt find any on the great web... "Balance" is a measure how far from the center the point of weight is. Blades are therefore usually "balanced", while hafted weapons (maces, spears) are "unbalanced", which may be expressed by a rough degree. The second influence is where you can hold the weapon: A weapon with a defined handle - as a katana - is harder to handle than (say) a polearm, as you can easily hold a polearm at its center of weight (although this is not necessarily a good idea). But balance is a concept I would not start implementing right away - and it's not important for the momentary rules of Stendhal anyway. > but my emediate thought about balance has alot of influence when calculating > speedyness, and also the amount of "crash damage" that is the main damage > type on morningstars and maces, where weight has a good deal to say aswell. This heavily interacts with the strenght and bodysize of the wielder. If you are a 10m high giant, any human sword is just an unimportant toy. > Hilt lenght and blade lenght is very interesting when calculating how much > of a heave effect you get with the blade, wich can be used to calculate the > amount of pressure the armor/body will take, and if the armor/body can > sustain the heavy hit. No human body can sustain even a butter-knive weld by a child. By relevance, it's the ability of a weapon to penetrate a given type of armour, and thereafter, it's mainly of importance where you get hit, and not "how much". Only when a weapon does not penetrate armour, a crushing effect is to be calculated. High-quality-armour in the advent of firearms was so good, that your only hope of getting a lethal hit was to get the enemy bashed to the ground, and then finish him with a special dagger through the visor of his helmet (yeah, if you had the money for it, and I don't mean the dagger). > Blade thickness is interested in situations when two people is fighting, and > one of them makes a hit on the side of the oponents blade. If the pressure > dealt on the blade is high enought, and the angle is right... it would end > with the oponents blade either taking sewere damage changing the balance of > the blade, or simply it brokes off, making it unusable as a katana anymore. There are simple algos to deal with this: Assign an "armour"-value to a weapon, depending on the aforementioned physical characteristics, that degrades when parrying blows: av. male size: 12 (equals 85 kg at 173cm) av. male strenght: 12 (an average men has strenght equal to his size by definition) hp of av. chest: 12 (chest=100% of size by definition) hp of av. arm: 8 (arm = 75% of size by definition) av dam.-bonus: 12 (strength by definition) av 2h-dam-bonus: 18 (150% of av. dam-bonus) (other attributes like "dexterity" et. al. are ignored for simplicity at this calculations) Platemail with heavy padded quilt under: protection vs. penetration: 44 (value arbitrarily drawn form a roleplaying-ressource) protection vs. impact: 16 (-"-) weight of complete set: 32kg 2h-Sword Weight 1,8 kg (no skill-or damage-deduction, as the dam-bonus with a 2h-weapon is not less than weapon-weigth * 10) Lenght 1,5m (lenght is ignored at the momentary calculations for simplicity) AV. Dam. for a hacking attack: 18 (weight *10 for a balanced weapon hold at its end) +18 (2h dam-bonus) + 9 (25% penetration-bonus because of average sharpness) total average penetration damage for an "average" hit = 45 (weight + strenght + sharpness, 100% for an "average" hit) total average bashing damage for an "average" hit = 36 (weight + strenght, 100% for an "average" hit) Armour: weight * 2 for steel = 36, /lenght 1,5m = 24, +25% for average quality = 30 These are rough sketches of parts of the system, I'm too tired to hack the algos at the moment... #-) > Offcourse I probably have way to few parameters for a battle system > Ragnar-GD is talking about, and IMHO it's defently up to him to make the > real parameter defenitions, since it's hes system after all. But as a > conclusion, I think that the current item xml file is indeed good enought > for even defining Ragnar-GD's RP system. Yes, as you can see, you are perfectly right. Ragnar-GD __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsstarkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131 |
|
From: Anders A. <and...@ho...> - 2005-08-20 10:13:47
|
Danter sits down on the floor making some form of mantra, trying to calm down... repeating the words for himself KISS, KISS... I shud have listened more to miguel... o_O Anyway, I have rewieved some of the Stendhal Objectives on the wiki: http://arianne.sourceforge.net/wiki/index.php/StendhalObjectives And realised that scripts will probably be in the next iteration of the Arianne project, but for that we still need to define them... The current item.xml file and the small defenition on creatures we have is still rather easy thou, and I think they shudnt be to hard to implement in stendhal for the moment. They would atleast make it a bit easier to create new monsters and items. Im still gona answer some of Ragnar-GD's critism pointed towards me thou, cause they still have something to say about future scripts and xml files, im not going to discuss your RP rules thou Ragnar, those are totally up to you to define. What I want is real defenitions on what you want, and that is interesting when making scripts or xml files. >Without being overly critic, without any real code, any too exact >xml-definition is perhaps wasted disk-space on sourceforge... :) Well you are perfectly right here, but what im hoping for in the end, is some form of script language after all. A script language that perhaps shud issue the keywords we define in the xml files... and for what I know... it was for that purpose I started this discussion. Something I do know thou, is that the current item.xml file shudnt be to hard to really implement in the current stendhal code, wich mean that it really is usable, as soon as we get code for it. >A realistic "equip"-value for any item would always be "any single hand, or >both". This value is only limited by our assets: This is a matter of how the "both_hands" value is treated in code/scripts, it could be treated as such: "yes you can use it with either left or the right hand, but you get drawbacks if you don't use it with both hands, unless you have a strenght above XX in your stats" Offcourse strenght could be replaced with any other value that is interesting in this situation, but it's just an example. Maybe a better way, or better keywords is needed when describing equiping stuff thou... cause I just thought about creatures that have 3 hands or more... and weapons that actually is made to be used with that amount of hands. I guess it might be an idea to just say 1H weapon 2H weapon 3H... and so on, not even mentioning if it's the left or the right hand, and you get drawbacks if you use it with less hands, or not work at all (ie: a Bow, you can't fire a bow without using both hands). With these keywords it's just a matter of changing the both_hand value to 2H, and it's usable with left, right and both, while the both_hand value is strictly for items like a bow, who really can't be used with only 1 hand (if you don't plan on using the bow in close combat that is...). >If we do have no two-handed swords as animations, we cannot have two-handed >swords... :-) Yes we can... because right now we don't have any battle animations at all (in a graphical view, we are just standing there staring at the monsters in stendhal :-P ), whats really interesting is what stands in the small text output window at the bottom of the client (and offcourse what the server "thinks" you are doing) ;) This is the only comment im going to make about your rules... heh... >No human body can sustain even a butter-knive weld by a child. (...) Well, whos refering to a human body?... the body in question might as well be an iron golem... try penetrate that with a butter knife ;) A small sugestion is to treat the body and the armor the same. The body just has a very weak defence parameter, compared to body armour. The "how much" of an attack still comes in play when determining how deep the wound would be, or if you actually would cut off the limb in question. The "how much" is also important if the ribs or any other bone in the body is in the way for a real critical hit to come in play, for example: if you throw a knife against the heart, it woldnt be that critical if it "bounced" against the ribs placed right over the heart, unless the power of the throw was so much, that it actually would penetrate the bone placed above the heart. Regards Anders aka danter @ irc.freenode.net #arianne _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
|
From: <Rag...@we...> - 2005-08-20 13:39:35
|
Hi, danter, > Danter sits down on the floor making some form of mantra, trying to calm > down... repeating the words for himself KISS, KISS... I shud have listened > more to miguel... o_O Uh-oh. Yes. Ok. I sit next to you, calm down as well, and... K-I-S-S Alright. Better. I'm with you... :) > And realised that scripts will probably be in the next iteration of the > Arianne project, but for that we still need to define them... > Im still gona answer some of Ragnar-GD's critism pointed towards me thou, Huh, did it sound so? Apologies. I don't see much differences in opinion, basically minor details. > cause they still have something to say about future scripts and xml files, > im not going to discuss your RP rules thou Ragnar, those are totally up to > you to define. ...as this is the developement-forum anyway. I got carried away... sorry... :) > What I want is real defenitions on what you want, and that is > interesting when making scripts or xml files. Ok. > Well you are perfectly right here, but what im hoping for in the end, is > some form of script language after all. A script language that perhaps shud > issue the keywords we define in the xml files... and for what I know... it > was for that purpose I started this discussion. I don't see the scripting language coming up soon with a java-based server. Java is it's own scripting-engine, and perhaps a bit too slow on its own to carry another scripting-language. On the other hand, it depends very much where and how we would use scripting anyway. > >A realistic "equip"-value for any item would always be "any single hand, or > >both". This value is only limited by our assets: > > This is a matter of how the "both_hands" value is treated in code/scripts, > it could be treated as such: "yes you can use it with either left or the > right hand, but you get drawbacks if you don't use it with both hands, > unless you have a strenght above XX in your stats" ...which makes it rulesystem-specific, because I know many systems that don't care about strength-requirements anyway. IMHO it's a save bet to use physical descriptions only, as the rulesystem-specific part of the engine can translate this into rulesystem-specific data at server-load or perhaps even at runtime. If some data are not used, any engine may ignore it. Therefore, your very detailed xml-format is highly desireable. > Offcourse strenght could be replaced with any other value that is > interesting in this situation, but it's just an example. Maybe a better way, > or better keywords is needed when describing equiping stuff thou... cause I > just thought about creatures that have 3 hands or more... and weapons that > actually is made to be used with that amount of hands. Lol. Yes, right. > >If we do have no two-handed swords as animations, we cannot have two-handed > >swords... :-) > > Yes we can... because right now we don't have any battle animations at all > (in a graphical view, we are just standing there staring at the monsters in > stendhal :-P ), whats really interesting is what stands in the small text > output window at the bottom of the client (and offcourse what the server > "thinks" you are doing) ;) I'm not sure, but: Isn't this an advantage actually? I wouldn't say I really miss any attack-animations right now, as the resolution of the avatars is so low anyway. Ultima 6 works without such animations as well, and no one can complain, it's still a fine game. So, yes, here you are right as well. > This is the only comment im going to make about your rules... heh... They would give me some headache if I really tried to implement them with this depth of detail (which I won't: KISS) > >No human body can sustain even a butter-knive weld by a child. (...) > > Well, whos refering to a human body?... the body in question might as well > be an iron golem... try penetrate that with a butter knife ;) *Caugh!*... well yes, we are doing basic fantasy here... May happen... Perhaps a butter-knive with +5 against golems?!? B-) > A small sugestion is to treat the body and the armor the same. Yeah. Thinking about it, I already do that: I treat it as if it were some quilt under armour (that is, high resitance against impact, and very low resistance against penetrating damage). What I'm actually interested in, is your opinion on my ideas how to re-structure the classes. May I ask you to have a look at it? Ragnar-GD ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193 |
|
From: Miguel A. B. L. <mig...@ho...> - 2005-08-31 14:23:50
|
> > Well you are perfectly right here, but what im hoping for in the end, is > > some form of script language after all. A script language that perhaps >shud > > issue the keywords we define in the xml files... and for what I know... >it > > was for that purpose I started this discussion. > >I don't see the scripting language coming up soon with a java-based server. >Java is it's own scripting-engine, and perhaps a bit too slow on its own to >carry another scripting-language. On the other hand, it depends very much >where and how we would use scripting anyway. I have tried to keep myself out of writting on this thread, because I suffered from featuritis on the past. I have read them all and breathing slowy I have repeated KISS, KISS, KISS... Java as you say is a script language, so where is the problem? We already have the script language, maps right now are loaded as script files. Java can be our script language. I myself tried to do something like that on June for making creature creation simpler but I failed. I mainly see two problems on the examples I have been reading: 1) There is no difference between an item and a class of items, we want to define attributes for a class of items, but then we need to fill world with items themselves. 2) NPC and creatures has a logic that MUST be coded. IMHO Java should be the way to go. Jython showed on mapacman that it was too slow to be considered. Regards, Miguel PD: I will try to reply a summarize post when I read all the thread. |
|
From: Anders A. <and...@ho...> - 2005-08-14 11:23:49
|
>Hi, danter, > > > I went away and made a draft xml file for items. > >Good work! thx ;) >And we have to make sure we understand which amount of work such an >approach produces - hardcoding in java-classes may look inflexible, but it >sure is efficient and effective none the less. The perfect database for a >game is not relational and SQL-based like MySQL, but object-relational, as >it would provide much more efficient with storing characters, items, assets >and the like. That may be true, but personally I want to move ALL data out of the source really, and thats what professionals writing game is suggesting you shud do with the data aswell (ever read game programming gems?, I have read some of it, and there they suggest you shud have all data outside the source). For peps having problems compiling the source (im one of them, bet im not the only one) moving the data out of the source would be a blessing aswell... not to mention the time we would save not needing to recompile the source every time you make a small change. >So, my suggestion is to keep xml in mind, but not start with it right away, >as the time required for implementation may delay the implementation of the >engines ability to carry varying rulesystems. I agree here, but xml is an accepted standard, and the reason I made the draft one is so that we can start with it somewhere, im prepared to rewrite the entire file if it turns out the approuch is entierly wrong. >At first, I suggest to generally accept the concept of "engine - ruleset - >game". In a perfect world this could mean: > >engine - Marauroa, with plugin "tilebased rpg" (which is, at the moment, >still a part of Stendhal) >ruleset - i.e. legacy D&D, or "a gamedesigners homebrew" >game - i.e. Stendhal, or Stendhal-GD > >Any xml-format should reflect this separation IMHO, so I took a look at >your ideas from this point of view: It would be nice if you mentioned some of the ideas you had in mind, so that we can try to adopt them into this file... or change it so that it will work for both rulesets. > > DOOR: Well, a Key usually only works on one door. This is a door id that > > is needed when dealing with a key object, the X'es shud be replaced with > > the ID the door has. > >This attribute is too specific. There might be other items than keys that >have a specific target. Maybe it should be "target-id" or something >similar. Hehe, to be honest I wasnt really satesfied with this name... but I didnt know what I shud call it at the time I made it, target-id sounds like a good name... and it will be the object the commands will try to react against ;) > > > Some things I also had in mind is some path to the graphics the item > > shud use, since two swords can look the same but has different names and > > different powers. > >Yeah, I was thinking of this as well. But this should be an optional field >to be filled by a gamedesigner, as different designers may assign different >meanings to different items, depending on background-story or such. Well, what I had in mind was what shud be displayed in like the inventory, nothing like animations and such. It would be strange if you didnt define any graphics for the item, cause in the game it would probably be a completely transparent object... Remember this file is descriptions for items alone, and not some quests or story segments, that naturally dosnt have any graphics at all. Even if the designer didnt define any graphics him/herself, it shud probably have some "dummy" graphics shown anyway. >Best solution would be, that items are independent from assets (aka >sprites, icons and animations), so that each item can be assigned any asset >for display. sprites and animations yes... dunno bout icon thou... read above for details. Anders Asplund aka danter @ irc.freenode.net #arianne _________________________________________________________________ FREE pop-up blocking with the new MSN Toolbar - get it now! http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/ |
|
From: Matthias T. <mt...@gm...> - 2005-08-16 20:34:46
|
Hi danter,
> [...] but personally I want to move ALL data out of the
> source really,
This is my opinion too. In fact, this will save us a lot if trouble when
we try to use a scripting system for the rules (some time far in the
future).
Your xml-file is a good start. More important is a description of the
NPC's (enemies and townpeople), as they are better implemented atm.
Something like this:
----8<----
<?xml version="1.0" encoding="ISO-8859-1"?>
<data>
<npc>
<enemy name="wolf">
<property name="tileid" value="4"/>
<property name="hp" value="20"/>
<property name="atk" value="2"/>
<property name="def" value="4"/>
<property name="speed" value="0.5"/>
<property name="size" value="1"/>
<property name="logic" value="patrol"/>
</enemy>
</npc>
</data>
---->8----
> <item id="spiked_shield"
> <type equip="left_hand" equip="right_hand">
> <stats def="14" atk="2">
> </item>
I would prefer named properties instead of hardcoded attributes:
<item name="spiked_shield">
<property name="equip" value="left_hand"/>
<property name="equip" value="right_hand"/>
<property name="def" value="14"/>
<property name="atk" value="2"/>
</item>
If we forward the properties to the rules they can even deal with
properties not known at compile time. The props of any entities are
stored in hashmaps anyway...
Regards
Matthias
|
|
From: Anders A. <and...@ho...> - 2005-08-18 17:11:15
|
Hi mtotz, it's good to have sugestions from one of the coders, so that the "script" can be adopted with good parsing and coding sollutions. >>[...] but personally I want to move ALL data out of the source really, > >This is my opinion too. In fact, this will save us a lot if trouble when >we try to use a scripting system for the rules (some time far in the >future). Exactly, and since this disscussion has started, I get a feeling it's not that far until we have a basic scripting system implemented. >Your xml-file is a good start. More important is a description of the NPC's >(enemies and townpeople), as they are better implemented atm. Something >like this: Well, it defently served it's real purpose, and that was to start a disscussion about scripts and future data sollutions. >----8<---- ><?xml version="1.0" encoding="ISO-8859-1"?> ><data> > <npc> > <enemy name="wolf"> > <property name="tileid" value="4"/> > <property name="hp" value="20"/> > <property name="atk" value="2"/> > <property name="def" value="4"/> > <property name="speed" value="0.5"/> > <property name="size" value="1"/> > <property name="logic" value="patrol"/> > </enemy> > </npc> ></data> I was thinking about making an xml file about NPC's and monsters (or creatures as the directory on cvs is called), but I wasn't sure how I was supose to start. Your example is a good start but there is some unclear stuff, and also some stuff missing. For instance, it seems like you are trying to create data for an NPC (the ones running around in the city) but have made data for a monster in it's data space. I also wonder what the tileid value is for, is it some id for the sprites?. What I mostly is missing, is a value that tells if the monster is hostile or not (an Elk is'nt hostile in nature, but can be very dangerous if you provoke it) if that is'nt something that shud be included in the logic (wich I guess is a name of a script?). I am also missing an xp value telling how much xp you get for killing the monster, or even some NPC's. Anyway, I was thinking that it might be possible to put both NPC's and monsters in the same file, but for NPC's we shud have a value that tells what dialouge script it uses, and for vendors/shops a form of shoplist they use. In that way we can have standard NPC's (example: healers) and even standardised shops/vendors, wich even in reality has just about the same stuff to say anyway, "Hello mister/missis, is there anything I can help you with?" Here is a my modefied version of mtotz xml "script", it features the wolf and an NPC we all shud know about ;) -------------------- <?xml version="1.0" encoding="ISO-8859-1"?> <data> <!-- I changed the enemy to creature, since an enemy is normally hostile on default --> <creature name="wolf"> <property name="tileid" value="4"/> <!-- Still wonder what this is for --> <property name="hp" value="20"/> <property name="atk" value="2"/> <property name="def" value="4"/> <property name="speed" value="0.5"/> <property name="xp" value="360"/> <property name="size" value="1"/> <property name="logic" value="patrol"/> <property name="hostile" value="yes"/> <property name="noise" value="Aooooooouuhhh!!"/> <!-- this is just an ascii string, showed above the creature sometimes ;) --> </creature> <npc name="Carmen"> <property name="tileid" value="?"/> <property name="hp" value="100"/> <property name="atk" value="0"/> <property name="def" value="0"/> <property name="speed" value="0.5"/> <property name="xp" value="0"/> <property name="size" value="1"/> <property name="logic" value="wander"/> <!-- well she wanders back and forth... must have a different logic then the wolf... --> <property name="dialouge" value="WelcomerNPC"/> <!-- Name on the dialogue script in use --> <property name="shoplist" value="HealingShop"/> <!-- Well Carmen dos'nt sell any healing items, but we need an example! --> <!-- Maybe she would be a good NPC to put a healing shop on aswell :-P --> </npc> </data> -------------------- In this way, the NPC/creature xml file would almost just be an overview on what monsters/NPC's that exist. >---->8---- > > > <item id="spiked_shield" > > <type equip="left_hand" equip="right_hand"> > > <stats def="14" atk="2"> > > </item> > >I would prefer named properties instead of hardcoded attributes: > ><item name="spiked_shield"> > <property name="equip" value="left_hand"/> > <property name="equip" value="right_hand"/> > <property name="def" value="14"/> > <property name="atk" value="2"/> ></item> > >If we forward the properties to the rules they can even deal with >properties not known at compile time. The props of any entities are stored >in hashmaps anyway... > Some of the keywords has about the same meaning (property and type for instance), but this way seems more logical and easier in a code wise view, so I have tryed to adopt these changes to my old xml file. I am mostly interested in comments on the key and bow item sollutions I made. -------------------- <?xml version="1.0" encoding="ISO-8859-1"?> <data> <!-- Item that exists in current official server version --> <item name="armor"> <property name="equip" value="body"/> <property name="def" value="1"/> </item> <!-- Item that exists in current official server version --> <item name="shield"> <property name="equip" value="left_hand"/> <property name="equip" value="right_hand"/> <property name="def" value="14"/> </item> <item name="spiked_shield"> <property name="equip" value="left_hand"/> <property name="equip" value="right_hand"/> <property name="def" value="14"/> <property name="atk" value="2"/> </item> <!-- Item that exists in current official server version --> <item name="club"> <property name="equip" value="left_hand"/> <property name="equip" value="right_hand"/> <property name="atk" value="7"/> </item> <!-- Item that exists in current official server version --> <item name="sword"> <property name="equip" value="left_hand"/> <property name="equip" value="right_hand"/> <property name="atk" value="14"/> </item> <item name="2Hsword"> <property name="equip" value="both_hands"/> <property name="atk" value="24"/> </item> <item name="bow"> <property name="equip" value="both_hands"/> <property name="depend" value="arrows"/> <property name="special" value="ranged"/> <property name="atk" value="10"/> </item> <item name="key"> <property name="command" value="lock"/> <property name="command" value="unlock"/> <property name="target_id" value="XXXX"/> </item> </data> -------------------- Regards Anders Asplund aka danter @ irc.freenode.net #arianne _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ |
Thanks for helping keep SourceForge clean.
X