Sonic and Sega Retro Message Board: Mobius Engine Project General Discussion - Sonic and Sega Retro Message Board

Jump to content

Hey there, Guest!  (Log In · Register) Help
Loading News Feed...
 

Mobius Engine Project General Discussion Formerly known as: ITT: Engine Project Proposal Discussion

#1 User is offline Gen 

Posted 16 February 2012 - 08:40 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine
Whelp, looks like we're going with Mobius Engine!

This thread is for general discussion of the Mobius Engine project, an open source project to produce an easy to use 3D (and 2.5D) game engine for Sonic fan games.

The goals of the project are to produce a fast, stable, and more importantly easy to use alternative to proprietary middlewares that can be used on any platform that it can be compiled on.

The renderer is in the design stages. You can find details here. Discussion regarding licensing will be starting soon!

Original Post:
Hello everyone!

I'm in for my usual 2 to 4 year checkin with the Sonic fan gaming community, and I've noticed that a number of "Sonic Fangame Engines" tend to be based off of either Unity, UDK, or based off of a fangame engine based off of Unity or UDK.

I'm not going to say that this is a bad thing by any means, as speaking from my own experience, both Unity and UDK provide quite a bit out of the box for people to create their own games, and even non-game applications. Naturally, each environment has their unique benefits and their disadvantages, Unity being barebones, but being highly flexible with its everything, and UDK mostly providing everything, even if it may not be quite as flexible as Unity.

But before we really get into the meat of this post, first off a bit of an introduction, since I'm sure I've been long since forgotten over the decent number of years that I've been relatively inactive (which may potentially be for the best).

I'm Gen. I used to be a bit more active in the Sonic community a good few years ago, until I finally started a career doing what I like to do. I like making games, and even the technology behind the games! Currently, my primary expertise tends to lay in the 3D rendering department, however I tend to work on a variety of things at my job, including general software design. My official job title is "Technical Artist", however I'm often times tasked with working on many other things that go beyond of the scope of my job title.

Now that's over with, on with the rest of the post!

So I've been kinda keeping an eye on various little projects scattered about here and there in the community, ranging from SonicGDK, to a few of the Unity-based projects here and there. They're all nifty stuff, but I often times find myself wondering, why hasn't the community produced their own engine from the ground up? There's been a couple of attempts, sure, but many of them seemed to lack an overall "general" direction, mostly focusing on a singular fan game's specific needs.

Now, by "the community" and "their own engine", I don't mean an engine that a singular individual or small group of people produced for their super awesome sonic fan game designed with the intent of blowing everything else out of the water, that's then either scrapped or generally kept to themselves. Nor do I mean a set of scripts for a pre-existing general engine such as Unity3D or Unreal Development Kit that better enables people to produce Sonic games. What I mean is, an engine that incorporates features that are in high demand amongst the community, that's freely available to anyone who feels that they'd like to create their own Sonic fangame, or Sonic-esque game, that's available for any platform that it can be compiled for, and can be openly modified by anyone with the know-how to do so, at any level of the engine.

What I'm describing here is a through in through, game engine.

Now I'm sure that there's plenty of good reasons why no one's really tried to take on such a project to a serious degree, or attempted to organize community members to produce such a project. Such a project would require someone with the know how to design a modern game engine, that incorporates things like an audio system, a rendering system, a physics engine, and the various smaller low-level bits and pieces that typically facilitate the creation of such systems (such as math libraries, threading systems, and so on). However, in my hanging around and drifting around the community, I know there's people out there who individually have the know how to create bits and pieces of the overall engine. For example, I have plenty of rendering know-how; I understand how modern rendering pipelines work, understand the need for an optimized vector math library, and have even played with different threading ideas. But these things don't necessarily make a complete engine, they're more components that would be part of an overall engine.

