Jump to content
  • Advertisement

OmegaEnabled

Member
  • Content Count

    13
  • Joined

  • Last visited

Community Reputation

100 Neutral

About OmegaEnabled

  • Rank
    Member

Personal Information

  1. OmegaEnabled

    New tech - RFC

    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.
  2. OmegaEnabled

    New tech - RFC

    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
  3. OmegaEnabled

    Xna Z-order precision

    Wow, that's a lot to digest. I get most of it, but once you get to using multiple clip planes -- woosh! If I had any hair, it would be blowing in the wind right now. But my question is officially answered. Thanks!
  4. OmegaEnabled

    Xna Z-order precision

    Thanks, that's concise and confirms what I suspected. So then, is there a way to use a 32-bit buffer in Xna? it might not be good enough, but it's better. Or do I need to use something more robust than Xna? What if I wanted to use a 64-bit buffer? Do graphics cards and/or APIs even allow that kind of thing? (good link. doubles are the bomb lol. someday i'd like to try implementing an infinite-precision math package for the world data, but that'll probably require a new kind of hardware to do quickly enough for realtime rendering.)
  5. Hi, I have a game management system that handles distance culling, so I use a custom frustum to cull objects before rendering. I don't clip the far plane because my system considers objects visible if they actually are visible. I mean, I don't cull distance at all. If the object is big enough to be seen at its current distance, then it gets drawn. It handles LOD sorting and is very fast. Anyway, just for fun, I set up a (actual size) Sun and Earth, and set them their actual distance apart. I used a 1:1 scale where the value 1.0 represents 1.0 meters. So I made the earth object 6M units (radius), the sun object 700M units, and set them 150B units apart. My system handles everything fine: objects look pretty, no jitter (double precision), and such. The problem is, the renderer is drawing the sun on top of the earth when the earth should obscure it. I'm guessing this is a z-order precision issue, but I'm not a rendering guy. My guess is that there's nothing I can do about it, but I wanted to be sure. Oh, I'm using Xna for rendering right now, but my system allows for any rendering codebase to plug in fairly easily, so I'm asking this specific to Xna but not to the exclusion of other rendering engines. Cheers, Dave
  6. OmegaEnabled

    New tech - RFC

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

    New tech - RFC

    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
  8. OmegaEnabled

    New tech - RFC

    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.
  9. OmegaEnabled

    New tech - RFC

    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.
  10. OmegaEnabled

    New tech - RFC

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

    New tech - RFC

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

    New tech - RFC

    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
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!