26 Sep, 2014, jeli wrote in the 1st comment:
Votes: 0
I'm looking to make a new game from mostly scratch but I wanted a nice framework to start from and I've come across these two options. On the one hand, I have to learn LPC on the other, I have to learn Python. Any advice?
27 Sep, 2014, Lyanic wrote in the 2nd comment:
Votes: 0
DSD is more developed than Evennia. Python is a better language than LPC. I'm not sure either is a good choice if your goal is "from scratch".
27 Sep, 2014, Idealiad wrote in the 3rd comment:
Votes: 0
From scratch I would go Evennia. Incidentally are you interested in collaborating? I've been looking at making a game with Evennia.
27 Sep, 2014, quixadhal wrote in the 4th comment:
Votes: 0
It also depends on the architecture you want.

I don't know the details of Evennia, but I believe it to be the standard integrated style, where the driver itself (coded in python) handles networking, file I/O, and the majority of game system code, and it provides "hooks" to run scripted code when various events happen. If you have people helping you create your game, this limits their ability to modify core systems, since to make non-trivial extensions, they will need shell access, or at least direct access to restart the driver.

LPMUD's, on the other hand, feature a split driver and mudlib design. The driver itself (coded in C) handles networking and file I/O, but all the game systems are coded in LPC, running under the driver. That means you can recode anything in the game, including things which are considered "core" concepts like rooms, on the fly, without needing to hand out shell access, and without needing to restart or recompile the driver.

Where the LPMUD design shines is when you have a good sized team and can honestly say you expect to have more people being added in the future. Because everything important can be coded in LPC, there's never a need for anyone except the admins to have access to the driver, and any mistakes in any subsystem are isolated to those systems. Making a bug in the AI code for your orc will only make your orc stop working, not the whole game.

However, most MUD's these days are one-man projects, so that benefit really doesn't mean as much. I would suspect you'd enjoy coding in python more, and there are very nice IDE environments out there that will make such coding easier and more fun than the classic IDE of bash + vim. :)
28 Sep, 2014, Cratylus wrote in the 5th comment:
Votes: 0
Install both and see which one you wind up working on more.

Or give more information on what your priorities are so people can comment on what you're looking for rather than what they would guess a random person might like.

-Crat
28 Sep, 2014, Nathan wrote in the 6th comment:
Votes: 0
jeli said:
I'm looking to make a new game from mostly scratch but I wanted a nice framework to start from and I've come across these two options. On the one hand, I have to learn LPC on the other, I have to learn Python. Any advice?


Reading this -> https://github.com/evennia/evennia/wiki/... might be useful if you haven't already.

@Quixadhal
On the surface your assessment is probably true, but, based on the stated features, etc I think there may be some distinctions that bring it closer to LPMud than Diku.

Quote
Evennia is in principle a MUD-building system: a bare-bones Python codebase and server intended to be highly extendable for any style of game. "Bare-bones" in this context means that we try to impose as few game-specific things on you as possible. So whereas we for convenience offer basic building blocks like objects, characters, rooms, default commands for building and administration etc, we don't prescribe any combat rules, mob AI, races, skills, character classes or other things that will be different from game to game anyway. It is possible that we will offer some such systems as contributions in the future, but these will in that case all be optional.


Basically the way that reads, there are no built-in systems. So, it's not really anything like Diku in that regard. You write your own module that does something somehow. I guess whether you have to modify any of the core code that you download to make your system works matters as to whether you are just modifying the main stuff or plugging stuff in somehow. If you don't have to modify the core to add a combat system and it's not strictly hooking into things other than the player's inventory, etc then it could be pretty modifiable. In fact if health and armor values are merely properties set on the player by your combat system then the game logic is fairly independent of the core.

Quote
Using the full power of Python throughout the server offers some distinct advantages. All your coding, from object definitions and custom commands to AI scripts and economic systems is done in normal Python modules rather than some ad-hoc scripting language. The fact that you script the game in the same high-level language that you code it in allows for very powerful and custom game implementations indeed.