Now, the intentions of this post isn't necessarily to announce some huge project that will be in perpetual development for the next 4 to 6 years before finally being cancelled. It's more to propose and gauge interest in a project to create an engine made by the community, for the community that incorporates many modern game engine design elements, while being completely free to use without having to download UDK, or "obtain" a professional copy of Unity 3D with all of the extra bits and bobs included. Another purpose of this thread is to facilitate discussion of such a project, and if such a project were to be found favorable by the community, to begin identifying individuals who would assist in the project, and what they could contribute to the overall design and implementation of the project.

The reason for such a project to exist, is to make an engine that's fine tuned for fangame development. One that has very specific workflows established for the community, that doesn't require a $1500 investment to unlock all of its features, or the need to learn a generalized solution that may not be quite as customizable, or particularly easy to learn for that matter.

The context of discussion generally should be amongst what would be a good idea, what would be a bad idea, how it could be favorable, how it could be bad, and generally the how of the project. If you feel that the project is a bad idea, that's fine. By all means express your opinion. If you feel the project would be a great idea, that's fine too. But please, keep feedback constructive regardless of if it's to encourage or discourage the idea of such a project.

To get the discussion started here, I'll propose a few ideas for such a project.

First off, to better facilitate openness, and the ability for anyone to use the engine, it should be open source. Likely licensed under the LGPL to ease licensing concerns when linking against a proprietary library that may be deemed useful (such as if it were decided that FMOD would be the best solution for an audio engine).

Overall the engine should use OpenGL as its graphics API of choice, primarily to ease porting pains to other platforms. A cross-platform threading library would be nice, primarily to aid in increasing performance with regards to physics and rendering, but wouldn't really be necessary for an initial pre-alpha release (besides, we probably wouldn't even really have a physics engine implemented at that stage, and no one would probably be using it to a degree where multi-threaded rendering would provide any noticeable gains at that point).

Proprietary libraries should be kept to a minimum, with exceptions being granted for those that are freely available on the target operating systems. A prime example of a library that would be acceptable is FMOD, as it's available for Windows, OS X, and Linux. It's also free for non-commercial use. A prime example of one that wouldn't be acceptable is PhysX, as despite it being generally free, it's only really maintained to a large degree on Windows, with occasional updates being made for Linux, and OS X support only being provided to commercial licensees.

Most importantly, the primary programming language of choice for the core engine should be C++, with a scripting language decided upon at a later date.

Of course, these are just a few ideas to get the discussion going. All ideas should be fairly considered along the way, and should be open to criticism.

EDIT: For reasons of easily consolidating people's opinions with regards to how many are for or against the idea, I've added a poll to the thread.
This post has been edited by Gen: 04 March 2012 - 11:38 PM

#2 User is offline Hitaxas 

Posted 16 February 2012 - 10:14 AM

  • SEGA: Sorry Classic Sonic, we are sending you back to 1994
  • Posts: 1370
  • Joined: 30-September 07
  • Gender:Male
  • Location:McCalla, AL
  • Project:Sonic: Super Deformed (head director) - Slowly working on it.
  • Wiki edits:196
While I have nothing I can personally contribute to the creation of such an engine, I'd like to share that your post reminded me of Sonic GL, the forgotten and unreleased C++/OpenGL fan game that Bosser Jerome was working on.

So, it's entirely possible. This guy seemingly did what you mentioned, alone.

#3 User is offline Gen 

Posted 16 February 2012 - 10:18 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostHitaxas, on 16 February 2012 - 10:14 AM, said:

While I have nothing I can personally contribute to the creation of such an engine, I'd like to share that your post reminded me of Sonic GL, the forgotten and unreleased C++/OpenGL fan game that Bosser Jerome was working on.

So, it's entirely possible. This guy seemingly did what you mentioned, alone.

I'm actually familiar with his work, and I actually feel that this is why going the open source route would actually benefit a project like this.

Even if the repository only has a few smaller usable bits and pieces, other people who know how to use them can still continue on with the project, helping it to achieve the original goals, or even establishing whole new goals to achieve.

#4 User is offline Candescence 

Posted 16 February 2012 - 10:57 AM

  • Posts: 1310
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
Okay, I'll admit. This is completely unexpected in many ways. It's certainly not something I would've anticipated at all.

