Update ProgramDesign

ProgramDesign.md

@@ -3,21 +3,31 @@
 This section is geared towards helping describe how you may want to design a game that is built with SpriteLibrary.  This is a suggestion only.  It will probably help you to read this section, as it does contain a fair bit of hard-won thought.  BUT, every developer must make a lot of their own decisions.  There is nothing magical about this.
 
 ## One Form
-It is a lot simpler to program a game if it is all within one form.  While you can develop games using multiple forms, things can get very messy.  The SpriteLibrary was designed for use with one form, and bouncing between different forms can result in some very strange behavior.  In my [AdventureDemo](http://www.codeproject.com/Articles/1110409/Using-SpriteLibrary-to-develop-a-Role-Playing-Game), I used multiple forms.  That was a bad idea.  If I closed the main game window during a battle, the game exited and the game-menu popped up.  Then, the sprites continued to fight, even though they were technically gone.  The party continued to take damage, and sometimes die.  It was a little disconcerting.
+It is a lot simpler to program a game if it is all within one form.  While you can develop games using multiple forms, things can get very messy.  The SpriteLibrary was designed for use with one form, and bouncing between different forms can result in some very strange behavior.  
 
-The game is a lot simpler to deal with if you only have one form.  This means you draw your menu on the same PictureBox that you have your game running on.  You can change the PictureBox background, so you have a different looking window when the window is up, or you can leave it be.  It does not really matter too much.  But, please, try using putting it all in one Form if possible.
+In my [AdventureDemo](http://www.codeproject.com/Articles/1110409/Using-SpriteLibrary-to-develop-a-Role-Playing-Game), I used multiple forms.  That was a bad idea.  The main "bad" thing I did was to take a sprite from one form and try to use it on another form.  I used the [SpriteController.AddSprite](http://tyounglightsys.ddns.info/SpriteLibrary/doc/search.html?SearchText=SpriteController.AddSprite) function to take a sprite and add it to another controller on a different form. If I closed the main game window during a battle, the game exited and the game-menu popped up.  Then, the sprites continued to fight, even though they were technically gone.  The party continued to take damage, and sometimes die.  Seeing your party turn into a gravestone on the start-menu was funny, but it was a bug
 
-Having multiple PictureBoxes works fairly well, particularly with linked sprite-controllers and / or a SpriteDatabase.  Both of those allow you to define a sprite once but use it on multiple picture boxes.
+The game is a lot simpler to deal with if you only have one form.  This means you can draw your menu on the same PictureBox that you have your game running on, or have separate PictureBoxes on one form.  If you use only one PictureBox, you can change the PictureBox background when you are playing the game, vs when you are looking at the menu.   This gives you a different looking window when the game is up.  It does not really matter too much.  But, please, try using putting it all in one Form if possible.
+
+Using only one PictureBox is truly the easiest way to do it.  When you resize the form, the PictureBox can resize with it, and it does a nice job.  It is by far the simplest way to do it.
+
+Having multiple PictureBoxes works fairly well, particularly with linked sprite-controllers and / or a SpriteDatabase.  Both of those allow you to define a sprite once but use it on multiple picture boxes.  But having multiple PictureBoxes does make resizing a little more complex.
 
 ## Enum for Game Mode
-To get everything to run in one PictureBox, it is usually easiest to have an Enum, which tells you which mode you are in.  The enum might be something like:
+To get everything to run in one Form, it is usually easiest to have an Enum, which tells you which mode you are in.  The enum might be something like:
 ```c#
 public enum GameMode { Menu, Menu_Settings, Menu_HighScores, Playing, Won, Lost }
 ```
 You will have a “Tick” function (more information below), and the first thing in your tick function is to determine what mode you are in, and process things accordingly.
 
 ## Instantiate Named Sprites (or instantiate on demand)
-You often want to load your sprites at the beginning.  Sometimes, you will want to make a function, called “GetSprite”, which will find a named sprite.  If the named sprite does not exist, it will load it and name it.  If you do that, you can load and name the sprite the first time you need it.  This only works in a few cases; if the process of instantiating a sprite is quick enough that it can be done in the middle of action.  Otherwise, you will want to pause long enough at the beginning of the game to load all your sprites.
+Loading your sprites at the beginning of the game is often the simplest way to do it, but it can make the game feel slow when it first opens.
+
+Loading the Sprites the first time you use them can add some complexity to the game (though the [SpriteDatabase](http://tyounglightsys.ddns.info/SpriteLibrary/doc/search.html?SearchText=SpriteDatabase%20Constructor) does most of the work for you if you choose to use it.)  If the process of instantiating a sprite is quick enough that it can be done in the middle of action.  Otherwise, you will want to pause long enough at the beginning of the game to load all your sprites.
+
+You can make your own functions to load sprites on demand too.  That is basically what the SpriteDatabase does, but it defines all the sprite information in an XML file, which you might not want to mess with.
+
+If you have twenty or thirty sprites, you will probably want to take the time to understand the SpriteDatabase.  Otherwise, just program them into your code and load them at the beginning.
 
 ## Function to change mode
 You should create a function to change the game mode.  We will place a call for this in a moment, but for now, we do something like: