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 do 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 to the clients. If anything, it ships the work from 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

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 the video),

The video was impressive. I'd love to see an update to it!

and I'm sort of looking for something meaningful to do with it

Right here baby!

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?

Visbility: Yes, it provides the renderer (or whatever local logic you have) with a set of lists 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.

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

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.

Persistence: 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.

Authentication: 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.

[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.

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.

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

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]

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 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. If you can do that, the world is waiting and I have to ask why would you make me do all of the work?

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.

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 would still prefer if I was working on it 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.

Cheers,
Dave

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 all the benefits of omega, but it should give you a sense of how it completely changes videogames and videogame development.