Features in a modern gameengine

This may be a silly question but I feel I need some creative ideas and suggestions.

What do you think is a "must have" or a "should have" in a modern gameengine?

What should the engine handle and what should be left for the gamedeveloper?

What common tasks are tedious and what could an "intelligent" engine do to simplify them?
For example, a reflection-shader require that objects below a reflected surface needs to be hidden before it's reflection-renderpass.
This is a perfect job for a gameengine to do.

Any suggestions are welcome.

Thanks.

http://www.projectoffset.com/ -nuff said

Try and do some realtime motion blur using motion vectors on all objects. That should keep you out of trouble.

A decent flexible AI system. Networking, decent collision and plug in physics solutions if needed. Animation blending/mixing.

Scrap BSP and use more modern polysoup methods. Occluder obscurer occlusion planes, Kind of like quake Vis blockers that can be placed in scenery to cull out large chunks of levels.

Decent shadow system, and more blend modes, with optional shaders for those that need them.

I personaly am more interested in the basics needed to make a competent game, rather than take on the likes of the latest unreal and offset type engines.

In many ways I think feature creep gets in the way of productivity, particularly for a small 2-5 man team. Better to focus on core engine components rather than features that require huge teams with a focus on pretty graphics over gameplay.

There's ton's of room left in previous gen hardware that has barely been touched yet. Just look at PS2 and Xbox games, there is very little made today that can't be mostly done in DX8. (many cases DX7) Let alone DX9 and soon 10.

I'm more interested in a solid set of core components, than too many bells and whistles that sound good on paper but most of us wouldn't find the time to explore and actually use in finished shipping products.

Access. Essentially, all the high level stuff you put in shouldn't obscure/lock out the low level stuff in the background so that the user can access both. That way you can put in any *super-fantastic-number-one* feature you like, and users have the option to use it OR write their own.

It should be able to load 3D models.

Just last week, Cygnus and I were talking about what we wanted most out of Bmax.

In the end we came to the conclusion that we really wanted a tweaked Blitz3D in blitzmax as a base platform, and would rather see that released as an initial 3D module first and wait for a fancy shader module to be added on later.

object and material browser

PO is impressive but it also require hardware that can handle every new shader effect invented. But sure, I'll try adding a motion blur pixelshader in one of the demos.


Don't know if it qualifies as an AI-system, but currently every GameObject can have it's own controller which can either be a callback function or script function.
The controller logic have to be coded but a set of useful functions should make this task easier.
Functions like...
* Nearest GameObject
* Visible GameObjects(visible from another gameobjects point of view that is)
* All GameObjects feeling depressed for not getting enough attention.
* and so on...


Exactly.
Everyone and their mothers are making 3D engines that can handle this and that but a game isn't all about graphics.
I'm not making a 3D engine here, in fact I even suck at 3D coding, so I let Ogre3D handle that part.
I'm focusing on the actual game components and the management of those, the "glue" that keeps everything together.



This is actually what I find most difficult.
Finding the perfect balance between easy and advanced.
Easy = "I'll help you but it's my way or the highway."
Advanced = "I'll will do anything you want, you just gotta tell me how."


Loading 3D models?, that's so retro... ;)
I prefer shape generation by algorithms.


Like some kind of editor?

It needs effective data conversion tools (to convert between whatever format your content is in, to whatever format the engine uses), it needs to work flawlessly and it needs to be able to be used by the technically disinclined. Nearly everything else, be it physics, shader code, AI, whatever can be bought, licensed or stolen.

Well, when it comes to meshes the engine only handles Ogre3D meshes.
Ogre already has excellent exporters for 3D Max, Maya and Blender.
But I'm thinking about creating some kind of conversion tool that accepts an input meshfile, identifies it, parse it by calling that meshformats corresponding conversionscript and spits out an Ogremesh.

When it comes to the scripting part I've been using Lua, but is there any scriptlanguage that is exceptional good at this kind of task?

Plug and Play net intergration. I want to be able to add a couple of simple commands and have instant multiplayer in my game. A kind of fire and forget solution.

If I could... Take Blitz3D and add built in realtime shadows, shader support with some form of point click and drag shader development tool (so the dev doesnt have to learn a new language just to use them), and improve support for DirectX devices like force feedback controllers (rather than having to buy a seperate 3rd party tool for the sake of a couple of commands).

Remove automatic object occlusion so I could write manual camera occlusion (much faster if it's integrated into a games state data).

Integral physics system which makes use of PPU units if available, or processes via CPU if not present using the same commands. (Obviously the dev would need to detect the PPU to know how many physics commands they could get away with it).

To me there's no need for AI systems (who wants genericism) or more automation. If too much is left to the engine then you end up doing work arounds to make it do what you want, if too little is done by the engine you may aswell use C++ (my opinion on Bmax falls into this category).

For me B3D is almost perfect, it's primarily problems being a little dated in regards recent developments in the industry: PPU; Shadows + Shaders. My only gripe is the automatic culling, if I try and take manual control over camera occlusion I end up with something slow and jerky - if I let B3D handle camera occlusion it's not as fast as doing it manually in DBP.

I am with Banshee.

Pretty much what I want is TV3D V6.5 with an integrated IDE/Compiler. No VC++ or C# or VB.net or (add compiler here)...

Please hurry Gabrial ... :)

If I was really going for it here is what I would lay down USD$1000.00 for right now:

Engine:
-Skinned meshes
-Materials/Shaders
-Per-pixel lighing and shadows
-Physics
-PVS/Portal system for model chunks.
-Collision detection - ColDet quality please.
-Integrated modelling/skinning/rigging and animating tool with shaders.
-Integrated IDE/compiler.
-Cross platform.

Allan

Most important things for me:
1. stability (Blitz3D is king in this category)
2. ease of use, rapid development
3. good art-path (supporting .b3d files would be great)
4. modern features that are easily accessible (like TV3D 6.5)
5. built-in physics and networking.

Basically, Biltz3D on steroids, without the hassle of buying/installing/updating/bugfixing lots of different plugins and dlls. (this is also a stability issue)

> What do you think is a "must have" or a "should have" in a modern gameengine?

the latest features of DX technology, eg. shaders.

> What should the engine handle and what should be left for the gamedeveloper?

All the "grunt" stuff, just making it accessible to use in a higher-level language ie. basic. with blitzmax though it is less clear what level should be accessible.

> What common tasks are tedious and what could an "intelligent" engine do to simplify them?

See last reply. The list is too long to contemplate. :)