Hey guys. I've been working on a game engine for almost 2 years now and since in half an year or so I want to publish it I'd like you to take a minute and talk a bit about what you like and what you don't. (Preferrably from the programming point of view). First of all what style of programming do you like in a library? Procedural or OOP?(DrawImage(image,x,y) or image->Draw(x,y)) Do you care more about 2D or 3D? If a game engine would only be 2D at least at the beggining would you show some intrest(provided it's of a good quality)? How much does the documentation help and how much does the on forum support help? How does a "all game-engine related questions are answered within 24 hours" policy sound to you? For a 2D engine that has the following features how much would you pay? Features: OpenGL and DirectX renderer Cross platform(only OpenGL for platforms other than Windows) Sound support Resource manager Very fast per pixel collisions and as well as bounding box collisions. Physics Advanced effects such as motion blur, shaders (yes for 2D). Tools for asset creation.(the engine supports a new sprite format based around png that's developed with game creation in mind and thus supports a smaller file size, animations,transparency etc). Interface system with a skin designer and a general designer (much like the way .Net has) LUA Scripting support. For a 3D renderer what kind of renderers would you like? Forward, Deferred or Both? Would you like to have allready created post processing effects like motion blur, ssao, volumetric light scattering etc? Do you consider shadow-mapping to be the best shadow system for game rendering? If the engine has it's own 3D format what's more important, plugins for 3D Max and Maya or general converters (stand alone)? Finally how should a simple program that loads a image and draws it should look in your opinion? Do you consider the following to be easy to use?

Okay, you are not helping at all. Just saying "You will fail" is not really nice.
I'm asking about procedural vs OOP because I want to know what interface to make. The engine is allready made using OOP but right now it gives a procedural interface (read about exporting C++ classes in dll's and you will know why I'm saying this).
Yes documentation is absolutely vital and I agree with you when you say up-to-date documentation is maybe more important than a big number of technical features.
Yes it might be a bit too much saying that all questions are to be answered within 24 hours but I for one at least want to try.
If you say countless engines are allready offering this for free then please name one that offers all those features and it's actually easy to use.(Really.. I mean it)
I want to make a series of great demos to show the engine's power. That should show people that I really take this serious. I for one have been changing engines and (commercial and free) just to find out that none is actually that great and easy to use for intermediate experienced indie. The only one I kinda like is BlitzMax but many people are afraid to use it just because it's not C++. On the other hand the way it works is great. Another downside is that it only has a 2D engine.
For the 3D renderer asking about about prefferences between forward and deferred is not really irrelevant. There are advantages and disadvantages on both. My engine currently has a both renderers in it. Deferred is great on new machines while forward is a good fallback for older machines on which games might run on.
Yes, shadow-mapping might have been a much too general term. I was thinking of variance shadow-mapping when I asked that.

I see you left out the last question and makes me wander why since you answered all of the other questions.

I'd like some people to answer the questions as if this were to be their "Dream-Engine".

Another thing I'm thinking of is to offer the engine free with no strings attached to a limited number of people just to make it known by developers.

Thanks.

What are you using for physics? Also, what platforms do you plan on targeting?

One quick comment on this line of your sample code:

Cls();//Clear the screen

There's really no reason to use abbreviated function names like that. I know it's just an example, but note that if you spelled out the function name in full, the resulting line:

ClearScreen();

Would be shorter overall, and no comment would be necessary. (In your existing code, you basically have a cryptic function call followed by a comment that's only necessary because the function name is abbreviated.)

Anyway, I certainly don't want to be discouraging here - if you have the time and technical knowledge and resources to create an engine that can compete with other similar free and/or commercial engines that are currently available, then more power to you. I will however admit to a certain degree of (healthy, I think) skepticism, simply due to the quality of the similar engines that are already available and the sheer number of man-hours required to create something of the scope you're describing,

If you haven't already, I'd recommend surveying some of the other similar engines and authoring tools currently available, such as Unity, Shiva, Quest3D, and so on. It does seem to me that there's a move towards RAD tools such as Unity and Shiva underway right now, and as such, it may be that a (comparatively) low-level C++ engine might have somewhat limited appeal (perhaps even more so by the time you actually get it finished). If you plan to release it for free, then it may not matter that much whether it finds an audience, but if you're hoping to sell it, I'd definitely do a careful survey of other similar engines and tools (both free and commercial) just to make sure that what you have in mind really has something to offer above and beyond what's already available (to the extent that people will actually pay to use your engine rather than one of the similar existing and established engines).

For physics it's yet undecided between Newton and Havok. I played with both and they both seem to be nice. I tend to like Havok more but I still have to think about their liceense system.

It just seems longer to write ClearScreen(); than Cls();. Think about the fact that one you will get used to the engine you will no longer need comments for the intstructions. I mean even if I hadn't wrote the comment you would have still understood what that line did right?. I added those comments just to be even more clear altough it seems to me that it's preety much straight-forward.
I don't really feel that function names are abbreviated. take for instance DrawImage or LoadImage. I really don't think a function that would sound like LoadStaticImageFromHardDisk would seem appealing. Don't get me wrong I do get your point and I am taking it in consideration.

I understand what you are saying about RAD tools and frankly I too want to go in that direction but first I need some good core components to further expand in that direction. My dream is to be a middleware creator. Basically I release this 2D engine and take it to a good point in development and after that I start working on a tool like GameMaker (sort of). Both will be on sale based on what the user wants. It's always more flexible to use an engine as a library than as a RAD tool but it's also slower. It all comes down to what the user wants.
I for one played with Unity and didn't really like it but I will try Shiva as well to see what's it about.

Every engine out there started in a way right? Most projects that don't go too far die just because the developer looses interest. I lost interest in many game related projects and that's usually because I didn't have graphics and general funds. Developing middleware is cheaper and you can focus on the programming of components rather than making character A follow character B.

Thanks for the answer.

Let me start by apologizing for my negative tone. I only mean to point out the challenges, as I see them, in what you are doing. Hopefully you can overcome them and produce a better product.

Quote:Original post by LorinAtzberger
Okay, you are not helping at all. Just saying "You will fail" is not really nice.

If I were you I would re-read Yann L's post. He wasn't saying "you will fail" and was definitely trying to help by giving you some good feedback. He explained his view on documentation, why he thinks the "help within 24 hours" is dangerous, why he doesn't think people would pay for such an engine and so on. If answering your questions isn't "nice" then how can you get feedback? Anyway, you asked for feedback and somethimes "you will fail" is indeed the most realistic feedback and you can do one of three things: try and prove everyone wrong and continue anyway, give up or listen to what everyone has to say and adapt your product.

Quote:Original post by LorinAtzberger
I'm asking about procedural vs OOP because I want to know what interface to make. The engine is allready made using OOP but right now it gives a procedural interface (read about exporting C++ classes in dll's and you will know why I'm saying this).

I'm certain Yann L already knows this. I don't know if they still exist, but a number of years ago, Yann released some absolutely amazing (for the time) screenshots from his engine. So when it comes to graphics engines, he knows what hes talking about.

Quote:Original post by LorinAtzberger
If you say countless engines are allready offering this for free then please name one that offers all those features and it's actually easy to use.(Really.. I mean it)

You didn't list many features and your sample code is very simplistic, so I'll list libraries and engines which support what you said to varying degrees:

SDL, GLFW - similar to your sample code. Lots of extension libraries out there. Excellent documentation and large communities.

Allegro, ClanLib, Haafs Game Engine - easy to use 2d game engines

SFML - easy to use 2d/3d game engine, seems similar to what you're proposing.

Pyglet, Pygame - very very easy to use game libraries, if you don't mind using Python.

OGRE, Horde3D - advanced 3D rendering engines

Irrlicht, Blender3D game engine, Panda3D, Nebula Device - complete game engines


There are also countless hobby engines out there and a lot of high quality commercial ones (if you can afford to license them). Basically, the market you are trying to enter is highly monopolized by the big players, free or commercial and its very dificult for new game engines to gain much recognition. As an exercise, do a google search for people talking about their awesome new game engine that will dominate the market here on gamedev.net. As someone whos spent a lot of time learning about startups, working on one myself and hanging out with other startup founders, I do not believe that a commercial game engine for indie developers is a good bet. You're mileage may vary, of course and I do wish you the best of luck and apologize that my post is so negative. I only hope to be realistic.

Quote:Original post by LorinAtzberger
For the 3D renderer asking about about prefferences between forward and deferred is not really irrelevant. There are advantages and disadvantages on both. My engine currently has a both renderers in it. Deferred is great on new machines while forward is a good fallback for older machines on which games might run on.

For, as you put it, "intermediate experienced indie" finds the masses of other engines out there to be too dificult to use, then chances are the forward vs deferred renderer question may be irellevant to them too, but thats just my opinion. I would say pick whichever _you_ feel would let you accomplish the desired features which you wish to support.

Quote:Original post by LorinAtzberger
I see you left out the last question and makes me wander why since you answered all of the other questions.

I think your sample code is much too complicated. It adds very little value over using libraries like SDL, GLFW, Allegro, ClanLib, Pyglet or engines like Haafs Game Engine, Irrlicht, Horde3D, Panda3D etc etc, all of which have excellent documentation, large userbases, a lot of development/testing/debugging time and effort has been put into them (many many years, in some cases) and are free.

Quote:Original post by LorinAtzberger
Another thing I'm thinking of is to offer the engine free with no strings attached to a limited number of people just to make it known by developers.

Do whatever you feel is worthwhile to market your engine. If the engine really does provide some edge over the alternatives (easier to use, better featureset, whatever) then any additional exposure you can get is good and if your engine doesn't provide anything meaningful over the competition, then it doesn't really matter what you do.

Also, I would like to say that I (and others here) consider developing game engines without games dangerous (instead, dveelop games and adapt the code until its an engine) because otherwise you end up with an engine which feature-wise and tutorial/sample code-wise is very nice, powerful and simple, but when you try and actually write complete games in them you relaise that its actually very dificult. Its very easy to get lost in your work and forget about the end-user. By writing the games first and adapting and reusing code which over a number of games is turned into an engine (I would say you should then go back and refactor the previous games to use the engine), then you have a well tested and proven engine, instead of having to hope that you do.

In any case, I wish you the best of luck and hope you can pull it off and produce a kickass engine.

Quote:I understand what you are saying about RAD tools and frankly I too want to go in that direction but first I need some good core components to further expand in that direction. My dream is to be a middleware creator. Basically I release this 2D engine and take it to a good point in development and after that I start working on a tool like GameMaker (sort of). Both will be on sale based on what the user wants. It's always more flexible to use an engine as a library than as a RAD tool but it's also slower. It all comes down to what the user wants.

Sure, that makes sense (in any case, even RAD tools such as Unity have a C++-based engine under the hood).

Quote:It just seems longer to write ClearScreen(); than Cls();. Think about the fact that one you will get used to the engine you will no longer need comments for the intstructions. I mean even if I hadn't wrote the comment you would have still understood what that line did right?. I added those comments just to be even more clear altough it seems to me that it's preety much straight-forward.
I don't really feel that function names are abbreviated. take for instance DrawImage or LoadImage. I really don't think a function that would sound like LoadStaticImageFromHardDisk would seem appealing. Don't get me wrong I do get your point and I am taking it in consideration.

Just for the sake of discussion, let me offer some counter-arguments.

I don't know that the argument 'X takes longer to type than Y' holds that much water these days. At least based on what I see in other people's code (including commercial engines) and on these forums, it seems to me that these days clarity and readability are generally favored over saving a few keystrokes here and there, and I really don't see abbreviations like 'cls' being used that often in middleware (at least not in the middleware that I've seen).

In any case, a 'clear screen' function is probably only going to appear in a handful of places in your code, so abbreviating it really doesn't gain you that much typing-wise. As for 'getting used to' the engine, I don't think that's a very useful argument; when I use middleware, I like the syntax to be clear immediately, not just after I've 'gotten used to it'.

As for 'cls', sure, it's pretty easy to venture a guess as to what that means (especially in context). However, if I saw Cls() in someone's code, I'd have to stop and think, consult the documentation, and/or examine the surrounding code in order to figure out what it meant, whereas if I saw ClearScreen() I would have to do none of those things.

Also, I don't think the LoadStaticImageFromHardDisk() example is particularly relevant, as you are comparing a clear, fully spelled-out function name to a rather contrived and overly lengthy name with a lot of redundant information in it, whereas the comparison I was making was between a clear, fully spelled-out name and a somewhat cryptic three-letter abbreviation.

Anyway, you already said you were considering the point, so I suppose all of the above probably wasn't really necessary. I do think clear code is important though, so I tend to argue for it when I get the opportunity :)

I would always prefer clear, well named identifiers over acronyms (unless they are very widely known acronyms like XML), shortened or abbreviated words. It helps readability, it helps understanding, it helps me figure out what the code does at-a-glance. Especially for an engine which, as you've said, aims to be _simple_. Readability is very important here.

As for it saving on typing, this is a useless feature. I type enough every day that an extra few characters here and there make absolutely no difference to me. Thinking about the problem at hand and understanding the code and task takes much more time and effort than typing ut the code anyway, esides, most editors have auto-completion nowadays, so short names are even more useless.

I wouldn't choose an engine which requires me to memorize too many abbreviations. Most likely theres plenty of other concepts I need to keep in mind, nevermind whatever the game I'm trying to write needs, I don't need that additional cognitive load.

I would suggest clear, meaningful but to the point names. So

ClearScreen() instead of Cls()
LoadStaticImage() instead LoadStaticImageFromHardDisk()

If there are different places you could load from, an OOP approach may be useful:
disk->LoadStaticImage()
network->LoadStaticImage()

or namespaces:
Disk::LoadStaticImage()
Network::LoadStaticImage()

To me, these are easy to understand, remember and they show intent.

Just my opinion. Hope its helpful.

Quote:Original post by LorinAtzberger
First of all what style of programming do you like in a library? Procedural or OOP?(DrawImage(image,x,y) or image->Draw(x,y))

It doesn't matter as long as its consistent. What languages do you want to support? If C++, then do the OOP style, if C then obviously the other way.
You could go the route that FMOD took: OOP C++ API with a procedural wrapper for C users. This way the user can choose their preferred way.

Quote:Original post by LorinAtzberger
Do you care more about 2D or 3D? If a game engine would only be 2D at least at the beggining would you show some intrest(provided it's of a good quality)?

Personally, I'm generally happy enough with 2D, provided the quality is high. This depends on the game and person though. Also, even in 2D, some 3D effects may be desirable.

Quote:Original post by LorinAtzberger
How much does the documentation help and how much does the on forum support help?
How does a "all game-engine related questions are answered within 24 hours" policy sound to you?

The more documentation and support you can reasonably provide, the better.

Quote:Original post by LorinAtzberger
For a 2D engine that has the following features how much would you pay?
Features:
OpenGL and DirectX renderer
Cross platform(only OpenGL for platforms other than Windows)
Sound support
Resource manager
Very fast per pixel collisions and as well as bounding box collisions.
Physics
Advanced effects such as motion blur, shaders (yes for 2D).
Tools for asset creation.(the engine supports a new sprite format based around png that's developed with game creation in mind and thus supports a smaller file size, animations,transparency etc).
Interface system with a skin designer and a general designer (much like the way .Net has)
LUA Scripting support.

Feature lists like this don't really tell me much. How much work is required for me to, eg, use motion blur on a character?
The list itself sounds good, but I wouldn't pay for it. As I said in my other post,t heres lots of free engines out there. Most claim similar feature lists. This doesn't mean that you're not on to something, just that you have to find a killer feature or niche that people will pay for. I cant tell you what that is, but this thread may be a good first step into finding out what people want from an engine. You need to do something better than other engines (and find a way of advertising and proving that it is indeed better) or you need a feature that other engines dont have. Maybe you already have this - you need to persuade your target market somehow.

Quote:Original post by LorinAtzberger
Finally how should a simple program that loads a image and draws it should look in your opinion?

I would like something where I can define the game objects/characters/entities, behaviours and the scene and the engine manages it for me. Off the top of my head, perhaps something like this:



...though I didn't put much thought into it.

The engine is written in C++ but I currently have ways to use it in C/C++ and C#(I wrote a wrapper).
I'll first start with the 2D engine and make sure that that one is very clear, bugless and has some advanced features that other engines don't offer.

I don't want to be mean but neither of the engines you guys told me about offers what I said. If I mean to get this engine finished you'd think that by now I'd know the competition.


This seems a lot more complicated to me than my ideea of simple code.