"This is probably the worst actual engine choice to make in this case, honestly."
You should talk to NCSoft too, I hear they're on a similar path. =P

Quote:

Original post by JJacobo "This is probably the worst actual engine choice to make in this case, honestly." You should talk to NCSoft too, I hear they're on a similar path. =P

Two facts.

A) Last I heard NCSoft was a huge corporation that has experience working with existing engines, gold games, experienced engineers, and some of the best network developers in gaming. Maybe I heard that wrong though.

B) I'm not trying to bash you or anything, I'm just saying have fun trying to use Source as the LoD, scene management, etc in the engine is specific to an FPS and you will have to rewrite this.

Bone LoD, Normal LoD, and many other important facts relevant to getting that many players on the screen are missing.

Not to mention how much work it is setting up a seamless world as hplus has already said. After a month of design work our company decided to go with a zoned approach due to the sheer amount of work a seamless server brings, along with all of the issues/problems. Sure it is a lot nicer than zones, but for the majority of development teams it just isn't feasible.

Also you might want to check on your target audience and hardware specs. Just FYI the majority of features you listed won't run on the average RPG players system so they are basically writeoffs or art-stalls. The features that will be usable in context are ones found in every other engine.. although I do see one single benefit. Tools. They are the most important part of an engine and that is one thing Souce has covered.

Also are you not having terrain? foliage? These are some very complex problems to get write and budget for. Even looking at cheap solutions, such as TSE by GarageGames, it is much more adaptable to a huge world. Reality Engine even more so.

Also if you think you are going to do the same types of physics simulations that HL2 does in an MMOG setting I hope you have some of the best network developers in the world... as you are going to need to write a lot of custom throttling, degration, etc on that end... and your guys with web server experience just won't cut it.


EDIT: Oh I just wanted to clear up that I in no way meant to go out and build a client engine over using an available one. Reading over my post again it kind of seemed I implied that in a way.. which I did not mean. I just meant that there are engines that are much better for building such a game than an engine like Source... hell even TSE by GarageGames gives you more usable features out of the box with paging terrain, large view distances, advanced water, etc which are more along the lines of actual features you will use. And before you mention the terrain capabilities and scenegraph of HL2 I will point you to download a map with a large terrain.. because on my 6800U it runs <60fps without objects.

[Edited by - Saruman on May 17, 2005 10:44:00 AM]

Quote:

Materials can interact with objects or NPCs such as mud or ice for vehicles to slide/lose traction on. (check)

Actually, that's not a "check" if by "check" you mean "can be used in an MMO game without more work". That's because it's a physics property.

The entire physics section, which you have marked "check," may significnatly impact how your networking performs, and in the end, may be a bottleneck for getting the "M" in MMO to actually deliver. I think this might be the main thrust behind the suggestion that Source is not a good engine for MMO games, and you'll have to scrap significant parts of it.

You should have someone who knows distributed simulation look at your goals for player count, visibility distance, physics model (including details of interaction mechanics), latency, and bandwidth, and come up with some realistic ideas of what's doable and what isn't. Before you can actually go into those details, nobody can really tell one way or the other. And, even if you were posting those details here, well, to get a good answer you'd probably need to pay someone for their work (and it'd take more than a single hour :-)

Quote:

Original post by Saruman Also you might want to check on your target audience and hardware specs. Just FYI the majority of features you listed won't run on the average RPG players system so they are basically writeoffs or art-stalls. The features that will be usable in context are ones found in every other engine.. although I do see one single benefit. Tools. They are the most important part of an engine and that is one thing Souce has covered.

One of the good things about most MMO's is that you can change the LOD. I recently bought EverQuest2, and even though my PC isn't a total POS, I still needed to set the visual and audio LODs to minimum. And I don't mean the minimum settings recomended, I custumized the settings to have the barebones of the game only, and I still have some problems with lag(though I can't attribute it to my connection because I have DSL, so it must be my computer). I don't mean to say that you are mistaken Saruman, you have helped me before and I know that you are very knowledgable. I just think that if the game had some massive custumization features avalible. Good luck with the game, and if you get near the end of development, post the name of it on here so I can buy it [smile]

Desmosthenes2005 you are correct in the sense that you need customized LoD schemes for dealing with the large number of mobiles that can be on the screen at any given time. Also the physics system will not work without major rewrites and modifications.

My post wasn't saying that the game could not be built, just that the source engine is a very bad choice for it because it exists to solve a completely different problem space.

Also what you said completely fits in context, that you can tune the settings down. But you must remember that the game you mentioned has an engine specifically created for large amounts of mobiles in the viewport at any given time. Source does not support having this many mobiles at any given time and would choke without a major rewrite.

The part you quoted was basically just saying that the majority of his 'pluses' are meaningless because they are unusable on many RPG players systems, let alone the fact that you can't use any of them with a massive amount of renderables/mobiles on the screen.

If we want to discuss the plusses and minuses of specific rendering engines, I suggest we move on over to "graphics programming and theory" :-)

That being said, I believe that how many entities you can draw in your viewport depends more on how you create and manage your art than which specific rendering engine you use to present that art to the graphics card. Personally, I think the Source renderer and art path could work just fine. If you need huge outdoor spaces, then the current tools limitation is likely worse than the renderer limitation.

Quote:

Original post by hplus0603 Personally, I think the Source renderer and art path could work just fine.

Meh.. I still think it would need some modifications (does source bone lod? normal lod? the terrain would need to be adjusted, you would want to build in foliage like speedtree or a custom solution) and obviously as you said the tools. Also I don't mean it's impossible.. just that even building it in Torque or another engine and using RakNet would actually be much easier and produce the same or better results. Although I will let it rest now as I agree you know more than me about the subject :)

//nod

Quote:

Original post by JJacobo We understand the risks involved with the high production costs (though the lisence itself is nowhere near one hundred thousand, DrEvil =])

Right, that's why I said several hundred thousand.

Unreal Engine 2, and hell even quake 3 engine still license for ~300k(unreal is 350k for 1 platform + 50k for additional platforms). If you are trying to say you got a proper license for the source engine for nowhere near even 100k, I'm calling bullshit.

Quote:

Original post by Anonymous Poster Quote: Original post by JJacobo As for the latency, we will be limiting and balancing what is processed by our server versus what is processed by the individual clients. NO processing whatsoever can be done on the clients. The client's duty is to present an appoximation of the game state on the server and to get input from the user. As soon as you let the client be authoritive over even one aspect of the game rest assured it will be exploited. Caching assets such as dialog, images, and models at the client is fine.

That post was mine.