Sign in to follow this  
OmegaEnabled

New tech - RFC

Recommended Posts

Hello!

I joined up because I have developed a new technology for game development and
I was hoping to get some eyeballs on the demo video.

I could really use some feedback from people in the know. I need to know things
such as if I'm explaining what it does well enough, and if the video is as impressive
as it should be.

I know the tech is amazing when you see it on the inside. I need to make it amazing
when you see it on the outside.

The catch is that it's not a rendering engine, and I'm not a graphics coder, so the
graphics suck. Also, I can only demo on the hardware I have, so it's not as huge as
it could be.

People like you should be able to see past that, but until I find rendering help, I need
to get across to potential investors that it would be impressive to a layman if I
actually plugged in a better renderer.

Some constructive criticism would be appreciated, but be gentle -- I've only just come
out of the proverbial closet with this. Any questions are also welcome before you
form an official opinion on the tech.

Last thing. Please excuse (and read past) the marketing language. I know you'd like
a white-paper, and there is technical info there, but for now, I'm trying to boast about
it a bit to get the attention of the muggles, not you wizards.

[url="http://www.youtube.com/watch?v=fnuGFDTCtcY"]Here[/url] is the latest video. [url="http://omegaenabled.com"]Here[/url] is the website.

Giga-Thanks!
Dave

Share this post


Link to post
Share on other sites
Irlicht looks much better than my garbage renderer.
I'm using Xna sample code for everything visual.
Omega is the other part: space, objects, interaction, AI, etc. and it's scalable.
You add rendering, physics, and stuff like terrain.
I don't force you to use anything you don't want to.
Also, it makes it easier to port to omega.
(I hope you can understand me too) :)

Share this post


Link to post
Share on other sites
You could add some text as i almost always have volume at 0 for no reason, and you could add more big planets and make them.orbit each other by adding gravity if thats possible. That would be interesting to watch... Also, does it have an option for also using the clients computer for processing if there is free resources available? That would be a possibly useful option to have.

Share this post


Link to post
Share on other sites
Thanks for the suggestions.

There actually is annotation to the video. Maybe you have it turned off? I know YouTube mobile doesn't show annotation. Maybe I'll add it into the video itself. Good call.

It is possible to design your game with what I call "physical" objects -- which won't be offloaded from the client. Let's say your player is a collection of objects and not just a single one -- maybe your character, his staff, and particles flying around it. All those objects can be processed on the local client and still be visible to everyone else plugged into the cluster (if they are near enough to see the player). No need to virtualize all the objects in the game -- it's up to the developer.

Now, using the clients as actual cluster nodes? No, that won't work. Omega can provide you with the ability to create a Battlefield 3 MMO that covers multiple planets in an entire star system. To do that, you can't have remote nodes in the core cluster doing the generic work -- even 20ms lag is bad for that many objects getting updated that often. The workhorses of the engine must be in a local network. So, while you can have many objects on the client, they must be created locally on that client, and the cluster will not send objects to the client to be processed.

Okay, so now I can come to the complete answer. If your game wants to ship objects to the clients for processing, then it can tell clients to create objects locally, but that's not the point of omega, so it's not inherent in the engine -- and too much of that ruins the scalability anyway.

EDIT: explaining this isn't easy. I may have given the wrong impression by using the term "client". Omega abstracts the concept completely, so your game doesn't know who's a client or not, but it does know if a given object is a "player" or not. It could then tell that player object to create child objects. If that player object is running remotely, then it will indeed create the objects remotely, but the game logic can't know that it's remote through omega, it has to be pre-determined in the game code (i.e. make sure all player objects are created as "physical" on your client end only).

Share this post


Link to post
Share on other sites
Now don't get me wrong there, but... that demo is very poor at showing what your point out as revolutionary. What I've seen there is more or less Celestia in demo mode, plus a minimalist starship model and the ability to shoot enemies (asteroids?), minus any visible detail on anything. Every star/planet/object is either a white sphere or a tetrahedron.

