You know what would be helpful in the creation of both strategy games and extremely detailed RPGs? A parse() proc, that would have one argument... a text string, representing a command a player of the game could've typed in. For instance:
mob.parse("buy 20 robots")
would attempt to call a verb called "buy", belonging to mob, with arguments of 20 and robots. This presupposes, of course, that such a verb exists and these are valid arguments. If this is not the case, parse() could simply do nothing and return 0.
I realize this seems superfluous when you consider that verbs can be called the same as normal procs... but I'm thinking more along the lines of player-directed macros/triggers/automatic upkeep. Game designers could provide as little or as much support for such things, by parsing text values stored in player variables or lists at predetermined intervals/hooks. In any game with long-term planning, it could be made so that players could set up their mobs to perform certain actions every turn/day/year/whatever... or not, if the game maker chooses not to include such functionality.
This doesn't really apply to any of my current projects, but it would be cool for some I'd like to do... it's basically an idea I came up with while kicking around ideas with somebody who was trying to figure out how to add triggers to their game.
[EDIT]
Now that I think about this... I wonder if there isn't some way it could already be done... I need to read up on the call() proc and perhaps the args list.
ID:137601
 Sep 15 2001, 7:56 pm (Edited on Sep 15 2001, 8:14 pm)
|
|
|
Sep 15 2001, 7:59 pm
|
|
Nadrew
  |
