Collision Detection

After reading some comments about The Render Engine it became apparent that the engine doesn't offer any really good way to do narrow-phase collision detection.  The SpatialGrid gives developers a quick broad-phase method of finding potential collisions, but when two objects are determined to be possibly colliding, it's up to the developer to implement some sort of narrow-phase detection.  I figured with the engine being what it is, it should at least offer one implementation out-of-the-box, so I've been looking into the GJK algorithm to solve the problem.

In the trunk I have added a method to quickly determine an approximate convex hull from a set of points, and also a method to compute the Minkowski Difference of the two hulls.  Eventually, there will be a method to perform GJK on the two hulls so that the amount of interpenetration can be determined and the appropriate collision response performed.  There are other methods, which I may implement in the future, such as the Separating Axis Theorem since it really isn't that far off from what I'm doing with GJK.

As an engine, The Render Engine needs to provide these operations to make game development that much easier on a potential developer.  Even though the engine does resource loading and rendering, it has to provide a more robust feature set for all potential problems which must be solved.  With the scene graph being fairly solid, and resource loading working as it should, I can focus on adding features which developers can use to enhance their game experience.

To me it seems like I've done a lot already, but I've only just scratched the surface.  To be a complete engine, there needs to be at least one implementation of certain features such as:

• Narrow-phase collision detection
• AI/Pathfinding
• Multiplayer/Networking
• Tilemap management
• UI Management

Of these, I was planning on everything except the collision detection.  As it stands now, the engine is already quite robust but it has a ways to go before it is truly a complete solution.

The Render Engine on Hacker News

An in-progress game, made with The Render Engine, called Pistol Slut was #1 on Hacker News today for a while.  The engine has also recently appeared in some beginner tutorials.  This only emphasizes the need to get v1.5 out the door as soon as possible!  I'm a little disappointed that the comments for the engine, by its author, were:
 

"The engine I used is mostly a drawing engine, with some basic game stuff included (particles, the beginnings of collision detection)."
 

It makes the engine sound a little amateurish.  Yes, it's only v1.0 of the engine, but The Render Engine is much more than just a drawing engine.  It's a framework that gives a game developer time to work on game mechanics rather than core functionality.  Is there something else that the engine should include that isn't there?  Anyway, it's still good to see it being used!

Announcing v1.5!

In an effort to get fixes out the door which have come up as part of the v2.0 development track, I am going to select some features and accelerate their development to get them out the door as v1.5.  The features I am thinking of including are:

1. Container and Iterator enhancements
2. IE support via FlashCanvas integration
3. New profile display
4. Updated resource loaders
5. Particle engine improvements
6. Basic physics (circle & box bodies, distance & revolute joints)
7. 2 Physics demos

I'm hoping to get v1.5 out before the end of October.  v2.0 will continue to be developed, but I want to get something out there because claiming support for IE, and having a fix for Google Chrome are pretty high on my list right now.  I'll have more specifics shortly.

New Website Launched

The look of the website was amateur and looked like it was done by a programmer.  Well, that's because it was -- me.  As of Oct. 13th, the new website has launched!  Interestingly, this website was done by myself as well but I borrowed design ideas from around the web.  Primarily, I liked the design style of Dojo Toolkit so I used their look and made it my own.

The new site took a week to assemble and a few hours to roll out.  I hope you enjoy the look of the new site!  Some things may be broken, but I believe I caught all of the "bugs".  Now back to the engine...

Cleaning up

It's been a thorn in my side, for a while, that I couldn't shut the engine down cleanly.  Spent a bit of time researching the issue and determined that it wasn't necessary to Assert every time an object didn't exist and it was being destroyed.  Instead, I've written them as Console warnings.  That way, a developer can still find orphaned objects or NULL objects and make sure they are cleaned up properly.  This lead to a few other issues which I was able to clean up and fix.  Now the engine shuts down as it did in v1.0 -- cleanly.  I'm a happy camper again.

Android Development Path

I've spent a lot of time trying to decide how best to approach development on the Android platform.  I tried to implement a bridge between a native rendering engine and the JavaScript engine but it was quickly becoming a real headache.  The direction I've decided to take is to convert the codebase to be a native Android library which will be available for purchase.

I really wanted to be able to keep the engine open, but the amount of time I spend on it does add up.  It'll be an inexpensive game engine for the Android platform, however.  I haven't even thought about price yet, but expect it to be a good value for the included features.  What this means for development is that it will follow behind the browser version of The Render Engine by about 2 months.

It will include all of the features of The Render Engine, and will include the exact same API.  Most of the work to convert a game from the browser based version to an Android version will only require you to rename your ".js" files to ".java" and build an Android project for it.  Some code will require changes, but I hope to create ANT tasks to simplify the majority of these common patterns.

On another note, after considering the results of the poll, The Render Engine will focus its future rendering context work on the Canvas, but will still support the DOM.  Separation of the two contexts will be more clearly defined, in the future, and support will be removed to allow simply switching between the two.  Once you've decided the direction you want to go with your game, it won't be as simple as switching to a new context.