[Chimera]

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


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.

...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?

[Gen]

Azu, on 18 February 2012 - 01:33 AM, said:

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.

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.

[Candescence]

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.

[Vinchenz]

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.

[Gen]

Chimera, on 18 February 2012 - 02:11 AM, said:

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.

...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?

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.

This post has been edited by Gen: 18 February 2012 - 02:57 AM

[winterhell]

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.

[Gen]

winterhell, on 18 February 2012 - 03:36 AM, said:

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.

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.

Quote

Its not enough to just follow a book on OOP forkflow standarts.

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
Planning
Design
Implementation

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".

This post has been edited by Gen: 18 February 2012 - 05:51 AM

[Falk]

Chimera, on 18 February 2012 - 02:11 AM, said:

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.

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.

This post has been edited by Falk: 18 February 2012 - 10:10 AM

[Knucklesdood]

Gen, on 18 February 2012 - 05:38 AM, said:

EDIT: Just so everyone's clear, the overall project progression that I'm proposing is something like this:
Brainstorming
Planning
Design
Implementation

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".

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.

[Mr Lange]

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.

[Azu]

UDK takes time to get use to, but it's much easier to import your assets. Although, I've never used anything else besides CryEngine3 SDK. I could figure out heads or tails on how to import things in there.

[Shade Vortex]

All I can do is offer my support to this project. I personally think it's a great idea, but I can definitely see this project being a big hurdle that will take lots of time, maybe lots of people, and a bunch of other complications within its existence. Since fangames barely get finished, making an entire game engine from scratch may be even more of a problem.

Thing is, not only do you need a team of hard-working people who know what they're doing and can get the job well in a reasonable amount of time, they need to be dedicated and have free time to spend on the project, and it must be understood that this work would be done for free, as a hobby, with almost no gain aside something else to put on a resume and helping out fans to make their own fangames with better/more convenient tools. And for those who already have jobs in the fields they specialize in, they won't have time, nor probably interest to join into the project.

To sum my thoughts up, I hope this project succeeds if it does start, and hopefully it won't take 5-10 years to complete. It's a lot of work, that's for sure!

This post has been edited by Shade Vortex: 19 February 2012 - 07:07 AM

[Ross-Irving]

Gen, it's been a while. I read most of what's been said, save for the talk of libraries and what not as that's not my forte, but I've gotten the gravity of the proposal. I know that nothing is set in stone yet, and I certainly don't want to start pushing anything on anyone, but I'm curious about the possibility of 2.5D. Sort of like what the hedgehog engine does with those transitions. You said that it was an extension of a 3D engine, so I'm assuming that would mean a lot of work in coding the camera to work correctly. Good luck, man, if saying that means anything.

Oh, one more thing. Since the engine has a focus on Sonic games, and the fact that you're trying to be economic in the features implemented and in the coding, I have a possible name for the engine. Mach 5

[Gen]

Ross-Irving, on 20 February 2012 - 12:33 AM, said:

Gen, it's been a while. I read most of what's been said, save for the talk of libraries and what not as that's not my forte, but I've gotten the gravity of the proposal. I know that nothing is set in stone yet, and I certainly don't want to start pushing anything on anyone, but I'm curious about the possibility of 2.5D. Sort of like what the hedgehog engine does with those transitions. You said that it was an extension of a 3D engine, so I'm assuming that would mean a lot of work in coding the camera to work correctly. Good luck, man, if saying that means anything.

Oh, one more thing. Since the engine has a focus on Sonic games, and the fact that you're trying to be economic in the features implemented and in the coding, I have a possible name for the engine. Mach 5

Not unless someone can come up with a good idea for a streamlined editing environment to handle different camera transitions, the best I can think of is a decent camera scripting API with a few included script examples to get people started with their own camera control systems.

Granted, doing a system that can account for both 3D and 2.5D areas at the same time may be doable from a technical perspective, but we'd still need a way to setup cameras that isn't a massive pain in the ass in-editor.

I suppose it would be a good time to start tossing ideas out there for a name. Though it may not be retro necessarily, given that the discussion and probably the development of the project is on Sonic Retro, maybe call it the Retro Engine? I'll add an additional poll for the projects name after there's some more name ideas out there.

[Aerosol]

That's what Taxman's engine was called. Retro3D, RetroSpace, or something else involving the word "retro" would be better, so as to distinguish it. I really don't think names should be tossed out at all until the project is actually started. Right now we're just talking about it...it doesn't really need a name yet. It's not even a thing yet, after all.

Now, when it comes to 2.5d, there's really only two things to consider, as far as I can tell. The first is obvious. Hint: it has something to do with camera scripting! The other involves trying to figure out how to handle movement when it starts going on the Z axis, as opposed to just the y and x axis. I'm talking about things like loops, corkscrews, jump-under platforms; basically anything that would be solved in a purely 2D engine with layer switching. I know there's two or three people around here that have their own solutions to that problem, and it's something that we'd have to discuss at length before we settled on one way to do it. There's no point in having two or three ways of doing something.