Since this suggests that scripting and coding for the game are almost one and the same and python is interpreted and not compiled, the degree to which things can be changed on the fly is probably a bit different. If you had access to the python shell (or a interface of some kind to it) and the file system you could probably add new kinds of objects and modify things from within the game even.

I probably don't understand it well enough, but suppose LPMUD was written in LPC and was otherwise the same. I think there is some similarity in these systems, except that LPMUD takes that separation further up the chain. Particularly in as you describe that

Quote
That means you can recode anything in the game, including things which are considered "core" concepts like rooms, on the fly, without needing to hand out shell access, and without needing to restart or recompile the driver.


I assume that by shell access you mean something like 'UNIX/Linux shell access' which means you have fairly direct interaction with the operating system on the machine? If so, I might argue that you are handing out 'shell access', but only to an in-game shell that has very specific utility. You might argue that the LPMud driver is a bit like a virtual machine/computer designed exclusively for making text based games.

P.S.
Sorry if I am rambling.
29 Sep, 2014, quixadhal wrote in the 7th comment:
Votes: 0
In a sense, an LPMUD is a bit like a VM. The softcode (LPC) is interpreted within the game driver itself, and all game code is written in LPC. As such, the driver has no concept of anything related to your game systems… it simply runs LPC code, and provides network and I/O callbacks, and a few utility services. How intertwined your mudlib code is, is entirely dependent on your own design.

For example, you might have a traditional room-based game, and decide to add an ocean with naval combat that uses a coordinate-based system. If your game driver is more like a DikuMUD, this means you have to modify the driver code, and add lots of stuff to check which system you're in, and make all the various movement and combat code adapt to both mechanics. A single error will usually crash the game.

If your game driver is more like an LPMUD, you'd add the new systems in parallel with the existing ones, and make your new ocean area inherit those new systems instead of the room-based ones. If you made a mistake, your ocean area might crash, but it won't have any effect on the rest of the game. In short, players not in the ocean area won't ever know anything happened.

My understanding is that Evennia is halfway between these extremes. The driver is coded in python, and it provides mechanisms for python functions to be called when a trigger event happens… and those triggered function calls can be modified at will, without rebooting. However, making a large-scale change like the above example will likely still require modifying the core code to add the new hooks.

Now, I'm not saying that has to be a bad thing. If you're working with a small team, and all your team members are trustworthy, it's not really an issue. In the "golden age" of MUDding, it wasn't unusual to have an LPMUD with a core team of 3 or 4 admins, another half dozen senior wizards, and then a dozen or more underlings…all of whom could code things in the live game, but the core systems were restricted to the admins, and the senior wizards typically had full content access. The underlings were usually restricted to a single area, as well as their own pet projects.
29 Sep, 2014, Kelvin wrote in the 8th comment:
Votes: 0
There isn't going to be any measurable difference between what you can achieve in-game with Evennia vs LPMUD. Even the shell access thing is mostly a non-issue, in that developers can work in separate dev environments and commit/push to a shared repository. If you cared to, you could easily automate deployment without shell access. Evennia can reload without interrupting connections.

It's very team-specific, but my observation has been that while a new MUD may have multiple staff members, there's almost always someone who is way more invested than the others in doing the development work. We all have finite attention spans and burn out in varying amounts of time, but your challenge is to pop out a playable game before you reach burnout. If you (the primary developer) can do that faster with LPMud or Evennia, make speed and ease of development one of your absolute highest priorities. If your codebase isn't a joy to work with, you aren't going to spend your fun/hobby time on your game for very long. Similarly, not everyone can be happy working on a MUD for three years before launching it, so if you are one of those people that has to have positive reinforcement sooner, pick what you can move most quickly with.

