package pokemon.entity;
import java.awt.Rectangle;
import pokemon.gfx.Screen;
import pokemon.levelgen.Tile;
import pokemon.entity.SpritesManage;;
public class Player
{
int x, y;
int vx, vy;
public Rectangle AshRec;
public Sprite AshSprite;
Screen screen;
Sprite[][] AshSheet;
public Player()
{
AshSprite = SpritesManage.AshSheet[1][0];
AshRec = new Rectangle(0, 0, 16, 16);
x = 0;
y = 0;
vx = 1;
vy = 1;
screen.renderSprite(0, 0, AshSprite);
}
}
public void update()
{
move();
checkCollision();
}
private void checkCollision()
{
}
private void move()
{
AshRec.x += vx;
AshRec.y += vy;
}
public void render(Screen screen, int x, int y)
{
screen.renderSprite(x, y, AshSprite);
}
}
private void render()
{
BufferStrategy bs = getBufferStrategy();
if(bs == null)
{
//Technically 3 dimensions;
requestFocus();
createBufferStrategy(3);
return;
}
level.renderBkgrd(xScroll, yScroll, screen);
level.renderSprite(0, 0, Ash.AshSprite);
for(int i = 0; i < screen.pixels.length; i++)
{
pixels[i] = screen.pixels[i];
}
//Here are your belovedthe graphics that you so meticulously use to put in a separate paint method.
Graphics g = bs.getDrawGraphics();
g.drawImage(image, 0, 0, getWidth(), getHeight(), null);
//If they are already drawn, don't show them again.
g.dispose();
bs.show();
}
...And level.renderSprite() is what I thought would work...But without it the code gives me a NullPointerException.
Update:
Normally, a Game/Board/World class can aggregate all of the object updates and renderings. Knowing what I do now, in a World update() method, I typically throw the player.update() method in there and the drawing method in the World draw() method. The answer concerning through objects into an object manager is also a good suggestion, especially considering you could have multiple different enemies that will probably be deleted or updated synchronously in the near future as the game runs.
It appears I had a specific problem with an NPE (as general as it can be). It looks like I was over-complicating things way too much: I could just abstract the render/draw method out and have a player sprite (determined by the Player Class, if need be) rendered at the player's coordinates (again, determined by the Player Class). As you can see in the Player Class above I have a render method which calls the screen render method while I'm fiddling around with the Level instances rendering something in the main render() method and it's just a hot mess.
Moral of the story: A good game dev tutorial will offer you the reason for their methodology based on design patterns like separation of concerns that make the code much more maintainable.