Mobius Engine revival

Great to hear this Sofox, but here are a few things I have noted over the (relatively few) years I've been here:

1) Planning - I think the original Mobius engine was planned really well, and as long as you continue as it was before I think you'll be fine.
2) Leadership - You need a much better leadership than what was before, if you think as a leader you can be active enough to deliver an update in the project; however small; once per week then I assure you the entire project will remain alive.
3) The term 'Community Project' - You need to remember that even though it may be a community project, the community part should be nothing more than the fact that anyone in the community can contribute if they want to. You should be doing this project because you want to do it, not because the community wants it because that's not what the term means. As the leader, you should set targets and deadlines (remember it's still in people's spare time) and make sure you let the main contributors know what they need to be doing. Ask specifically for things that need doing, don't be ambiguous whatsoever (unless necessary).

I hope you take my opinions into consideration when running this project, and I really hope it goes well!

EDIT: Aha, hadn't read your posts in the subforum. Looks like you have all this covered anyway. Good luck!

 

I would agree with Relick, you need a set of consistent contributors to go most of the way with you and rely on the community for things that you CAN do but just don't have the time to do. Honestly, if you depended on the community I don't think you'll get a lot done, but if you're open to whatever anyone has to offer, than it would supplement the project and create a richer and more diverse experience. Hope it goes well! What language was the Mobius engine written in?

 

I'm pretty sure the original intention was to write it in C++ and OpenGL/CL/AL for Mac OSX then port it to Windows and Linux with cmake or something. It's up to sofox though I guess.

 

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 think SDL is a pretty solid choice -- if you know the library there's no reason not to use it. Also, its not like its obscure, so I think it would work fine. SDL also has a bunch of library extensions that are useful if you don't want a lot of overhead but only want/need some components of it.

EDIT:
On the other hand OpenGL is OpenGL so screw it -- its less heavy with less overhead. I dunno. I guess its a matter of preference.

 

SoFox stud,

Interesting that yesterday I was looking for your Mobius source and you just started working on it again...

Could you do me a big favor and provide me your Golem, accidental engine code? Your link to accidental.zip is dead. If I use any of your ideas or source, I will duly grant you prominent credits.

Pretty please!


"Sorry, I forgot to mention that we are using SDL for window management and input"

SDL is awesome and a great choice but limits your end platforms. They also require a license. I just took the Sauerbraten engine and ported it to Allegro 5 from SDL for the purposes of supporting iPhone and Android. You might want to consider using Allegro 5, it is very well supported and pretty well written code. Allegro 5 is open source. I will give you my work if you wish.

https://www.allegro.cc/forums/thread/611469

 

Personally (I am not speaking for the entire team, they may have other opinions), I think the sacrifice of two platforms that won't be able to run Mobius well anyway (if the graphics are as good as we intend) is better than sacrificing control and adding bloat. SDL handles what we didn't want to do ourselves - cross-platform input and OpenGL hooking. Now we can add what we need when we need it, unlike if we used Allegro where we would start with tons of stuff and more than likely end up with crap we don't need (which adds to filesize and memory requirements).

Also, as far as I can tell (please correct me if I'm wrong), other than your Sauerbraten example Allegro is barely used for 3D games, which is the whole point of Mobius, the open source 3D engine.

 

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.

 

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

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!

 

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?