Hi,
Welcome to JavaRanch!
When you're reporting problems, it helps to show us the actual exception stack trace: there's a lot of useful info there, and we could help you learn to interpret it.
In any case, a lot of the code where the problems might lie isn't shown here, but I'm going to say a few things anyway. In no particular order:
First, it's odd that the "ppieces()" routine seems to be expecting the gameEngine[][] array to contain Strings. For example, this line clearly thinks each element of the array is part of a filename:
Image img = tk.getImage (array[x][y]+".gif");
although this could work if the gameEngine class had an appropriate toString() method.
Second, note that Toolkit.getImage() can return null if the requested image doesn't exist. You really need to check for this and report the error sensibly before passing the img variable to g1.drawImage().
Third, "g1" is not initialized anywhere that I can see; therefore any calls to g1.anything are going to throw a NullPointerException. This really isn't the right way to do graphics in Java, anyway; you're supposed to subclass a JComponent and override the paintComponent() method; see, for example,
here. Fourth, note that allocating an array, be it one, two, or n-dimensional, only allocates references to objects, and not the objects themselves. I don't see where the gameEngine array is every filled with actual gameEngine objects. Therefore using the elements of the array for almost any purpose will, again, lead to a NullPointerException.
Fifth, Java has some fairly firmly entrenched naming conventions that are worth following; perhaps the most important is for all ClassNamesToLookLikeThis, and variableNamesLikeThis -- i.e., using "camel case", with capitalized class names and lower-case initials for variable names. These rules are important because they make it easier for other people to read and understand your code quickly.
Finally: this looks and sounds to me like an example of "big bang integration": writing a bunch of code, compiling it, and then marveling at is as it spectacularly fails to work. Experienced programmers know that the right way to do things is incrementally, in baby steps, testing at every step. Write two lines of code; test to make sure it works. Write two more, test some more. If a test fails, you know that whatever's wrong must be in the last two lines you wrote, not the last two hundred. Make sense?
So my advice to you is to back up, take a deep breath, and start over, making sure at every step of the way that each line of code does what you think it should do.
