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.

Minecraft: Sorting and smelting system using RedPower 2

Since building the Compact cobble generator I've been expanding my base. This article describes the sorting and automatic smelting system I built using RedPower 2.

The system uses seven sorting machines in series all sharing a common delivery tube. The use of a single delivery tube saves tubing and space in exchange for limiting your sort to fifteen categories (sixteen if you included unmatched items). While I used seven sorting machines, this system could be expanded to any number of sorters which would allow the sorting of hundreds of different items.

Photo 1: Seven sorting machines fed from the alchemical chest on the left (click to enlarge)

Of course you could use any number of sorters all using separate delivery tubes, but I wanted to see what could be done with an array of sorters using just a single delivery tube.

Overview diagram (click to enlarge)

• A chest serves as the main input to the row of sorting machines.
• The sorters assign color tags to the items which travel to the storage chests.
• Items which traverse all 7 sorters without getting matched end up in an exceptions chest.
• Ores which require smelting are sorted to the furnace feed chest.
• 8 blulectric furnaces arranged in parallel make short work of smelting tasks.
• Ingots from the furnaces are returned to the sorters, bypassing the input chest.
• Also bypassing the input chest are the harvests from the sugar cane farm, a cactus farm, and a low-output passive tree farm.

An alchemical chest from the Equivalent Exchange mod serves as the input chest (see photo 1).

A filter pulls the items from the chest. Because the filter's inventory is empty, it will pull all the stacks from the input chest. (If you want single items pulled, use a transposer.)

Output from the filter enters the first sorting machine. It's powered with a blue alloy wire, and passes the power along to the adjacent sorters.

Since the sorting machines are all in-line and receive items already traveling through the tubes, they don't require a redstone signal to activate.

Configuration for the second sorter in the chain (click to enlarge)

The sorting machines are set to mode 5 and so sort everything they receive, and assign a color to items that don't match. This system uses pink for unmatched items.

Sorted items emerge from the sorters with a color tag. They go up and take the common delivery tube to their destinations. Unsorted items enter the next sorter in the chain.

To understand how this arrangement of sorters works it's useful to review two basics about tubes in RedPower 2:

1. Routing in RedPower tubes selects the closest valid destination.
2. Color tags keep wrong-colored items out.

After the first sorter, the inputs to the subsequent sorters in the chain are colored pink. All items emerging from these sorting machines want take the shortest path and enter the next sorter in the chain, but the pink input tubes keep everything out except the unsorted items. Thus the sorted items are forced up into the common delivery tube on top of the sorters.

Photo 2: The transposer near the last sorter (click to enlarge)

The last sorting machine in the chain sends its unmatched output to a chest (see photo 2). Note that the chest is further away than the route back to the last sorter's input, so unmatched items will loop through the last sorter unless special measures are taken. An in-line transposer causes the route to the chest to be seen as the shortest path for pink-tagged items. (If you have extra colors, you can eliminate the transposer by replacing the pink tag with an unused color.)

Photo 3: A filter pulls a few unsorted items (click to enlarge)

A filter grabs a few specific unsorted items for storage in a separate chest (see photo 3).

Currently the sorting machines still have many unused columns available for sorting additional items. Besides the default color of pink, this system currently has 13 colors assigned, for a total of 14. That leaves two colors for expansion.

Note that sorting machines in mode 5 without any items in their configuration columns don't think they have anything to do, and won't assign the default color. In other words, an empty sorting machine won't do anything. When you are testing the handling of unsorted items, make sure you put at least 1 item into each sorting machine, even if you don't assign it a color. [Update: This has been fixed in RedPower 2 Prerelease 4c.]

Photo 4: The common delivery tube connects to the storage chests (click to enlarge)

The common delivery tube leads from the sorting machines to the storage chests (see photo 4).

The two alchemical chests are not connected to the sorting tubes. The first stores the RedPower 2 supplies for color tagging the tubes.

The second is for tools storage, and uses an Equivalent Exchange mod item called the Talisman of Repair to keep things in good condition.

Here's the current assignment of storage chests:

Yellow: metal ingots
Light blue: redstone, glowstone, and covalence dust
Brown: wood products

White: RedPower rocks (marble and basalt)
Gray: stone, stone brick, and clay

Green: plant harvests
Lime: creature drops

