Line 13: |
Line 13: |
| === Using Subpackages === | | === Using Subpackages === |
| | | |
− | Rather than clutter up a single class and package with everything, it is recommended you break your mod into subpackages. | + | Rather than clutter up a single class and package with everything, it is recommended you break your mod into subpackages. Below are a few possible methods for laying out your folder structure though you may as well come up with your own layout too. |
| | | |
− | A common strategy is to make a subpackage for grouping classes that have a common purpose. For example, your blocks classes can be under <code>blocks</code>, your entities classes can be under <code>entities</code>, your helper utilities can be under <code>helpers</code>, etc.
| + | * '''Group by Logic''': One possible strategy is to make subpackages for logical units of your mod. For example, if you have a block called Super Furnace you would put its block, its block entity and its item all under <code>feature/superfurnace</code>. |
| + | * '''Group by Function''': Another common strategy is to make subpackages for grouping classes that have a common purpose. For example, your blocks classes can be under <code>blocks</code>, your entities classes can be under <code>entities</code>, your helper utilities can be under <code>helpers</code>, etc. |
| | | |
− | It is recommended to add a <code>client</code> subpackage under your main package, to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers.
| + | No matter how your final structure looks like it is highly recommended to add a <code>client</code> subpackage under your main package. This helps to isolate your [[Sides|client-only code]] from the rest, such as your GUIs and renderers. |
| | | |
| By keeping your code in clean subpackages, you can grow your mod much more organically. | | By keeping your code in clean subpackages, you can grow your mod much more organically. |
| + | |
| + | {{Tip|If you are unsure on how exactly you want to structure your mod it can be a good idea to look at the source of others to see how they did it.}} |
| | | |
| == Class Naming Schemes == | | == Class Naming Schemes == |
Line 27: |
Line 30: |
| The usual style is to use suffixes for your classes, for example: | | The usual style is to use suffixes for your classes, for example: |
| | | |
− | * An <code>Item</code> called <code>PowerRing</code> would be in the <code>items</code> package, with a class name of <code>PowerRingItem</code>. | + | * An <code>Item</code> called <code>PowerRing</code> would have a class name of <code>PowerRingItem</code>. |
− | * A <code>Block</code> called <code>NotDirt</code> would be in a <code>blocks</code> package, with a class name of <code>NotDirtBlock</code>. | + | * A <code>Block</code> called <code>NotDirt</code> would have a class name of <code>NotDirtBlock</code>. |
− | * A <code>TileEntity</code> for a block called <code>SuperChewer</code> would be in a <code>tile</code> or <code>tileentity</code> package, with a class name of <code>SuperChewerTile</code>. | + | * A <code>BlockEntity</code> for a block called <code>SuperChewer</code> would have a class name of <code>SuperChewerBlockEntity</code>. |
| | | |
| == The Mod File == | | == The Mod File == |