Beginnings of a 2D Java game engine

I've been out of working in Java for quite some time now (almost two years), so I've been working on a fun side project just to get back into the swing of things.

Essentially, in the long term, the goal of this will to be to compile a library that can be used in to create basic platform-like 2D games.

I'm never dealt with the development of engines themselves, so I was wondering if I could get some feedback on how the engine itself actually runs. I'm also just looking for overall input - is this a well-written Java library so far?

```
package io.code.gm;

import java.awt.BorderLayout;
import java.awt.Canvas;
import java.awt.image.BufferedImage;
import java.awt.image.DataBufferInt;

import javax.swing.JFrame;

import io.code.gm.Input.GMInputHandler;

public abstract class GMEngine extends Canvas implements Runnable {

private static final long serialVersionUID = 1L;

public GMInputHandler inputHandler;

private boolean executionStatus = false;

private JFrame frame;
private BufferedImage image;
private int[] pixels;

private int updateCount = 0;
private int frameCount = 0;

private int updates = 0;
private int frames = 0;

abstract void init();
abstract void update();
abstract void render();

public GMEngine(String title, int width, int height) {
super();

this.frame = new JFrame(title);

frame.setResizable(false);
frame.setSize(width, height);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.setLocationRelativeTo(null);

frame.setLayout(new BorderLayout());
frame.add(this, BorderLayout.CENTER);

frame.setVisible(true);

this.image = new BufferedImage(width, height, BufferedImage.TYPE_INT_RGB);
this.pixels = ((DataBufferInt) image.getRaster().getDataBuffer()).getData();

init();
}

public synchronized void start() {
this.executionStatus = true;
new Thread(this).start();
in

A few abstract notes about game engines and going with the times:
Choice of UI-Framework

You have chosen Swing as your UI Framework. This is a decision I frankly cannot understand. Swing has been officially deprecated in favor of JavaFX. Not only that, Swing is slow.

It's not getting easier by virtue that I know of no way to load textures in Swing. Also there's no proper integration for OpenGL (let alone any other render engine) into Swing.

These problems could easily be remedied by instead working with JavaFX, which is the new official UI framework and has acceptable, if not good integration for OpenGL through javafx.scene.canvas.Canvas
Raw AWT

Working on raw AWT to integrate free drawing with java.awt.Canvas is a royal pain and actually just a workaround for the lack of proper support in Swing. You shouldn't have to work against your UI Framework. Instead work with it and use it to your advantage. Leverage it.
Design mistakes and OOP violations

Making your GMEngine an abstract class is probably a good move. Making the stuff I need for drawing inaccessible from subclasses probably isn't.

Note that most graphics engines are expected to work on a different basis than your "Engine". This comes back to favouring Composition over Inheritance. The point I'm trying to make is that an Engine should help a programmer get work done in significantly less steps than it needed before.

It should boil down to loading Textures, positioning them and then calling something like render() repeatedly after updating the texture positions. This is simply speaking impossible with your current design, because I as "user" of your Engine have to write the code to do that myself anyways. It would've been easier for me to just write those 200-ish lines here myself, because then I have the full control over what I render and only insignificantly more work.

I think you should revisit your motivations for this class and get a clearer idea for what it should actually do to make life easier for you (and other programmers).

StackExchange Code Review Q#124058, answer score: 5