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.

Here is the latest video. Here is the website.

Giga-Thanks!
Dave

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)

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

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.

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.

What I need is to partner with someone who can do what I cannot: rendering.

I found this video -- 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.

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 very 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 one 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 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.

Now, If I want to prove 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, assume for one second that everything I am saying is true: all that amazing stuff that omega does all together is real. Now, with all of that capability, would you be pleased to know that how 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