Base Code Question
-
So I had been tossing around the idea of an MUD with a very role play intensive idea that was more realistic in that if your character died, it was dead and you had to make a new one. If the body wasn't burned by survivors then it would come back as a zombie mob using all your old gear and skills so there was potential there.
I know a /bit/ about MUX code, but have never really done much beyond building a few areas and mobs for circle and diku way back in the day.
So my question is, what MUD code base would be the easiest to do this with. Or at least the easiest to learn to code since it might require some serious coding changes (maybe even hardcode, which I have never really messed with).
Maybe this would be an RPI (But I really dislike that term) but it's outside of my comfort zone for coding. So advice help on what code to get started with etc would be grateful.
-
@Lithium Personally, if I was trying to do the same thing, I probably would give evennia a try. I think python is a lot easier to learn than much more complicated soft code even though it's a hard code language, so if you are in the situation of like trying to adopt tinymush style lisp-like language or taking an evennia game out the box and customizing it in python, I think it'd be much less of a headache going with python. As I recall, evennia out the box already comes with a MUD like split of a player object vs the character object they are puppeting, so I don't think it would be so bad to go from that to leaving corpse objects on the ground that animate.
-
@Apos said in Base Code Question:
@Lithium Personally, if I was trying to do the same thing, I probably would give evennia a try. I think python is a lot easier to learn than much more complicated soft code even though it's a hard code language, so if you are in the situation of like trying to adopt tinymush style lisp-like language or taking an evennia game out the box and customizing it in python, I think it'd be much less of a headache going with python. As I recall, evennia out the box already comes with a MUD like split of a player object vs the character object they are puppeting, so I don't think it would be so bad to go from that to leaving corpse objects on the ground that animate.
Agree. With what I've read and seen this would probably be your best bet for the type of game you're thinking of making. Python isn't that hard of a language and it gives you the added benefit of actually learning a language that can be used outside of just a small sub set of games that use a super out dated system.
-
I don't want a separation of character object and player object. That seems really unnecessary to me. I also have at least some experience coding in MUX so don't want to try and learn a new language right now.
This might be something as easy as a fix to say Diku or Circle or whatever that is as simple as turning off respawning, where when a character dies they create a mob with their gear and level and the zombie subtype that lives in the room the character died in.
-
-
@faraday said in Base Code Question:
@Lithium As I understand it, the character/player separation in Evennia is configurable, so you don't have to use it. Maybe @Griatch can confirm?
When he gets around, but it was one of the things I was prodding about both on the channel and in the documentation. Griatch may recall my comments of "holy hell, you can do it all three ways whhaaaaaaat?"
To make things more confusing: There is always a player and always a character, but it's configurable that the player login connects you immediately to one and only one character, making it appear to the player that there's no difference.
-
You don't have to use the player/character separation, no. Evennia has four different modes for how you relate your account (aka player) and the character you puppet.The default is that you log directly into a character like in traditional engines. In that mode, the player/character separation is pretty academic and mainly useful for staff who wants to easily puppet NPCs.
Of course, having one login (player, aka account) for playing multiple in-game characters is very useful in many types of games. But if multi-playing is not desired one can certainly just ignore the separation.
Edit: Ninja'd by @Thenomain
.
Griatch -
To all the ones spouting about the joys of Evennia and all, that's great, but:
@Lithium said in Base Code Question:
I also have at least some experience coding in MUX so don't want to try and learn a new language right now.
^
That. Just throwing that out there.
-
-
@Griatch said in Base Code Question:
Language famliarity is certainly a valid reason for going with a particular system. After reading that I would honestly not had commented in this thread if @faraday had not specifically asked me to clarify something.
.
GriatchOh no, not you. You were summoned.
-
@Lithium Diku and Circle are both written in C and neither of them use MUX softcode that I know of. If you wanted to make a more traditional MUX, I probably wouldn't say anything, but with your desire for a highly coded game, evennia is very much a better choice if you don't know C.