26 replies to this topic

[marcusp]

Hi altogether,

currently I'm a student working in a (for German dimensions) bigger game studio. Next year I'll have to make my bachelor thesis. My advisor told me he would support any feasibility study about new features for the inhouse engine. So now I'm looking for features which our quite mature engine has not yet.
So I ask you: What do you think is a cool feature a modern engine must, could or would be nice to have?

Thanks for your time,

Marcus

[rouncer]

Get rid of as much coding as possible, so when you first start, your automatically making a game, not writing under code.

[Sol_HSA]

That pretty much sums it up, yes. =)

[marcusp]

Well - we are using the engine to make full price games and need to edit a lot of content. So creating a "default-game" is not what THIS engine could use (although this would be a pretty nice feature in a "beginner engine"). But perhaps some more clicky-clicky-features would be nice in our engine ...
I thought of something like this:
http://drawlogic.com...lash-video-etc/

(well..this would be perhaps a little lot of todo for one person :) )

[Mattias Gustavsson]

So, what suggestions would you like us to give you? :unsure:

[marcusp]

Ok - the "less code, more design - suggestion" isn't that incorrect on our engine I think.
But I thought of something like blooming, 3Dlighting or something like this. The problem is: our engine already has got all those "common" features.
Btw: I didn't mention it until now, because there is no real engine-feature-list for our engine, but we use Nebula3-engine.

[alphadog]

This won't help you, but I'll say it anyways: The best "engine feature" is real documentation... and not just the typical GhostDoc/Doxygen/Sphinx/whatever crap that gets spit out from a parsing of the API and lame inline commenting.

What I mean is something is a good "textbook"-style map that really lets a developer sit down, get a 10K view of your convoluted engine. Something that talks through the architecture and, to some extent, the tradeoffs that were made. Then, I always know where to go in the API for various functionality, or for integrating middleware, or some of the other big tasks we face daily.

[TehOwn]

I agree with the Documentation suggestion. Definitely the most time wasted is time spent trying to understand someone else's code... or even your own!

But if you're looking for features that would please designers, then the ability to change scripted content and call functions in-game is absolutely fantastic. A console with some decent functions is always a great addition, including debug displays and such.

Nothing I hate more than having to change scripts, reload the game, test them, close the game, change the script some more, reload the game, etc... >_<

[SyntaxError]

First I'd like to say I haven't really looked into a lot of commercial or fee engines. So take these comments in that light

I'm currently working on my own engine and these are the problems that I am struggling with. My feeling is that in the future games (especially online games) will need support a large play area. I'm using real time fractal terrain generation so that my world can be extremely large. My goal is to have a world or even universe large enough to support all players on a single shard with the possibility of player added worlds (by means of specification of fractal parameters)

This means that numerical precision issues must be handled. Most graphics cards only support single precision floating point. Even then these cards may not fully IEEE compliant. In the near future this may change. However even with double precision you start loosing millimeter resolution at the solar system level. Therefore having some system of handling numerical precision becomes paramount. I'm implementing a system of nested scopes but there are surely other and probably better ways of handling this. This type of thing goes hand in hand with LOD (level of detail) algorithms to reduce the sheer volume of data needed to for large play areas. Then there is collision detection with large terrain data models, procedural texturing etc. The list on......

So I guess in general I would say I would like to see an engine that would handle a *BIG* and realistic universe with relative ease.

[Hertta]

As it was pointed out earlier, documentation. Fast, clean and bug free code. Flexibility and platform independency would be a definite plus, though at this stage they might be a pain to implement. :)

[Wernaeh]

Add another one for documentation.

For me, a good documentation mainly means high level documentation!

This is usually the documentation you need when starting to get into some system - unlike low-level documentation within code.

What lines does data travel through ?
Where in code do I look for what functionality ?
How are tasks distributed over classes and objects ?

Most of the time, I'm not really interested in whether a call accepts a NULL pointer or not, but I want to grasp the big picture.

Important points for achieving this are IMHO:

- Properly annotated class and collaboration diagrams

A single image usually says more than half a page of written words.

Additionally, pictures are easy and fast to create and to synchronize to changes - unlike normal comments.

Finally, at some point or the other, you need to present your stuff to others - then, you'll anyways need some images around.

- Design decisions

Why has a concept been realized in a certain way - what were the alternatives ?

- Use cases

An use case (small piece of example code) for common scenarios usually helps much more than a pure interface documentation which you need to fish required code out of.

There is a generic deserializer in your codebase ? Build a small example that shows how to set it up, feed a file into it, and get variables out of it.
The same goes for any other helper subsystem you might have - rendering, threading, ...

In most cases, the remaining documentation then will only be used as reference material in any left over inclarities.

Cheers,
- Wernaeh

[ely_bob]

Ship with a number of Game samples, .. if your engine can handle it
Basketball, FPS, RPG, Racing.. don't need to be big, but like 3 levels (I've found that after three most of the "issues" have been resolved.. i.f if 3 then N)
along with a Documentation "walk-through" ... (in narrative form,, but with references to the appropriate in depth reading : we make a Character (see page 32) and change the default var X to .32 because this allows us to utilize the ghouls system.. etc.


Also perhaps GUI/API's for those people who want to "Make" a game.

[rouncer]

Id actually like code windows that pop up as the action im putting together plays through.
So I can adjust code, and it instantly pops in, and i can insert graphics and media any way i want really easily and I dont have to worry about importing models so much.

But thats not your average api, its more like an ide.

[JarkkoL]

Funny you guys mention high-level technical documentation, because I have spent fair amount of effort in writing one for the engine I'm working on. It's not ready for public eye yet, but if someone with decent C++ background would like to skim it through and give some comments about the style, level of detail, etc. PM me (: And sorry for the shameless plug ;)

[marcusp]

Thanks so far for all suggestions!
First of all I'll look what possibilities there are for creating a simple to use "documentation-builder" which efficiently transformats code + additional descriptions into easy to read overviews. (lot of research of existing systems and what's missing there is needed I think.)
Second I'll talk to our graphics-department and others to gather information what ingame-editing would be most time-saving at our developement-progress.
As far as I know there is actually no problem with floating-point-accuracy in our games - but it may be in the future so I'll talk to my heads-of-programming about this.
Thanks again to all of you! Any further suggestions are still welcome, of course.

Kind regards,

Marcus

ps: pie?! o.O

[Mattias Gustavsson]

marcusp said:

First of all I'll look what possibilities there are for creating a simple to use "documentation-builder" which efficiently transformats code + additional descriptions into easy to read overviews.

I think you might be missing the point here... I think that what the other posters feel is needed from an engine, is better actual documentation, not a better system for generating documentation.

Systems like doxygen work fine for generating docs, but those are detailed reference docs (and only as useful as the comments going in along with it, at that), not tutorial style flowing text.

Or, put like this - do you have a "MarcusEngine for Dummies" book to go along with your engine?

[SyntaxError]

marcusp said:

As far as I know there is actually no problem with floating-point-accuracy in our games - but it may be in the future so I'll talk to my heads-of-

It's more that you lose accuracy with scale with floating point numbers. It's probably an issue with most engines unless they do something specific to handle it. However on second thought it might be beyond the scope of your post so It's probably not be worth it address it.

[kvakvs]

[starstutter]

0_o

[Reedbeta]

:worthy: