Better practices in large Html5 projects? (Mainly Javascript but some Html/Css)

The biggest arguments against previous JS exploits have been tons of global variables and the increased potential for collisions... the simplest way around this has historically been namespacing...

//"this" is the global namespace, window in a browser.
this.project = this.project || {}; //establish project namespace
project.section = project.section || {}; // project.section
project.section.somevar = 0;
project.section.someMethod = function(){
  ...
};

This has it's ups and down sides, the upside is you get structure, and can avoid collisions... the down side is that this practice takes a lot of discipline to minimize leaky abstractions. Also, the cost of tree searching for project.section.subsection.area.method has a bit of a lookup cost.

You can reduce leaky abstractions (accidental variable leaks) by wrapping your code files in Immediately Invoked Function Expressions (IIFE)

(function(){
  this.project = this.project || {};
  //
}());

Even then, there is still a lot of work involved in maintaining such a codebase. More recently there has been a growth in module patters for JavaScript. You will probably want to think in terms of modules, and working with those modules and objects/classes they expose. Currently there are two popular patterns for this, which are Asynchronous Module Design (AMD) and CommonJS (CJS) there are also many different tools for building your modules into scripts that can be used client side.

You will most likely want to use RequireJS (AMD), and look into Bower (JS Package Manager), Grunt and Yeoman.

There are quite a few tutorials available for this, and you may want to look into a toolkit like FrozenJS, at least for structure examples.

Following is an example of how you might structure a module for your system... said module would be for a given Character on the field that inherits from field module's Entity... You would expose a constructor 'Character' that has a bind(field) method, and a render() method... to handle its' own state. You could think of this as a character controller or ViewModel (in MVC/MVVM terms).

//character.js AMD Module
define(['jQuery','./field'],function($,fieldModule){
  //module
  return {
    'Character':CharacterObject
    ...
  };

  function CharacterObject() {
    ... constructor internals ...
  }

  //inherit from field.Entity
  CharacterObject.prototype = new fieldModule.Entity();

  //prototype methods
  CharacterObject.prototype.bind = function(fieldInstance) {
    ... bind the CharacterObject instance to the field ...
  }

  CharacterObject.prototype.render = function() {
    ... render UI update(s) ...
    //assuming an event loop for UI processing
  }

  ...
});

Beyond all of this, you may want to even consider coffee-script which reduces the chance of certain behavioral issues even farther, at the cost of a middle-man language/compilation step that you may not find worthwhile.

There is really no good argument for having many global variables. Make a single global container, and stick everything inside of it.

window.globalContainer = {};
globalContainer.var1 = 1;
globalContainer.var2 = 2;
//etc

More than likely you will realize that it is possible to not even use a globalContainer as you can have everything run in a scoped environment where entry is dictated by events.

Every file which houses .js must be fetched. The fetching is slow, so you should just try to do it once instead of multiple times. Combine all the script you can into one file instead of having them all over the place. That being said, you should only do that for production - when developing you should do what is most readable. Keep in mind that your production and development javascript should always be different. One which is easy to read and logically separated, and one which is easy to transfer, and minified.

The route you take to load an image does not really matter. createImage or new Image() will both have the same results. The important thing to remember is that the actual image is not fetched until .src has been assigned. When that happens, the image is loaded. Once a browser sees a resource it caches it. So that is how the preloading magic happens. Rendering is a whole other beast. Even if you have cached an image it may take some time to render, especially if there are many of them set to render at once and they are large images.