Light gray: glass and RedPower microblocks
Blue: RedPower wiring and logic items
Orange: pistons and RedPower machines and tubes.

Cyan: diamonds and other valuables
Black: coal and flint

Photo 5: The red tube ends at the furnace feed (click to enlarge)

The red tube leads to the furnace feed chest (see photo 5).

A filter pulls items from the chest in stacks of 4 to send to the furnaces.

Stacks of 4 take 20 seconds to smelt, so the timer for the filter is set to 2.5 seconds, which is 20 seconds divided by 8 furnaces. I haven't done timing tests to optimize the timer setting. An optimum configuration would locate the filter adajcent to the first split in the tubes to minimize travel latency.

Photo 6: The 8-way Blulectric Furnace system (click to enlarge)

The feed tubes lead to the center of each furnace cluster; equal path lengths yield even distribution (see photo 6).

Return tubes go under the floor and lead to a retriever. An empty inventory causes it to pull any item from the furnace outputs. Equal length tubes ensure that the retriever pulls evenly, and it's on a fast timer.

Prior to prerelease 4 a transposer would have been needed for each furnace to gather the output, but a single retriever can pull the smelting results from all the furnaces.

Blulectric furnaces take input on the left side and make output available on the right, so each cluster has the furnaces rotated so that left faces in towards the feed and right faces out for the return.

The two furnace clusters could have been located closer together but I wanted to be able to walk between them.

A bank of 18 battery boxes powers the furnaces. Three blue alloy wires in the floor provide power to different sections of the two furnace clusters. Since the wires are rated for 100 amps, and each furnace pulls about 10 amps, there is no danger of overloading the power feeds.

Photo 7: Not quite enough solar panels for the job (click to enlarge)

The battery boxes are charged by an array of 22 solar panels, which is only half of the 40 panels that I should have to run the furnaces (see photo 7).

