Janin posted:

zootm posted:

This is apparently a method which can return a varied number (using the Random) or a constant depending on what type of block (allegedly what the class represents) it is. It's sadly not a coding horror.

zootm posted:

This is apparently a method which can return a varied number (using the Random) or a constant depending on what type of block (allegedly what the class represents) it is.

The Reaganomicon posted:

This sounds as abominable as copious goto usage. Is there a justification for it?

Internet Janitor posted:

zootm: Wouldn't it make more sense to make methods like that take no arguments and access a static Random instance somewhere if they need one?

zootm posted:

Maybe. I don't think that it's a terrible horror, though. Avoiding centralised static instances isn't a particularly poor coding pattern, given that even in this case it couples everything that uses a Random together. Having said that passing the Random in to the constructor might have made it easier to deal with, and the static reference would hardly be a sin in a monolithic codebase like Minecraft or 90% of other software.

No Safe Word posted:

What is so abominable about it?

Some blocks always spit out the same number of items, some blocks spit out a random number and use the passed in RNG. This one is for a particular block that produces four of something. But it has to conform to the block interface so it just doesn't do anything with the Random.

As to why he doesn't just use a public static RNG elsewhere, I don't know but that doesn't make this abominable

quote:

When you define static fields (also called class fields) of type String, you can increase application speed by using static variables (not final) instead of constants (final). The opposite is true for primitive data types, such as int.

For example, you might create a String object as follows:

private static final String x ="example";

For this static constant (denoted by the final keyword), each time that you use the constant, a temporary String instance is created. The compiler eliminates "x" and replaces it with the string "example" in the bytecode, so that the BlackBerry® Java® Virtual Machine performs a hash table lookup each time that you reference "x".

Lysandus posted:

http://docs.blackberry.com/en/developers/deliverables/5716/Using_static_vars_for_strings_447038_11.jsp

quote:

Optimizing division operations
Division operations can be slow on BlackBerry® devices because the processor does not have a hardware divide instruction.

When your code divides a positive number by two, use shift right by one (>> 1). Use the shift right (>>) only when you know that you are working with a positive value.

Code sample

int = width >> 1;

Ugg boots posted:

Oh god, this is a Blackberry JVM implementation only thing, right?

quote:

Optimizing subexpressions
If you use the same expression twice, use a local variable.

Code sample

int tmp = i+1; one( tmp ); two( tmp );

Scaevolus posted:

It's probably a straightforward interpreter, with zero optimization:

Outlaw Programmer posted:

Wouldn't replacing division with bitshifts be the compiler's responsibility, and not the interpreter?

As for the Minecraft code, isn't the real WTF that all of his blocktypes are defined by the code instead of in a property file or separate scripting language? I realize this guy wrote 99% of the code by himself but I can't imagine any artists or game designers that want to write Java code just to add in a few new assets.

Scaevolus posted:

It looks like the Blackberry JVM is really bad

Ryouga Inverse posted:

No. If blocks can have different behaviors based on their type then it's not really a horror to implement those behaviors in code. Where the code is stored isn't really of concern - if a game designer wanted to create a new block type with its own custom behaviors they'd have to write code no matter what. Implementing something that lets you write the code in a language other than Java is a ton of work for no gain.

Ryouga Inverse posted:

No. If blocks can have different behaviors based on their type then it's not really a horror to implement those behaviors in code. Where the code is stored isn't really of concern - if a game designer wanted to create a new block type with its own custom behaviors they'd have to write code no matter what. Implementing something that lets you write the code in a language other than Java is a ton of work for no gain (everyone working on the project right now knows Java ... at least, for some definition of "knows")

ToxicFrog posted:

Untrue. If that were the case, languages like Lua wouldn't be showing up all over the place. Pulling this sort of game logic (as opposed to engine logic) into external scripts has a number of benefits, including making it a shitload easier to mod, and making development easier because you no longer have to recompile the entire game every time to change something - just "/reload" from in game and your changes are ready to be tested.