Celestia, on the other hand, lets you zoom known planets (of which image footage is available) to quite impressive detail. An universe with 3000 solar systems and 17 million objects all of which are zero-detail blobs total is not impressive. What's impressive is if after flying through those zero-detail blobs, you show how you can do a Deathstar-trench flight through a canyon on a nearby "no detail blob", showing that it has in fact detailled, individual terrain.

Share this post


Link to post
Share on other sites
I appreciate the input!

I tried to make it eminently clear that this engine does not handle graphics, so my graphics are not impressive. Rest assured, every sphere could be as complex a mesh as you want. Since omega doesn't handle drawing directly, how many complex objects in view at one time is the developer's problem, omega just says, yeah these objects are close enough to be seen, and provides a LOD value for each object when you draw it.

I was hoping at least people who make videogames for a living would recognize what omega can do despite the lack of cool graphics -- since that's how all games begin. You can replace those objects with any meshes you want -- or whatever rendering programmers do, I'm not one of them. Though, you could say the spheres are pretty complex because the high-res model was built with UV settings of 512x256 -- so that's a lot of triangles.

Celestia does seem to provide some of what omega provides. The large-scale aspect is just one part of omega. Can Celestia allow all of the users to join a shared space and travel the galaxy together mmo-style? I'll have to run it and see how it works.

See, omega isn't doing any ONE thing that's special -- it's doing them all together that has been, I believe, the holy grail of game development.

While I can assure you that what you said would be cool is easily doable in omega, I can't prove it without more time and/or money.

Thanks for the critique! Keep it coming guys!

EDIT: Yeah, Celestia is neat, but it doesn't come close to what omega can do, since omega is cluster-based and thus highly scalable. With omega, if you visit another galaxy, you don't just look at it and zoom in a bit, you can enter it and fly around it. Celestia is obviously doing some tricks to make it seem like you're freely running around the universe, because it's not doing that exactly. I'm still looking for wasd controls -- or can you just view things from orbit? Because that's a neat way to get around the single-precision float issues, but it's very limiting.

My point is, celesta is cute, but you can't make a game out of it. Omega lets you do what celestia pretends to do, but omega does it for real -- and with a pantsload of other players in the same space.

Share this post


Link to post
Share on other sites
What I need is to partner with someone who can do what I cannot: rendering.

I found this [url="http://www.youtube.com/watch?v=OiGADgezjC8&feature=g-all-u&context=G24184b8FAAAAAAAAAAA"]video[/url] -- which is what led me to join GD, actually. I need something like that, because omega would allow that planet and thousands of others to exist within the continuous space in my demo. So in that video, you'd leave orbit, and then take off for another star and enter the atmosphere of one of its planets -- with (at least right now) me and a few other people following you there.

If I could do that, then I think my demo would be impressive enough for anyone. It's easy to do with omega, actually. I just need help making the planets.

Share this post


Link to post
Share on other sites
You may be asking quite a lot there - [url="http://swiftcoder.wordpress.com/2009/05/28/starfall-planet-rendering/"]planet rendering on a realistic scale is not trivial[/url]. On the other hand, if there is money in it, I imagine you could attract one or more of the planet rendering people to help out.

To be honest, I'm still not clear exactly what Omega *does*. I get that it distributes server workload, and that it has a flexible coordinate system (though the latter is pretty trivial - my planet renderer does the same).

Can you describe in a little more detail what exact sets Omega apart from other MMO architectures? And where it represents a net savings over other toolkits that assist with the expensive parts of the game development process (asset pipeline, rendering, pathfinding, AI, etc.)?

Share this post


Link to post
Share on other sites
Thanks for your time.

I'm still learning how to describe omega myself, actually. That's really why I'm asking for help. Let me see if I can clarify.

