inQ is a simple game engine written in Java
I am passionate about games and I love solving problems, so it made sense to me that a game engine was the obvious choice for a large-ish summer coding project. It started off as a small UI test but the more I worked on inQ, the more things I wanted to implement. I've had a lot of fun learning and creating with this project. So, even though it's on hold, I'll be back.
The info below isn't an overview of the entire project, but it serves as a brief description of some of its systems. If you would like to see some of what was completed over the summer of 2016, please download the inQ_Test.zip from the inQ GitHub repository. If you value your time and would rather get it from here instead, click the "inQ_Test POC" button below.
The proof of concept consists of a level with dynamic and static scenery objects, a controllable character, a highlightable clicky, and a fading wall. Use the 'A' and 'D' keys to walk, and press the spacebar to jump.
If you'd like to see the code, check it out on GitHub.
GRAPHICS
inQ currently uses Java and its AWT graphics API for rendering. The main graphics class extends a JFrame with repaint disabled so AWT and Swing will play nice. The graphics class also has a Canvas, with a double buffered BufferStrategy, which serves as the front and back buffer. At the start of each render call, a compatible BufferedImage is created and drawing is delegated to all of the inQ view components; this creates a composite image of the scene which is then clipped to the size of a camera object's viewport.
Right now there is a large bottleneck during render time. After doing some research I found that Java's native graphics API might not be powerful enough for the sort of engine I would like to build (surprise!). I'm now working on an OpenGL based engine written in C++ in hopes that I can alleviate the problems inQ is experiencing with AWT.
PATHING & MOVERS
The pathing system in inQ is implemented with a matrix of pathing cells, with each cell having an enum signifying its pathing type. As collidable actors move through the game space, their mover system checks the scene state's pathing map to see if nearby cells allow that mover's pathing type. Movement involves a mover system which is attached to a moveable actor, and mover modules which can be attached to the moversystem. The current scene state issues movement commands (i.e. walk, jump, etc.) to the actor state which delegates to the mover system.
I think these systems could use some redesign, but right now the biggest problem is that jumping and jumping while moving don't function well. With the C++ and OpenGL engine in the works, I think any redesign and problem solutions will likely end up in that version instead.
INTERACTIVE OBJECTS & GAME EVENTS
Interactive objects mainly consist of subclassed actor and actor state objects. They may have additional attributes such as fading and highlighting, both of which can be disabled, and can have a game event added to them using an attach method. Game events are the basis of what will eventually become the scripting system, and currently come wrapped in one of two trigger objects: timed event and area trigger.
I'm kind of a sucker for abstraction and modularity. Thus, I try my best to implement everything so that it can be customized to some extent. For instance, you can create an interactive object with an attached trigger area, give it a game event that tells it to fade, then have a fading wall like the one in the inQ_Test program. I believe that designing and building with abstraction and scaling in mind can make additional features easier to implement in the future, like an editor. In reality it may not always be so simple, but I believe it's good to have an idealistic springboard to start from.