This also means you can make your game crazy moddable without exposing the guts of the engine to everyone, although in Minecraft's case specifically the obfuscation used is so pitiful that it hardly matters.

It's not "a ton of work" either; if you're using something like Lua, there are seamless or nearly-so Java APIs to it. It's trivial if the engine is designed with this in mind from day one, and even retrofitting it in isn't very hard.

Kelson posted:

Oh come on; pulling game logic into external script files provides some enormous advantages on big projects, but hefty costs initially [especially to retrofit]. Perhaps he should rend the behavior code free, integrate a scripting engine, and refactor surrounding code to handle scripts properly. Perhaps that's too time/effort intensive though.

Almost all individually (and many professionally) developed games start with behavior logic hard-coded. As they become successful, they shift models to pull the behaviors into external data files. Neither way is terrible, or cost-free. One should note it only makes development easier if you're spending a significant amount of time modifying script-effected-behaviors. Retrofitting, while not insurmountable, could easily take weeks given the existing code base. That's a lot of time without bug fixes, other features, or whatever. It's a trade-off (though I agree he should make the investment).

Outlaw Programmer posted:

I think that might be better expressed in a properties file like:

code:

block.grass.numRubble=2
block.grass.sprite=path/to/grass.png

block.snow.numRubble=2+rand(2)
block.snow.sprite=path/to/snow.png

Outlaw Programmer posted:

Even without Lua or another scipting framework, externalizing these things can give you a lot of flexibility. This isn't just specific to Minecraft; I've seen it in production business code as well. Java developers are almost infamous for favoring complex type hierarchies when some other options might be simpler and more flexible.

Outlaw Programmer posted:

Even without Lua or another scipting framework, externalizing these things can give you a lot of flexibility. This isn't just specific to Minecraft; I've seen it in production business code as well. Java developers are almost infamous for favoring complex type hierarchies when some other options might be simpler and more flexible.

quote:

This is the fatal mistake made by frameworks like Spring XML, as well. As awful as Java can be, it is not improved by replacement with XML. These "configuration" files are always deployed along with the application and are never changed at run time. They dictate the wiring and behaviours of code and are rarely anything other than a representation of a shorter Java program. These configuration files are, in other words, code, albeit code with little to no compile-time checking and a more verbose syntax.

ToxicFrog posted:

Who the gently caress uses floats to store monetary amounts

Internet Janitor posted:

Google Docs is implemented in Javascript. If I understand correctly, JS numbers are ALL stored as 64-bit doubles.

Sewer Adventure posted:

Yeah but still they should ditch the decimal point and treat the numbers as cents

ToxicFrog posted:

^^ I don't disagree, but where zootm's argument goes off the rails in the assumption that any use of external scripting or configuration falls into this category. The experience of Adobe, Blizzard, Gas Powered Games, Firaxis, and Relic directly contradicts this, and shows that such an architecture has very real benefits.

Outlaw Programmer posted:

If you've ever played Minecraft, you'll see that most of the blocks (dirt, stone, sand, gravel, snow) are really similar. The differences between them are mostly superficial: their appearance, what tools work best on them, whether or not they are affected by gravity, etc. I feel that each of these behaviors would be better implemented as parameters or properties instead of subclasses.

quote:

Anyway, I would agree that in many cases, I would rather just express this stuff in pure Java code. However, I feel like notch really backed himself into a corner here, maybe because he didn't anticipate how popular Minecraft would become. His inheritance approach probably did speed up his initial development, but now that there is demand for a true mod community, he might be better off with a different approach.

zootm posted:

I don't disagree with that in general but due to Java's general suckiness, passing in a dynamic value like this as a parameter is non-trivial. Unless you want to pass in an implementation of some obscene interface called BlockDispersalCalculator or something, you're stuck. It is a language limitation though, what you suggest is generally sensible.