[Edit: I thanked them on the forum, but I'd like to express my gratitude to Minecraft Forum users Kyyshrrk, TheEnlightened, and Eloraam for clearing up my confusion about the way that color tags influence tube routing.]

Minecraft: Compact cobble generator using RedPower 2

Now that Eloraam has released RedPower 2.0pr4 I've generated a new world in Minecraft 1.0.0 and have been starting to build things.

One of the basic devices that I build early on is a cobblestone generator, to ensure that there's plenty of cobblestone at hand.

Back in 1.8.1 with RedPower 2.0pr3 I'd come up with a vertically-oriented design for a cobble generator on a small footprint and minimal use of parts. The Redstone Tubes added in RedPower 2.0pr4 make the design cleaner and use even fewer parts, since Redstone Tubes carry the redstone signal to the block breakers.

Side view (click to enlarge)

Top view (click to enlarge)

 YouTube video of the cobble generator

Each vertical layer uses two lava and four block breakers, producing four cobble. As is typical for me, I went overboard and opted for four layers, so the cobble generator produces 16 cobble per two second tick.

Here's the layout of each vertical layer of the cobble generator:

Redstone Tube	Block Breaker	Cobble	Lava
Block Breaker	Stone	Water	Cobble
Cobble	Water	Stone	Block Breaker
Lava	Cobble	Block Breaker	Redstone Tube

The Bill of Materials for each layer:

• 2 Lava
• 2 Redstone Tube
• 4 Block Breaker
• 8 Glass Covers (for the sides of the lava and cobble)

Additional materials required to complete the cobble generator:

• Timer (set to default two second interval)
• Lever
• Various bits of wiring and tubing
• Chest(s) to store output

Just a single water source block is used for the entire generator. Note the water has a 1 block horizontal run before the vertical drops; this is critical to prevent the water from flowing horizontally inside the generator and turning the lava into obsidian. The water columns extend 1 block into the floor below the bottom level of the generator.

Each layer requires lava source blocks in order for it to flow horizontally and create the cobble. A more compact version could be built with lava source blocks above the cobble columns, but the vertical flow of lava is so slow that the generator couldn't operate on the two second cycle, so output speed would be reduced. This might be something to try in the Nether, since lava flows faster there, I think.

Each layer generates 4 cobble every 2 seconds, which works out to 120 cobble per minute per layer. This 4 layer generator produces 480 cobble per minute, which is 7.5 stacks.

An alternate layout is possible using half as much lava in a central column:

-	T	B	C	W	-	-
T	B	C	L	C	B	T
-	-	W	C	B	T	-

This can be used if lava is at a premium at the expense of a wider footprint and the use of more redstone tubes.

Update 11 Mar 2012: Ouroborus's comment about tilings is accurate. Here are some tilings I've worked out:

Cobble generator tilings (click to enlarge).

I've built the first two designs in the first column—the ones with 4 and 12 block breakers per layer. I don't think I'll go any larger; the 12-breaker design was built with six layers and it's a beast:

Six layer cobble generator puts 72 block breakers in a 7x7 footprint (click to enlarge).

It belches out cobble at an incredible rate. However, due to the changes in Equivalent Exchange 2 the amount of EMC is underwhelming.

This will change once Eloraam releases the Pulverizer for RedPower 2. Using Pulverizers to grind the cobble into gravel will quadruple its EMC value.

Mojang speaks with authority about a mod API, but many questions still unanswered

Last week Gamasutra published Persson Hands Minecraft Lead To Jens Bergensten, 'Confident' About Move which contains the following:

Bergensten's next step is to work on the mod API for Minecraft, a feature that players have been yearning for.

"Until January I will be the only developer on Minecraft, so things will have to be slow initially. But my absolute main priority now is to create a mod API, because there is no way in hell I will be able to add as much content as the whole internet can do," he laughed.

"The game needs an API, so end users can obtain the mods without hassle.... I'm not going to do it all by myself though. We have a new programmer beginning in January, and we are talking to existing mod API teams, such as Bukkit, Minecraft Forge, and Minecraft Coder Pack."

As for an estimated release date for the API, the new Minecraft frontman suggested that we will see a release "no sooner than March." [my emphasis]

Jens gets it. He gets that it's absolutely critical at this point for Mojang to shift focus from Minecraft the game to Minecraft the platform.

Because outside of a cultlike reverence for Notch by some Minecraft players, there's nothing tying people to the game, and a significant percentage of the user base will jump ship the moment a viable alternative arrives. Particularly if the successor offers advantages by being technically superior, or is easy to mod, or free, or some combination of the three.

And alternatives are coming, but that's for another post.

Reinforcing the technical base of the Minecraft platform will ensure its continuing vitality with users and modders and buttress it against forthcoming competition.

Additional details became available as a result of a subsequent interview with Jens:

MFM: You said in another interview you were going to work on the Mod API. I know it’s early to ask for specific details, but a lot of people are wondering do you plan on doing this through a web interface, or directly from Minecraft or the launcher?

Jeb: My plan is that you are going to find and install mods from ingame in the main menu.

MFM: How do you plan to handle it for the modders? Does the old plan of making the latest source code always available still apply?

Jeb: No, we will only release an api that you build your mods upon.

MFM: Are you going to work on the Mod API exclusively, or alongside developing new features for the coming updates?

Jeb: I’ll still add some new features, too. Currently I’m looking for a mod api team that can help me out with the modding stuff.

Will Jens announce the membership of this mod API team helping him? He specifically listed Bukkit, Minecraft Forge, and Minecraft Coder Pack, but did he also talk to the Modloader/ModloaderMP and Spout teams? And there may be additional players interested in the direction of the mod API who'd like to talk to him or be included on the team.

Changing a mod to use the new mod API may involve a fair amount of work. One can speculate that a certain amount of lobbying must be going on behind the scenes from proponents of the various APIs. If two APIs offer similar hooks implemented in different ways, modders using the technique which is selected for inclusion into the official API won't be required to make changes that are as extensive as those who use the API which implemented the techniques that were passed over.

Some of the lobbying is overt. I recall seeing on Minecraft Forum a number of messages from a member of the Spout community; the messages addressed Eloraam and touted the advantages of Spout along with exhortations to switch RedPower 2 to Spout instead of using Forge. (I can no longer find these messages; either they've been deleted, Minecraft Forum's search function is flaky, or Google's indexing of Forum messages is incomplete.)

With the prospect of a new modding system, there are many questions which arise. A sampling:

• Will the arrival of an official mod API, will Mojang withdraw permission for mods to directly modify Minecraft using decompiling/deobfuscation techniques?
• What will become of MCP? Will the community still perceive that there is value in the work needed to support it?
• If a modder needs a hook that hasn't been implemented in the API, will there be a way to request that it be added?
• Since the new mod system will likely result in more mods being used simultaneously, the demand for the limited number of block IDs will increase.  Will a Block ID-conserving practice such as specifying block types as Block ID/Tile Entity pairs become standard? Will Minecraft itself be modified to use such techniques to reduce the enormous number of Block IDs that it currently consumes?
• Will there be an option to disable particular installed mods? Currently sophisticated users are able to change their mod configurations to allow different mod combinations on a per-map basis.
• Will mod combinations/block ID assignments be stored for each map? This would support the easy exchange of maps requiring particular combinations of mods.
• If mods will be downloaded and installed from the main menu of Minecraft, where will they be hosted? Is Mojang going to offer to host the download files for mods?
• Many modders rely on ad.fly and other sites to receive a small amount of revenue when the link is clicked to download a mod. What will happen to this revenue stream?
• To date, while amassing millions from Minecraft, Mojang has done nothing to share its windfall with the mod community that helped propel the game to success. Will Mojang implement a "mod store" to allow modders to recoup their sometimes considerable time investments?

 
I'm sure that many modders will be paying close attention to the answers of these questions as they emerge.

Luke Plunkett's great Minecraft review on Kotaku

I highly recommend Luke Plunkett's Minecraft: The Kotaku Review. He does a great job of capturing the essence of the game and how it rises above its shortcomings.

I take issue with just a couple of points.

The first is that I think he's overly negative about solo play. I play solo almost exclusively and don't seem to have the issues he does. Of course, I'm now using mods to eliminate some of the tedium. And I basically ignore the Nether and End dimensions.

Then he says:

Tell me that any other game needs such extra-curricular dedication and I'll tell you it's a game not worth playing, but there's just something disarming about the way Minecraft does it that makes it all OK.

I certainly agree that games should be more self-sufficient when it comes to information, but has he forgotten MMOs such as World of Warcraft? You'll waste much time and play poorly if you don't refer to external sources of information while playing WoW. But maybe he doesn't like WoW, for this reason. It's unclear.

Plunkett really nails it in his penultimate paragraph:

It does something that's very important to a lot of people, so important that they're willing to put up with its flaws and quirks. And that something is allow freedom. Expression. Creativity. Minecraft gives you the means to truly play a game, to bend it to your whims, and not just press buttons to advance someone else's story. [my emphasis]

You make the story. No cutscenes. No voice from Headquarters in your ear explaining your mission. Just complete freedom.

Overall a terrific review of Minecraft by Luke Plunkett, check it out.

A statement on Minecraft mods copying features from each other

In No One Cares About Your Cool Game Idea, Mike Birkhead, Senior Game Designer at Vigil Games, said:

Ideas are worthless. The only currency that holds any weight is the ability and drive to execute. That awesome game idea you have, the one that’s going to “change everything”, the one that you’re going to sell for a million dollars, the one that no one has come up with yet… frankly, no one gives a shit. Harsh, but then, the truth is not pleasant; it is just that, the truth. [my emphasis]

Copying ideas and features is okay. (Copying code or textures is not, unless it is open source and the copying is compliant with the license.)

Notch himself copied the idea of the final boss fight. Years ago, before many Minecraft players were born, someone named Scorpia used to write a column for the magazine Computer Gaming World. So many games ended with a final boss fight that she coined the name Foozle as a generic one for a final boss. Since we hadn't expected it, many of us were surprised when Notch chose to make Minecraft a Kill-the-Foozle game.

The game industry has been copying itself for years! The software industry, too. Have you ever used a spreadsheet? I bet it wasn't Dan Bricklin's VisiCalc.

Many of the cases so far of mods implementing each other's features are the result of parallel development, not copying.

We've been in the early, "wild west" phase of mod development, where it was frequently possible to write the first mod to implement a particular feature. As the Minecraft mod scene matures and it becomes harder to achieve a "first", we will increasingly see mods incorporating each other's features.

In cases where parallel development isn't involved, when implementing a feature from another mod the polite modder will acknowledge the mod that served as inspiration.

But above all, no modder should criticize another modder for copying, or imply a lack of creativity. Copying is merely a sign that the "wild west" phase of Minecraft modding is coming to a close. 

[This post first appeared on the Minecraft Forum.]