If anyone wishes to submit fiction, feel free to contact me about it to work out if it might be something I would include. I think as fiction as valid content seemed to be accepted by the people who discussed it on the forum, there's no reason I shouldn't include at least one piece. That is assuming anyone even wants to write any.

I wanna be interviewed! :blues:

Another choice for simplification on my part: I will be publishing all submitted articles of sufficient quality in the issue they are submitted in time for. There will be no limiting the amount of content in the first issue. If I've mentioned that an article may be published in the second issue, forget it, if you can produce what you volunteered.

With the possibility of some of "first issue" authors not providing their volunteered article in time, juggling promises about what will go where is an unnecessary complication.

I think there's around 10 volunteered articles, and 3 pending invited articles, at this point.

Can it be fiction that was submitted to an old mud?

Not for fiction. Non-fiction is a different matter. If someone submits a non-fiction article that was previously published elsewhere, if they have updated it in ways that bring it current, address their changed views.. at this time I'd be likely to take that.

This is one of those cases where one person will have to take charge instead of getting stuck in an eternal circle jerk.

The biggest problem I see with these kind of projects is that one or two persons will do 95% of the work, while 20 persons will want to share the credits or dominate the decision making process. It's like modern day democracies where a bunch of monkeys dick around while the working man is at work.

I like how donky is doing it. Once the first issue is done he hopefully will document the production steps and then anyone can do it.

I agree with Scandum. When it comes down to it, the project needs one person to have authority on all decisions, and to be willing to do all the work themselves should team members (who are also volunteers) not be able to provide the assistance they wanted to. At this time, there's four people on the publication team. There's me, acquiring content and managing and dictating a vision, and then there's three experienced people who've offered to edit. This is three more people than Pinkfish had, as far as I know.

What sort of documentation are you hoping for? There are almost no production steps, and any I intend to do can be found with simple google searches. How to publish the web pages? A simple update to the existing site in line with the existing issues. How to publish the mobi/epub? Presumably generate with calibre, from the HTML exported from google documents (or hand rebuilt, if necessary). Any of these approaches can be substituted for others. Lack of notes on production steps should not stop anyone from doing this.

