Wannabe crafting monopolists hating on Guild Wars 2

I've been playing and enjoying Guild Wars 2. One of the differences between GW2 and other games is the universal Trading Post, which is an auction house that spans all the servers.

Because spanning all the servers allows the Trading Post to provide a very efficient market, it's been subject to some heavy criticism from MMO bloggers.

While not criticizing the Trading Post, Spinks notes that:

...raw materials (particularly metal, cloth, and leather) typically sell for more than the finished pieces.

How is this new? This was always the case with WoW items crafted from trainer recipes. The issue is the crafting system, not the TP. (I don't mean to imply that Spinks is a wannabe monopolist; I just wanted to point out that selling crafted items below cost is not new with GW2).

Tobold weighs in with a piece titled Crafting regrets in which he says:

I think Guild Wars 2 is extremely bad for making money from crafting, because the auction house spans all servers. There is no opportunity for arbitrage in such a large economy. [my emphasis]

And later:

There simply doesn't appear to be a point to crafting in Guild Wars 2. Are the any "bind on pickup" recipes like in World of Warcraft? If not, I'll just buy everything for cheap on the AH. [my emphasis]

Arbitrage—that's something Wall Streeters do. I've done it to earn gold in MMOs, but I've always felt a bit dirty doing it. I think it's excellent that the efficiency of the Trading Post reduces the opportunity for arbitrage.

I read Tobold's post a few days ago but had forgotten it by the time I read and commented on Elder Game's The Case Against Auction Houses. I'm reproducing my comment here in full since it serves as an excellent rebuttal to Tobold's desire for monopolies via bind-on-pickup recipes. On Elder Game I wrote:

I love crafting, particularly to make items for my main and alts.

Sure, it's nice to be able to sell at a profit, but not if it involves monopolies. What the crafters who whine about profit are really saying is "I want a monopoly." Personally, I wouldn't cater to the wannabe 1-percenters, but hey, it's your game.

In-game shops use geography to achieve local monopolies (perhaps shared with a few others). Not all locations are as good as others, so how would the game decide which players get to have shops in the prime locations of the crowded main city?

The problem isn't with the AH, the problem is with crafting systems. WoW limited the supply of crafted items by making some ingredients rare, but mostly by making recipes random rare drops; anyone lucky enough to get a Pattern: Rich Purple Silk Shirt can make a bundle, either by selling it outright or as a tailor making the shirts.

Worst were the bind-on-pickup recipes that dropped in endgame instances so that non-raiders had no hope of ever acquiring them. As someone more interested in crafting than raiding it was one of the things about WoW I hated most.

The issue is how to limit the supply of crafted items in a fair and equitable manner without resorting to using the random number generator to award monopolies to 1-percenters.

As I see it the problem is with designs that make it possible to create items in the blink of an eye. Why do so many games allow one to "lovingly handcraft" a valuable item in the time it takes to click a mouse? Craftsmanship implies labor over a period of time.

One game I've seen which implemented a crafting bottleneck well was Fallen Earth, where crafting takes real time whether you're playing or logged off. Making crafting use real time limits the supply without resorting to randomness or monopolies. Yes, it's still open to exploitation, or at least mass production, through the use of alts and additional accounts, but the idea of making item creation take real time seems like a good mechanic.

It leaves unsolved the issue of how to provide a sink for all the commodities left unused by a time-throttled crafting mechanic.

There are other ways to improve the profitability of crafting instead of implementing recipe monopolies or making the Trading Post less efficient:

First, others in the thread brought up the old idea of real wear and tear so that items don't last forever but wear out and require replacement.

Second, eliminate gear as quest rewards, and do away with 99 percent of all item drops from mobs so that they only drop salvage items or vendor junk. A useable item of any quality dropping from a mob should be a rare thing. Make the majority of gear in the game player-crafted, except for a handful of items.

The ancient trope of phat lewtz drops carried down from the pencil and paper days of Dungeons and Dragons hurts crafting more than any Auction House. Early D&D's focus on combat at the expense of crafting has persisted in RPGs for years and continues in MMOs.

For the first couple of years of its existence, Minecraft had it right in that mobs only dropped raw materials. I was very disappointed when an update cause mobs to sometimes drop weapons and armor, possibly enchanted.

As I see it, Guild Wars 2's changes to crafting and commerce aren't the problem—the real problem is that the changes didn't go far enough.

Soren Johnson on Minecraft in the cloud

One can’t help wonder what Mojang could do with a cloud-based version of Minecraft, seamlessly updated, playable from any device or browser, that connects every world end-to-end.

-Soren Johnson in GD Column 20: The Coming Storm

Originally published in the Feb 2012 issue of Game Developer magazine, he posted it to his blog today.

Beyond the mention of Minecraft it's an interesting discussion of cloud gaming that I highly recommend.

6502 emulator in Minecraft runs Forth

Notch's new game 0x10c and its virtual 16-bit computer, the DCPU-16, have made news recently. Somewhat eclipsed by Notch's project is the 6502 emulator now available for Minecraft as part of Prerelease 5 of the mod RedPower 2 by Eloraam.

Eloraam calls it the 65EL02, because "it supports all the 6502, 65C02, and part of the 65C816 instruction set" as well as "a set of completely new instructions and two addressing modes."

The emulated CPU comes with 8K RAM, with up to seven additional 8K RAM Modules installable on Backplanes that must be placed on blocks behind the CPU.

Additional components are Monitors, floppy Disk Drives, and IO Expanders, all of which may be located at a distance from the CPU as long as they're connected by Ribbon Cable blocks.

A minimal installation consists of a CPU, Disk Drive, and Monitor. Up to 256 devices (just the Monitors, Disk Drives, and IO Expanders thus far) are supported by Redbus over the ribbon cables.

RedPower 2's 65EL02 computer system in Minecraft. Shown are a CPU with three 8K RAM Modules, a Monitor on the left, and a floppy Disk Drive adjacent on the right. Further right a Ribbon Cable connects to an IO Expander interfaced to a Bundled Cable that carries 16 redstone signals. (Click to enlarge.)

The portion of Eloraam's addon with the computer is known as RedPower Control due to its intended use for industrial process control. Among other things the computer can control in Minecraft are automated mining machines built with RedPower's newly-introduced Frames, which are movable scaffold blocks used to build moving gantries, booms, and cranes.

Eloraam has put an incredible amount of work into RedPower Control and the other parts of Prerelease 5, and it shows. Her textures, while remaining at Minecraft's low resolution, are very attractive and make RedPower's items pleasant to look at in-game.

A example is the front panel displayed when you right-click the 65EL02 CPU block:

The front panel of the 65EL02 CPU. Yes, the toggle switches really work! (Click to enlarge.)

The front panel recalls the look of Digital Equipment Corporation (DEC) hardware really well. The rocker switches, in particular, are great renditions of those on the front panel of PDP-11/35s and /40s. When I complimented her on the appearance of the front panel, Eloraam described the effort it took:

The rocker switches took hours to draw. They were so hard that I ended up resorting to tracing the rough contours and illumination from the one good front-on picture of a PDP-11/35 I could find on Google. Even then, it wasn't a copy-paste job. The exemplar gave me a good map of where the speculars and shadows fall, but it was also a grainy JPEG with a myriad of photographic imperfections, as well as having the wrong aspect ratio. So once I put down the basic outline and marked out how the speculars fall, I tossed the exemplar and drew everything myself.

I must admit I found working on such a large canvas daunting. I'm an engineer, this art stuff is all new to me. I've developed a knack for 16x16 through lots of practice (RedPower has something like 500 sprites now, and I drew them all), but this was something else entirely.

Since the 65EL02 is an 8-bit CPU, Eloraam didn't have as many options for programming environments as we have on today's 64-bit computers. While it's possible to program the 65EL02 in assembly language, for general use she chose to implement a Forth interpreter. Less well-known than BASIC, Forth is far more powerful while retaining a tiny footprint and being easy to understand.

The output of the Forth WORDS command. (Click to enlarge.)

Note the sophistication of the scheduler built into the 6502 emulation as described in this reply by Eloraam to a question about infinite loops:

Infinite loops are fine. RP Control is carefully designed so that you won't screw up your world even if you crash the virtual computer. It's actually not especially hard to crash the virtual computer, since the whole OS is loaded into its RAM and you can easily write to that RAM. Still, since the computer is fully virtualized, it won't hurt your world or even cause a slowdown.

The one thing to note is that you should always use at least one TICK or some TICKS in a loop if you're just waiting for things in the world to change. The computer will run a lot faster if you're not constantly wasting CPU cycles. The CPU only gives you a small number of cycles each tick, but it saves them up (to a certain limit), so if you don't waste them, your CPU can run a lot of code at once when you need it. TICK (and TICKS) calls a special instruction in the CPU which saves up any unused cycles, so it's your friend.

Further technical information about RedPower Control's 65EL02 is available on Eloraam's blog RP Control Internals, and on the RedPower wiki's page for RedPower Control.

For those that prefer video, YouTuber direwolf20 has a video introduction and basic tutorial for RedPower 2's new computer system:

It's interesting to note that Notch considered the 6502 before switching to a custom 16-bit CPU, even going as far as writing a working 6502 emulator. Just two days after getting his emulator running, Notch tweeted:

Starting to dislike the 6502 idea. Spending heaps of cpu cycles to emulate not being able to multiply. Reconsidering custom CPU again.

It appears that Notch intends his virtual CPU to be a major part of his new game and thus decided that the 6502 would be too limited due to being eight bits. Judging by the enthusiastic reaction to the DCPU-16 it appears he made the right choice.

Eloraam took another path by augmenting the 6502 with 65C02 and some 65C816 instructions and implementing MUL and DIV. The goal for the 65EL02 is much lower than for the DCPU-16. While capable of cool things, the 65EL02 seems intended to be a workhorse for carrying out the business of industrial process control in Minecraft.

Much of the excitement about the DCPU-16 has been anticipatory, although this will change soon when Notch releases the DCPU-16 emulator and then the first playable release of 0x10c. On the other hand RedPower's 65EL02 is available now and fully usable in its intended environment.

Let the 65EL02 hacking begin!

Update: This article was linked on Hack a Day, Slashdot, and engadget.

Escalator in Minecraft using RedPower 2 Frames

Eloraam recently unveiled prerelease 5 of her RedPower 2 mod for Minecraft. One of the long-anticipated features in PR5 is Frames, which are movable scaffolding blocks that have had fans drooling since last fall.

On my list of possible things to build with Frames was an escalator. I'm pleased to show that RedPower 2 Frames indeed make it possible to construct an escalator in Minecraft.

Escalator using Frames from RedPower 2 (click to enlarge)

A still picture really doesn't do it justice, one needs to see it in action:

One fly in the ointment: Frames don't move the player horizontally, so you have to hold the Forward key during the horizontal movements.

This escalator somewhat misuses Frames and Frame Motors. In normal projects where Frames are used to construct mobile gantries or booms, the ratio of Frames to Frame Motors might be on the order of 30 to 1. Here it's roughly two Frame Motors for every Frame.

The design turns out to be quite simple. Because the Frame Motors for each direction of escalator travel are in the same plane and are adjacent both horizontally and vertically, no additional wiring is needed for power beyond the the single Blue Alloy Wire providing it at the base. Like all blulectric devices, Frame Motors conduct blutricity to their neighbors.

A Red Alloy Wire on the back of each set of Frame Motors supplies the timing signal to synchronize all the motors. The signal is from a Timer set to an interval of one second. I'm not sure how inefficient it is in terms of blulectric power consumption to activate all the Frame Motors for each move when only half are needed, but it's much simpler to wire.

This escalator just represents the tip of the iceberg. Frames are an incredibly flexible building block that can be used in a countless number of ways in building things that move.

And Frames are just one of the new things that arrived with prerelease 5. When you combine Frames with Control's emulated 6502 CPU, the liquid handling provided by pumps, and the parts added to Logic, the result is a set of components that will keep RedPower 2 players busy for a long time.

Edit: Thanks to Eloraam and others on the Minecraft Forums who answered questions, and to direwolf20 for his YouTube tutorial showing the basics of frames.

Minecraft: The meaning of Mojang's hiring of the Bukkit team

As promised a couple of weeks ago when I reported that Mojang hires the Bukkit devs for its Minecraft team, here are my thoughts on its meaning.

First, in-game mod selection and download is an important strategic direction for Mojang as made clear by this sentence in Mojang's announcement:

In addition to the bukkit members, Daniel Kaplan (@kappische) will join to handle the project lead to coordinate Minecraft’s broader goals.

Second, it was a brilliant hire in a couple of ways.

1. As volunteers the Bukkit team could have done anything; while most people modding Minecraft have chosen to do the fun thing and implement new game features, the Bukkit devs instead chose to dig in and do API infrastructure work.

Their experience and self-selected API focus makes them the best people for the job.

2. Bukkit's About Us page includes this:

This advantage is further extended by our design choice to keep in the mind the possibility of 3rd party Minecraft servers needing a modding and plugin interface. That being said, when any 3rd party developed Minecraft server becomes stable, Bukkit will be there to allow our collection of plugins to work with them too through a new interface, without any work required for the plugin author to make it compatible.

"Third party Minecraft servers", now there's a phrase to strike terror in Mojang's heart. The arrival of third party Minecraft server software would begin to wrest control of Minecraft from Mojang in the same way that PC compatibles took control of the PC from IBM in the 1980s. Good for customers, not so much for IBM and Mojang.

While open source software can't be killed, projects can be robbed of momentum, in this case by hiring the staff and focusing their efforts elsewhere. So this is a good move for Mojang as it probably delays somewhat the arrival of viable third party servers. The Bukkit devs weren't working on third party servers, but they were clearly sympathetic in anticipating their arrival; in Mojang's employ they will be less so.

Third, it means that the official Mojang mod API is still months away. Instead of delivering an API solution in March, Mojang is just starting its design. So don't look for anything before summer. And considering the server and client work necessary to support in-game mod selection and download, a late summer or fall timeframe is likely more realistic.

Fourth, and this is not new, it means that ModLoader, ModLoaderMP, AudioMod, Forge, Bukkit, and several other small APIs are all dead once the official mod API arrives. This is a good thing; these mods would never have existed in the first place had Mojang fully supported modding from the outset. If Mojang stands to benefit from the Minecraft platform, then it, not the community, should do the work to implement and support that platform.


Fifth, Spout refuses to die and is attempting to exploit Bukkit's imminent demise by encouraging people to switch over to it. Spout needs to do this now because it will be a very tough sell to get people to switch to its launcher once the new official client arrives with in-game mod selection and download. Not to mention that Spout will be interfering with Mojang's strategic goals.

Sixth, since Mojang is just getting the design process underway, few details have been worked out at this point and there are still many unanswered questions.

Seventh, since Mojang will be hosting the download files once in-game mod selection is available, any incidental revenue associated with downloads currently earned by modders from URL shorteners like adf.ly will disappear. It remains to be seen how Mojang might replace that revenue stream for modders.

Eighth, once in-game mod selection is available, presence in the client's list of downloadable mods will be all-important. Absence from the in-game mod list will render a mod invisible to the great majority of Minecraft users. It's not clear if Mojang will have an approval process for mods, or whether all mods will be accepted. I think it's likely that the arrival of the first offensively tasteless mod in the mod list will cause Mojang to initiate an approval process to protect Minecraft's family-friendly orientation.

In-game mod download will also give Mojang an effective incentive with which to shape the behavior of modders. It will have a carrot in the form of featuring a mod, and a stick in the form of removing a mod from the list. Thus, should Mojang develop a Code of Conduct for modders, it won't be toothless.

Ninth, modpacks will die. The convenience of modpacks won't be needed once in-game mod selection and download arrives. Many modders will be quite happy to see the demise of modpacks and may help it along by revoking permission to include their mod.

Finally, this move further complicates Curse's strange relationship with Mojang. I had wondered about Curse Client support for Minecraft mods, but after nothing was announced at Minecon it seemed that this wasn't in the cards. When Curse signed the Bukkit team it began to support server mods, and today lists for download 2,475 Server Mods and 48 Client Mods. Jens has stated that in the future single player Minecraft will function by connecting to a local server, thus unifying the current split between single and multiplayer mods. Thus it appears that Mojang will reclaim server mod hosting once it implements the mod support in the client.

[Updated to add the ninth thought about modpacks.]

WoW developer Blizzard Entertainment to lay off 600

As reported by Develop (Blizzard to axe 600 jobs) and Gamasutra (Blizzard cuts 600 employees in organizational shift):

Blizzard Entertainment will lay off around 600 employees -- around 90 percent of which will come from its non-development departments -- after completing a review of its "current organizational needs."

According to Gamasutra's numbers, that cuts Blizzard's workforce from roughly 5600 to around 5000.

Even though it's mostly overhead, that's still 60 developers. Gamasutra reports:

Blizzard says its World of Warcraft team will not be impacted, nor will its development and publishing schedules for upcoming releases like Diablo III, StarCraft II: Heart of the Swarm, Blizzard DOTA, and its Mists of Pandaria expansion for World of Warcraft.

Not mentioned as exempt from the cuts were the in-development Titan MMO project or the Battle.net online gaming service.

Although it's not mentioned, World of Warcraft's falling subscription numbers must be a factor.

This is the surest sign yet that WoW has peaked and, while still a powerhouse, has entered a period of decline.

Mojang hires the Bukkit devs for its Minecraft team

And just like that, with one swift move Mojang more than doubles the size of the team working on Minecraft:

Today we can announce that the four main developers of bukkit – a community-based Minecraft server implementation – have joined ranks with Mojang to bring you the same flexibility and versatility to the official Minecraft server. The four, Warren Loo (@evilseph), Erik Broes (@_grum), Nathan Adams (@dinnerbone) and Nathan Gilbert (@tahgtahv), will work on improving both the server and the client to offer better official support for larger servers and server modifications.

The plan is to build a fresh server API, and then extend it to support client-side modding (in one way or another). We will try to make it easy for bukkit users to convert if they wish to do so, but backwards compatibility is not guaranteed. We will, however, help bukkit to be compatible with 1.2, to avoid having a long gap while you wait for the official Minecraft server to catch up.

Many of you may ask why we decided to work with bukkit instead of other Minecraft teams, such as Spout or Forge. The reason is that we want more than just modding, and these guys have always had server admins in mind when developing their additions to the game. We hope that this will help the quality of Minecraft multi-player to improve, both for large and private family servers, while still being able to add fun stuff for the bigger audience.

In addition to the bukkit members, Daniel Kaplan (@kappische) will join to handle the project lead to coordinate Minecraft’s broader goals. I (@jeb_) will remain as lead developer and game designer for Minecraft.

From the announcement on bukkit.org:

I am extremely pleased and proud to announce that, as of today, the Bukkit team has joined Mojang. When discussing the possibility of a modding API publicly, Mojang was concerned that they would be unable to provide the community with a suitable and powerful enough solution and we honestly feel that our experience building Bukkit will help them do so. Thanks to our work with Bukkit, we have a years worth of experience, failures and lessons to help us develop a proper modding API and intend to do whatever it takes to produce one that satisfies the needs of the community. Now that we have an opportunity to design the official Minecraft API, we intend to make it a suitable replacement for Bukkit, if not a significantly better one, while bukkit.org will remain a community for modders for the foreseeable future.

This is a good move; I'll have an analysis in a later post.