This was mentioned by Cratylus, but this really comes down to whether you (jeli) want to learn LPC or Python. I'm obviously biased, but I find Python to be a joy to work with in a MUD setting. I can easily use my favorite editor and dev environment (checkout PyCharm if you don't already have a favorite), plus the huge selection of tools, modules, blog posts, and documentation out there in Python land. And it's useful for far more than MUDs.
30 Sep, 2014, Nathan wrote in the 9th comment:
Votes: 0
I used PyDev (basically gives you a Python IDE in Eclipse) in school a couple years ago and that is far better than a text editor and the python shell. It's a bit of a pain to set up, in my opinion, and not for you if you don't like eclipse to begin with, but at least you don't have to keep buying the next version (either brand new or through some "renewal" license).
01 Oct, 2014, Kelvin wrote in the 10th comment:
Votes: 0
I came over to PyCharm from PyDev. PyDev reeks of Eclipse's Java tilt. There are reminders everywhere that you're not using a Python IDE, you're using a Java IDE with a Python plugin. The Django integration isn't nearly as good, either. This is a big deal for projects like Evennia.

PyCharm has a free community version that's still very good: http://www.jetbrains.com/pycharm/downloa...
03 Oct, 2014, Nathan wrote in the 11th comment:
Votes: 0
From what I suppose it makes sense if you rely on Django, but I don't know that it's really Java tilt so much as Eclipse or maybe Sun/Oracle tilt. Maybe you just don't like Eclipse? Someday i'll get around to trying it, but the free version of Pycharm sounds like a highly limited gimmick to get you to buy the full thing more than a valid standalone just for python. Note the "Full-featured" vs. "lightweight" and the fact that the free version doesn't support Django, or at least that's an implication of the statements.

Quote
Professional Edition Free 30-day trial

Full-featured IDE for Python & Web development
Supports Django, Flask, Google App Engine, Pyramid, web2py
JavaScript, CoffeeScript, TypeScript, CSS, Cython, Template languages and more
Remote development, Databases and SQL support, UML & SQLAlchemy Diagrams

Community Edition FREE

Lightweight IDE for Python development only
Free, open-source, Apache 2 license
Intelligent Editor, Debugger, Refactorings, Inspections, VCS integration
Project Navigation, Testing support, Customizable UI, Vim key bindings

* http://www.jetbrains.com/pycharm/downloa...

