I've been following a JavaHub tutorial that basically uses a pixel engine similar to MiniCraft. I've attempted to make a Player Class as such, and I'm basically making a mock Pokemon game for learning's sake:
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);
}
}
I guess what I really want to do is have the Player centered in the screen and have the sprite drawn based on an Input Handler.
I have a render method in the main Game Class that I'm using to render the tiles for the map. I'd imagine I'd just need to add some parameters or methods in the Player Class? Do I create and render the sprite for the Player in the Main Class or Player Class?
Main render method:
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 the graphics that you 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.