But then I look through your post, and I rub my chin, considering all the ways this could actually be of benefit to fangame makers. But let's start with the pros and cons of this idea, in my opinion.

Firstly, the main disadvantages is that you would be missing most of the great features of UDK and Unity (and more recently, CryEngine 3) from the get-go. But I suppose you already know that.

On the other hand... There are some features from one development package that I would love to see in others, and so on. C4 Engine's voxel terrain system is, in some ways, far more flexible than the heightmap system that UDK, Unity and CryEngine 3 use. Being able to have an engine that would have all kinds of neat features in one convenient package is certainly something I can get behind. Hell, you can even look at more obscure stuff, like what the guys over at Wolfire are doing with their engine for Overgrowth, the sequel to Lugaru, which has some very neat ideas of its own that should be looked at.

And then you have things that these engines, well, just don't have, stuff that they COULD have, like this...



I mean, Christ, don't you wanna see Sonic run through these green fields? Entirely possible at reasonable speeds with OpenGL, I imagine, since that actually supports tessellation without needing the newest friggn' operating system, unlike DirectX. :v: An open engine that we can work on ourselves could keep up with the latest technologies, and hell, do new ideas that maybe nobody else has done before.


Of course, to make this all workable, we would need some things for the sake of ease of use for people. Not everyone is a hardcore programmer. A proper level editor would be an excellent start. And next... Support for a scripting language to make creating gameplay relatively easy for people who don't want to bother with C++. I reccomend Lua.

A considerable amount of work will be required, but that's a given. I believe, however, there is a massive amount of potential in this idea.

First things first, however, planning will be required.

#5 User is offline Gen 

Posted 16 February 2012 - 11:28 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostCandescence, on 16 February 2012 - 10:57 AM, said:

Firstly, the main disadvantages is that you would be missing most of the great features of UDK and Unity (and more recently, CryEngine 3) from the get-go. But I suppose you already know that.

Well of course there would be a great deal of functionality that would need to be implemented. That comes with any game engine. :P
We're looking at a rendering system, an asset system, an efficient way to manage available resources, physics, and scripting just to name a few.

Quote

On the other hand... There are some features from one development package that I would love to see in others, and so on. C4 Engine's voxel terrain system is, in some ways, far more flexible than the heightmap system that UDK, Unity and CryEngine 3 use. Being able to have an engine that would have all kinds of neat features in one convenient package is certainly something I can get behind. Hell, you can even look at more obscure stuff, like what the guys over at Wolfire are doing with their engine for Overgrowth, the sequel to Lugaru, which has some very neat ideas of its own that should be looked at.

Transvoxel would be great, and I'm sure ideas could be tossed around all day long for potential terrain ideas. Definitely a subject that I'd foresee getting some decent discussion in on.

Quote

And then you have things that these engines, well, just don't have, stuff that they COULD have, like this...



I mean, Christ, don't you wanna see Sonic run through these green fields? Entirely possible at reasonable speeds with OpenGL, I imagine, since that actually supports tessellation without needing the newest friggn' operating system, unlike DirectX. :v: An open engine that we can work on ourselves could keep up with the latest technologies, and hell, do new ideas that maybe nobody else has done before.

Which really underlines how a community produced engine could be greatly beneficial. If people want feature XYZ, that just isn't very trivial to implement in another engine, work could go into producing such a feature at the lowest levels to help ensure maximum performance is achieved; something you just can't do in UDK or Unity (even if you can get close to doing so in Unity).

Quote

Of course, to make this all workable, we would need some things for the sake of ease of use for people. Not everyone is a hardcore programmer. A proper level editor would be an excellent start. And next... Support for a scripting language to make creating gameplay relatively easy for people who don't want to bother with C++. I reccomend Lua.

This is one of those subjects that will likely receive plenty of attention. There's so many options here that can be utilized. LUA is one of the better performing ones, and there's even javascript for those of you who are more familiar with web programming, or even going the Unity3D route of using a stripped down mono runtime.

