20 Sep, 2014, KaVir wrote in the 22nd comment:
Yes, such systems can be potentially complicated to implement, particularly if you're not familiar with games that use them.
There's a good article on the subject on Gamasutra: User-generated content: When game player...
Well worth a read.
There's a good article on the subject on Gamasutra: User-generated content: When game player...
Well worth a read.
20 Sep, 2014, Ssolvarain wrote in the 23rd comment:
Nathan said:
Sure, you can modify properties and do stuff like that, but you generally never get an object you can interact with like you could one created by hardcode.
I think that attitude is largely descended from the fact that stock scripting tools are very primitive in diku-rivatives. I've said it a thousand times, and I'll probably say it a thousand more, but when you add variables, and ways to interact with them, it really opens the door on what is possible with soft coding. I hear LP muds and other dikus with modified scripting tools, like Lua, are also very powerful and flexible.
And I'm sorry my previous response was so harsh.
22 Sep, 2014, quixadhal wrote in the 24th comment:
Yep, and an LPMUD is a different kind of beast entirely.
What you think of as "hard coded" and "in the driver" is a phenomenon of DikuMUD's and similar systems where the game logic is indeed hard-coded into the driver binary. In such a system, you can have "hooks" to soft-code routines in your favorite mini-language (custom, or embedded lua/python/etc), but you are still limited by what hooks exist. To add a new system, you have to modify the driver and generally reboot, possibly also update data as it is reloaded.
An LPMUD uses the driver only for I/O, networking, and interpreting the LPC soft-code. The entire game, is coded in LPC, from the parser to the concept of rooms, npcs, etc. The driver provides only minimal support to allow you to do this, in the form of a few callbacks (new connection, closed connection, data arrives, etc), and a few functions you can use to manage your game code… such as the ability to schedule an LPC function to be run at a (potentially) future time.
So, where your Diku-style game would have a main loop that handles combat, healing, weather, etc… the LPMUD does that in soft-code. Combat might be centralized, or it might be entirely based on the things doing the attacks… IE: you swing your sword and then schedule a call_out() to swing again in weapon-speed seconds.
The advantage is, you can code anything you want, on the fly. Each LPC object is isolated, so screwing up your combat system only breaks combat, not the whole game. Screwing up a single orc's code breaks that orc, not the whole game. The disadvantage is, of course, performance… and the difficulty of writing a mudlib from scratch. That means you either find one you mostly like and cannibilize it, or you suffer with figuring out how to write your own.
What you think of as "hard coded" and "in the driver" is a phenomenon of DikuMUD's and similar systems where the game logic is indeed hard-coded into the driver binary. In such a system, you can have "hooks" to soft-code routines in your favorite mini-language (custom, or embedded lua/python/etc), but you are still limited by what hooks exist. To add a new system, you have to modify the driver and generally reboot, possibly also update data as it is reloaded.
An LPMUD uses the driver only for I/O, networking, and interpreting the LPC soft-code. The entire game, is coded in LPC, from the parser to the concept of rooms, npcs, etc. The driver provides only minimal support to allow you to do this, in the form of a few callbacks (new connection, closed connection, data arrives, etc), and a few functions you can use to manage your game code… such as the ability to schedule an LPC function to be run at a (potentially) future time.
So, where your Diku-style game would have a main loop that handles combat, healing, weather, etc… the LPMUD does that in soft-code. Combat might be centralized, or it might be entirely based on the things doing the attacks… IE: you swing your sword and then schedule a call_out() to swing again in weapon-speed seconds.
The advantage is, you can code anything you want, on the fly. Each LPC object is isolated, so screwing up your combat system only breaks combat, not the whole game. Screwing up a single orc's code breaks that orc, not the whole game. The disadvantage is, of course, performance… and the difficulty of writing a mudlib from scratch. That means you either find one you mostly like and cannibilize it, or you suffer with figuring out how to write your own.
Random Picks
I might be, but then a lot of the codebases out there are based on it either as derivatives or regarding ideas and concepts. Also, many systems also don't offer the same degree of control through softcode that they do if you hard code things. That is probably because some letting the player fiddle around freely and do things that could break the game is generally frowned upon. In the vending machine case it might very hard in lots of systems for the object itself to create more objects. Sure, you can modify properties and do stuff like that, but you generally never get an object you can interact with like you could one created by hardcode. LPMud could probably be considered an exception, but it seems pretty complex to make anything happen in that. You definitely can't start from scratch and hope to get something complete in a reasonable amount of time and using someone else's system has it's own separate learning curve in addition to the one to learn how LPMud works. I don't know about hardly anything about MOO, but then who actually uses that?
I really don't consider a crafting system to be "content creation". The vast majority, if not all, crafting systems are ultimately limited to pre-created recipes that the game developer decided on and which are artificially limited. In Minecraft you are only confined to game physics and the limitations of building with blocks, but otherwise you can build any structure and, within the height limits, any scale of it that you want. Granted that you have far less control when it comes to making tools. It might be stupid to do so, but you can't actually make a sword with a metal grip or a solid stone sword. There's that and you also can't add arbitrary enchantments easily. You'd have to go through a lot of metal or a lot books to get an iron sword with the desired magic/enchanted attribute. I'd be willing to bet that most games with player housing at all limit you to pre-designed homes that you can only expand in pre-designed ways such that there is nowhere near the level of control in Minecraft. I.e. you can have a house, but you can't have some crazy castle or fortress or anything floating in the sky no matter how much money you have or whether magic would allow levitating/floating that much mass.