[Candescence]

Gen, on 17 February 2012 - 01:32 AM, said:

Candescence, on 17 February 2012 - 12:56 AM, said:

OGRE 3D - I'm sure many of you have heard of Ogre, and as far as open-source rendering engines go, it's the most well known, and for a reason. I have seen some amazing stuff in Ogre, and the best part is, it's completely open source, so we can do whatever we want to add new features to the rendering engine, and as a bonus, we can pass on those features to the Ogre community as well, so everyone benefits.

MyGui and Crazy Eddie's GUI System - both of these are GUI libraries that are flexible and allow for some very sweet things to be done. I'd reccomend MyGui, but both are viable options.

Ogre would be an almost instant no. Reason being, is Ogre is a good example of a middleware that's fairly bloated, and has a workflow that just generally sucks. Horde3D is a nice alternative, but I personally am kinda interested in writing a renderer. MyGui is nifty, may be worth checking out later.

I suppose that's fair enough. That's something that can be discussed later once planning starts.

Edit: And I just realised some things we actually need to start planning:

- A name for the project
- A place to actually discuss said project (just one thread is far from satisfactory)
- People who are willing to work on it

This post has been edited by Candescence: 17 February 2012 - 06:44 AM

[Caniad Bach]

For a program that offers plenty of functionality without being overwhelming, might I suggest a sort of beginner/(mid)/expert menu option? Or developer/programmer/whatever, if you get my meaning. Alternatively a plugin based system could hold potentially infinite functionality without making the initial program too large.

[Falk]

Wwise is, as fmod is, also cross-platform and free non-commercially- but the designer/devkit runs only on Windows; that's where some of the confusion comes from along with the fact that if a game is on console/iOS it's most likely not non-commercial.

[Gen]

Caniad Bach, on 17 February 2012 - 07:20 AM, said:

For a program that offers plenty of functionality without being overwhelming, might I suggest a sort of beginner/(mid)/expert menu option? Or developer/programmer/whatever, if you get my meaning. Alternatively a plugin based system could hold potentially infinite functionality without making the initial program too large.

Could all be good ideas.

Falk, on 17 February 2012 - 03:52 PM, said:

Wwise is, as fmod is, also cross-platform and free non-commercially- but the designer/devkit runs only on Windows; that's where some of the confusion comes from along with the fact that if a game is on console/iOS it's most likely not non-commercial.

The bigger issue though, as is the case with many middleware providers from my experience, is how comfortable are they with a project that may be distributing libraries they don't normally make publicly available. Probably something that needs to be discussed further elsewhere.

[StreakThunderstorm]

The egg engine made in Cryengine 3. Thats all that needs to be made.

[Gen]

StreakThunderstorm, on 17 February 2012 - 05:52 PM, said:

The egg engine made in Cryengine 3. Thats all that needs to be made.

So, I'm taking it you didn't really read the initial post.

[StreakThunderstorm]

Nope.jpg

Lets get right down to it though.

Graphically:

Realtime Global Illumination. The latest graphics cards can handle it.
Animation blending.
Environment variables. Things like weather. Handling of a day and night system.
Any of the latest DX11 features that could possibly be implemented such as image based reflections, tesselation, etc.
An intuitive shader builder like UDK's material editor. I know that some people want to achieve certain effects but have no real shader programming experience. UDK's material editor is pretty nice and very robust.

Gameplay:

Physics that stay true to a Sonic game. No floaty or drifty characters. Sonic is supposed to be fast and agile. I'm sure he's pretty dexterous with his speed so I doubt he'd be sliding everywhere.
I'm sure there are people who want certain things from Certain games. Some people are geared towards the classic while some are for the modern style of gameplay. Its frustrating when one chooses what he is going for but everything else is left over. I propose that movement handling and powerups be programmed modularly. What I mean is... If someone wants the classic styled movement, they'll use the classic movement module, script or whatever it may be. That way all the extra stuff isnt cluttering the game. I feel as though some people will either want everything done for them or just have a basic movement template they can build on. If you keep everything separate, it'll make it easy to choose what you want to work with rather than having to dig though code to remove things you don't want in your game.

Sound:

I don't know much about the libraries out there. I do feel as though certain things should be implemented for immersion purposes. Things like low and hi pass filters for sound. The doppler effect is a must in a sonic game. Imagine zipping past things and hearing the sound react as it normally would.

Asset Handling:

Importing your assets is a big deal. Making your characters in whatever program you may use and exporting them to be read by an engine can be an excruciating task. Try to keep asset handling very open. Have a way to import all animations, materials, smoothing groups. FBX handles nicely but some people may not like Autodesk's FBX.

Engine:

A simple "MAEK GAEM" button that compiles all your source into an executable or whatever. It should include your assets and whatnot.

This post has been edited by StreakThunderstorm: 17 February 2012 - 08:48 PM

[Gen]

StreakThunderstorm, on 17 February 2012 - 08:17 PM, said:

Nope.jpg

Ah, okay. So you don't even really know what the topic is about then, right?

[StreakThunderstorm]

Reload this page and read my edit.

[Gen]

StreakThunderstorm, on 17 February 2012 - 08:17 PM, said:

Gameplay:

