Minecraft Forums

Quote from Caelann

And yet they brought things to Minecraft that Mojang probably wouldn't even dream of. If all modders worked together to add new things into the "trunk" of Minecraft, if you will, then all those incompatibilities would either be a thing of the past or an easy matter to sort out. I've seen enough of that in open-source community projects to know that it is possible and much better. It's not perfect, but it is better. It is also a lot of work, obviously, but if one's not willing to work, then why bother with the game at all?

Still, I do agree with the Forge problem. The idea is great but their spirit is a bit misguided. But it's still a great foundation and an example to follow and improve upon.

So ... the question is, what is the base game known as "minecraft" supposed to be?

Notch had an idea, a dream, a vision, inspired by Infiminer, and Dungeon Keeper, and others. He implemented some/most of that, and then hired Jeb.

But ... that first game, Infiminer? From what I understand, the idea was to mine the blocks out from under your opponent, but people would rather build together. The code was not obfuscated, and was decompiled -- so people were able to make their own versions of it. Rather than work with the mod community, to make a good base game that people would add to, to build a community, that developer basically said "I quit".

Notch did not. Notch accepted the mod community. I disagree with the need for code obfuscation -- a number of problems come from the workaround of an incompatible decompilation. But Notch started a base game.

Is Notch's / Mojang's implementation of "Minecraft" the only one? No. The only one with that name, but there are a number of different implementations, with different features, being worked on or released.

But then, what do you put into the "trunk"? What goes into the "Standard"? Does 15 blocks per tick of redstone make for more creativity in designs? Would 255 blocks be better? Is instant-wire a good thing or bad thing? From what I understand, redstone pre-dated pistons, and IW requires pistons.

Yes, modders bring new stuff to the game. But ...

Let me try it this way. "1,000 pictures ideas can be drawn from one word ("modding"), but who is the leader, what a help that would be." (Apologies if I got the quote slightly wrong).

Someone has to have the leadership role.
Someone has to have the job, not of chopping the trees, not of managing the workers with excersizes, stretching, back managements, etc., not just of deciding "Chop that way", but of actually climbing up a tree, surveying the land, and saying, "Hey, we're going in the wrong direction!". "Be quiet, we're making progress".

First Notch, and now Jeb, has that job.

---

The mod community is not open source. Some people are, some people are not.

But open source is not the answer. Open documentation is much more powerful, and it builds on top of it.

Lets give you an example. "Decompile my code, and read it to see what to do" -> "I gave you the source, read it and the comments" -> "Here's a description of the steps you need to go through to start with a copy, compile and test it, and then make changes and how to get us to accept those changes".

The best modders are at stage 2 in that chain, and assume that everyone else that wants to mod knows how to do step 3.

But ... well, many programs and mods have different development environments. Some people know one, some know others.

Right now, as far as I can tell, many (but not all) mods that have public source assume that you know all of the following:
1. How to use MCP to decompile.
2. How to use MCP to recompile.
3. How to use Eclispe which seems to be required with MCP.
4. How to modify java flags to work with J5 if you need to.
5. How to use Github and make copies of an existing mod
6. How to get data out of github and then back in later
7. How to get eclipse to work with whatever source code control system you know and use.

Some even go farther, and don't actually release their source on Github, or even in diff format to feed to patch. Instead, they have manually edited files showing lines and describing where to place it -- which generally only works for specific versions of the original.

So ...

Documentation on how to work on a mod (how the internals work)
Documentation on the compilation environment for that mod (how to compile, how to test)
Documentation on how to work with the system that the mod is using (both github and MCP in that example)

Lacking all that, having the source code does no good.

Minecraft 1.1 I was able to decompile with MCP. I was never able to recompile it, I had all sorts of error messages, and I got no help at all from asking the MCP people. None. So I never even got started with step one of modding.

Not from a lack of knowing java (and in fairness, I have not used anything newer than J5 yet -- I don't know what makes Generics so critical for forge or why defining an interface instead of a class for the objects being used won't work). From a lack of documentation.

Modders, in general, for this community seem to be of the "If you have earned your place in the mod community, we'll help, but you have to get there first". It's like the old days of "comp.unix.wizards is moderated, but there's no moderator". Except that back then, there was a document describing how Usenet worked, how moderation worked, and if you asked, you were referred to that document. Github's help system ... seemed more confusing than explaining; eclipse documentation seems non-existent, and no one has pointed me to anything on it, and MCP's failures ... I got nothing back at all. So I can't even get started on forge, or getting portions of it to work in J5. And even if I could, then what? If I could get FML plus the dictionaries plus the ability to work with new blocks and entities, enough to support new ores, new trees, new leaves, etc -- but forge would not accept the commit, and no one knows of, or even knows to use my work?

Forge, as I understand it, was made to support IC -- so it has a lot in it, because it was to support a large mod. It was not broken up into parts. The whole idea of FML being stuck inside forge instead of being separate because "Users can't understand the concept of order of installation", ...

Maybe this example will make it clear. Tell me why modders do not always release something that you can toss at Magic Launcher, and say "Install with Magic Launcher". Why does everyone say "Start with a clean jar, then dump my stuff in"?

Why does everyone start at square 1 and assume you aren't working with anything else? Why not point all the users at tools specifically for working with non-modded jars and other mods? Why do people not package the contents of a directory containing class files, but instead package directories, or sometimes multiple directories, requiring the whole thing to be unpacked and repacked?

The reality is that a large portion of the modding community has a very strong ego. The "This is my way, take it or leave it" approach exists in large amounts.

The idea that modders will work together? It happens. But I would not call it the rule.

===

