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:

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! ), so I will not be uploading a test version for a few days!

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

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.

I plan on accomplishing this by providing a massive array of functions for every class,

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? :/ Shouldn't an engine should be a sole executable with resource files everywhere, am I wrong?

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

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!

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!

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.

Definitely! That's the whole reason I only used LibGDX once or twice; it just wasn't flexible enough for me and I hate not knowing exactly what everything does. A utility library seems to suit me well because you can abstract them and do whatever you want with them. I don't need to pass in a texture as a parameter for that sprite because I can create a new constructor that doesn't require a texture. You simply just can't do that in engines that don't support it. I can quite honestly say I think I'm done with engines unless I absolutely need them because a teacher says I do or a job says I need to. I just don't like using code I haven't written!

I await the people who will bash on me for not taking the easy way out of things

I decided to turn this into a utility library instead of an engine. So, here's my first update of the new library. Please note that some of the code I'm using I've taken from other people over the years. Basically, code hoarding. It's temporary until I decide to re-write it, but oh well.

ResourceManager (tookthegeneralideaofthisclassfromwessles' engine (sorry!), it holds hashmaps that store data. I added support for adding in your own custom hashmaps, so you aren'tstuckwithmyhardcodedones. Stillneedtoworkonitalittleandaddmorestockmaps.)

SpriteBatch (Large class, only half complete, that batches geometry together for rendering. It utilizes VBOs and VAs to render static geometry and dynamic geometry, respectfully.)

Texture (Utility class to load and bind textures. Only half done)

Time (Small utility class that gets the current time and handles the delta)

Vector2f (Two dimensional vector. All the math is complete!)

Vector3f (Same as above just three dimensional and with more complex math)

Window (Static utility class that creates, updates and destroys the current OpenGL/Window context. Still need to add support for different display modes and other stuff.)

So, that was a huge list (Looks significantly smaller when actually looking at! it, oh well!) I'll probably release the first version once the sprite batcher is finished, so maybe in a few days. For now, here's the repo to go look at all the code! Sorry, its very undocumented!

I wanted to show off a little, so I decided to create a new program that has a 3D camera in place, a game loop that lets you limit the FPS and a Window. I was able to do this all in 45 lines of code (not including the extra spaces and imports)! I'm pretty happy with it, and I can further reduce the amount of lines by wrapping all the low level OpenGL functions into a separate class. Here's the example code:

And a little update on the spritebatcher; Its pretty much finished, I just need to add color and texture support. Furthermore, I need to remove any dependencies (or allow you to not use the class with any dependencies) on the other classes in the library. Should be pretty easy to do!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org