I want to try my hands on a little shooter on the Android platform, and I'm looking for a full-featured 3D game engine. I can't afford to pay more than 400 € for a license, so expensive engines are excluded from the start.

These are my requirements:

The engine has to have good level editor (able to place entities, actors and triggers); so "graphics engines" like Irrlicht and Horde 3D aren't what I'm looking for.

The engine should be based on OpenGL Core and use shaders rather than the fixed function pipeline.

It shouldn't use octrees and BSP/PVS.

It needs to have decent occlusion culling because I need good frame rates on not-very-powerful graphics cards.

It should come with source code.

I like Horde 3D very, very much and I like it's smart design, rendering capabilities and compactness. Sadly, I can't use it due to the lack of tools.

So far I've come across Torque 3D, C4 engine, Shiva 3D, and Unity 3D.

Torque 3D is really nice, decent design, has good tools, good performance, it's really cheap and comes with source code. Sadly it's only DirectX for now.

Unity has a lot of features, decent performance and tools, runs on Android but they don't give source code within my price range.

C4 is good enough, has tools, and source code but there's a catch. While you have source code the source isn't ported to Android and the engine's owner expressly forbids anyone to port source code on other platforms or to release a game on not officially supported platforms.

Why is having source code so important to you?
–
Nicol BolasOct 15 '11 at 19:57

In addition to clarifying why source code is important, it would be nice to know why some of your other requirements matter to you -- in particular the octree point seems unusually specific so understanding why you chose to call that out may help tailor peoples' suggestions.
–
Josh Petrie♦Oct 15 '11 at 20:09

@Nicol Bolas "Full featured" as in a complete game engine with a complete set of tools as opposed to "rendering engine" or "graphic engine" or enfine with poor tools.
–
MackOct 15 '11 at 20:23

@Nicol Bolas Source code is important because without it I am limited in things I can do. A lot less of customization is possible. Beside that, doing all the things in scripting is slower than doing some things in C/C++
–
MackOct 15 '11 at 20:25

2 Answers
2

There is no engine on the market that works against the core profile of OpenGL. None. All of them use some of the removed functionality to some degree, even if it's just GL_QUADS. All of them.

There is no need for the core profile requirement anyway. Especially since you're making a game for Android, which does not support OpenGL at all.

It supports OpenGL ES, which is not the same thing as desktop OpenGL. ES has no concept of profiles at all, let alone a core profile. Furthermore, you can't just take a desktop-based OpenGL engine and throw it onto OpenGL ES 2.0 and expect it to work. That will involve porting, which (given the significant differences between desktop GL and GL ES) will involve quite a bit of work.

Therefore, you should be looking at engines that have OpenGL ES support.

No BSP/PVS, octrees. I need some decent frame rates on not very powerful graphic chipsets, so I need some decent occlusion culling.

Quake 1 used BSPs, and it ran just fine on GPUs that are inferior in every way compared to anything that implements OpenGL ES 2.0. Also, what is not "decent occlusion culling" about BSPs or portal systems?

You seem to have some misinformed ideas about what are good ideas and bad ones.

Yes, no engine code uses 100% Core but there's a difference in using 100% fixed-function pipeline and using as little fixed function pipeline as possible. I don't expect to take a desktop based OpenGL engine and "throw" it onto OpenGL ES and expect it to work. I newer said that. OpenGL ES itself is a subset of OpenGL. OpenGL ES 2.0 discarded most of the fixed-function pipeline in favor of programmable pipeline.
–
MackOct 15 '11 at 20:36

@Mack: Why does this matter so much to you? If you want something that uses shaders, you should ask for something that uses shaders. That it is or is not "core" is irrelevant. Also, that doesn't change the fact that Desktop OpenGL and OpenGL ES are two different things, with different featuresets and abilities. If you're making an Android game, you should be looking for an engine that supports GL ES, not Desktop GL.
–
Nicol BolasOct 15 '11 at 20:41

Of course I want something based on Open GL ES. But as I said, Open GL ES is nothing but a subset of Open GL. Both Unity 3D and Shiva 3d use OpenGL ES to support iOS and Android. Maybe on the desktop they use just the features present in OpenGL ES to make it portable.
–
MackOct 15 '11 at 20:45

@Mack: No, OpenGL ES is not a subset of OpenGL. It would be nice if it was, but it is not. Unity and Shiva have ES and desktop support the same way programs might have D3D and OpenGL support: by having different backend renderers. They have a desktop-specific rendering path, and an ES-specific rendering path. Supporting one does not imply support for the other.
–
Nicol BolasOct 15 '11 at 20:48

I have said nothing about portals. In fact I think it can be a good idea to use portals in space partition. As for BSP you consider it being a good idea? I consider BSP a poor idea for the engines of today. Was good for Quake 1 but if I remember correctly Quake was released 15 years ago.
–
MackOct 15 '11 at 20:49

If you are fine with it being 2D, the slick engine can be ported to android. It's not an engine as per say, but still high level.
http://slick.cokeandcode.com/.
If you don't mind not having the high level stuff, you can code directly using LWJGL and implement into your game. However I'm not to sure how well that would port.