Due to our recent downtimes, due either to our fault and Amazon’s, I’ve put together a status website at http://status.myth-weavers.com that, for the moment, has our twitter feed. If the site should go down, and we’re unable to get it fixed in a short period of time, we’ll redirect traffic there so people can get updates on what’s going on. You can also follow us on twitter or facebook and get updates that way.
I felt our discussion on private games was very productive. I also felt expressing our reasoning and the thought that goes behind every decision would be helpful for users, so I’m making a blog post out of a post I made in the thread.
It started when we were discussing solutions to an issue we often have to fix – someone is subscribed to a game forum, the parent game has become private, and the user is not a member of the game. They don’t have any recourse for unsubscribing from the forum. It moved into under what conditions we should automatically unsubscribe, alternate link locations so users could handle it themselves, and why the unsubscribe link isn’t displayed within the subscription row (it was there before, and after much to-do and many requests, was removed).
We started talking about other issues that private games cause. Every time we are adding functionality, or modifying behavior that relates to forums, threads, posts (and their child objects, sometimes other, seemingly unrelated things), we have to consider private games, and ensure we’re calling the right permissions checks at the right times, and for only the right pieces of information. That doesn’t even get into efficiency – a page, like a search, may draw in data from many games. To make things more efficient, we have to break some logical/conceptual barriers, and that makes maintaining more difficult.
This discussion has made me realize we already do a poor job of enforcing private games as envisioned. Arella’s post reveals that, and drives in the point about how this feature’s tendrils do, and need to, reach so many parts of our codebase, including the bits we forget about.
There’s also the issue (for those siding with private games) that archived games become totally public. I’m not sure everyone realizes that, or how it affects their stance on the issue. I’m not sure if it means we shouldn’t make game content public when the game is archived. Doing that presents another very large coding and resource usage issue for us.
There’s philosophical issues with private games. I really like the notion of public, social gaming. Private seems to be the default for people who don’t want others posting in their games (despite how absurdly unlikely that is), or who are setting up, but don’t necessarily need the game to be invisible.
I like the idea of people being able to read each others games, learn from each other, and to take and share ideas – whether they be ideas of content, or ideas of style and delivery and storytelling devices and technique.
Private games mostly, but also threads, and tags (and closed ad threads), present difficulty or impossibility for people wanting to retrieve or reference posts they’ve made. I really feel that when people play together, they’re essentially writing collaborative fiction (with some rules to make things interesting). Even if we did get permissions right and they still had access to everything they personally wrote, they no longer have access to all of the context, all of the other posts that gave theirs any meaning. I feel that’s wrong. I feel that ‘getting this right’ would either mean ensuring they have access to all content up to the point they left or were removed, or forever having read access to all the game content.
Private games hide gaming history, for good or for ill. It means there’s less reference material for a potential gaming partner to get a feel for your style. The less information people have for building games with compatible members, the higher chance of them failing. While I don’t personally feel a high turnover rate is a problem in principle (play is about play, not necessarily getting anywhere), I understand a lot of the concerns and the frustration of abandoned games. When there’s been so much investment that just isn’t matched, or that is cut short by incompatibilities, it causes a lot of doubt and makes one not want to play.
People also seem to be using games, specifically private games, as information repositories – not as actual games, and this is not their purpose and it is something that is frowned upon quite a bit. That stuff belongs in the wiki, or a google doc or your own website.
There is a fair bit of work involved in tearing the guts of private games out. Turning it off and making it unavailable would just be a stop-gap, it’d need to be totally removed to eliminate all of the code bloat. So, even if we were to decide to do it, it’s not something I’m about to just jump into.
We discussed how to balance these concerns. We came to a conclusion that removing private games entirely was the best way forward. This is a conclusion, not a decision to remove private game functionality, and I feel the distinction is important.
We know we are not the final arbiters of the scope of function of the tools we make. Members find creative (sometimes destructive or annoying) uses for tools that we’d never thought of, or the tools fill needs and fix problems we didn’t know existed. That’s why we made this thread.
Issues of protecting one self, or others, from discomfort, jealousy, even downright paranoia made me pause. I know these sorts of issues are low-frequency, and are often perceived, but when they are real they are a problem. It’s funny… I am an actor and was just discussing the openness, mutual vulnerability, trust, and comfort that exists between actors – in rehearsal and in performance. We talked about how having non-participating observers, especially in the rehearsal process, can destroy that feeling of comfort, limiting the potential of the performance and the growth of the player. As much as play by post is collaborative writing, it is still role playing, and is therefore just as much acting, and improvised, at that! There are decisions and feelings you might close yourself off to if you don’t feel absolutely comfortable. There’s a big part of me that wouldn’t feel right if I knew that possibilities (within our rules, of course!) were not being explored because there was a sinking feeling one might be being watched.
Issues of managing one’s online identity also really struck a chord with me. About a lot of things, I’m generally a pretty private person. At Myth-Weavers, because of the collaborative nature of all content here, we are opposed to deleting accounts and/or deleting content (sheets, posts etc). I understand that makes managing your online identity difficult. I also understand why people wouldn’t want to be associated with certain games, or gaming at all. Aside from the people on the site, people can find your MW activity via web searches. There is real discrimination around the world for the hobby, from the standard stereotypical bullying to being passed up for jobs and other opportunities. At the same time, I also don’t want to encourage people to have multiple accounts on the site to enforce anonymity or separation of activities – resource usage, statistics gathering, moderation issues, etc come up from having multiple accounts. So, there’s a balancing act here, and private games provide a unique method of managing one’s identity and associations on a site that otherwise limits that ability.
Playtesting new games or content is a very valid issue. Whether it’s user-generated or from long-standing publishers, sometimes the information in a game needs to be under wraps for legal reasons. Having private game functionality could be the difference between a publisher agreeing to MW-hosted playtests and being denied them.
I feel the general response that, with private games removed, members would just make all their threads private, misses a big part of the point, and makes me wonder if members’ workarounds for privacy might be worse than the problems we already have.
That some people might not continue to game here as a result of losing private games seemed odd at first, but much less so when I considered these issues. While I don’t think there’d be many of these folks, we certainly aren’t putting any potential gamers off by having private games.
There are a lot of things to balance, here, and I’m feeling like I’m reversing position. I’m thinking we should keep private games.There are a lot of issues with how they’re are implemented and handled, and this doesn’t mean I’m about to jump in, gung-ho about fixing them and ‘getting it right’, but it does let me know that as we move forward, this is something we have reasons to support and to continue to tweak and develop until it feels right.
I do still like the idea of more open gaming, and if anyone has any suggestions of how to encourage that, I’m open. An additional game state where a game was public, but outside posting was not allowed, seems like it would alleviate a lot of concerns (even if I don’t feel they’re well founded), so I think that’s one thing we can put onto our infinite to-do list.
I really appreciate the turnout we got here, and how open some of you were willing to be about your reasons for wanting private games, or that you felt games should be open books! This may be our project, and we always want to limit our pain however we can, but ultimately the project, the site, is about you all, and making it your first choice for playing.
… for an announcement is what’s in vogue now, right?
Over the last week, in fits and bursts, I’ve been working on the next generation of character sheets. I’ve had to go back to the drawing board, and to the cutting room floor, for a lot of ideas, because I need to start getting v5 components out the door. I’m nearing up on something that we can demo.
However, I can extoll some of the great things about the new sheets. These are all features that are written (not pie in the sky), and being tested by staff.
They’re smaller. Though we’re not strapped for bandwidth, caching optimizations and changes to how the template is stored and loaded mean that less files get loaded, and they’re all significantly smaller.
They’re bigger. Most current sheets are cramped, and the developers have clawed for every pixel. Pages on new sheets are nearly 20% larger, allowing breathing room or easier packing, and still print flawlessly.
They’re safer. Current sheets rebuild all sheet data on save where data can be lost if interrupted. New sheets save only the changes you’ve made.
They’re smarter. Better data cleaning and filtering means less weird display of special characters.
They’re time travelers. Versions are back, and better than ever. You can navigate forward and back through the various versions of the sheet right on the page.
In the coming weeks you can expect a demo, with a few new sheets (in their early stages) including Exalted and Dark Heresy.
This morning, for about 4 hours, we had a reachability issue due to a DDoS attack on our authoritative nameserver hosts. This is not the first time this has happened – in fact they seem to get successfully attacked a few times a year. The last time we started exploring options to change our DNS host, and had looked at Amazon’s Route53 service. At the time, it was still in beta and was extremely difficult to set up, manage, and debug, so we had to drop it.
In response to this latest issue, I looked into it again, and it’s matured as a product. In fact, MW should be returning as the new DNS information propagates, and we’re now using Amazon Route53 for all our domains. I’m certain Amazon is considerably more reliable, and also gives us flexibility to quickly respond should a problem occur.
I’m also going to be switching domain registrar because our current service, Dynadot, is silent an unreachable when problems like this occur. I’m looking at Hover, Gandi, and Namecheap and will make a decision and get us switched over within the next few weeks. Expect a bit of downtime for that.
Wiki Homebrew Forms
One of the problems we considered , rethought and rethought again with the creation of worlds was how to handle homebrew crunch. The obvious ones like classes and feats but also deities and some others that may be less obvious candidates .
We wanted to achieve various things; make it easier to create wiki articles for homebrew material, remove the need to insert links to your article and make the articles searchable by criteria (Hit Dice or CR for instance). We needed to do that for the usual homebrew listings but still find a way that individual GMs could easily drop these homebrew pages into the wiki pages of their worlds or campaigns.
Thanks to the assistance of three people who’ve put in a great effort over the past few weeks we have a framework in place for doing this. I’ll be blogging about other members of the wiki team (and what happened to the original team) later but right now I want to single out for thanks, Brodiggan Gale, Nikolai, and Pheonyx .
The framework is still evolving but the basics are fixed enough to start rolling things out gradually. Specific forms are used for creation of each article type but can be bypassed by users with existing content in other formats. Forms (optionally) consist of two halves, the first half is composed of input fields (text, checkbox, dropdown etc). The second half deals with things which are too varied to handle with questions, it appends default text to the content generated by the first half. Once finished users can edit as much or as little as they like of this appended text. Simpler ones will only use input fields omitting the optional preloaded text.
We plan to demo each of these forms before full release so that any issues can be discussed. We’ll run a thread for each and hopefully member feedback will enable us to get each one to fit your needs.
In order to allow everyone as many attempts as they need to try the forms we’ve created a sandbox area (namespace Test:) where we’ll periodically wipe everything.
Our first example, a deliberately gentle introduction, one with no preloaded second half, is 3.5 feat. Please try it out and for help or to discuss use this thread. The form itself is launched from this page, where your created feats will also be indexed.
Pathfinder Sheet Interim
As an interim solution I’ve stickied a sheet dump in Site Discussion which can be used to convert 3.5 Sheets for use with Pathfinder . The thread can be found here and more detail with instructions here.
Mike has just created a new bbcode. If you have a character sheet attached to a game which contains a character portrait it can now be displayed with a bbcode. Used in a thread associated with the same game as the sheet [charpic]x[/charpic] will display a smaller version of the sheet character portrait.
The 7th Sea Sheets have been available for a while but have never been officially announced, Shadowrun 3e is brand new today. Credit for both goes to Mordae who has two more sheets nearing completion.
We’ve finally made good progress on the wiki integration. There’s a lot to cover so I’m going to spread it over several posts. I can also properly acknowledge the help given others in later posts.
The world creation feature of the wiki is now moving to public beta. In order to edit or create “World:” pages you will need to be added to the wiki usergroup “Trustees”. Fire me a PM to become a “Trustee”, that way it’ll allow me to keep a handle on the rate of new worlds. As soon as we’re satisfied no new issues are likely to surface, we’ll remove the need to be in a special group.
The main page for each world is created by a form/input box on http://www.myth-weavers.com/wiki/index.php/World:Index . The page also contains a query that lists worlds thus eliminating the need for editors to worry about adding links and categories.
Any GMs who would like to experiment linking their game forum to an already created world can do so using the wiki button. Any link created can subsequently be removed by repeating the process and submitting without making a selection (reload page, hit wiki button, hit submit button).
Prizes of $50
We agreed with Gameground a new social gaming platform with some cool features, to host a competition. Myth-Weavers admins discussed their proposal and whilst we saw no direct benefit for the site we felt prizes for members was something our community deserved. The details will be posted Saturday.
We have a new poll going on the site, as we’ve come to a bit of an impasse regarding how to structure game advertisements and their associated applications. Please read and vote on that in the Site Discussion thread.
In v5, we plan for advertisements to work fairly differently from how they currently work. We have nailed down most all aspects, but there is one area where we still cannot make a decision. We have narrowed it down to two options.
As you are familiar with, the game advertisement thread has its primary post, with extra information about the game, and there are additional posts to the game advertisement thread.
New, is the list of applications, and the Apply button. Clicking ‘Apply’ presents the user with a form from which he can write his application. Submitting it creates an application and attaches it to the advertisement, so that it is listed on and accessible from the first post of the advertisement thread.
The difference between our two options is how the application can be interacted with from there.
Again, please read and vote on that in the Site Discussion thread. Thanks!
I would like to welcome new staff members to the hallowed staff halls. They will all be joining the wiki team. We have been planning a team to handle wiki issues for some time, I feel that between them, what they bring to the table will make this team a great asset.
The new staff are: Nikolai, Dr Morganes, The Firkraag, Soul Reaper, and Roi
As a result we have reorganised staff into three groups with distinct responsibilities.
- Moderation Team.
- Wiki Team.
- Dev Advisers.
Mordae will be joining all three teams for a while.
The roles are clearly split and we will be updating the wiki staff page to indicate who would be the best point of contact. Only the moderators have blue names and the permissions to deleted/undelete/move threads around in non-game forums and issue infractions. Dev advisers will be people who provide various minor development assistance, mainly things like sheet design.
The wiki team have various objectives which will include a complete new help section and providing assistance with the creation of “World” sections. They’ll also be keeping those world sections updated by adding categories and semantic tags as we define which ones are need for each world.
Nikolai is familiar with Semnatic Media Wiki and others have expressed an interest in learning more. Semantic Media Wiki (SMW) , is a wiki plugin feature which allows information within articles to be tagged and various operations such as search and sort to be performed on them. It also allows articles which have a group of standard data to be created using special forms. We will be using these for creation of homeberew classes,monsters, feats etc for 3.5 and 4e initially with others to follow as the need arises.
How semantic form based classes change things is illustrated by the following: Currently, when adding a class it’s necessary to edit the page which lists 3.5 or 4e classes and manually provide a link. We redo the page and add a list display based on a semantic query, all articles tagged “class” and having the category “3.5″ will show on this list automatically. Where this begins to become really useful is when used in worlds, even though worlds will exist in their own section(namespace) of the wiki tagging them correctly will mean they’re auto listed on the correct index page.
World Link , the Motivator
Some time last year around July or August I’d been working on a Myth-Weavers project, for now we’ll call it Qmat and I’ll b introducing that in a separate blog entry. Development of Qmat has been on hiatus for the best part of 11 months. The impetus to revive it came when I recently spent 10 or 11 weeks yoyo-ing into and out of hospital. Whilst laid in hospital beds, laptop at home with broken screen, my mind wandered and ran over all the outstanding projects I have on The Weave and I found I wanted to pull Qmat off the shelf.
The reason Qmat got left behind is enthusiasm, or a total lack thereof from gradual erosion. Several issues had arisen with the project over time and I’d not been able to resolve them effectively, or for that matter think of a way forward on some, eventually turning my waning enthusiasm ino a stalled project. One of the problems concerns people running multiple games(groups) inside one game/gameforum. This most often involves all the games sharing a world or module so the GM uses the game forum to share this background between several games or groups. I needed a way to make it easy to share this into across several game forums and the wikilink-tree idea was born.
So once I was home and stable with access to a computer and the intertubes I gave more consideration to reviving Qmat. If that was going to happen the first step needed to be to finish off the wiki linking code. The biggest part of the project would be to automate the creation of the worlds and world-sub-pages, a preferred option to make the wiki seem less intimidating to those who haven’t used it. Unfortunately, getting all the automation working all the way down the tree was a big task, too big given the timescales which were emerging.
The best way forward was obvious, compromise, go ahead with minimal automation on the wiki end of things, write up a good set of instructions on how to create and maintain a world using wiki pages. This should allow us to release the feature fairly soon, especially as there have been two games using it for some time, it just wasn’t ready for a production release.
The outstanding issues which were originally present have now all been resolved, unfortunately upgrading to the latest version of jquery-ui and adding a custom themeroller theme have introduced some odd styling issues. When selecting a world from the autosuggest list the current one is not highlighted and after selection the input is looking for a second world. These two will need resolving before we’re ready to roll. As soon as you see a wiki button appear on the game forum button bar you’ll know it’s been released.
There are a number of improvements on the todo list for this feature but they will have to wait. I have a number of projects running which will all be getting features cut in order to get them released, we can then add features incrementally in line with our policy on MW-V5, although these features aren’t specifically V5. I’ll be adding blog posts over the coming days and weeks describing these projects and what features will be getting delayed to achieve the earliest possible release.
The function I’d most like to get added soon is saving the state of the tree (which branches are expanded and which aren’t) in a cookie. The current arrangement is for the tree to reload and display in it’s default state.
On of the games we’ve been testing this feature on can be found at http://www.myth-weavers.com/forumdisplay.php?f=11363
This is really just a minor update, I don’t want to steal the thunder from the v5 post.
In one of the comments on the other sheets post, I mentioned having developed a bit of a kit for creating sheets a bit faster. We’ve passed it around to some of the staff, and have shown it to one or two other people, and, while we’re still hashing out some major decisions for it, the response has been great. There’s a Dresden Files sheet in the work, the Mutants & Masterminds sheet is getting rebuilt since there have been some long-standing issues with it, and awesome enough, Mordae has already pumped out two sheets:
These aren’t available yet, as there’s still a little bit of editing to be done and some style/behavioral changes, but the speed has been incredible. I’m looking forward to how some other sheets go once people are more familiar with the toolkit. Once there’s a good amount of samples, we’ll start looking at handing the kit out to others to make new sheets and remake old sheets.
That reminds me that sheet deployment is also an issue for remaking sheets. The new versions will be separate from the old versions. You’ll be able to make new sheets under the new version only, and after a period of time (a long time, we expect, like 6 months) the old sheets will be removed with the template.
Kinda escalated this beyond ‘minor update’ but, oh well. I have stuff to say and I’ll say it!
While we’ve hinted at it for a while, we have finally started inching along on development of our fifth major revision of Myth-Weavers.
Now, beware, there’s a lot of technobabble in here, sparing the wall of text. But, I think it’s important users know why development is so slow, and why it kills us inside to not be pushing MW even farther ahead of other pbp sites.
tl;dr – eff vBulletin, we’re remaking MW with a new framework, and we’ll release it to run alongside the main site as soon as it’s usable.
Look around on the web, and pretty much any article or blog post on the subject will tell you why you should never, ever, rewrite instead of make piecemeal edits. Well, we’re rewriting.
Using vBulletin as our base does not make sense, and has not made sense for some time now. vBulletin is proprietary and 3rd party, and its structure doesn’t match our vision for the site. It makes no sense to use it as our framework (extending its tendrils into everything on the site), especially when its competency is in what amounts to a small segment of our site functionality, and when using it hinders our ability to quickly and easily add or change functionality. Our version of is outdated and therefore unsafe, and upgrading, due to the amount of editing we’ve done, would amount to a rewrite. While adding threads to Subweaves this past weekend, I had to do a large amount of hacking of default vBulletin code to get this simple feature working. It’s not working out.
It’s not just vBulletin – our code, and not just the stuff tied to vB, could use a lot of touching up. We’ll be able to reuse a good deal of it, even if it does get refactored for the new framework. My work on the last revision was done when my understanding of a lot of concepts was in infancy. Many improvements were made, and in a lot of ways it made development easier. We’ve come to the point of reduced return on that work. It’s not to say I’m an expert on this stuff now, I’m certainly still learning, but in the staff chat, it’s not uncommon for something like, “I didn’t write that, it’s not my fault,” to be thrown around.
Site development is still at a standstill, and part of it is due to the difficulty of working with what we currently have. It makes any task unbearable, and we can’t move forward under conditions like that.
For v5, we are completely leaving vBulletin, and will be basing our work on the KohanaPHP framework, a fork of CodeIgniter. Plugsy and I recently used CodeIgniter on a project and were very happy with how easy and fast development was, and the amount of control we had. We’ve started testing with KohanaPHP and, while it has some odd quirks, it’s looking like it’s taken the best of CI and added on to it. Aside from time spent learning (and debugging a really, really simple issue), we were able to conjure up a quick demo with user accounts/sessions (this is generally a stumbling block to get right), and content creation going very quickly.
One of the advantages we gained in the latest revision was leveraging vBulletin’s data manager system. It allowed us to set up objects like games, game members, game ads, etc. more quickly than we had before, since it cut down on time writing code to validate input and database code, and heavily standardized what we were writing. Now, we’ll be able to leverage something that’s significantly more powerful, and takes far less time to set up – ORM, specifically, Jelly. I haven’t played with it enough to really bring out the beast, but I’ve been really excited about what I’m seeing so far. This, combined with the better code/db profiling available to us, will allow us to quickly write the code for the database, check for bottlenecks, and fix problem areas.
Another advantage in our move will be flexibility, especially in regards to creating the user end of things. Under vBulletin, we’d write page routines that took advantage of functions or objects we’d created, and these would often feed data into templates, and save these until the end of the routine when the output from those templates would be fed into one larger template before getting served up to the user. These templates are rigid (though architected in the spirit of reusability, and are stored in the database, both are bad ideas. Because templates are rigid, we tried to reuse them wherever we could. This meant throwing in mountains of conditions to show different columns on different pages, among other sorts of things. This kind of behavior was in vB by default. (gasp! I know!) The kinds of things you can do in these templates is also extremely limited, which results in muddling different levels of logic in the code (essentially creating a single-tier system), and loading in layer upon layer of templates. Well, now we won’t have to deal with that. If I want to make a page that loops through the results of a database query, I make the page, without having to make a template to format those results. It would only ever get used on this page anyway, so why have a reusable template?
Performance matters. For inexplicable reasons, page generation times on the site have been very wild, from .2s to 40s. Overhead in vBulletin causes excessive memory usage. This paragraph is short & sweet, because that’s what we expect performance to be like.
So, that was us telling you how terrible the site currently is, and promising you the future holds better. No specific feature promises, just, in general, a better site.
Well, we don’t want to wait until we’ve rewritten the site (by which time it’ll be outdated) to release this, and we’re pretty sure you don’t want to wait either. We’ve decided on a development/release system similar to what’s been done over at rpol. We’re going to write just enough of v5 so that it would be usable to run a pbp game, based on what it would need to compete against other pbp sites. Then, we’ll release it. You can use it exclusively, alongside MW, whatever you like. We’ll add more functionality to it until it can stand toe to toe feature-wise against the current site, all the while getting user input and making changes to make it even better. Then, we’ll look at porting all our information, and converting entirely to v5.
This way, if you can deal with a limited feature set, you can start using the new site early.
I could write pages more, I’m certain, but this is already bordering on an unreadable rant.