Overview of Forge (and what it can do for you)

The main purpose of Forge is to allow multiple mods to be installed without interfering with each other. It does this in a few ways;

1. providing a standard mechanism to load and initialise mods.
2. providing ways for your mod to interact with the vanilla minecraft code without you having to modify or overwrite any of the vanilla code.
3. allowing your mods “assets” (custom sounds, textures, etc) to be stored in your mod’s zip file instead of in the vanilla assets folder.

Loading and Initialising your Mod

Forge achieves the first objective by searching for your mod in the mods folder. When it finds your mod, it uses a technique called reflection to discover which of your mod’s methods it should call to initialise it. During initialisation, your mod then calls a number of forge methods to instruct forge on how to interact with your mod’s code.  More details below.

The load and initialisation sequence is covered in some more detail here.
Forge also uses a file called Mcmod.info (if provided by your mod) to display a description and other information about your mod.

Avoiding the need to modify vanilla code

The three key ways that Forge achieves this second objective are:

1. providing a number of Registries where you can register your new Blocks, Items, Recipes, etc, so that the vanilla code can interact with them.
2. adding extra methods to the vanilla base classes (eg Block), so that your code can override them when you extend the base class – i.e. using inheritance to make vanilla code call your new code.
3. providing a multitude of “events” that your mod can register its interest in, for example “call myModTickHandler every 1/20 of a second” or “call mySleepHandler” every time a player sleeps in a bed.

Loading your mod’s assets

Forge adds your mod to the list of places that minecraft searches when it’s looking for assets. The most confusing part of the assets folder is that you need to know where to put it! When your mod is packaged up as a zip and placed in the mods folder, this is easy.

Basic structure of the zip file for an example mod "speedytools".

When you’re debugging, it’s a bit harder. You need to find the base path that Forge looks in. To be honest I’m not sure what this is supposed to be. Here is how I figured it out for my setup:
http://www.minecraftforge.net/forum/index.php?topic=11963.0
If you're using Eclipse (which I'm not), apparently you should put your assets into 
\src\minecraft\
 in order to get them copied into the right place during debugging.

Based on painful experience I'd suggest you use lowercase for your modid, folder names, and filenames. This will avoid subtle problems where (eg) textures are loaded ok during testing but can’t be found once packaged up into a zip (zip files are case-sensitive, windows folders aren’t).

For those who are interested - FMLFileResourcePack and FMLFolderResourcePack are the two classes that Forge uses to represent your mod assets, i.e. textures, sounds, etc - either as a file (zip) or a folder respectively. When minecraft goes looking for (eg) a texture such as “mymod:myawesometexture.png”, it uses “mymod” to identify the correct FML Resource Pack and pull the correct data out.

---

~Overview of Forge (and what it can do for you)
    Forge concepts
           Some general notes
           How Forge starts up your code (@Mod, @SidedProxy, etc)  
           Registering your classes
           Extra methods for vanilla base classes
           Events
     Forge summary - grouped by task
           Blocks
           Items
           TileEntities
           Entities
           World generation, loading, saving
           Miscellaneous - player input, rendering, GUI, chat, sounds