Wednesday, 9 October 2013

The most important Minecraft Classes... continued (1.8)

The Minecraft world is made up of a relatively few different types of objects.  The major ones are:


These obviously don't require much explanation.  There many different types of Blocks, all derived from the Block base class.  The Block class and derived classes do not store unique information about every location in the world (it is a "Singleton" and uses the "Flyweight" design pattern), they only store information related to the Block type.  The Block classes hence consist mostly of methods to determine the behaviour of the block and how it is drawn on the screen .  Blocks are laid out in a 3 dimensional grid, every location in the grid has a corresponding BlockID and metadata which specifies the type of Block stored at that location.  This information is stored in an array inside ExtendedBlockStorage objects.  For more information see here.  Blocks are drawn (rendered) using RenderBlocks - for more information see here.


There are some special blocks which need to store more information than a standard Block - for example the BlockSign or BlockChest.  A TileEntity is used in this case.  TileEntities are treated differently from ordinary Blocks.  Each TileEntity corresponds to a single Block at a particular [x,y,z] location.  Minecraft maintains a list of TileEntity objects, each of which stores unique information such as the text on a sign or the contents of a chest.
When rendering, the Minecraft may either render the underlying Block, the TileEntity (using TileEntitySpecialRenderer), or both.  The major difference is that the TileEntity is rendered fresh every frame, whereas the Block uses a 'cached render'  that is only refreshed when the block changes.  This means that if you want your Block to be animated, you need to either use an animated texture for your Block, or use a TileEntity.


Items are things that the player can carry, such as Pickaxe, Sword, Gemstone, Wood.  For blocks which can be mined and carried (eg stone block), this is represented by a Block when placed in the world, but is an item when carried by the player.   Similar to Blocks, each Item class is a Singleton and only stores information about the Item type.    There are many types of Item, all derived from the Item base class.  They are rendered in a number of different ways as described here.  

ItemStack is the class used when an Item is actually "created" - in addition to the Item type, it also stores the item count (eg a stack of 46 planks), "damage" (eg pickaxe "wear-and-tear" indicator), and several other pieces of information.  ItemStacks are stored in "Slots" in the inventory, in the hotbar, in Containers (eg Chest, Furnace, etc). Note: an item which is in the world (eg sitting on the ground after the player has thrown it) is represented by the corresponding EntityItem, not an ItemStack.

A bit more information about Items and ItemStacks here.


An Entity is used to represent anything that can move around - such as cows, snowballs, or minecarts.  All entities have a fractional position (unlike Blocks and TileEntities which have integer [x,y,z] only) and most have velocity information.  They receive a call to onUpdate() every "Tick" (1/20 of a second) to update their state using appropriate logic - for example updating the position for a thrown object, attacking the player for a hostile mob.

There is a rather complicated inheritance hierarchy shown below, which can be used to group Entities with similar behaviour together.  Entities are rendered using EntityRenderer derived classes, with each Entity mapped to the appropriate Renderer using RenderManager.

The EntityPlayer derived classes are special cases because they deal with players (i.e. human users) and are updated quite differently to other entities.

A note about EntityFX-

EntityFX are used to create visual effects on the client such as explosions, air bubbles, splashes, etc. Although they derive from Entity, they are not proper Entities -  they are not saved on the server; the client creates them for a short time only, in response to other events, and they are handled using totally separate code to Entities (for example - spawned using world.spawnParticle()).  All EntityFX derive from the base EntityFX.