Next time you should really make sure to clean it up before posting.

Thats why i thought you were using the fixed-function pipeline.

Looks like you aren't enabling and setting the texture coordinate attributes correctly.

you need these.
glTexCoordPointer
glEnableClientState(GL_TEXTURE_COORD_ARRAY);
glDisableClientState(GL_TEXTURE_COORD_ARRAY);

Try replacing that return statement with a break statement.

You only have the vertices and colors for a single cube.
Ideally you could just draw the single cube twice and adjust its location with the model matrix.

Edit: Oh didn't see you weren't using matrices, maybe you should consider using some.

Not quite, now you tell it to draw the same square twice.

Think of the vertices as if they are on a numbered list, the first 4 vertices in your vertices array are those of the first square.
The next 4 vertices are those of your second square.

So your indices should look something like this.

The indices simply tell the gpu which of the vertices you have sent it, it should draw, and what order to draw them in.
The advantage of this approach is that you don't need to send the same vertex several times to join multiple triangles together.
As an example you only sent 4 vertices for each of the squares, but you need 6 to make a square by combining two triangles, but two of them is already on the same location.

You need to add the other squares indices to your indices array.
The indices tells your vboi which of the vertices it should draw and what order to draw them in.

getSprites()?
In the code you posted before currentFrame isn't being instantiated either.

Edit: by the way, you really should check your code an extra time before posting more of these NullPointerException errors, because they are often easy enough to spot,
make sure you have a clear idea where your variables is instantiated.

It doesn't look like you are ever creating that SpriteBatch object, so the variable just hold a null value.

Any errors?
Just the wrong output?
What do you code look like?

Edit: lost the post, this one answered.

image.getHeight();

The viewport is set automatically to whatever the display resolution is set to when created.
but you set the resolution after creating the window, so you had to set it manually.

try doing glViewport(0, 0, 800, 600); right after creating the display.

There is nothing there that requires it to be static, but you made the field static, so the it has to be called statically when you draw it.

On the line g.drawImage(Tiles.tileImg, Level.thex, Level.they);
remove "Tiles."
and remove the static modifier on the field "tileImg".

Seems tileImg in Tiles is static, so it is replaced for "all" your tiles, every time a new tiles is created.
if I read your map creation code correctly, that means they all use "res/twat.png".

Looks like the effect that happens when you enable anti-alias on the Graphics object.
If you are, try disabling it before drawing images.

Switch

so it says

Override keyPressed(int key, char c) in BasicGameState or BasicGame.

the c parameter is similar to calling KeyEvent.getKeyChar() and the key parameter is similar to calling KeyEvent.getKeyCode()

Casting to int on rendering, is likely the best way to do it and shouldn't cause any errors.

This problem often pops up on the slick forum, and most of the time casting to int on render, is the first thing people will tell you to do.
But sometimes making an invisible 1 pixel frame around the image works too, but in your case I'd recommend casting.

Try putting these in your unit class.
Call nullifyImages() on you object just before out.writeObject(object) and call loadImages() just after loading in.readObject().

If your program still need the object after saving you can either.
1. pass the images to somewhere else, where you can retrieve them from, before you nullify the fields.
2. reload them with loadImages() after saving.

Do you actually need to save the images into a file?

Otherwise you could simply save the Image paths, then set your image fields to null before saving the file, and then after loading the file, load the images based on the path you saved.

I didn't mean to say it "did", i meant it could cause performance problems if the program would start spamming exceptions, which in turn could cause memory leak, but thanks for correcting me, wasn't really sure about what impact exceptions had on memory.

Looking at your code i don't see anything obvious that would cause memory leak, but i do have a few criticisms.

The first one, and possibly causing the memory leak, is that you silence exceptions, i see you do this a few times.
Try not to silence exceptions, because if your program is throwing a lot of silenced exceptions, it could easily cause all sorts of performance problems, and try to use specific exceptions that you know could be thrown rather than the standard Exception.

The second one, try to add more comments or arrange you code based on functionality, to make it easier to read, because large walls of code is tend to be hard to read, and limits the amount of people who would post here.

As for your drawing algorithm, it looks fine, i don't know how much of an improvement it is as i have little experience with it, but you could try using bufferstrategy rather than a bufferedimage its supposed to be faster.

I don't recall slick 2D having an entity manager, only some of its extensions that have and a few tutorials that explains how to make one.

My advise, make your own, it will be alot easier to understand whats going on, than using someone else's system.

My idea's:
For your crowd manager(npc-director), make it an entity, and make all the npc's entities too, have the npc-director create and remove npc's first thing per loop, maybe using an npc pool, npc-director could assign them behaviors too.
Then have the npc's control what they do on their own.

This is what i would do based on your description.
But its up to you, to decide how it should work.

For looks, i'd clearly say the sketched one.
When i compare the screenshots, i look at the tile-based and think "why? another one of those." but when i look at the sketched one i think "This seems interesting, wanna see more."

But for control, i'd say that the tile-based might be easiest for the player to understand and interact with, when using click and drag, while the sketched one would be better of with a different control system such as point and click.

My conclusion would be, pick the sketched one, it have the best "feel".

Sounds like you would want to use a statemachine for the different screens.
As example, create a mainmenu state that shows the buttons for each option.
The gameplay, highscores and credits would go in states of their own.