[Sofox]

At the moment, I'm focusing on reviving the Mobius Game Engine. As you may know, this was a project that aimed to create a fully open source high quality 3d game engine that could be used to make Sonic games that could be in the Adventure, Unleashed or 2.5D style. The project stalled after the team leader became inactive, and while we were waiting for something to happen, the forum got archived (though still postable). It seemed tragic to me that a project with such potential could just end like that, so I stated that the project would be revived and became the team leader by default.

Since then I've set up a new source code repository, done some coding to show a basic 3d "Hello World" program (which was more than the previous project did, surprisingly), and made some posts asking for feedback on my license proposal, the direction the engine should go for, talk of milestones and art. The simple fact is that while I'm going to push this project forward as much as I can, I need help, and honestly this is meant to be a community project.

The Mobius Engine Forum is still here, and the most recent posts there should cover what's happened since the revival. If anyone has any thoughts on anything, or something they'd like to contribute, feel free to post. The engine has gone through a rough patch, but there's really so many places that this engine can go in terms of being a great and popular game engine that can help so many 3d games come into existence. There's a lot of skill and talent in this community, and I really believe we can make something great with this.


Sofox

[Relick]

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!

This post has been edited by Relick: 27 November 2012 - 03:49 PM

[nchavez]

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?

[Relick]

nchavez, on 27 November 2012 - 02:09 PM, said:

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.

This post has been edited by Relick: 27 November 2012 - 02:51 PM

[Sofox]

Thanks for the replies.

Relick, as you've seen, I've been trying to ensure that the project keeps surging forward. We've all seen what happens when the leader drops the ball.

I will admit my planning needs improvement, but I'm at least trying to lay down what we aim to get done, and detail short term tasks to go for.

I agree with both you and nchavez on community project, I want this to work out and I intend to keep working on this project for a long time and keep it going even if it's just myself; it's just that help from others would make a big difference, cut down the time it takes by a large amount, and hopefully will lead to a better quality project overall.

And yeah nchavez, at the moment it's written in C++ and OpenGL. Similar to how the project started out, as Relick said.

[Aerosol]

We're not relying on a library like SDL, right?

[Sofox]

Aerosol: Sorry, I forgot to mention that we are using SDL for window management and input. Is this a problem? I was deciding between that and GLFW for the same purpose.

[Aerosol]

Honestly? I'd prefer GLFW for those purposes.

[winterhell]

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.

[Sofox]

Aerosol: I have no objection to using GLFW instead of SDL, but I'd appreciate it if you could post your reasons for wanting the switch in this thread I just created for technical discussion.

winterhell: Completely agree. Not only that, but a game engine can't really be called one unless a full game has been made using it. The plan is to first make a demo level consisting of an English Countryside themed level. After that, the long term aim is to create a high quality 6 Zone 3d game, including cutscenes, full variety of badniks, and an example of how the gameplay can be varied using the engine. Obviously the game is a while off, it's gonna take a lot of work and effort in many different areas, but since I can't focus on everything at once, I'm focusing on the technology right now.

[nchavez]

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.

This post has been edited by nchavez: 28 November 2012 - 12:54 PM

[SChalice]

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....s/thread/611469

[Relick]

SChalice, on 02 December 2012 - 12:58 PM, said:

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

This post has been edited by Relick: 02 December 2012 - 01:38 PM

[Raz]

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.

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

[Thousand Pancake]

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.