And, mods don't work together. Not without a lot of work. And guess what? That work defines the start of an API for mods.

The Forge dictionary is one such. But ... well, it's an ore dictionary. What if you want a leaf dictionary? A tree dictionary? A this, that, other dictionary?

Why not a dictionary of dictionaries?

Why have multiple dictionaries? What about defining properties of materials, of blocks, etc?

What if two different mods want to use the same ore, like tin, in two different ways -- so one set of recipes has you smelting the tin ore, and the other set has you using the tin ore.

Or if two different mods use the same ore in different names?

What about custom map makers that need to work with different stuff?

===

Mods work together when two different mods that do not know about each other, where the different authors have not had to modify their mods to work with each other, just work. That requires an API.

My personal favorite example, and this is real, by the way, is to combine Biospheres, Mystcraft, Extra Biomes, and Better Ore Distribution, along with my own idea for Mananium (found high in extreme hills rather than deep in the depths -- http://www.minecraftforum.net/topic/1224140-game-balance-idea-for-new-ore-mana-rich-enchantability/ ), and nether ores, to all work together.

Extra Biomes and Mystcraft are being co-modified.
EB and BOD are being co-modified.
Biospheres would probably have to be re-written

Different mods would want to decorate different areas of the surface, or the underground, differently -- BOD and Mystcraft want to alter the depths, EB wants to alter the surface, MC wants to work with EB's surface, and if Bio works with MC then MC (and possibly EB) needs to alter Bio's surface.

Nothing like that API exists that I know of.
It's being developed in pieces by different groups.

And if you've ever worked with multiple API's from multiple groups as opposed to a single consistent, well-designed API from one small group or single individual? Worlds apart.

http://www.minecraftforum.net/topic/1127382-mod-api-ideas-and-concerns/

Agreed, that mod does wonders. But something tells me Mojang would prefer to try and mimic their own Optifine before they'll ever hire or even just ask for its creator's help. And it's that kind of pride that tarnishes my opinion on Mojang.

It is my understanding that Mojang did offer to buy Optifine. But it's also my understanding (warning: this is third hand info, and may not be accurate at all) that the value offered -- $10,000 -- is no where near appropriate compensation for something that represents 6 months of work (which is probably the minimum value for the current state of Optifine), and certainly not even close to the actual development time (including all the wrong turns and work that had to be pulled out). Buying code from someone else makes sense if you are trying to minimize your risk, your development time, and protect you from the risk of lost time from bad ideas and implementations. But buying insurance means paying more.

I didn't say Mojang was completely unprofessional, nor did I say I know how a company should act. I simply said what they did with this update was unprofessional,

Ding.

You called this update unprofessional. So you have an idea of what is "professional", of how companies should act.

So, clarify for us please. What is professional?

Rather than unleashing a buggy update into the public, they should've tested it further with additional snapshots, for as long as it required. Call them release candidates, if you will.

Gee, good idea. Maybe if Microsoft did that, would they be professional? What about Sony, or Blizzard, or ...

Or any company that says "This is the date we ship off the gold master, this is the date we release". Heck, to my knowledge, every company in the industry sets a release date before they have gone through release candidates.

The people who do release candidates until it works? The independent hobbyists.


====

Seeing as I'm not a programmer myself, I can't really provide a personal opinion, but I've had programmers and developers mention languages such as C++ as an alternative. The point is Java is a great language for certain applications, but for games like Minecraft it's not as optimal as it could be. Maybe if Minecraft were a simpler browser game, then it would be more adequate.

Alright, then here's a very important rule of thumb for programming languages.

Very few have any real difference in execution speed.

Yes, you heard that right. Very few have any real difference in speed.

Knowing how to get the speed out of your language is something else.
Having a good, mature compiler helps. New languages tend to have weak compilers.

Java really was not well designed in this regard, as the bytecode model was not "write the compiler once, for this relatively simply set of instructions, and you're done". If it were, then once you had the language compiler working for one version on one CPU, you'd just use the same compiler for that CPU on the next version. Instead, there's lots and lots of changes from version to version, and the compiler has to keep being modified, as does the system API interface, etc.

The result? Some CPU/OS combinations have better java's than others.

If you know Prolog, then consider this: People who know prolog well can write prolog code that runs as fast as the C++ equivalent. And prolog is normally considered one of the slowest languages because bad prolog code is very slow and easy to write.

For the case of Java vs Scala vs C++ vs a Google internal language, Google did a study. They concluded that C++ was fastest, but not by much, and only because Java/Scala are dependent on garbage collection tuning, and how to tune it is not obvious or well documented. Equally, it looks like Scala is the better langauge for writing/designing code in. (Scala, if you are curious, is a language that compiles to Java bytecode, and runs on the JVM. It is similar to Java, and could almost be described as Java++ -- except that most C is legal in C++, and as I understand it, most Java is not legal Scala.)

The Register:
According to Google's tests (PDF), C++ offers the fastest runtime of the four languages. But, the paper says, it also requires more extensive "tuning efforts, many of which were done at a level of sophistication that would not be available to the average programmer."

Google's paper: https://days2011.scala-lang.org/sites/days2011/files/ws3-1-Hundt.pdf

Should minecarts be destroyed if you break them?
Should stone bricks turn into cobblestone if you break them?
Should staircases turn into wood planks if you break them? Or cobble/etc?

Should sandstone turn into a few pieces of sand?

Nothing else in the game (well, glowstone, and maybe bookcases) is destroyed and yet pick-up-able. (Glass is destroyed and not pick-up-able).

Boats being unrecoverable is just not minecraft.

"Destroy" == "Pick it up". That's just how it works in the game.