24 Aug, 2014, Rarva.Riendf wrote in the 21st comment:
Votes: 0
Kelvin said:
you probably won't resemble Diku/Tiny under the hood, and you won't have the benefit of all of those mailing list posts and snippets that are floating around for your older alternatives. It's a substantial barrier to overcome, so resist the temptation get too stiff with the license, if you want people to actually use Havoc.


Just put all those snippet directly in the codebase you provide, so no need for them at all.
Mostly what are those ? maps, groups, clans etc etc, stuff a new codebase should provide per default anyway.

ps:and for the license: yeah go BSD…all the other are way to complicated/legally annoying to even consider.
and if you really do it for the good of humanity go WTFYW license.
06 Sep, 2014, Famine wrote in the 22nd comment:
Votes: 0
plamzi said:
Chaos said:
Seems awfully handy to have the same data format in your program code and your persistence layer, not have to work around remapping of not-directly-compatible types, not have to update a schema to add fields. I dunno.


This is exactly what an ORM does. I use node-sequelize. Right now, it supports 3 dialects, and NoSQL databases are not among the ones supported. But nothing stops them from adding support for MongoDB, for example, in the future.

When you use an ORM to achieve persistence, your server is basically agnostic to the exact type of storage being used. It can be virtually anything. You can switch relatively painlessly from one supported storage method to another, if you ever need to.

I haven't used any NoSQL databases yet, but from I've read they have one thing in common in that they limit the ways to manipulate the data directly. That's the main reason I haven't looked beyond my standalone MySQL server. I like being able to create entities, and correct any issues that can be corrected via one-off queries, directly in the database. It would be a major pain for me to give that up.


ORM is more a benefit for you, the developer, and not the solution that is storing your data. You're basically cutting out the storage solution out the picture for greater benefit of you, the developer. This leads to poorly designed databases in most cases, which lead to bottlenecks in your application among other things like being restricted on which storage solutions are available to you such as NoSQL solutions.

I'm not saying NoSQL is right for your application, but if you're finding yourself not having a clear plan of how to query your data, then it makes a little more sense why you're still using MySQL. However, if you can clearly define how your application is utilizing that data, then ad-hoc is out the picture and you can have greater freedom to pick a storage solution that will be the best option for your application going forward.

Personally, I would use a NoSQL solution, especially Couch as someone suggested already. The performance, scalability, object creation and more is likely far better for an online game than your current solution. Ad-hoc queries shouldn't be a restriction to your application because there should be a clear plan on how your application is going to utilize the data before it's implemented. Anything else can be fed into a SQL solution that allows for ad-hoc queries such as there is for reporting needs.
08 Sep, 2014, plamzi wrote in the 23rd comment:
Votes: 0
Making good progress:

* Path-finding and basic click-to-move implementation for the web client.

* Portals / traveling between zones / jumping within zones.

* A few thousand roaming mobs with persistence to test performance. Lots of optimizations there.

* Shopping is ready / easy / awesome.

* Increasing modularity, a dozen new commands.
16 Sep, 2014, plamzi wrote in the 24th comment:
Votes: 0
Screenshot frenzy:



Pictured above: a splash image, click-enabled graphical overhead map.



Pictured above: click-enabled help files, zone portals, the new quest system, varying font sizes via MXP



Pictured above: more commands including sample class spells, the attack picker for setting default defense, melee, and skill attack



Pictured above: More Unicode symbols, score / stat screen, dynamic reload of code and updating live objects after modifying files



Pictured above: Powerful syslog, mobprog that wiki's what players say, inventory items showing worn, carried, and an item up for sale to others
16 Sep, 2014, arholly wrote in the 25th comment:
Votes: 0
Looks really nice. And when will this be available? :)
17 Sep, 2014, plamzi wrote in the 26th comment:
Votes: 0
arholly said:
Looks really nice. And when will this be available? :)


Engines are at full throttle just because it's exciting stuff, but there's no real rush (who needs another codebase, right?) and I want to release a complete package. That means not just all the components of a playable game that people can think of, but also building tools, and maybe even an integrated version of the web app. Ideally, I want to get to a point where I can have a playable game with modest content that can be player-tested. There are tons of issues that will only crop up with actual players, and I really want to make this a strong offering.
17 Sep, 2014, arholly wrote in the 27th comment:
Votes: 0
Like after you login to your account, if instead of clicking on your character, you type play <character name>, it seems to crash or boot you out.
19 Sep, 2014, Nathan wrote in the 28th comment:
Votes: 0
plamzi said:
arholly said:
Looks really nice. And when will this be available? :)