The editor discussion is going to be very interesting. I'm of the mindset that if a project like this goes forward, the content production toolchain should be easy to learn, almost to the extent of being able to "dive right in" with regards to making levels, and importing content.

Quote

A considerable amount of work will be required, but that's a given. I believe, however, there is a massive amount of potential in this idea.

First things first, however, planning will be required.

Planning is always necessary for any project, and the amount of work that needs to go into it should reflect the overall demand of the community. If people only really want some sort of 2D sonic engine, then there really isn't much of a point for the project, as there's already viable 2D engines for this sort of thing. If they want a 3D sonic engine with basic collision detection, then that's certainly doable. If people want a 3D sonic engine comparable to say, SEGA's Hedgehog engine, then that would be a pretty tall order, that would only be accomplishable in smaller phases over time.

#6 User is offline 8-Bit Dragon 

Posted 16 February 2012 - 11:31 AM

  • Posts: 839
  • Joined: 12-February 04
  • Gender:Male
  • Location:Gainesville, Florida
  • Project:Too many!
  • Wiki edits:2
What you have described is the perfect Sonic engine. Cross-platform, written from scratch in a common programming language like C/C++ and meant to be an overall solution for all fan gaming projects. Sadly, execution of such a project would be next to impossible. Such a project would require coordination from every team member, which would simply not happen. As a free project (people are not getting paid for coding) just about everyone would come out of the woodwork, and it would be difficult picking out the right programmers for the task. Some people would be great coders, some would be just learning and would make a mess of things. Getting the team together and working well would be the first hurdle, and its a big hurdle.

Programming the engine well is critical because the individual fan game maker will want to modify it to their needs no matter what you do. Small basic engines like Sonic GDK and BlitzSonic work because the majority of the math is done (the physics) and the programming (and language) is usually simple and easy to understand. Whats more, a basic Sonic engine is (usually) not loaded down with all the add on abilities like jump-dash, light-dash, skidding, rail grinding, etc etc. People are not overwhelmed and can easily add exactly what they want in their engine. For every feature/ability you add, there will have to be an accompanying animation or graphic, which means more work for the team making the base engine, and more work for the end user to create the animations for their own models. I can give you an example. BlitzSonic BGE is massive, and has soooo many features it actually makes it more difficult to add your own content. So, the engine you propose would have to be either very simple, in which case we have Sonic GDK, or alternatively it must have it's own dedicated UI for editing various functions of play so that people are not bothered with extensive cfg files and editing it and re-compiling in C++.

#7 User is offline Gen 

Posted 16 February 2012 - 11:48 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View Post8-Bit Dragon, on 16 February 2012 - 11:31 AM, said:

What you have described is the perfect Sonic engine. Cross-platform, written from scratch in a common programming language like C/C++ and meant to be an overall solution for all fan gaming projects. Sadly, execution of such a project would be next to impossible. Such a project would require coordination from every team member, which would simply not happen. As a free project (people are not getting paid for coding) just about everyone would come out of the woodwork, and it would be difficult picking out the right programmers for the task. Some people would be great coders, some would be just learning and would make a mess of things. Getting the team together and working well would be the first hurdle, and its a big hurdle.

This underscores a crucial point. Execution of such a project wouldn't be next to impossible, so long as there's at least a couple of programmers who are competent, and are capable of working with each other.
This is where a decent project management structure should be defined from the get-go. I've worked on a couple of open source projects, and we very much treat it as if it were any other part of our careers. We set project management standards, we evaluate each other's code to ensure a particular coding standard, and generally speaking try to maintain some level of order amongst the project. Granted, from my own experience in the Sonic Community, you do get a lot of people who will popup mostly just to stroke their ego boner. But those can typically be weeded out early on, and newbies to C/C++ can always be given smaller, less mission critical tasks as they work their way up in terms of skill. This is where I think a project management structure should be discussed well in advance to help mitigate these scenarios.

Quote