A. That video I linked is an engine doing planet rendering in Xna, and it looks like CGI water. So, planet rendering may not be easy, but it is doable. I would like to marry that with omega because omega imposes a 99.9% server load, and the client is doing [u]very[/u] little work. Therefore, the client has 99% of the local CPU to handle all the planet rendering and whatever else (assuming it's at least a decent CPU). On my QX9650 @3GHz, it literally peaks too low to register. I can minimize the window and exclude the rendering work, and omega is all the work that is being run. The CPU usage goes to 0, even with my buddy killing enemies within my visual range. (edit: Also, I can move my thumbstick around with the game minimized and he can see me moving around, so omega is still doing its part of the work)

This is why I think it would be so impressive. For the first milestone, the planets would be integrated as game content, but I could see the system being implemented within the omega API someday. The idea is you wouldn't need local content for each planet. The data would stream to you as you visited (and even as you got closer to) the different planets. That opens up the ability to auto-generate worlds. At that point, my vision of thousands of stars, each with their own unique planets, becomes possible. In the meantime, planet-specific local content is acceptable for the first milestone.

B. Omega uses double-precision. I've checked around, and the only mmo middleware products I've found use single-precision. Their spaces are measured in kilometers. Omega's spaces are measured in millions of kilometers. How you do it is surprisingly trivial, but only once you figure it out. I've been surprised how many engines only use single precision, and I thought it was a good selling point that omega uses doubles.

C. What makes omega special? Well, I can't point to any [i]one[/i] thing necessarily -- not without exposing my secrets. However, it's what omega does in total that makes it special. Some engines handle thousands of players. Some engines can handle FPS-level update speeds. Some engines can handle spaces of billions of meters cubed. Some engines can remain stable even under an immense load. Some engines require very little bandwidth. Some engines have a small client footprint. Some engines make game development incredibly orderly and logical. Some engines even do more than one of those at the same time, but...

From what I can tell, no existing engine can do all of those things together at once. That's what omega does. Also, I'm being conservative when I say things like "thousands of players" because there's no reason that, with enough nodes in the cluster, you couldn't handle hundreds of thousands of players. It's inherently massively parallel, so there's almost 0% overhead to adding nodes to the cluster, even many thousands of nodes.

Now, I can't [i]prove[/i] that this system will scale up like that. I can only say that I've tested on two low-end xeon machines, and run 2/4/8/16 node clusters. I can say that omega scales up perfectly, and the overhead is too small to detect.

Now, If I want to [u]prove[/u] it can do more:

1. I will need more computers to run on
2. As far as I know, that will require money
3. To get the money, I need to impress muggles with lots of money and very little technical knowledge
4. To impress muggles, I need shiny things
5. To get shiny things, I need to partner with someone who knows rendering

That brings me to you lovely ladies and gents. If I can't find a partner here, then at least I could be critiqued by the experts.

To your final question, omega has 0 to do with rendering. It will not save you work in drawing cool graphics. On the developer side, omega gives you a very simple object-oriented framework. It makes your game code simpler and more logical. Your rendering-loop is another story. That's for you to build. I don't know how other engines work, but with omega, your game logic is separate from your rendering code. The rendering code uses info from omega to decide what and how to render, but the game logic is pure "if target gets this close, track and chase him" kind of code and as a result, the code is very clean.

An OOP-based game API is nothing new in itself, but, [i]assume[/i] for one second that everything I am saying is true: all that amazing stuff that omega does all together is [u]real[/u]. Now, with all of that capability, would you be pleased to know that [i]how[/i] that distributed "magic" is being done is 100% abstracted from your game code?

I hope that helps. Sorry if I'm long winded, but I'm trying to be as specific as I can.

Cheers,
Dave

Share this post


Link to post
Share on other sites
You might look into Virtual Private Servers or adapting Omega to cloud-computing architectures. For relatively little money you could at least do a proof-of-concept where you can scale up and load-test. Many providers have fast backplane networks for inter-server communication. VPS is typically sold month-to-month or on longer terms, but many cloud computing platforms are stictly pay-what-you-use -- so you could spin up a couple dozen large instances inside of a few-hour window if you wanted. Cloud processing also often has dynamic provisioning, which it sounds like Omega could tie into.

Share this post


Link to post
Share on other sites
Lol don't try to judge a tool just for the graphics of its demo. Irrlicht can be very powerfull as many other engines. And your OMEGA demo is great. If you are really going to have all that features, that will be the most innovative game engine ever. Pepole just spoken about the chance of distributed games, but you were already writing a distributed game engine ;-) great great new keep working on that. Of course is not scalable to other non-window machines (so will be hard to see it on linux or mac for now right? if not impossible).

Share this post


Link to post
Share on other sites
Ravyne:

I have a VPS and I tried running omega on that. All the amazing things omega does is only possible with a low-latency network. It requires dedicated machines or the whole thing poops out. It took two dedicated servers (hosted by voxel and the most I can afford). Thanks for the suggestion though!

DemonRad:

Wow! Finally! Now I know there are indeed people out there who can see the worth of the engine despite the lack of a good rendering side!

I really needed that encouragement, thank you. Now where's the rest of you all?

Of course there's still the obligatory "if" in there. I [u]do[/u] need to prove it will scale up like I say. I hope I can.

One interesting note about scalability -- and I think this may indicate that omega is inherently parallel -- is that I only have 2 machines (8 cores) to run my cluster, but even running 16 nodes (2 per core), I see each node using 1/2 the CPU than they did with an 8-node cluster.

I'm an inventor who can code, not a coder who can invent -- so I'm not an expert in anything, least of all cluster computing. However, instinctively, I feel that having more nodes than cores and still seeing it scale up is a good indication that it's massively parallel.

(Edit: Missed your last question, here's the answer:)

Portability of the client is very high, actually. I haven't tried it yet since I can't handle rendering in Xna, let alone OpenGL or whatever else. However, the omega libs are all pure CLR assemblies. Only Zmq and Xna aren't pure. Zmq is server-side only, the clients use normal sockets, so that's not an issue. And Xna would be replaced in a port (or used because of portability, I dunno), so in the end, Omega itself is 100% pure managed assemblies.

I've been looking around, and I found something called "Mono". That makes porting .Net relatively trivial. In fact, I've done Android development, so I'm now looking at "Monodroid". If I could get help with the rendering on android part, I could port omega to android. Also, monodroid lets you build for iOS too apparently.

Since omega uses so little of the client cpu, the demo I have now on PC would easily run on a phone/tablet. I'm still looking into it (I'm just one man, after all), but it looks like targeting Xna initially and using .Net managed code was a good plan for the portability ease.

If the question was more about distributing the load to Mac/Linux -- that tells me I'm not explaining omega very well at all. Omega doesn't ship work [i]to[/i] the clients. If anything, it ships the work [i]from[/i] the clients. The cluster is a tight group of identical machines. As I said, the omega client is using less than 1% of my CPU. Clients connect into the cluster and they can share the game space with other players -- and games can benefit from all the other cool stuff omega does.

Keep it coming yall! Encouragement, questions, or comments. I'm eating it up!

Cheers,
Dave

Share this post


Link to post
Share on other sites
I must admit, I'm not asking out of purely academic interest. I have a quite advanced planet renderer (there's been about a year's work since [url="http://www.youtube.com/watch?v=8aQhCO6hpu4"]the video[/url]), and I'm sort of looking for something meaningful to do with it [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

You cleared up some of the points that were mentioned on the website, but I still don't know what services Omega provides.

I assume it provides per-player visibility determination? Does it provide distributed physics simulation or collision detection? Does it provide persistent storage for player attributes? Does it provide a framework for user authentication and account management?

[quote name='OmegaEnabled' timestamp='1330121717' post='4916344']
Now, I can't prove that this system will scale up like that. I can only say that I've tested on two low-end xeon machines, and run 2/4/8/16 node clusters. I can say that omega scales up perfectly, and the overhead is too small to detect.[/quote]
You have to understand, without a better idea as to your simulation architecture, I am a little skeptical of this claim.

For a heavyweight simulation, scaling to 16 nodes is not too dificult, but scaling into the hundreds/thousands of nodes is a whole other ballgame.

If however, Omega is effectively just a distributed spatial partitioning structure, with a little bit of visibility/physics/ai tacked on, then scaling to a large number of nodes is fairly trivial - and in that case, I'm not sure what you are offering over what I can write myself.

Share this post


Link to post
Share on other sites
[quote name='swiftcoder' timestamp='1330154153' post='4916443']
I must admit, I'm not asking out of purely academic interest. I have a quite advanced planet renderer (there's been about a year's work since [url="http://www.youtube.com/watch?v=8aQhCO6hpu4"]the video[/url]),

[i]The video was impressive. I'd love to see an update to it![/i]

and I'm sort of looking for something meaningful to do with it [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]

[i]Right here baby![/i] :D

You cleared up some of the points that were mentioned on the website, but I still don't know what services Omega provides.

I assume it provides per-player visibility determination? Does it provide distributed physics simulation or collision detection? Does it provide persistent storage for player attributes? Does it provide a framework for user authentication and account management?

[i]Visbility: Yes, it provides the renderer (or whatever local logic you have) with a set of lists[/i][i] of objects that are "visible" -- though, there's other things you could use LOD info for, such as for long-range object detection to load local assets before they are actually visible.[/i]

[i]Physics: No, in omega, physics is like rendering, it's game-specific. So you plug in your physics like you do with rendering.[/i]

[i]Collisions: Yes, this is the entry-point to the physics. I tell your objects the who where and when of collisions and your objects react to them -- be it exploding like in my demo, or bouncing around with physics logic.[/i]

[i]Persistence:[/i][i] Not yet. This is as far as I've gotten. I need a backing store, but I have plans. I was just hoping to get funding, so I wasn't the only person working on this -- it's become a huge system and I'm tired.[/i]

[i]Authentication: [/i][i]Not yet. It's a prototype. Stuff like a backing store and adding ssl to the sockets is ancillary work to the core I have so far. The hard part was doing what I've done.[/i]

[quote name='OmegaEnabled' timestamp='1330121717' post='4916344']
Now, I can't prove that this system will scale up like that. I can only say that I've tested on two low-end xeon machines, and run 2/4/8/16 node clusters. I can say that omega scales up perfectly, and the overhead is too small to detect.[/quote]
You have to understand, without a better idea as to your simulation architecture, I am a little skeptical of this claim.

For a heavyweight simulation, scaling to 16 nodes is not too dificult, but scaling into the hundreds/thousands of nodes is a whole other ballgame.

[i]That's why I need help. I need to prove it scales up further.[/i] [i]It will...[/i]

If however, Omega is effectively just a distributed spatial partitioning structure, with a little bit of visibility/physics/ai tacked on, then scaling to a large number of nodes is fairly trivial - and in that case, I'm not sure what you are offering over what I can write myself.
[/quote]

[i]Hmm... I suspect if it was that easy, then my claims wouldn't be so revolutionary. "Spatial partitioning"? You mean like is my system nothing more than a distributed oct-tree? Yes, it is much more than that. You've got to do a lot more than just put objects in a tree to distribute a game in a general way (without knowing the content of the game itself), and allow all of the tens of millions of objects to potentially interact with any other object in the billions-of-meters-wide space.[/i]

[i]I won't get into the secret sauce, but if it was that easy then we'd be playing something like "Mass Effect Online" where every planet is unique and engaging the mass-drive doesn't bring up a load screen, you actually travel a billion miles to get to your destination. Meanwhile, the 1000 other players are all doing their own thing on other planets, killing other AIs, in the same game space you are in.[/i] [i]If you can do that, the world is waiting and I have to ask why would you make me do all of the work? :D[/i]

[i]So, I'd love to see if we're a fit, but if you feel you can do what I just did -- and apparently nobody else has been able to do -- then I wouldn't blame you if you did it yourself.[/i]

[i]But here's the thing: I just came up with a new idea for a way to render planets last night. I'll be working on that for a bit. Even if my way is as revolutionary as omega, I [/i][i]would [/i][i]still prefer if I was working [/i][i]on it[/i][i] with someone, rather than alone. I don't know about you, but I'm exhausted. I could use some collaboration in my life right about now.[/i]

Cheers,
Dave

Share this post


Link to post
Share on other sites
Let me try it this way. Here's a situation that illustrates how omega would be beneficial to your game. For a moment, put aside the doubt that omega works. Assume I've proven to you that it will scale up as far as you need it to.

Let's say you wanted to turn your planet renderer into a game. You used omega to build a 4-player survival-mode game that takes place on your planet, each round at a different random location. Let's say it requires 1 node to handle the load of a single individual session.

Now let's say someone loved it and said let's make it a 16-player game, how much would it cost?

The answer is: as much as 3 more nodes cost. You don't have to change anything in your game code -- you would probably just have to raise your lobby server's max player count from 4 to 16. Since you'd have more players, you'd probably want more monsters, so you'd have your lobby server set the cluster up with a higher monster count. If you had a lot more monsters, you might actually need 4 or 5 nodes, but the point is, it's simply a matter of hardware assets.

Then let's say your game hits it big and your company is doing very well. You decide to make your game an mmo with thousands of players. How much will that cost?

The answer is: as much as the hardware for enough nodes costs. You still don't have to change your game code -- unless you want to change the game rules to allow for that many people. For example, instead of survival-mode at a random location, maybe players can explore the entire world as they see fit, and bump into monsters as they travel.

Then let's say your player base explodes and you need to set up separate "realms". Why? Just create more planets and put them all in the same single game space -- again, it's just a matter of how many nodes the cluster will require to handle the extra load of all those players and objects. Then you could allow players to travel between the worlds -- stargate style or via transport ships, your call.

I hope that helps. It might not illustrate [i]all[/i] the benefits of omega, but it should give you a sense of how it completely changes videogames and videogame development.

Share this post


Link to post
Share on other sites
I'm not trying to gang up on you here - one of my hobbies of late is writing parallel simulations in Erlang, and running them across the 40 node cluster here at the University [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img]
In the interest of keeping this (very engaging) topic alive:

What happens if we have a 1,000 user simulation, and they all decide to park their spaceships on top of each other? I can't quite wrap my mind around how you expect this to scale linearly - it's easy enough to distribute simulation if we can neatly partition users between available nodes, and inter-user interactions are localised. But users (and simulations) don't tend to be that well behaved...

Along the same lines, do you have some sort of provision to handle the case that the visibility query returns 1,000 items, but the mobile client is only capable of rendering/simulating 100 items?

Share this post


Link to post
Share on other sites
I've been following this thread as it's slowly developed, and I have to say, I'm still wondering exactly what it is Omega [i]does[/i]. The video showed several planetary systems, none of which really seemed to follow the laws of physics and be organized in protoplanetary disks. You talk about the capabilities of engines (handling many players, update speeds, universe size, etc.) without any mention as to the games those engines are running (and yes, that makes a huge difference, as two games using the same engine can have bottle necks at two different places) and why specifically Omega can do everything, and how I can expect Omega to be useful to me whether I'm making a high-speed MMOFPS or an MMORTS. I see it's got some collision detection, but what primitives/meshes does it support? Is visibility determined by the view frustum, or are things inside/outside of the view frustum ever reported as "visible"? Does Omega allow hot deployment of modules? How does it differ in features from other module-scaling solutions, like Apache Karaf? What are the limitations of Omega? What does it do for me, and what does it not do for me?

I'm not really wondering [i]how [/i]Omega does what it does, but [i]what [/i]it does. A large, detailed feature list is a must. If you can't clearly explain [i]what [/i]it does (whether because it's too secret or too difficult), I can guarantee you won't ever get an investor (and probably not a quality partner). I see you've listed some things, but they're either vague (distributing the game without knowing anything about it... what is it even distributing?) or already solved problems (like double precision...).

And let me say this last thing in total honesty: I am not in any way trying to discourage you. These are the honest questions I think everyone is trying to understand in this thread, and particularly questions people with money want answers to. The clear answer of [i]what [/i]Omega does. You make it sound like the panacea to all problems, but then I realize I don't even know what problems specifically it's solving.

Share this post


Link to post
Share on other sites
Sign in to follow this