Engines are at full throttle just because it's exciting stuff, but there's no real rush (who needs another codebase, right?) and I want to release a complete package. That means not just all the components of a playable game that people can think of, but also building tools, and maybe even an integrated version of the web app. Ideally, I want to get to a point where I can have a playable game with modest content that can be player-tested. There are tons of issues that will only crop up with actual players, and I really want to make this a strong offering.


Offering a playable game would go a long way to gaining interest even if it's just an alpha/beta.



Kind of unrelated, but it would be nice if, instead of (or in tandem) with releasing codebase people would consider drafting design documents with the aim of providing sufficient information for other people to take a shot at implementing the systems that have been created for the game in question. Code is great, but with so many people writing their own projects I don't know how much real progress is achieved (i.e. how many projects produce workable results and results in actual games you can play/make). It would be wonderful if any time someone wanted to write their own mud codebase they could look at, and, if they wanted to, pick a design for the sort of system they need (combat, magic, economy) and implement that instead of having to go through a design and implementation phase for many systems just to produce a working game by themselves. It need only be ~5 or so of each and wouldn't need to be vast, just a basic design of the components of the system and how they interact. – Not a perfect example, but KaVir's telnet option handler is really of the most use to a couple of particular, pre-existing muds and would require some significant work to refit the concepts to a custom mud in, say, Java or some other "modern" language that isn't C or C++.
19 Sep, 2014, plamzi wrote in the 29th comment:
Votes: 0
Nathan said:
Offering a playable game would go a long way to gaining interest even if it's just an alpha/beta.


Technically, I'm not that far away from a playable game (2-3 weeks). But I want to ship it out with things like crafting that some people think of as an advanced system (in its best implementations, it is). I also want to organize and document a set of utilities that will allow even solo devs to put a solid world together. I know that's a tall order but I don't really care about bragging that I wrote a codebase, I want it to actually help folks.


Nathan said:
It would be wonderful if any time someone wanted to write their own mud codebase they could look at, and, if they wanted to, pick a design for the sort of system they need (combat, magic, economy) and implement that instead of having to go through a design and implementation phase for many systems just to produce a working game by themselves.


I don't personally enjoy the design and planning stage. Or rather, I normally go through that stage while coding rather than with just a pen and paper. So the kind of assistance I will provide to people who are looking for some "preset" design ideas is living documentation–the actual early-stage implementation of a certain design.

Each of the major components in Havoc will be a working example, with a good number of inline comments, and a good number of existing content that can be simply expanded by those who don't want to reinvent things but want to jump into content creation right away.

Folks who are not happy with how the built-in quest system works at the ground level can still learn from it before ripping it out or modifying it. Components are designed to be very modular, so unplugging an existing one and plugging new ones is going to be very easy. Even the world can be ripped out together with the movement logic, and replaced with a different one.
20 Sep, 2014, Nathan wrote in the 30th comment:
Votes: 0
Well, good luck then. It just seems like plenty of things get stuck at the stage where they might be playable, but don't get "released" because something like crafting or some other system isn't finished to dev satisfaction (and might never be).

You're making my point there for me. Plenty of people, probably most of us, write the code for things as we go. Thus, even though there may be a significant degree of intentionality to the design it is probably inscrutable to others. It is a lot of work to analyze an existing implementation and reduce it to the concepts behind it. The point of making what amounts to a design document is to talk about the design without entangling it with the implementation. Obviously seeing the evolution of code over time is useful but someone who arrives later when it's all finished will have a much harder time – I'm just saying that in general it would be nice for people who write codebases to not have to work entirely from scratch (or piece together forum posts to get the total gist of what someone is saying when they talk about a system they made) when designing/implementing systems. Not everybody starts out or ever becomes a fabulous coder. A lot of time can be spent beating your head against a wall to do the same thing someone else has already done…



That ripping the world/movement bit sounds kind of excessive. How many times has someone tried to make the "ultimate" framework? I'll take your word about the comments, but there is lots of very poorly commented code out there. Commenting is not particularly fun, especially post coding.
20 Sep, 2014, plamzi wrote in the 31st comment:
Votes: 0
I don't have a problem with people not releasing code because they don't think it's ready. We don't exactly suffer from a shortage of codebases, we suffer from a shortage of full-featured, comprehensive, dev-friendly, and builder-friendly solutions.