Programming the engine well is critical because the individual fan game maker will want to modify it to their needs no matter what you do. Small basic engines like Sonic GDK and BlitzSonic work because the majority of the math is done (the physics) and the programming (and language) is usually simple and easy to understand. Whats more, a basic Sonic engine is (usually) not loaded down with all the add on abilities like jump-dash, light-dash, skidding, rail grinding, etc etc. People are not overwhelmed and can easily add exactly what they want in their engine. For every feature/ability you add, there will have to be an accompanying animation or graphic, which means more work for the team making the base engine, and more work for the end user to create the animations for their own models. I can give you an example. BlitzSonic BGE is massive, and has soooo many features it actually makes it more difficult to add your own content. So, the engine you propose would have to be either very simple, in which case we have Sonic GDK, or alternatively it must have it's own dedicated UI for editing various functions of play so that people are not bothered with extensive cfg files and editing it and re-compiling in C++.

These are all very important issues to discuss, and of course there's no simple answers to any of them. Too little functionality, and people pass it by as unusable because it doesn't support homing attack light dashes into the depths of robotnik's bowels, or simply lack a trivial means to implement such. Too much functionality that's exposed to the content creator, and the user rips their hair out trying to determine what they need to do to achieve one of their design goals while putting up with hundreds of different options thrown in their face.
Personally, I think a combination of editor UI design that just makes sense, and an easily scriptable engine is the best solution here. At the same time, how all of that works would still need to be defined, and that's where the biggest challenge will lay I think.
This post has been edited by Gen: 16 February 2012 - 11:51 AM

#8 User is offline Candescence 

Posted 16 February 2012 - 11:59 AM

  • Posts: 1310
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff

Quote

Well of course there would be a great deal of functionality that would need to be implemented. That comes with any game engine. :P
We're looking at a rendering system, an asset system, an efficient way to manage available resources, physics, and scripting just to name a few.

Well, that's fair enough, obviously.

Quote

Transvoxel would be great, and I'm sure ideas could be tossed around all day long for potential terrain ideas. Definitely a subject that I'd foresee getting some decent discussion in on.

Very much so. Terrain would a vital part of any Sonic game that uses natural, wide-open environments, so it should get special attention. Sculpting terrain via voxels would be great.

Quote

Which really underlines how a community produced engine could be greatly beneficial. If people want feature XYZ, that just isn't very trivial to implement in another engine, work could go into producing such a feature at the lowest levels to help ensure maximum performance is achieved; something you just can't do in UDK or Unity (even if you can get close to doing so in Unity).

Well, can't argue there. Especially if the source is open and can be improved by anyone, provided that it doesn't cause issues.

Quote

This is one of those subjects that will likely receive plenty of attention. There's so many options here that can be utilized. LUA is one of the better performing ones, and there's even javascript for those of you who are more familiar with web programming, or even going the Unity3D route of using a stripped down mono runtime.

The editor discussion is going to be very interesting. I'm of the mindset that if a project like this goes forward, the content production toolchain should be easy to learn, almost to the extent of being able to "dive right in" with regards to making levels, and importing content.

There's also Google's 'Native Client' that allows native code to be run in a browser. Granted, that's currently Chrome-only, but still. There's quite a few options.

And yeah, an editor will as best ease of use as possible is very much ideal. Overgrowth, as I mentioned before, is a fantastic demonstration of this. Cube 2: Sauerbraten allows you to build level geometry in a 3D equivalent of how you would make tiles in a 2D game, and even features cooperative level editing (which is an awesome idea). Both of these editors are within the game engine itself, allowing you to edit and then test immediately. There's plenty of ways to make an awesome level editor.

Quote

Planning is always necessary for any project, and the amount of work that needs to go into it should reflect the overall demand of the community. If people only really want some sort of 2D sonic engine, then there really isn't much of a point for the project, as there's already viable 2D engines for this sort of thing. If they want a 3D sonic engine with basic collision detection, then that's certainly doable. If people want a 3D sonic engine comparable to say, SEGA's Hedgehog engine, then that would be a pretty tall order, that would only be accomplishable in smaller phases over time.

