Features

[notthecheatr]

I myself like as many features as possible in a game engine, I say the more cool stuff you can do the better.  But when it's just one man doing the engine, with things going slow as heck, I sometimes wonder... which things do you perceive as being hugely important?  Obviously some of these things need to be there no matter what, but which things do I really need to put a lot of effort into and which can I slack on, make a lazy, quick-and-dirty job of?

-Scripting
-GUI
-Particles
-Map editor
-Battle engine?

I guess I'm curious how different people do things, what seems to be the most likely/best method for doing things.  So many things to do, which are the most important and which are the least?

[Lachie Dazdarian]

Well, I learned this recently, but devising a good scripting system and a map editor (if needed) is very important and will save you hours of time doing grueling tasks that otherwise wouldn't have to be done at all. Doing these features in the beginning tends to be tedious as you don't produce anything rewarding or to play with, but pays off a lot later.

In a game engine I don't consider the GUI very important. You should make it functional and not restricting. I don't recommend spicing up your map editors and dev tools with user-friendly (unless it helps the development) and pretty looking features, unless you plan to release those programs to public as strong game dev tools.

Anyway, a lot of these things depend on the game you are making. A very customizable battle engine is a must have if you are making a RPG, for example.

Any element that is repeating a lot in your game must be backboned with proper tools that allow you to easily place/implement and alter the elements in question.

Also, you need to find a limit between the continuous expansions of the game engine and completing a game with it. No sense in creating a placement/scripting tool for every single instance in your game. But of course, if you are aiming primarily to a super-flexible game engine, you can never get enough of features.

[notthecheatr]

I'm actually working on a rather complex scripting engine now that aims to be more generally usable (i.e., could be used in any game or even in a non-game application) - if I don't give up before I get somewhere, I'll release it to the public.

Any element that is repeating a lot in your game must be backboned with proper tools that allow you to easily place/implement and alter the elements in question.

That makes sense, something I'll probably be thinking about carefully.

Also, you need to find a limit between the continuous expansions of the game engine and completing a game with it. No sense in creating a placement/scripting tool for every single instance in your game. But of course, if you are aiming primarily to a super-flexible game engine, you can never get enough of features.

This is my real problem, because I do intend to eventually make a game but I get all these great ideas for things to add to the engine (which so far does not exist, as such, but is what I term my bits of random pieces of code that I will eventually pull together into an engine).

[SSC]

Every time I come up with a new idea, I come up with ideas about how to make the tools for it. First thing I did when srarting EJ was made a basic gfx engine and built a map/scrip editor out of it. It took a long time but was well worth it.  As far as things other than tools, of course the major things to worry about are the parts of the game the player will be spending the most time with. So if it is an RPG, the character will spend most of his time interactive with NPCs, watching scripted scenes, and battling. In simpler games such as racing, the playerr will spent the great majority of his time on the race track, even though there  may be a garage or other features to play with, the most important thing to focus on would be the racing. So what I'm saying is whether it be a specified game engine or not, just image what is most important to the player and how the creator will be able to go about making it the best that is can be (such as more dev features ^^)

[nkk_kan]

Scripting system is really important if you want to make a good game and also saves you hours of frustration and headaches and Map Editor and Graphics Engine is Important, the more fuctional it is, the easier it is to make a maps.
I think we can slack in GUI section as long as it is functional...but people do get impressed (Sometimes) if it is better.
But the really important thing is your code structure. The more optimised the code, the better and easier to read.

[notthecheatr]

I'm glad most people agree with me that scripting is important 

I imagine graphics and maps will also be a big thing.

What about sound/music?  Do people have any preferences on that?

[Pritchard]

Quoted from a friend:

Often this is just coming up with actor use cases, the actors in the case of games being:

1. The developer (always very important in design to think of developers as users of your tools)
2. The end-user
3. Game objects that may interact with your interfaces
4. Game objects that may provide stimulus the same way a user might, e.g., if there is any kind of game UI or characters that behave in a similar way to the player.

This is always an important consideration for games, especially when you're thinking about how input is provided. You could say "If the 'X' key is depressed, move the player forward. Loop through other objects and see how they react." or you could say "If we have a pending INPUT_MOVE_FORWARD message, handle the message for the object that posted the message appropriately. Post an OTHER_ACTOR_MOVED_FORWARD message to any objects that meet a certain criteria."

The idea is that you want to provide a simple environment to run and edit all of these, but the more abstraction you add, as he demonstrated later in his message to me, the more work.

[Lachie Dazdarian]

What about sound/music?  Do people have any preferences on that?

Are we still talking about game engines or games?

Hmm...maybe I'm not clear with the thread topic.

But yeah, as far as sound effects and music IMPLEMENTATION it can't hurt adding scripts for these things too.

[notthecheatr]

I was wondering how far my engine should go to support these things, how much I should support and what I should do with it all.  Should I just have a hack for sound/music or a full-blown OO interface?

[KristopherWindsor]

Should I just have a hack for sound/music or a full-blown OO interface?

With existing libs, you can effectively do music with just a few lines of code. Orb and Zonaxtic are good examples; just load the sounds when the program starts, then call a Sub to play a certain sound / track.