[Raz]

Thousand Pancake, on 02 December 2012 - 05:29 PM, said:

Raz, on 02 December 2012 - 02:56 PM, said:

winterhell, on 28 November 2012 - 05:12 AM, said:

Sofox in order to make the engine you need to create a game with it. There is no successful "lets do an engine first" project in the whole industry, UNLESS you have done big AAA games with proprietary engines in the past. Even the big names rarely make an engine for the sake of it. All id Software's engines came from a game- Wolfenstein3D and Doom 1, Quake 1, Quake 3, Doom 3, Rage. Same with the Epic's Unreal 1, Unreal Tournament 2003, Gears of War, etc.
What I'm saying is this project will succeed if you think about making a game first, and then distill the parts.

I have to agree with this completely, and we've seen proof of this working in the 2D arena for sonic fan games. Gamemaker, media fusion, etc., have been used extensively by the community as foundational technologies to bridge the complexity gap. I think the first checkpoint should be an API or package that sits on top of an existing game engine. Unity3D, Ogre3D, or Panda3D, or similar. ( Naturally my preference goes to Unity3D because, well, it's probably the easiest for anybody to get started with, you can create wizards for it, and custom widgets. The UI is customizable enough that you can turn it into pretty much anything you want with the right tweaks. It pretty much comes with a scene editor out of the box, and it handles all your file formats natively )

Every project I've been around that hasn't come to light has usually included some form of the phrase, "Let's create a totally custom engine from the ground up". While the attempt was admirable, unexpected roadblocks would come along and either debilitate the project or kill interest in it. Unexpectedly, even when there was an engine available, often only the developer knew how to use it!

Unfortunately often the most useful and important part of the game project is the least fun to do, working with an existing fully functional game engine and going straight to scripting the gameplay sort of steals the glitz and glamour out of working with low level GL code, UI code, what have you, there's some common aversion to working in such high level languages like C#, or Python, because of the idea that "it's too slow". I have experienced these feelings myself, there's just something about a non-precompiled language that seems to put a stain on how pure we want our piece of work to be.

However, you gain so much from swallowing that pill and immediately thrusting your hands into the most important parts. From the very beginning you get instant feedback, instant gratification, you get to spend more time and effort on how the gameplay mechanics are supposed to function. Just getting Sonic's movement and physics right alone could be considered a project in itself, and I think with a team of talented programmers such as have been appearing here, I think that would be the best place to aim everyone's efforts.

I'd much rather the underlying engine be open source rather than proprietary. It would potentially be more work, but the portability and flexibility would be a huge boon in the long run.

Ogre3D and Panda3D ARE open source..
Also, a Unity3D package could be kept in an open repo.

This post has been edited by Raz: 02 December 2012 - 07:01 PM

[Relick]

Raz, on 02 December 2012 - 06:51 PM, said:

Thousand Pancake, on 02 December 2012 - 05:29 PM, said:

I'd much rather the underlying engine be open source rather than proprietary. It would potentially be more work, but the portability and flexibility would be a huge boon in the long run.

Ogre3D and Panda3D ARE open source..
Also, a Unity3D package could be kept in an open repo.

Using Ogre3D or Panda3D because they are open source would defeat this point:

Quote

portability and flexibility would be a huge boon in the long run.

Raz, there are already tons of engines out there ready for use with Unity, UDK etc. We even have one excellent engine for EACH of those platforms (SonicGDK, EggEngine). It's not necessary to build off of another existing 3D engine because it will bring nothing new to the table. Making one from scratch may not be completed but we'll try to get damn well close!

This post has been edited by Relick: 03 December 2012 - 01:22 AM

[Sofox]

Hey SChalice,

I'm sorry, I'm not involved with the Golem/Accidental project you are talking about. Try contact these guys.

SChalice

The SDL debate has continued on here, rather than the Technical Discussion thread where I tried to move the discussion to. In that thread, the debate died down after I made this statement:

Sofox, on 28 November 2012 - 06:29 PM, said:

In any event, I see where you're coming from. I'll consider changing to GLFW, but not right now as there are other things that I'm concerned about. Frameworks are things you can get easily hung up about (we could spend ages debating whether to choose SDL, SFML or GLFW; each have their advantages), and right now I'm more focused on making the game then getting too caught up in the debate.
Don't worry though, any good engine will make it as easy as possible to swap one framework out for another, and as the game project continues, we'll have a better idea on what we're looking for.

Obviously I forgot to add Allegro to the above list.

Raz & Pancake:

If we were to build off an existing game engine, it would have to be open source, so Ogre3D (which is a rendering engine, not game engine), Panda3D and the recently open sourced Torque3D game engine would be viable candidates. Each engine is an interesting proposition with it's own arguments for and against basing a Sonic engine off of it.

Building off an existing game engine may increase ease in a lot of areas, but it won't give you fundamental understanding of how the engine works. If you want to change something fundamental about how the engine operates, you may not be sure the best way to do it.

So far, we've decided to program the engine from basic SDL and OpenGL. Once we've made more progress, we can look at where we are, and consider whether moving to an existing open source engine would be a step forward or a step back.

[Raz]

I understand your reasoning but I still have reservations about starting from scratch. I mean, if the team already has an in depth knowledge of OpenGL's api, skinning, reading import formats (either existing ones like FBX, or your own), batching, shaders, and so on and so forth, then I have no reservations whatsoever- however if the general idea is "all that stuff can be learned along the way", I fear this is going to turn into just another learning experience after a few months and dropped from frustration or roadblocks.

Anyway, assuming everyone knows their stuff about game engines and I'm worried about nothing, I apologize in advance, and I'm particularly interested what format you plan to support, or if you decide to go custom, what package will you be writing exporters for?

This post has been edited by Raz: 03 December 2012 - 04:46 PM

[Aerosol]

I actually like the fact that Mobius is a learning experience for many of us. If we hit impassable roadblocks later, we can still switch to an open source engine/renderer, right?

[Raz]

After some thought I realized there are practicalities and ambitions. Give me the ambitions any day, I hope to see the Mobius Engine come to fruition

This post has been edited by Raz: 04 December 2012 - 04:09 AM

[winterhell]

I can help with the OpenGL shaders and giving general tips on the engine as I have previous experience with these things.