When this issue is published, if enough content eventuates from volunteers to call it a worthwhile effort (I'll ask the team how they feel about it), I'll include a request for article submissions both in it and in any announcements. The offers from volunteers for articles for the second issue won't go to my email address, but will instead go to a mailing list most likely at submissions@journal.imaginary-realities.com. This should make it easier for transitions in changes in ownership in the future. Read ownership as ability to be responsible for both publishing it, and what gets published. If consensus is that ownership would be better transitioned to someone else, you can either convince me, and if that doesn't work then you might convince Drakkos who can reassign the domain.

Here's a question for the second issue and beyond..

Should the scope be widened as originally planned during Drakkos' previous revival attempt, to include IF, roguelikes, text-based browser games and gamebooks? Perhaps the scope will be widened further at a later point. Why not include articles on RPGs? Why not include articles on tabletop games? Why not include articles on graphical MMOs? My main concern is that at some point there's a danger of this becoming a vanity project for wannabe game journalists where any vaguely related filler is collected to pad out successive issues.

Once the first issue is published, we can discuss it here and work out how we feel about it. If we agree it was worthwhile, or at least promising and salvageable, then maybe scope can be extended and further request for article submissions can go to the related non-MUD communities.

Here's some article ideas I posted to someone inquiring. The quoted text follows from here on:

I'm not asking or interested in discussing the following questions, but using them to illustrate my article topic interests. My personal interest is articles that collect information that make it easier for people. To play, to build, to design, to program. And I am interested in fact-based objective articles, not subjective opinion pieces. Bonus points for getting opinions of players of MUDs, where otherwise you would only have your own experience and viewpoint.

• If you implement a MUD, what are the benefits in going your own way, or doing things in a standard way?
• If you implement the standard LP set of player commands and their syntax, does this make the development easier and make your MUD more approachable?
• With the view that knowing the standard sets of commands for LP, ROM, Diku, whatever, is a benefit, an article detailing them and perhaps even moving on to compare them, would be of value.
• There's been some past discussion on MudBytes about terrible newbie experiences, you make a set of choices which you're stuck with and don't fully understand (race, class and so on), then maybe you enter a contrived newbie area you suffer through, after which you're dumped into the game. And this is probably a bland room, with no direction provided, where a bunch of strangers are talking English that may as well be jibber jabber. Are there any MUDs which do this well, and why is it any better than the MUDs which just do it and make the player suffer through it? Kavir's MUD and I believe Drakkos' Epitaph MUD both have a tutorial mode, how has this worked out in each approach? Is it better? If so, why is it better and how could it be improved further?
• How common are recognition systems? Is there a common approach to it? How is it done on various MUDs, and what are the ways in which it either gets in the way (non-subjectively) or that it makes the game better? How could they be improved?
• Are there standard approaches to room-based MUDs? What are the common ways it is done? Are there different standards in each of the different code bases that people work with?
• Alternative approaches to room-based. Who has actually implemented them? What live MUDs have them, and what are common ways they are done? Has anyone actually implemented a 3D proximity-based MUD, with commands like "approach target"?
• How common are dynamic descriptions? Are there any MUDs that generate them? What elements do they build them from? Do any MUDs actually generate them from 3D terrain surfaces, and overlaying terrain metadata - or is this just something talked about?
• History of mudding: write up the history of the LP driver, from LP to MudOS to FluffOS. Did you know FluffOS is getting support for web sockets? What other changes are happening? Alternately, similarly for Diku, ROM and whatever else has a long history.
• How given MUDs which have been around for a long term have evolved. Change in cost of hosting over time. How they've handled leadership / ownership changes. How they are led / owned. Plans for the future. Plans actually already being worked on.
• Review of a MUD, accompanied by a full log of play, perhaps annotated. But not a romantically painted abstract view of a MUD which you enjoyed due to subjective preferences.
• A summary of mudding and mud development resources on the internet. Forums, the types of discussion, mailing lists, etc.
• A survey of skill systems and how well they are made use of on different MUDs.
• A definitive article on PhysMUD. Go through all mailing list postings, forum posts and more. Paint a picture of what it was supposed to be. Get further detail from Nathan Yospe, perhaps get him to summarise what he thinks people should take from it. Poll the older community members who were around whether they thought it actually existed. Come to your own conclusion based on the evidence.
• A definitive article on CornMUD. Go through all references to it, summarise it. It was a hoax, but maybe take it further and both describe and prototype how it's intriguing features could have been made.
• A definitive article on Bloodstone. Google MUD-Dev and Bloodstone. You should find reference to an uber MUD that bit off more than it could chew. What good ideas did it have? Do any modern MUDs have them? Have they tried them and discarded them? Is there someone you could interview about it? See here.
• Have you ever read a MUD advertisement that when paraphrased said "you can be a fighter, cleric, thief, barbarian.. we have classes for everyone! you can even be multi-class!" There's nothing wrong with the class-based approach, and there may be an argument to make that it is the easiest and simplest way. That it is a standard approach people understand. To go freeform where people can learn knowledge and skills as they play, following their needs and interest, is another approach. Past forum or mailing list posts have suggested an approach where when characters get created they choose a character history that determines the starting skills, abilities or knowledge they have. Are there standard non-class based approaches on live MUDs? How do they work out?
• Back in 1997, someone said "There is a mud called 3M whose engine (not sure what mudlib it's based on) is written to work exactly like Angband." What does this mean? Was it text-based? Did it have a roguelike interface? Is it still around? How has it changed? See here.
• Abstract commands. You want to dig a well, do you start by getting your shovel, then doing 2000 dig commands interspersed by 3000 other commands building a support infrastructure that lines it with mortar blocks and prevents it caving in you? Or do you just do "dig well" and all the sub-commands happen as part of a simplified game managed process? There's the simple end where there is simply a well object placed, and there's the more complex end where all those commands actually happen, sub-skills are applied, and resources required and used. Does anyone do the latter? See here.
• Storing nearby objects in a spatial data structure like a b-tree using morton codes. Has anyone ever done it? Prototype it, explain it and make idea ready for adoption. 3D mud discussions are in vogue these days, why not make people aware of useful techniques. See here.

I can offer more targeted alternatives if reading this has made clear some preferred article categories.

Yeah, let's get the first issue out and then think about expanding scope.

Some updates:

The first article submission has been received at 7000 words.

One of the editors took it upon themselves to invite people to write articles, so there are more unconfirmed articles in the wings. I think we're at around 13 confirmed articles (which fingers crossed will eventuate). And maybe 8 unconfirmed articles.

Here's a forum post that definitively solves the problem of what determinate to use.

Tyche, you don't accept PMs, you want to submit this as an article?

Anyone else got any similar posts which pretty much state the way things should be done for various problems, that haven't otherwise been documented elsewhere?

Update for 25th August 2013:

• 18 potential authors lined up.


• 1 article already submitted.

I'll give it some thought.

2/18 potential articles received. It's slow going, but at least it's not just going to be Drakkos' article and mine in there :lol:

3/19 potential articles received. One month to go before the deadline people, if you've offered an article.

Don't worry, I've not forgotten, and I'll definitely submit something.

Same here, working on it.

Ditto that.