Pretty much. Start small, work your way up as you go. And, as an open project, anyone can present their own ideas on how we could go about it.

#9 User is offline Gen 

Posted 16 February 2012 - 12:43 PM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostCandescence, on 16 February 2012 - 11:59 AM, said:

And yeah, an editor will as best ease of use as possible is very much ideal. Overgrowth, as I mentioned before, is a fantastic demonstration of this. Cube 2: Sauerbraten allows you to build level geometry in a 3D equivalent of how you would make tiles in a 2D game, and even features cooperative level editing (which is an awesome idea). Both of these editors are within the game engine itself, allowing you to edit and then test immediately. There's plenty of ways to make an awesome level editor.

An easy to use editor would likely be the biggest reason to do a project like this. In-game editing could be a great feature to have, being able to edit and test your changes instantly without having to switch windows or what have you. Object placement could be a trivial matter as well, depending how asset importing is to be handled.

#10 User is offline CorralSummer 

Posted 16 February 2012 - 09:42 PM

  • Posts: 24
  • Joined: 01-November 11
  • Gender:Male
A modern Sonic engine? Interesting.

The subject of features is a tricky one, however I doubt they would be all added at once so there would be a lot of time to make it work and easy to understand. Either way if you have a good UI it shouldn't be a big problem.

It's times like these I wish I could program, alas it's not my area of expertise.

#11 User is offline Aerosol 

Posted 16 February 2012 - 09:47 PM

  • FML
  • Posts: 6381
  • Joined: 27-April 08
  • Gender:Male
  • Location:New York
  • Project:Sonic (?): Coming summer of 2055...?
The main things you want to identify are what physics features are at the base of a Sonic engine. The problem with that is...there are different kinds of Sonic games that people want to make. You've got your "Adventure" kind of Sonic games, and your "Unleashed" kind of Sonic games, and your "2.5D" kinds of Sonic games, and your "3D Marble Playground" Sonic games. What are we gonna do, make the most basic physics engine you can for each of those and throw a scripting language in there to handle the rest? There isn't a way to code one physics engine that works for all of that. You may be able to consolidate a "2.5D" engine with the "marble playground" engine, but that's about all I can think of.

#12 User is offline Gen 

Posted 16 February 2012 - 10:01 PM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostAerosolSP, on 16 February 2012 - 09:47 PM, said:

The main things you want to identify are what physics features are at the base of a Sonic engine. The problem with that is...there are different kinds of Sonic games that people want to make. You've got your "Adventure" kind of Sonic games, and your "Unleashed" kind of Sonic games, and your "2.5D" kinds of Sonic games, and your "3D Marble Playground" Sonic games. What are we gonna do, make the most basic physics engine you can for each of those and throw a scripting language in there to handle the rest? There isn't a way to code one physics engine that works for all of that. You may be able to consolidate a "2.5D" engine with the "marble playground" engine, but that's about all I can think of.

One thing that could potentially be done, is having a centralized character controller that accepts different parameters. Parameters like a movement plane, whether it should follow some sort of path, what the jump gravity and arc should be, and and even a surface normal angle threshold for how sonic should "stick" to surfaces, and what speed he should be moving at to do so. It could be a more generalized solution that gives a relatively comprehensive set of functionality, that could be iterated upon rapidly as the engine evolves, as I do see enough parameters that would cause enough overlap for an overall generalized solution here. To make customization easier, sets of presets could possibly even be provided later on, to better accomodate for different play styles, since naturally, different people will have different ideas regarding how their game should feel in terms of gameplay.

This is where I think a larger discussion about how a general character controller *should* work would be beneficial.

Camera control is a whole other problem in its self, however. I believe that would be the bigger issue here, as that is something that can be quite hard to generalize in a similar way.