You're right that other people's code can be difficult to read and abstract concepts from. When I write foundational code like the Portal app and Havoc, I make many choices to keep the code more transparent, and add comments where that's not possible. But as far as what you seem to be looking for, you may be better off looking at books and blogs on virtual world design. It is not the focus of any actual game engine to teach readers general concepts they can use in their own projects (why would it be). Its goals are to make it easier for people to understand how to utilize that particular engine by providing extendable architecture and docs and examples specific to that architecture. If you want to glean design lessons from it, you can't expect a reverse-engineering roadmap–that's work you have to do, and it's the kind of work that qualifies you to write your own codebase.

There are specific reasons why I'm making the world modular. The included world will be comparible with the Battle of Wesnoth maps and map editor. That would be great for people who don't mind a grid-based world with hexagonal movement and portals, but some folks may want to have (or import) a traditional mud world with denser rooms, static room descriptions, doors, etc. So I'm toying with the idea of including a plugin that can read a Circle / Diku world.

In general, grouping similar code is very helpful even for those who are not planning to rip it out. It means less time spent looking for the place you need to modify to change how characters move, e. g.
20 Sep, 2014, Idealiad wrote in the 32nd comment:
Votes: 0
plamzi said:
The included world will be comparible with the Battle of Wesnoth maps and map editor.


Great idea plamzi.

@Nathan, that was sort of the idea behind the PseudoMUD thread I started, http://www.mudbytes.net/topic-4549 . Looking back on that I wasn't nearly organized enough to pull it off but I still think the idea is decent.
20 Sep, 2014, cody wrote in the 33rd comment:
Votes: 0
plamzi said:
I don't have a problem with people not releasing code because they don't think it's ready. We don't exactly suffer from a shortage of codebases, we suffer from a shortage of full-featured, comprehensive, dev-friendly, and builder-friendly solutions.