Physics that stay true to a Sonic game. No floaty or drifty characters. Sonic is supposed to be fast and agile. I'm sure he's pretty dexterous with his speed so I doubt he'd be sliding everywhere.
I'm sure there are people who want certain things from Certain games. Some people are geared towards the classic while some are for the modern style of gameplay. Its frustrating when one chooses what he is going for but everything else is left over. I propose that movement handling and powerups be programmed modularly. What I mean is... If someone wants the classic styled movement, they'll use the classic movement module, script or whatever it may be. That way all the extra stuff isnt cluttering the game. I feel as though some people will either want everything done for them or just have a basic movement template they can build on. If you keep everything separate, it'll make it easy to choose what you want to work with rather than having to dig though code to remove things you don't want in your game.

Should probably definitely go with an easily extendable system. This is where I think talk of what scripting API should be available, and how they should be designed to enable easy usage.

Maybe a package system should be used? A package being a set of scripts and assets that can be associated with a game, and added or removed as such.

Quote

Asset Handling:

Importing your assets is a big deal. Making your characters in whatever program you may use and exporting them to be read by an engine can be an excruciating task. Try to keep asset handling very open. Have a way to import all animations, materials, smoothing groups. FBX handles nicely but some people may not like Autodesk's FBX.

There's a few open source libraries out there that are designed to import the vast majority of assets, so I don't think we'll really need to worry about format support. I guess the bigger problem would be how would the project system (assuming there is one) should handle assets directly. I.e., should it be an automatic import, or should the user manually import each asset (which is what will likely be happening in the first few releases).

Regarding material editing, that's going to be a tricky one that will end up having to be handled in different ways across different APIs. Under OpenGL, there's two ways of handling it; associate ARB assembly with each node, and output a sort of "pre-compiled" shader of sorts to a file, or do the same thing with GLSL, and incur a shader compilation cost for easier to read and modify code for other programmers who will be working on the core engine. Direct3D makes things a bit easier in this regard, since we can just precompile the shaders into a binary that can be executed on anything that supports Direct3D, but that kinda defeats the purpose of a cross platform engine (although it may not be a bad idea to do a Direct3D rendering path just for the sake of better compatibility with some graphics cards, namely those from AMD).

[StreakThunderstorm]

I was wondering if a visual scripting language could be possible. Node based like kismet and flowgraph. I know kismet and flow graph compile and execute just as fast as hard coded things. This would really help out those who are new to scripting and/or coding and have previous experience with things like MMF2 and Construct.

[Gen]

StreakThunderstorm, on 17 February 2012 - 09:06 PM, said:

I was wondering if a visual scripting language could be possible. Node based like kismet and flowgraph. I know kismet and flow graph compile and execute just as fast as hard coded things. This would really help out those who are new to scripting and/or coding and have previous experience with things like MMF2 and Construct.

It could happen. I imagine it'd work similarly to the node based material editing idea, but it really comes down to what ends up being decided with regards to the underlying scripting technology. If we go with LUA or some sort of mono runtime, it'd probably be a good idea to compile the scripts into their respective executable formats, meaning special considerations would have to be made when doing a visual scripting system.

[HighFrictionZone]

I am assuming, of course, that you are talking about fan game engines which make extensive use of 3D environments.
Because, you know, if all you wanted was a cross-platform 2D game engine, E02 already exists.

Obvious pros:

• It already Exists
• Multi-platform
• Built in Level editor
• Scripting support

Cons:

• Is not and probably never will be open source, so don't even try. But if you make scripts, you can probably share them however.
• Sound support. WAV and XM. But your generosity could improve that.
• Obviously not meant for commercial use. In the case of a Sonic fangame, this is probably not a concern, but if you make something you can market, I'm sure you could probably come to a licensing agreement or something.

I will acknowledge that this is not really a good suggestion if you want a "3D" fangame, but that's life for you.
Besides, I thought people here preferred the classics, right?

(((At any rate, consider me in favor of this idea, even if I can't really contribute useful information to further it. I just want it to be something that can run on my shitty integrated graphics)))

[Gen]

HighFrictionZone, on 18 February 2012 - 12:49 AM, said:

I am assuming, of course, that you are talking about fan game engines which make extensive use of 3D environments.
Because, you know, if all you wanted was a cross-platform 2D game engine, E02 already exists.

Obvious pros:

• It already Exists
• Multi-platform
• Built in Level editor
• Scripting support

Cons:

• Is not and probably never will be open source, so don't even try. But if you make scripts, you can probably share them however.
• Sound support. WAV and XM. But your generosity could improve that.
• Obviously not meant for commercial use. In the case of a Sonic fangame, this is probably not a concern, but if you make something you can market, I'm sure you could probably come to a licensing agreement or something.

I will acknowledge that this is not really a good suggestion if you want a "3D" fangame, but that's life for you.
Besides, I thought people here preferred the classics, right?

(((At any rate, consider me in favor of this idea, even if I can't really contribute useful information to further it. I just want it to be something that can run on my shitty integrated graphics)))

Really, I'm speaking more amongst a 3D engine. Doing an open source 2D engine doesn't make a whole lot of sense right now. 2.5D would be an extension of a 3D engine (technically).

[Azu]

I don't know, even if you guys managed to create a fully Sonic 3D engine, I don't know if a lot will use. At most, you'll see what we've seen with Damizean's old Blitz Sonic Engine. Level Rips. It's easier to make a 2D sprite than a 3D geometrical object or player. People are inept in 3D game making or who is currently working on one maybe able to, but I don't think the "average Joe" will.

This post has been edited by Azu: 18 February 2012 - 01:35 AM