Discussion in 'Mobius Engine Project' started by Gen, Feb 16, 2012.
So, I'm taking it you didn't really read the initial post.
Lets get right down to it though.
Realtime Global Illumination. The latest graphics cards can handle it.
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.
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.
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.
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.
A simple "MAEK GAEM" button that compiles all your source into an executable or whatever. It should include your assets and whatnot.
Ah, okay. So you don't even really know what the topic is about then, right?
Reload this page and read my edit.
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.
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).
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.
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.
It already Exists
Built in Level editor
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).
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.
In today's sense of the "average joe," game making in itself really isn't a possability. If you're good enough to make a solid, enjoyable 2D game, making a 3D game using what you already know is just a matter of getting used to the editors.
Plus, most Indie titles are made off on engines like UDK and Unity anyway, because all the insanely hard work has been done already. This would be the case where you have a single guy with a vision but little money attempting to make something cool. However, for game companies like SEGA, you have multiple divisions working together using their own skills to make a game; these people would be artists making the level geometry, level designers making the level layout and topology that the artists make their high quality art around, the programmers that make everything able to actually work, etc.
Basically, if you're going to be making a Sonic game up to par with any other indie titles out there, the last thing you want to do is rush into making one entirely on your own. Don't be afraid of help if said help is reliable :v:
That said, this idea of a fully customized engine built from the ground up for the persuit of the perfect Sonic engine is intriguing, and would be interesting (nay, amazing) to see come into full fruition(sp), but I have the stinking suspicion this would turn out to just be a grande theory. Don't get me wrong, I love the idea, but considering how much work would have to be put into it, if you have the skills you might as well make your own liscencable engine and make a unique game for it... Which is exactly what people with this kind of skillset do.
Of course, if you do end up doing exactly that you can of course allow free liscencing of the engine for noncommercial open-source use (though that may be risky) and give the engine the toolset you need to make a great Sonic engine / game not as an indie company, but as fans. :v:
...what's more is that when you get to that point, you can likely strike a deal with SEGA to develop your own unique Sonic game in your own vision and sell it, if you're lucky. After all, SEGA liked Taxman's work enough to liscence his engine and remake Sonic CD, didn't they?
I've learned that so long as people have an easy to use toolset at their disposal, that makes sense to most people, and a bit of content to work with, they can make 3D games with little issue. If the objective were to make a general 3D game engine with no ties to making a specific kind of game, there wouldn't be much point in the project. But an engine geared specifically to make sonic games, that can easily be tweaked to support different play styles (or even support multiple play styles, such as Generations did), would be a bit easier in terms of catching on provided it had a sufficient editor that made this functionality easy to use. Ease of use is the biggest factor here.
And, there are various things about various SDKs that people would want to integrate into one package, for the best SDK fangamers can use.
Well, since the majority are all for it so far... We need a name for the project, haha.
Aww man, I'd LOVE to be a part of this. But I don't know how much I can bring to the table.
As it stands, I barely have any experience with OpenGL (although I do have the Red Book and have wanted to go through it for a while now...). I have a bit more experience with DirectX but then I saw the more complicated shaders and I thought "WHAT THE FUCK HOW HOW AM I SUPPOSED TO... AUGH".
I think I'm a decent enough programmer though and I really do want to be a graphics programmer. Just haven't really had much time since I'm going through college still (learning a lot of new techniques though, such as how entities work and octrees for collision meshes).
When you guys start this, if you think I can help then I'm definitely in. If not, well, I'll eventually be up to snuff on my OpenGL and maybe I'll be confident enough to help then.
There's other beneficial reasons to make an engine in this case. Projects like these, provided they're successful, can look great on a resume. On top of that, it gives people in the community the ability to produce whatever they please using completely freely available, and modifiable, tools that doesn't require them to learn UDK, or Unity, or in some cases, how to write code. Community is probably the biggest part of it here, although if people get jobs out of it, I'm sure they won't complain. Open source from the start also helps with the non-commercial aspect, and doesn't result in tricky situations where it has the chance of compromising an existing business model (Linden Lab went through much debate about open sourcing the Second Life Viewer, and a later CEO tried to kill the initiative after the fact). If something commercial ever comes of it later, that'd be a good thing for everyone involved with the core engine team, and there is precedent for such a thing (fun fact: Unigine's predecessor was originally a small open source rendering engine before it became a commercial fully functional game engine).
As the project evolves, more people will be necessary to help out with the engine. Later on, even more people would be required filling various positions (think along the lines of, programming, scripting, and even example content production) at later stages to become truly usable by the broader community. I personally am looking at the project as a "best effort" sort of thing; if it goes nowhere, then nothing of value is lost aside from the time it took to discuss it, and the idea is scrapped. If it goes somewhere, but ends prematurely for whatever reason, then that'd suck pretty hard, but it is what it is. If it ends in success, then everyone deserves pats on their backs, hand jobs, and maybe even something they can list on their resume for future employers, and the community in general benefits greatly as a result of everyone's efforts.
To make an engine you usually need to make it around a proof-of-concept game meaning assets and stuff. In the end the engine needs to go through one or two games that utilize it in order to distillate its parts to be simple(as opposed to bloated) and flexible.
Its not enough to just follow a book on OOP forkflow standarts.
So one of the problems is to create a game demo that can double as a template for people starting off with the engine. For beginners it'll be easier to start with modifying some of the content as opposed to make everything from scratch.
Will the engine have a self-contained editor to rule them all (like UDK I guess?) or it'll be partly a compilable project in (visual studio, gcc, mingw etc)?
Is there going to be a specific 3D file format for the engine, and exporters for it from the major 3D modelling software?
How the collision mask/geometry going to be stored, is it going to be inside every 3D file or a separate file ?
Also what are the hardware requirements for the engine? I saw Streak mentioning DirectX 11 class functionality. There are 2.5 year old hardware that supports OpenGL 4.0(DX11) and the cheapest I found is 30 bucks. By the time the engine is released some more years will pass and it'll become more mainstream. If there is desire to support DX10 class hardware but have the option to use newer technology if available on the client, it'll make a need for more codepaths and fallbacks when a feature can not be executed.
You say this, as if the goal is to make some kind of licensable game engine. Assets aren't that big of a problem. Testing assets can easily be procured. Different parts of the engine should generally be tested over time as a general rule as well, and adjusted as needed to better enable scalability as more complex scenes are produced, even if means working an entire system to better ensure future scalability. This is a general rule of thumb when making pretty much any kind of software.
Well of course. For a decent functioning engine, you're looking at implementing different programming patterns that fit different scenarios, and implementing different data structures to handle different things (such as octree data structures to assist in occlusion culling, or a dedicated material structure to contain different values for shader uniforms, and to designate what shader a material is associated with). On top of that, if the engine ever gets to a state that threading should be utilized, different threading techniques would then have to be discussed; I.e., should we throw different systems on dedicated threads, or should a thread pool model be adopted. I won't lie and say this is going to be a trivial undertaking in the least.
Everything else are things that should be discussed in a brainstorming phase, where features and workflows should be discussed and debated amongst the community, which would influence the design, and eventually implementation stages of the engine. Currently, we're maybe at the very early beginning of brainstorming, meaning we're not even ready to designate a project management structure, plan different roles and a general progression of the project, or even design the engine its self for implementation. We're more in an introduction phase, to gauge overall interest in the project more than anything. So it's too early to decide what format we want assets to be in, how an internal asset format would be structured, how the editor will work, what middlewares or libraries we'll use, or even specifics such as how collision masks should be handled and hardware requirements. We may be getting there, but we're no where near being close to being there right now. It may even be a good idea to setup a separate forum to discuss these things at this point.
EDIT: Just so everyone's clear, the overall project progression that I'm proposing is something like this:
Brainstorming comes first, so an overall idea of the sort of features that people want, and their practical uses, may be identified. Planning would come about to determine a project management structure, what features are feasible, which ones aren't, and an overall break down of where the project should be in what timelines. Design of course being dedicated to the overall engine design; I.e., what systems do we need, what sub-systems do those systems need, and generally how these systems should interact. Implementation of course being making the engine its self. Of course each feature will likely have their own individual brainstorming, design, and implementation phases, and the reason for going about such a progression is to better increase the chances of doing things right the first time, as opposed to the fourth, fifth, sixth, eighth, or tenth time, and minimize the need to rewrite things over and over again to "make it better".
It may be parts cultural pride and parts language barriers for SDK/support/etc (or simply old fashioned... old-fashioned-ness) but I've definitely noticed that Japanese devs tend to build everything from the ground up themselves with minimal usage of middleware compared to the average Western dev. I mean heck, Mass Effect, Batman AA/AC, COD from the first game, etc are all based on 3rd-party engine technologies with an almost hilarious list of middleware. The most you typically ever see on Japanese games is like RAD Tools and the occasional Havok. I'm not dismissing Western devs as not having programming chops, it still takes a lot to make everything work the way you want it to, but essentially there's a difference when bringing up SEGA compared to, say, Rocksteady.
Funny part is how much games still generally slide their deadlines with all the legwork done and without reinventing all the wheels. And when you think about it, it's part of how far things have come and why it's not as likely the 'average joe' can keep up vs how things used to be. MODERN GAME DEV. :v:
I suggest making the progression more flexible. By this I mean add testing and test iteration into the loop, as well as time to adjust the plan. You said you wanted to aim for doing it right the first pass, and while I believe that's definitely do-able with low-level things like generic containers and OpenGL, it won't be so easy when you (or the other devs) have to implement user-end features like the UI and script bindings.
You did mention multiple phases per feature though, it's possible I may just be overly cautious about this since you posted only a brief outline.
I'm in great support of this project. Think about this folks, the UDK Sonic engine is the only majorly featured 3d Sonic engine out there right now. Its very feature rich and works in a powerful editor, but its really all we got. UDK won't even load the Sonic engine for me. It just gives me a fat list of errors and a blank map. If that isn't a problem, UDK has to be the most user unfriendly foreign thing I've ever used for game development. I'm sure a lot of you can agree with me when I say UDK is awkward as fuck. I would rather not use it for developing anything Sonic related.
Other than that, Egg Engine is still private, for god knows how long, and it may not even be released. All the other 3d Sonic engines are either very incomplete or part of some obscure language/toolset that has no centralized means of editing. Might as well make your own from scratch in Blitz 3d or some shit.
An engine like this would not only be great for Sonic fangames, but any games, given its being made from scratch, and the Sonic engine would only be a rich template. It would be fantastic to see not only an open source game engine developed by this community, but one striving for higher end features and powers with a complete IDE like Unity. It would be FREE. Open source. Even Crystal Space which is pretty well featured has no editing environment, and the only open source game engines out there with good features are crippled by frayed edges and a lack of interest. When you ignore human factors such as time constraints or laziness, I have no doubt that if anyone is capable of making this happen its Retro.
What I personally would like to see with this is a more receptive project. People who have practical ideas who want to contribute useful things would have an easier time being added to the program. Blender isn't far off from this philosophy and look at it now, the features its starting to get are mind blowing, all because the developers are NOT fathead rich people with their heads up their own asses about their so called products who don't listen to user feedback. Older commercial software is starting to suffer because of this blind development mentality and its why Blender is winning the race. I'd like to see a game engine following the same drummer.
Separate names with a comma.