I think that would make buying/selling a whole lot easier.
|
No more so than the existing macro system, I should think... and even then, only if the game designer were to give you the ability to "save" favorite commands and use them again.
You do understand that I'm not suggesting an improvement/addition to the interface (macros have a lot of potential for abuse, after all), merely the ability for programmers to provide such an improvement? The other benefit (which I forgot to mention) is that this would allow designers of long-term strategy games to give players the ability to have their interests represented while off-line or away (assuming the player's mob remains extant in the world while the player is not connected)... if each player has a list of commands that will be executed every turn they're not there, a well-managed kingdom/country/what-have-you could be run by someone who only logs in once or twice a day and fiddles with things. | |
LexyBitch wrote:
mob.parse("buy 20 robots") This is a good idea, and I believe it's been suggested a few times in the past. The main obstacle is that the parsing is actually handled client-side, so when you type "buy 20 robots" the client sorts things out before sending the data along to the server. The client has to know about the various argument types and, to a degree, the accessibility in order to handle the command-expansion and verb popups. So the easiest way to pull this off would actually be to send the string back to the client, parse it along as if the user had typed it in, and then send it back to the server! Of course that would only work if the user actually had a client. The more powerful alternative would be to build in an equivalent server-side parser. I wouldn't expect that anytime soon, but I do envision that in the long term we will have this kind of functionality. Dan may have a different opinion :) Now that I think about this... I wonder if there isn't some way it could already be done... I need to read up on the call() proc and perhaps the args list. Yep, that's the first thing that came to my mind. Unfortunately, it doesn't quite work. With a bit of effort, one could probably hack together a library that can handle, at least, verbs attached to the player, but that might be kind of tricky too. | |
God, that's what I've been trying to program all week...
I was going to try to make my own command of the sort, it isn't working yet... when it is, I'll put it somwhere. | |
Tom wrote:
LexyBitch wrote: The current behavior when someone types something into the command line that the program doesn't recognize as a verb or a predefined macro is to send an error message to the output screen. What if this error could be trapped? For example, suppose we had a built-in proc called InputError() that would contain the text the user tried to type in. Then if you wanted to parse instructions as text, you could override the built in error routine: InputError(input) This would be generic enough that we could customize other behavior if we wanted it, such as suppressing all input error messages, or creating a custom message of some sort. | |
have you guys thought of messing with the say() verb?
mob verb say(T as text) view() << "[src.name]: [T]" src.parse(T) proc parse(T as text) switch(T) if(T == "Buy number something") blah blah with this, you can check to see what the person said by passing the T argument into the parse proc. If you were smart enough, you could set up some procs and some variables to handle this much easier rather than haveing tons and tons of if statements. Its just an idea to hold you over until they decide to do it or release the real deal. | |
Excellent, though I'd guess that a lot of us have figured that out already. :)
I use, for my say-listen: mob verb/say(message as text) oview() << "[src.key]: [message]" for(/mob/NPC/N in oview()) N.listen(message) mob NPC vendor proc listen(var/saidtext) if(saidtext == "Vendor Buy") dispwares() if(saidtext == "Vendor Sell") dispsellprices() farmhand proc listen(var/saidtext) if("Hire Farmhand") offeremploy() if("Fire Farmhand") if(src.owned_by = usr.key) fire() | |
I fail to see how that would be any better or worse than any other way of doing a custom parsing system... but it actually wouldn't work at all for what I'm talking about, which is calling any specified verb manually, but at a later time... when the player isn't even necessarily connected... essentially, letting players soft-code their own simple AI (of course, the interface for inputing these, and the triggering events, would have to be hard-coded. But this instruction would at least give the designer the option.) In games with few commands, it's easy to implement a hard-coded one, but I'm thinking of ones with hundreds of verbs and such.
| |
If y'all recall, I was working on a parser library (back when I had a place to live), which was nearly complete and approached the sophistication of your typical pay-for-MUD parser. I can try to finish that up when I'm able, though it may still be a few months before I release the first version.
Z | |
i never said it would be better than the custom method, i just thought i would put something.
i would be delighted to see a parse code, where a user could call verbs with arguments, but i would not for them to be able to create their own, sounds senseless to me. Maybe they could macro the parses, like buy 10 apples. Where they would just macro an ALT + KEY = "say "buy 10 apples" thats the only customization i see out of this, and i think that all of the parse codes should be hard coded, meaning only they can spit out possibilities that you put in. If you didnt want them to buy 100 apples at one time, they wouldnt be able to. --FIREking | |
The fact that you can't see a use for this says more about you than it does about the idea. I don't think you understand the basic concept here... parse() would be a proc, just like any other proc. Obviously, players wouldn't be able to do anything that you, the designer of the game, didn't want them to be able to do with it. If you coded your entire game without once using the parse() instruction, there would be no parsed macros whatsoever. If you only wanted a few select commands to be called in this manner, you could (and can, as things stand right now) simply make a proc which calls those commands with the appropriate arguments at the appropriate time.
The point of the hypothetical parse() command that I've envisioned is it would allow the designer of a game to allow the player of a game to create server-side (rather than client-side) macros/triggers of any and all verbs... if more verbs are added later, the designer wouldn't have to do any additional coding to fit them into the macro parser. Yes, there's a lot of games where this would be pointless, or inappropriate, or ruin the game balance... but three things to consider: One, it's impossible to prevent people from using macros... people can macro "buy 10 apples" right now. Even if DS doesn't support them, someone would make an external application that sends output to the DS window. The solution to preventing macro-abuse is to make it so macros cannot be abused: build in delays, minimum rest time, etc. Two, if you give players inducement to use server-side macros, processed internally, you can exert more control over the macros. Three, think about long-term strategy games, where the player's physical representation/avatar isn't a humanoid figure that vanishes when they log off, but a city or starship that remains in extant in the world. These are the sorts of games that probably would have hundreds of different command combinations, and the games that would benefit most from the ability of players to set up server-side macros. Take Leftley's Completely Generic Strategy Game. Imagine a version that's more long term and more complicated... where you can log off and leave your city behind on autopilot, come back and reclaim it later. You could set up macros to plant in the spring, cultivate in the summer, and harvest in the fall. You could set up macros to build houses when you run out of houses, or even just at certain intervals if you expect a steady growth. You could set up macros to buy 10 apples whenever apples are on the market, not just when the player is logged on. Obviously, not even the cleverest macros/triggers are a substitute for a thinking, reacting human brain... but the existence of such a thing would make it easier to set up a semi-real-time-strategy game with a persistent world that doesn't require players to log on every hour in order to survive. | |
Imagine a version that's more long term and more complicated... If it got any longer, I'd have to supplement the in-game inheritence and succession system with a real-world inheritence and succession system. That aside, yes, this sort of thing would be a very good idea for pretty much any strategy game of the sort, unless you wanted the emphasis of the game to be on having m4d m1cr0m4n4j1ng 5k1llz. | |
