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