The PyDev (http://pydev.org/) website does suggest getting it bundled with LiClipse (http://brainwy.github.io/liclipse/). Although that's probably most useful if you don't already have Eclipse installed/don't want to install the usual Eclipse. Of course, their site is a bit unclear on whether you need to buy a license or not.
03 Oct, 2014, Kelvin wrote in the 12th comment:
Votes: 0
Nathan said:
From what I suppose it makes sense if you rely on Django, but I don't know that it's really Java tilt so much as Eclipse or maybe Sun/Oracle tilt. Maybe you just don't like Eclipse?

You only need look through the icons/menus to see the Java remnants. I still see these when I use PyDev with the C++ extensions. It'll always be a Java-first IDE. That's where the majority of its contributors spend their time, it makes sense that it'd be their core competency. I've spent lots of time trying to cull the clutter, but it's weighed down by its legacy.
Nathan said:
Someday i'll get around to trying it, but the free version of Pycharm sounds like a highly limited gimmick to get you to buy the full thing more than a valid standalone just for python. Note the "Full-featured" vs. "lightweight" and the fact that the free version doesn't support Django, or at least that's an implication of the statements.

Why is it highly limited? By Django support, it means being able to do stuff like run the devserver from within the IDE, which doesn't personally appeal to me at all. You're probably not going to be doing this with Evennia, anyway. It still understands Python and Django just fine, though. And what it does do, it does much better than PyDev as as a whole. The refactoring is worlds better, the searches are in a different plane, and its default linter/PEP8 checker is a lot more sanely configured out of the box. The "Jump to definition" more consistently handles third party libraries, which has always been iffy in PyDev for anything but the most trivial dependencies. PyCharm's virtualenv and general interpreter site-packages awareness is really good, too.

Source: Made my living writing Python for the last 8 years, many of those with PyDev, and now the last three with PyCharm. These are my tools of the trade, I spend at least 40 hours a week with them.
07 Oct, 2014, Griatch wrote in the 13th comment:
Votes: 0
@OP

Without having tried Dead Souls, I imagine the two are rather different to work with. Whereas I, as the lead dev of Evennia, favor the use of Python (both hobby-wise and professionally) I would suggest downloading both to test. Toy with each system, read the documentation and hang with the respective communities before you decide.

Nathan said:
Since this suggests that scripting and coding for the game are almost one and the same and python is interpreted and not compiled, the degree to which things can be changed on the fly is probably a bit different. If you had access to the python shell (or a interface of some kind to it) and the file system you could probably add new kinds of objects and modify things from within the game even.

You can add and build normally from inside an Evennia game. The difference comes in changing more advanced features or when creating new "types" of objects. Game entities in Evennia (be they in-game objects, scripts, players, channels or what have you) are all stored and modified in normal Python modules as pretty-much-normal Python classes. These classes are loaded dynamically and are used to "decorate" the database-bound objects they are linked to.

So Evennia allows modification of objects' very source code - also while the system runs. This modification is generally done in the Python code though and not from the game input line. Once code has changed, applying it generally requires a server reload - but no players are disconnected by this and it's usually no more than about a second's hickup for the users.

Evennia does allow you to run python code directly from the command line - it's really useful for debugging and testing. Since this is a full-fledged Python command parser it is not something to offer to random people on the net however, so it is not equivalent to LPC in that sense.

quixadhal said:
I don't know the details of Evennia, but I believe it to be the standard integrated style, where the driver itself (coded in python) handles networking, file I/O, and the majority of game system code, and it provides "hooks" to run scripted code when various events happen. If you have people helping you create your game, this limits their ability to modify core systems, since to make non-trivial extensions, they will need shell access, or at least direct access to restart the driver.

LPMUD's, on the other hand, feature a split driver and mudlib design. The driver itself (coded in C) handles networking and file I/O, but all the game systems are coded in LPC, running under the driver. That means you can recode anything in the game, including things which are considered "core" concepts like rooms, on the fly, without needing to hand out shell access, and without needing to restart or recompile the driver.

Where the LPMUD design shines is when you have a good sized team and can honestly say you expect to have more people being added in the future. Because everything important can be coded in LPC, there's never a need for anyone except the admins to have access to the driver, and any mistakes in any subsystem are isolated to those systems. Making a bug in the AI code for your orc will only make your orc stop working, not the whole game.

Evennia actually splits its "driver" from the game implementation too. It's just that in our case the "driver" is the whole tree of sources making up our distribution (so it may be more accurate to call it a "library" with an API). Game-specific code (the stuff added by a dev creating their own game) is kept separate from the Evennia "driver" code itself (i.e. the stuff you download from us). The "core" stuff includes the networking/protocol code that makes Evennia tick but also acts as a toolbox and API for building a game. In there are handlers for adding new commands, managing timers, game-channels, locks and other things that are game-agnostic. It also holds some default content in the form of default commands and base game entities, all of which are intended to be overloaded with your custom implementations. The actual modification and addition of custom entities for a given game happens separately, only importing and making use of the core from the outside.

Our philosophy is that you as a game dev should not need to change the stuff we supply in the repo (well, unless you are contributing upstream). It's of course easy to modify the core since it's all Python but generally you shouldn't need to - it's all pluggable to a very great extent.

The shell access difference is true. Evennia does not offer a safe full-fledged in-game coding language in the same way as LPC is. Full access to Python is not something you want to give to untrusted users. This is a deliberate design choice on our part. Our philosophy here is that actual game system development is better done in a proper text editor (I am a VIM man myself), your team collaborating and updating the game via a modern version control system. Only the gatekeeper merging the new code into the server needs shell access.

Committing buggy code can of course cause crashes (you are not working in a sandbox in the sense as I guess you do in LPC) but Python's error management is very good and most of the time you will find that Evennia will log a graceful traceback rather than crash horribly if your code is a mess.

Beyond that, the Evennia command-design system is flexible enough for devs to design extremely powerful yet safe build commands for builders who want to make their objects a little more intelligent or interesting. But that said - it is of course possible to implement SoftCode or LPC in Python should anyone feel ambitious and really want that functionality for their Evennia game!
.
Griatch
Random Picks
0.0/13