NEngine - Nishu Game Engine

This is my latest project, NEngine, or Nishu Game Engine. Its my pet project for the next month or so, and after that it will be put to use to create a game for christmas for my girlfriend! Its purpose is to be flexible, yet fast, high level, and graphically appealing. Currently I have support for:

-Spritesheets
-Texures
-Creating basic primitives
-Immediate mode & display lists
-Coloring
-Screens and changing screens
-Basic camera

I started the library yesterday (10/26/2013), so I unfortunately didn’t have time to set up advanced code like VBOs and shaders. That’s on my to-do list. I will be keeping deprecated code as the aim of the engine is to provide you with flexible code, not just modern styles. It will be a 2D library strictly, unless I really want to give 3D a go. I have already set up a small demo, but its nothing more than a moving rectangle. The library is approximately 10% finished (by my advanced calculations! :slight_smile: ), so I will not be uploading a test version for a few days!

What I want to have done

-Textures, spritesheets, advanced image manipulation
-Easy animator
-Shader support
-Advanced rendering techniques (modern opengl)
-GUI
-Support for all kinds of file types
-Maybe basic networking
-Other stuff I can’t think of right now

Here is the demo, which creates a square in immediate mode, colors it and moves it using the camera:


package com.nishu.tree;

import static com.nishu.nengine.base.graphics.GL11.*;

import java.util.Random;

import com.nishu.nengine.base.Game;
import com.nishu.nengine.base.graphics.camera.Camera;
import com.nishu.nengine.base.graphics.color.Color4f;
import com.nishu.nengine.base.graphics.geom.Shape;
import com.nishu.nengine.utilities.Screen;

public class Tree extends Screen {

	private static Game game;
	private Shape shape;
	private Camera camera;

	Random rand;

	@Override
	public void initGL() {
	}

	@Override
	public void init() {
		camera = new Camera(game.getWidth(), game.getHeight());
		shape = new Shape();

		rand = new Random();
	}

	@Override
	public void update() {
	}

	@Override
	public void render() {
		clearScreen();
		camera.translate(rand.nextInt(20) - 10, rand.nextInt(20) - 10);
		pushMatrix();
		begin();
		shape.createColoredSquare(new Color4f(0, 0, 1, 0), game.getWidth() / 2, game.getHeight() / 2, 32);
		end();
		popMatrix();

	}

	@Override
	public void resized() {
	}

	@Override
	public void dispose() {
	}

	public static void main(String[] args) {
		game = new Game("Tree", 1280, 720, 60);
		game.addMainScreen(new Tree());
		game.start();
	}

}


Just wondering what happened to your chunks etc. Remember the ones you were talking to me about.

Ah yes, I’ve iced that project for now. I was starting to write really crappy code, and I needed to take a step back for a few months. Plus, I have to write a game library, a world/block editor tool and then a game all before Christmas for my girlfriend! I’m in a crunch right now :slight_smile:

Hey cool engine! :slight_smile:
Love the logo.
I would change the “base” to “core” however, its alot more standard.

Yeah well its not my standard :wink:

Whoa, this is cool! Did you make balanced energy using this library? Your game looks cool!

So, I haven’t updated the engine in a while, and that’s partly because I encountered some frustrating bugs early on that I couldn’t solve for some reason. I decided to start again, and I re-did the whole thing. I decided to change it up a bit, and focus on more modern OpenGL primarily, but I’ll allow the user to dig into the old OpenGL code, but the functions won’t be as high level. I want to design the engine to allow flexibility, yet provide high level code so anyone can create a simple game in a matter of hours. I plan on accomplishing this by providing a massive array of functions for every class, allowing the user to have choice about what to use, but still have it easy enough to use so that anyone can understand. I’m designing it so that the user shouldn’t have to touch low level OpenGL functions unless they absolutely need to, and its going good so far.

What should I add in to the library to make it stand out from others? I want to mention that first and foremost I want to get the basic spritebatcher done. I want to create a geometry library that will allow the user to quickly create objects with predefined shapes.

[quote=“opiop65,post:7,topic:44771”]
Don’t.
Except you want confusing interfaces, ###### off users, god-like classes and extra work while maintaining.
Achieve flexibility by combining clean, small classes and objects that were designed to the point and not overloaded.

Well, of course. I wouldn’t make the user actually deal with the methods. I (and I already have started this) plan on making the engine high level so no one has to touch low level code. I should’ve said that I want to make functions that will automatically allow the user to easily create the type of game they want, and the engine will handle all the underlying programming involved in that. Some engines are more advanced used orientated, and those aren’t the people I want to target. I’ll throw in some extra wrapper classes for advanced shader usage, custom rendering techniques etc…

Here’s the repo, everyone feel free to tell me what I’m doing right so far, what I’m doing wrong, and anything you would change! My main fixation right now is the sprite batcher, I want to make sure that’s done correctly. I haven’t done a ton yet, but I just want to make sure it’s all solid before I move on.

Hm, what’s the difference between an engine and a library? It seems like all these “engines” that have been posted lately need to be included into your project, or library. Wouldn’t an engine be where you have a base, and then you import resources? I suppose though it can go both ways? :confused: Shouldn’t an engine should be a sole executable with resource files everywhere, am I wrong?

Game Engine vs. Game Library

Long story short… there is a LOT of gray area on what separates the two.

In my opinion you’re completely right, but NEngine sounds better than NLibrary or NLib!

Why not NGine?

Imo a library is a bunch of utils while an engine attempts to be something like the ‘master’ of the program and it is less easy to replace.

But this seems to be something you have to decide for yourself.

I’m torn between trying to create a full put engine and just a library of graphical, shader and buffer utilities. I think I know enough to actually make an engine, but it will have lots of dependencies on the old stack matrix and some deprecated buffer functions. I just don’t know enough math to utilize my own matrices yet! Plus, my goal of making the “engine” so high level that the average user never has to touch OpenGL directly is going to be hard to accomplish as I’ll need wrappers for everything. I have a hard time staying dedicated to projects :frowning:

As for NGine, it doesn’t roll as nicely as NEngine off the tongue. I think NEngine sounds kind of weird and funny, which I like!

NGine and NGE would be my favorite ways to refer to the project. NEngine is hard for me to say in my head…
Great project though, whatever you choose to call it. :smiley:

I take NGine as being pronounced engine so that sounds pretty cool to me

Well, NGine is cool, but I really do like NEngine. I think I pronounce it different than everyone else and that’s why I like it so much!

[quote]Great project though, whatever you choose to call it.
[/quote]
Thank you, that means a lot!

Quick update, I decided I’m going to turn this project into more of a collection of utility classes. I just don’t have the need right now to create a full out engine (or library!), so I’m just going to write small classes and throw them into the project. Anyone can then go in and utilize them however they like, I feel this is more useful for me at least, because I generally don’t like programming in engines. I seem to do better with more open style libraries, and this really does it for me!

Yes. This is such a good way to do things.
Too many libraries you just want for one or two things but require everything else as well.

Plus it becomes easier to learn from the code since you don’t har to dive into a web of other irrelevant library components.

Best of all it makes it extremely easy to avoid the ‘too-many-options’ syndrome most bug librarie have where they try to cover edge cases but in he end make confusing APIs and fail the edge cases anyway. Let the user figure out their own edge cases and KISS.