Refactor GameScreen and WorldHandler

[fallenoak]

GameScreen is potentially a not-so-great place to set up the renderer and camera.

For starters, as rendering gets more sophisticated (for instance, if we begin to use multiple render passes), the WorldHandler will need to dip in to the GameScreen to interact with the renderer, or vice versa.

Additionally, at present, the initialization of WorldHandler begins loading a map-- prior to logging in or otherwise starting to interact with the game. It'd be better if the world didn't begin to load at least until the game screen is selected from the screen dropdown.

An alternative approach to this is outlined below.

Progress

• Create a new WorldRenderer class
  Responsible for: managing THREE.WebGLRenderer and render passes; managing world camera(s); updating the renderer in response to resize events; managing the RequestAnimationFrame loop
• Update GameScreen to no longer handle the camera, renderer, or the animation loop
  These aspects of rendering would instead be managed by WorldRenderer.
• Stop worldport'ing the player on construction of WorldHandler
  Instead, wait until GameScreen mounts to do the worldport. Eventually, worldport should only happen after character selection.
• Stop loading player model when Wowser loads
  Instead, wait until GameScreen mounts to do the model load. Eventually, player model loading should only happen after character selection.

[fallenoak]

@timkurvers Any thoughts on this?

[fallenoak]

I've started playing around with this idea here: https://github.com/fallenoak/wowser/tree/refactor/world-handler

I'm definitely liking the idea of moving anything relating to camera / rendering logic out of GameScreen and into a dedicated WorldRenderer.

Down the road, we could conceivably create a few more renderers unique to other contexts-- such as MenuRenderer and PortraitRenderer.

[timkurvers]

Fully 👍 on all of this. I might have a peek at some of the main menu or introduction cinematics, where this would definitely come in handy.