Firstly, I've lurked here off and on for a while (cannot say how long and with the sleep issues I have I wouldn't trust much beyond 1 - 1 .. okay it isn't that bad but you get the idea) but created this account the other day. The reason is I wanted to respond to this thread and at some point maybe other threads (note: I am notoriously bad with forums so I apologise if I am slow in response or if it appears I vanished - I may very well have). Second, what I'm quoting is true gold (hence quoting it). It is why I've not really announced beta to the players interested, to a rewrite (from scratch) of an old MUD. Technically it can be played but there's so many new ideas that have recently come to mind (through discussions and otherwise) that I feel it would be bad to give the go ahead and then oh, now there's these changes that affect game play so let's start testing all the new features (more like: new systems) all over again … I think not. That is not only unfair to the players (and it is a fair bit arrogant too, to waste their time like that - they can play IF they like but to tell them it is ready for X is not fair when it IS NOT ready) it isn't helpful to anyone involved. Bottom line, source code should be clean, stable and easy to maintain (they go together). Don't go for half-complete changes… that is just bad practice that will eventually bite you hard (that or you're very lucky).

Now then, the reason I actually wanted to respond to this thread is your idea of persistence world. I then read just a few minutes ago, something that made me think you're only doing it for testing purposes (system resources etc.). Which is it ? Or both ? The reason I ask is the MUD I am work on has persistent loading. Given that node.js is well, javascript, I assume it is another platform entirely (web based? phone? I think I saw in the past you were working on MUDs compatible with phones, forgive me if I am showing my delusional self…) so therefore different ways to store things and different goals. Either way, here's my thoughts (which may need changing based on platform etc., and or what you like/dislike):

1. Make it persist until otherwise told not to (and/or you delete the actual data). The way I do this is not at all perfect but it is low on the priority (that is a better way - it works). It is similar to diku zone resets only it is 'to be saved' queue (and different timer). Furthermore, only (and I find that the old world, unique as it is, is a curse and a blessing… I want to do more than rooms but at this time that is what it is due to the old world) rooms marked as an instance are saved and only save what needs to be saved (e.g., don't save name or descriptions unless they changed, don't save door states unless they changed, don't save monsters if …. you get the idea). And an instance is where the flaw is: once marked it it isn't going back to unmarked. To continue that flaw, if a zone reset (or boot up of MUD) loads a NPC or object in to the room, then it is "modified" and so is an instance. Yes, that part really is bad (but the trick is: finding the right balance of always persisting and not). Even with its flaws though, boot up happens quicker (especially when a forest of elves has been mostly slaughtered, a task I most enjoy even though I love elves more than other races).
2. I won't discuss how to store it. That's an implementation specific decision and there's pros and cons of all sorts of formats (file formats, database type, …). I think it is a moot point even, as long as it is easy to save and restore (backup restore that is) well and that it simply works (and is efficient).
3. One thing I would suggest not doing is saving where players are, on a reboot. There's some pros and cons each way. I think it is more a problem if you tried some copy over (and potential for players abusing the fact there was a reboot and now I'm dead…). If you do save them though, on a reboot, then I'd think to not really piss them off, you would want to have them load once they log back in. If there is one thing I learned early on, it was this: certain players are going to find a problem with anything and it is best to BE one of those players in thinking (because if you can predict how they are going to think and act, you can prevent the abuse right away). Yes, I really do go that way (but there's more to it than just to avoid problems… it is just in my nature to find flaws in things and that indeed includes flaws in my own thinking).
4. Aside from that, whether it is a reboot, server (hard reboot or even shutdown due to extended power outage) reboot or crash (what's that ? … better worded: a test mud, a staging mud and a playing mud is very useful here), indeed the world loads fine, as is. I quite like it. I think it is well worth the effort and it really makes things more real for something that actually is not all that real.

Oh, I'm also notorious about one other thing: I write a lot, usually.
20 Sep, 2014, plamzi wrote in the 34th comment:
Votes: 0
Idealiad said:
plamzi said:
The included world will be compaTible with the Battle of Wesnoth maps and map editor.


Great idea plamzi.


Hopefully not the only good idea, heh, but I do count it among my best ones. A single person can lay out a world of 10-20k rooms easily over a weekend. It will be an empty world in need of more love, but at least their project won't die in the "looking for a builder to write 20k room descriptions for me" stage.

There are additional neat things about this choice: if someone uses the overhead graphical map, it's not just pretty, it also enables click-to-move, so the hexagonal layout ceases to be an issue–no-one ever needs to type another directional command. If a dev hates hex and doesn't want a graphical map, they can just not use it, but still use Wesnoth's graphical Map Editor, whose maps can easily be interpreted as a grid of squares (they are, under the hood).

I'm not yet sure what in-game building will look like. I do think it would be useful to at least be able to micro-edit some existing content. But, it's already possible to edit the database and have the live code pick it up, and MySQL Workbench is better than any telnet-based OLC I've ever seen. This is one of the big reasons I decided to stick with MySQL – I test-drove the latest Mongo Client UI's and they are just not there yet.


cody said:
…your idea of persistence world. I then read just a few minutes ago, something that made me think you're only doing it for testing purposes (system resources etc.). Which is it ?


High persistence is not just for testing / development, I want it to be one of the major selling points. It's much higher than a typical Dikurivative, but not full like in some MUSH codebases. I have a very specific balance in mind: something performant enough to handle PK-heavy and PvE slaughter fests, while still making it very easy to persist all the key elements of a world so that crashes and reboots would not make a difference, and so that constructive and destructive environments would be within reach.

cody said:
Given that node.js is well, javascript, I assume it is another platform entirely (web based? phone?…


Here is a worthwhile read: http://nodejs.org/

cody said:
The way I do this is … similar to diku zone resets only it is 'to be saved' queue (and different timer).


Timers are involved in persisting data that changes too quickly for every state to be recorded, or data where precision is not really necessary. A prime example is the exact location of roaming NPC.

However, I deem certain things to be important enough for their state to be recorded every time it changes, e. g. movement of items from one place to another.

The advantage of an async framework like node.js is that you can fire off a save to persistent storage of a changed state without blocking everything else, and just set it up to notify you if the save failed for some odd reason (database died?).

cody said:
Furthermore, only (and I find that the old world, unique as it is, is a curse and a blessing… I want to do more than rooms but at this time that is what it is due to the old world)


I feel the exact same way about the Bedlam (CircleMUD) world. Even with everything loaded up into an RDBMS it was unnecessarily difficult to add NPC follower saving, for example, and so it is one of my goals with Havoc to bake in such things.

cody said:
3. One thing I would suggest not doing is saving where players are, on a reboot. There's some pros and cons each way. I think it is more a problem if you tried some copy over (and potential for players abusing the fact there was a reboot and now I'm dead…). If you do save them though, on a reboot, then I'd think to not really piss them off, you would want to have them load once they log back in.


I know what you mean but only because my current MUD happens to have a similar game logic so restoring PC positions almost always brings heartache. However, it helps to recognize that these kinds of problems are created by existing mechanics that don't have to exist, and by the absence of mechanisms that could exist.

For instance, in the example world for Havoc (which I will go on to develop as a game called Aaralon) there will be enough persistence in place to avoid any "mob full heal + zone resets and locks you in" effects of a crash. And it will be made easy to set different starting points for PC's based on details such as whether their last saved position was too long ago, whether it is deep inside a zone that they need to re-do for some reason, etc.

One the main uses of higher persistence is to minimize the negative impact of crashes and reboots on the player experience. If the game server reboots, it is certainly not the players' fault, and the less you penalize them for it, the better. If you are able to restore all important parts of the world state, then there's no intrinsic downside to restoring the positions of reconnecting players within that world as well.
21 Sep, 2014, cody wrote in the 35th comment:
Votes: 0
First, apologies on the quoting. Trying to close the day and I am not familiar with any forum so not really sure on the best way to quote messages that have quotes themselves.

Quote
cody said:
…your idea of persistence world. I then read just a few minutes ago, something that made me think you're only doing it for testing purposes (system resources etc.). Which is it ?


High persistence is not just for testing / development, I want it to be one of the major selling points. It's much higher than a typical Dikurivative, but not full like in some MUSH codebases. I have a very specific balance in mind: something performant enough to handle PK-heavy and PvE slaughter fests, while still making it very easy to persist all the key elements of a world so that crashes and reboots would not make a difference, and so that constructive and destructive environments would be within reach.

I agree. For me it is to make the world much more realistic and fun. A reboot is for maintenance purposes (code update, world too although not as required in the MUD I work with) but the world shouldn't be cleared out unless actually desired (and a new feature, as far as I am concerned, is not a reason for the world to be reset entirely). As for crashing, while it certainly isn't fool proof (humans and all…) we have over the years really done well here and list and pointer tracking is a big help (how much so depends on what specifically is being tracked and why). The rewrite is only like diku in that, the world is from the old circlemud based (heavily modified but still). So if there were limitations in the old way we have to migrate the world over time. The code is easy enough but changing one thing that might seem harmless is not necessarily harmless (it is interesting how many used features that shouldn't have been features to begin with, that you can find when improving things). Aside from that, it is all unique zones (not stock circle zones) as before, but it is built with the standard room structures (as in in the world… exits including non-linear exits, exits that lead to the same room, etc.). Instead of C it is in C++ (for many years I resisted OOP and I finally got over that and I wanted to do this for me, to test my capabilities (and the only one that knows me, that was surprised, is me)). Scripts are only forward compatible but with a special utility I wrote and also a long sed script (essentially not even close to backward compatible). Some other scripts have to be rewritten completely. Pretty much everything is new but with a similar game-play (or enough for old players to get it… combat system is very different for example, because we wanted it "our own", but still it is auto-combat rounds, not counting spells and skills (which is all scripted and that is how it is in the circlemud version too, our own system has only one similarity in the standard system: names of some spells)).

Quote
cody said:
Given that node.js is well, javascript, I assume it is another platform entirely (web based? phone?…


Here is a worthwhile read: http://nodejs.org/

I'll open it in a new tab for a read another day (I should be off soon). I was more thinking of the host environment (and more specifically: I understand that not everything applies in every scenario and that is good… would be boring otherwise).

Quote
cody said:
The way I do this is … similar to diku zone resets only it is 'to be saved' queue (and different timer).


Timers are involved in persisting data that changes too quickly for every state to be recorded, or data where precision is not really necessary. A prime example is the exact location of roaming NPC.

However, I deem certain things to be important enough for their state to be recorded every time it changes, e. g. movement of items from one place to another.

The advantage of an async framework like node.js is that you can fire off a save to persistent storage of a changed state without blocking everything else, and just set it up to notify you if the save failed for some odd reason (database died?).

True. I do think however (but again, this is an opinion and nothing more) that mobiles roaming is something that should be saved (because they are part of the world and its state). Objects are the same way. On the other hand, yes, it isn't to say that everything is saved instantly. That would indeed be a penalty. I also have it save the world state on reboot (and shutdown) so even if nothing was pending (or put another way, it would be some time until something was saved again), it is saved. And yes, that is why I have a queue… I don't want it delaying things as it would. One thing I do not save yet is something I implemented many years ago (in the C version). Example: objects that hold rooms (imagine a container). Or another example: a dragon with number 555 (thin air) but more than one loaded. Each has its own stomach, right? So what if something is in one of the dragon's stomach (say an object or… a charmed monster is swallowed)? That doesn't mean it is in the others. And indeed if the dragon moves to another place and is then slayed, whatever was in its stomach is now in the current location (and the stomach no longer exists). Objects could be this way too (objects can move as well and I am not referring to the object is picked up and then moved by a character, I am getting at the object moving by itself). Well I save the mobiles/objects, I don't save what is in them (no builder has taken advantage of it yet but in the end this will have to be decided on and I'm more inclined to indeed save this). Let me change that a bit, objects holding objects are indeed saved. But what is not saved is if a character is an object (contrived example: toybox), then if there is a reboot or someone destroys the object, the dimension collapses and you end up in another dimension.

Quote
cody said:
Furthermore, only (and I find that the old world, unique as it is, is a curse and a blessing… I want to do more than rooms but at this time that is what it is due to the old world)


I feel the exact same way about the Bedlam (CircleMUD) world. Even with everything loaded up into an RDBMS it was unnecessarily difficult to add NPC follower saving, for example, and so it is one of my goals with Havoc to bake in such things.

For me it was more like: what didn't exist or what existed in ways I would rather have different. While I have the world (which is rather important) I really wish some things were different. So it is an over time progression that is required. This is related to the next point, actually.

Quote
cody said:
3. One thing I would suggest not doing is saving where players are, on a reboot. There's some pros and cons each way. I think it is more a problem if you tried some copy over (and potential for players abusing the fact there was a reboot and now I'm dead…). If you do save them though, on a reboot, then I'd think to not really piss them off, you would want to have them load once they log back in.


I know what you mean but only because my current MUD happens to have a similar game logic so restoring PC positions almost always brings heartache. However, it helps to recognize that these kinds of problems are created by existing mechanics that don't have to exist, and by the absence of mechanisms that could exist.

For instance, in the example world for Havoc (which I will go on to develop as a game called Aaralon) there will be enough persistence in place to avoid any "mob full heal + zone resets and locks you in" effects of a crash. And it will be made easy to set different starting points for PC's based on details such as whether their last saved position was too long ago, whether it is deep inside a zone that they need to re-do for some reason, etc.

One the main uses of higher persistence is to minimize the negative impact of crashes and reboots on the player experience. If the game server reboots, it is certainly not the players' fault, and the less you penalize them for it, the better. If you are able to restore all important parts of the world state, then there's no intrinsic downside to restoring the positions of reconnecting players within that world as well.


Well yes. It was more like: if for instance you had something like copy-over (which I do not for a variety of reasons) and you load players in the same way and they are in combat, then the player could abuse the fact (or try to), if they die (but I don't tend to reboot the MUD while players are on so it is somewhat a moot point). But if you try to load combat over a reboot, there is going to be potential for abuse. In an ideal world one could have everything in sync even across reboots but that implies no reboots, for some things (the moment the MUD Is reloading, even if to old state, there is a disconnection in parts of the world… for that time, and some things happen more often than that time frame, if that makes sense. If not though: this is more of how far you want to go with definition/view/etc.). As for loading in to the same place, well I can see the good and bad each way. I think this is one thing that is worth experimenting with but definitely not one way or another is the best without that experimenting (with your player base, environment, etc.). The safer solution is to their normal start area, however, at least for reboots (if they quit somewhere well that is another story entirely). One downside is while only potential, still to be considered: you reboot and player is loaded in to the same area. They're currently low on health and right as they log on, a huge demon walks in on them and attacks. Are they prepared for this? Will they blame you if they die? Not all would but some would (I know 100%).

And you're absolutely correct, if you remove the flaws you can do a lot more. That's what I was getting at with the way builders designed their zones and therefore the world is a curse and a blessing (also: they might have been limited by lack of functionality which means you now have to not only implement the functionality - good thing - but then migrate the old world to the new way). I think we're on the same page here but maybe wording it differently.

As for abuse, well, you're always going to have some which is what I was getting at as if you can think like them (or perhaps you act like them when you play ?) you're a lot safer (but not safe). So in the end, I think we have persistence for different reasons (or at least some reasons differ). For me it is for reboots (regardless of players on, if a shop keeper had been robbed, say, they're going to not now have the money that was taken from them); in the event of a crash I have more to worry about (this is sort of like how often do you save your work? What is too much? What isn't?). And indeed, getting locked in or out of a zone does suck and always has to be considered. True that if it crashed then whatever was last saved would indeed be restored, but obviously some of it will not because it isn't saved every moment in time.

Hopefully this makes sense. I admittedly can barely see (and will be heading to bed momentarily) and I also often have very different views from others (but I wouldn't change it). This is what is great though: this idea is very much up to implementation and what works here might not work there (and any combination is possible). I think I was interested in sharing my views but with the caution of there isn't a right or wrong so much as more ideas increases chance of further ideas which … well, you get the idea.

Oh, something else: for my horrible vision (the things people tell me they have no problems seeing, and I'm wearing my glasses… it always amazes me that I can't see what they are talking about), the screen dump earlier in the thread looks quite impressive. Keep it up. Whatever anyone wants to call it then, is their choice, but for me it shouldn't be what it is called that matters. What matters is what it is and whether you are happy with it and the players are happy with it. And something tells me you are indeed happy with it. I'm not big on graphics but that's a personal preference (I have more fond memories of the Atari 2600 for example).
23 Sep, 2014, plamzi wrote in the 36th comment:
Votes: 0
Support for password reset tokens, more clickables:



Ideas about countering the snowball effect:



Persistent channel logs. The quest log. Example progress bar in the stats:



In other news:

* Leveling up works! (Only for testing, sorry.)

* Optimized roaming NPC's, added NPC's that produce and sell goods.

* Integrated Websockets server and raw socket server running side by side.

* Spell / skill buffs that persist and expire properly. Consumable items.
24 Sep, 2014, Nathan wrote in the 37th comment:
Votes: 0
Looking nice. The different fonts really have a nice effect.

@plamzi 'Apothecar'? Is that deliberate or is there supposed to be a 'y' at the end?
27 Sep, 2014, plamzi wrote in the 38th comment:
Votes: 0


* Multiple tabs drawn and refreshed very simply using MXP frame tags.

* Database editor (Express Admin) for content creators.

* Coding IDE w/ integrated shell (Codebox)
27 Sep, 2014, roguewombat wrote in the 39th comment:
Votes: 0
I really dig the map based movement, and the links embedded into the display are nice. One usability improvement, at least for the way I was playing, would be for the input text field to regain focus after I click on something else in the UI.

Also, I'm not sure what's up, but with the latest Google Chrome on OS X I had a difficult time using that windowed interface. Stuff just didn't seem to move properly, and it was confusing to me how split up the various types of output were.
28 Sep, 2014, plamzi wrote in the 40th comment:
Votes: 0
roguewombat said:
I really dig the map based movement, and the links embedded into the display are nice. One usability improvement, at least for the way I was playing, would be for the input text field to regain focus after I click on something else in the UI.

Also, I'm not sure what's up, but with the latest Google Chrome on OS X I had a difficult time using that windowed interface. Stuff just didn't seem to move properly, and it was confusing to me how split up the various types of output were.


Thanks for the feedback! The more of it I get, the better the result will be.

I made the cursor return to the text input field after a mouse click. Right now, the UI + Havoc is at a stage where typing is still needed for some very common actions. That I hope will change before it ships.

I believe part of the issue you were having with the split output was the same as what I experience. By force of habit, when I type 'who', I expect the input to show up in the window I typed it. This seems very much related to the above. I think that through use, even veteran mudders will realize they don't have to type who if they have a tab with that info that automatically stays up to date.

Ultimately, I want to get to a point where 99% of the time the reason to type something would be to chat, and nothing else. All that, while still remaining very text-centric (at least for the open source release milestone).

I'm guessing the oddities you experienced had to do with my tinkering in the server and in the Portal app. I find Chrome faster than FF, even on OSX. Of course, it's a bit of a memory hog so if you're not using it on a speedy machine, your experience may differ.

A web app windows UI is probably always going to feel a bit twitchy compared to native OS. Just have to see things in perspective though. Nothing compares to the portability and reach of a website. And the portal app is already at a point where it does things even desktop clients can't. Losing some responsiveness should not feel like much of a trade-off. I'm hoping that by packaging in a very nice web app that can basically integrate 90% of the content creation flow, people are going to start getting tempted to cut the telnet cord.
20.0/76