EDIT: Come to think of it, could just offer a camera control scripting API, and offer a variety of premade scripts that can accomodate different play styles with different adjustable parameters, while also serving as examples of how to make your own if they just don't fit the overall gameplay feel that someone is going for.
This post has been edited by Gen: 16 February 2012 - 10:08 PM

#13 User is offline Falk 

Posted 17 February 2012 - 12:44 AM

  • Posts: 979
  • Joined: 03-October 11

View PostGen, on 16 February 2012 - 08:40 AM, said:

A prime example of a library that would be acceptable is FMOD, as it's available for Windows, OS X, and Linux. It's also free for non-commercial use.


If we're open to middleware (and I don't see why we wouldn't other than "OMG IT'S BLOATWARE AND I'm REALLY PROUD OF MY OWN CODE THAT LOOPS OGGS AND STUFF") I'd actually suggest Wwise over fmod. The only thing fmod has going for it is it's more well-established in the industry proper; there isn't much it can't do that Wwise can't and Wwise is five times more flexible, especially in terms of soundtracks- don't get me started on the hilariously broken music tab in fmod designer and the bazillion workarounds that people hack-job into their banks. For a fangaming community that's going to have to learn one or another anyway (as opposed to say, a dev who's already familiar with the ins/outs of fmod) the familiarity perk of fmod holds no weight.
This post has been edited by Falk: 17 February 2012 - 12:47 AM

#14 User is offline Candescence 

Posted 17 February 2012 - 12:56 AM

  • Posts: 1310
  • Joined: 22-October 10
  • Gender:Male
  • Location:Sydney, Australia
  • Project:Construct stuff
I pretty much agree with what Gen said above. Modularity and giving developers options and examples of how they can go about doing things can certainly help.

Also, it would be a good idea to look for libraries and open-source technologies that could greatly speed up the development of the engine so we can get to the important stuff quicker while also allowing for the developers to implement their own stuff and ideas. Here's a couple:

OGRE 3D - I'm sure many of you have heard of Ogre, and as far as open-source rendering engines go, it's the most well known, and for a reason. I have seen some amazing stuff in Ogre, and the best part is, it's completely open source, so we can do whatever we want to add new features to the rendering engine, and as a bonus, we can pass on those features to the Ogre community as well, so everyone benefits.

MyGui and Crazy Eddie's GUI System - both of these are GUI libraries that are flexible and allow for some very sweet things to be done. I'd reccomend MyGui, but both are viable options.

#15 User is offline Gen 

Posted 17 February 2012 - 01:32 AM

  • This is halloween! This is halloween!
  • Posts: 309
  • Joined: 03-August 06
  • Gender:Male
  • Project:The Mobius Engine

View PostCandescence, on 17 February 2012 - 12:56 AM, said:

OGRE 3D - I'm sure many of you have heard of Ogre, and as far as open-source rendering engines go, it's the most well known, and for a reason. I have seen some amazing stuff in Ogre, and the best part is, it's completely open source, so we can do whatever we want to add new features to the rendering engine, and as a bonus, we can pass on those features to the Ogre community as well, so everyone benefits.

MyGui and Crazy Eddie's GUI System - both of these are GUI libraries that are flexible and allow for some very sweet things to be done. I'd reccomend MyGui, but both are viable options.

Ogre would be an almost instant no. Reason being, is Ogre is a good example of a middleware that's fairly bloated, and has a workflow that just generally sucks. Horde3D is a nice alternative, but I personally am kinda interested in writing a renderer. MyGui is nifty, may be worth checking out later.

I haven't really heard anything about Wwise, and at a glance, it seems nifty enough. But the primary concern is availability for non-commercial projects, that are also open source (this is the part that many middleware licensors get a bit squeamish about). For something crossplatform, we'd need a flexible enough license that allows compiling and linking on whatever we intend to have the engine running on. They seem to support many platforms, but only have the windows version publicly available it seems.

  • 9 Pages +
  • 1
  • 2
  • 3
  • Last ►
    Locked
    Locked Forum

1 User(s) are reading this topic
0 members, 1 guests, 0 anonymous users