Sign in to follow this  

MMORPG Utilizing Valve's Source Rendering Engine

This topic is 4592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Because none of my threads can be an easy read, I am going to offer some information on our plans for our Medieval/Fantasy-based MMORPG project and humbly request any feedback. =P Please note that I am not a professional coder, and am trying to understand our technical goals from a developers standpoint. We have just finished liscencing Valve's Source rendering engine for our project and our goal is to convert it to a fully functioning, dynamic and persistent game world. Now, I mentioned that we will be utilizing a voice system in my last thread, but I would like to bring up a small sample of some of the more technical features: - Powerful Character Customization Players will be able to edit their face shape, hair/skin color, nose width, etc.. Additionally, there will be several layers of clothing/armor that can be customized as well. - Innovative Combat System Since the Source Engine can offer dynamic action, players will be able to swing, duck, and doge blows in real-time, fire bows from 1st Person, or aim a ranged spell at a target. - Interactive Spacialized Voice System Players can approach one another and speak over the microphone, to be packaged with the retail copy. - Speaking NPCs and Voice Recognition NPCs will regonize certain key words, such as a name of a key character or the command to buy or sell. Also, spells will be casted by speaking aloud incantations into the microphone. - Fully Rendered and Interactive Items Items can be held and manipulated, offered, traded, used, even played upon (in the case of instruments), and will be rendered instead of the traditional MMORPG gump system. - Innovative War Campaigns Like a strategy game, different nations/races will be able to build up their forces to wage war upon their enemies' territories. Armies will consist of players, in-game actors (for larger less frequent events) and NPCs which will follow the orders of commanding officers in battle such as: push catapult, fire catapult, advance on location, defend the line, heal, pillage, and retreat. - Large Populated Worlds There will be relatively few servers with large and spread out countries amonst the vast in-game world. If your heads are hurting you should see our coders! Anyway, I would like any feedback on ideas on how to realize some of the following features. We are a little Art-Heavy on the team at present as we have more Developers and Artists (2D/3D/Animators) than we do programmers. Please try to keep the feed-back constructive, as we realize the scope of the project. I would really like to hear what our talented devs here, have to say. =] (shameless flattery) [Edited by - JJacobo on May 14, 2005 5:36:13 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Wow. How are you planning on handling all the clients though? I thought that the source engine had limitations on the amount of clients you can have connected to a single map.

Share this post


Link to post
Share on other sites
Well, more than any other programming difficulty, this is our paramount issue. The network side of the software architecture will have to be reworked to accommodate potentially, hundereds of players on screen at the same time. Additionally we do not have the luxory of a single-player game where we can load each small area, as needed nor that of a contained multiplayer game. The challenge will be to create a zoning (or map) system that can provide information to our players and databases dynamically.

Share this post


Link to post
Share on other sites
Rofl how much did it cost? It sounds like you guys are trying to make one hell of a game.

The problem i see with using the Source Engine for an MMO is that a lot of that stuff would probably cause very high latency (physics, voice, NPC's if they can recognize voices and commands, and dynamic action). Your gunna be sending tons of stuff over the wire and that's probably going to be a problem.

Personally, if i were going to use the Source Engine for an MMO i would probably only use the graphics. Most of the other stuff would probably only cause problems.

Share this post


Link to post
Share on other sites
Well, of course certain limitations will have to be put into place, but the physics engine will be important for creating realistic combat interactions. Some spells in Kinetic Magic, for example might send an enemy flailing like a ragdoll. As for the latency, we will be limiting and balancing what is processed by our server versus what is processed by the individual clients. For example when speaking to an NPC your client will recognize the keyword and a simple command will be sent to the server so that the NPC will respond with a scripted reply already on the client machine. The Source Engine allows for streaming technology though for voice communication, but that's a topic for another thread (which it has been). We're not pretending that it is not gonna be a lot of work. =P

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
From what you've written, it sounds terrifingly like you don't have anyone who's highly experienced with building distributed systems or high performance network servers. Without at least one person (in charge of the team!) with that background, you are doomed. I have consulted for several MMO's and I speak from experience: I've even seen a perfectly competent (but not great) guy in this role fail to save the project because he wasn't senior enough, and there were people with the power to overrule him.

So, I have just one piece of advice: go hire some real ****-hot network programmers who really understand this stuff. Without it, you're dead. Valve, Unreal, etc are all useless for MMO work, and they know it - you *have* to do all the hard MMO-stuff yourself.

Shrug. Just MHO. But I do do this stuff professionally (currently building a new system for circa 1 billion hits per day).

redmilamber

Share this post


Link to post
Share on other sites
Quote:
Original post by Anonymous Poster
From what you've written, it sounds terrifingly like you don't have anyone who's highly experienced with building distributed systems or high performance network servers. Without at least one person (in charge of the team!) with that background, you are doomed. I have consulted for several MMO's and I speak from experience: I've even seen a perfectly competent (but not great) guy in this role fail to save the project because he wasn't senior enough, and there were people with the power to overrule him.

So, I have just one piece of advice: go hire some real ****-hot network programmers who really understand this stuff. Without it, you're dead. Valve, Unreal, etc are all useless for MMO work, and they know it - you *have* to do all the hard MMO-stuff yourself.

Shrug. Just MHO. But I do do this stuff professionally (currently building a new system for circa 1 billion hits per day).

redmilamber

Well I do agree with you that IF we're unable to secure more professional network programmers, we WOULD be doomed, but rest assured that we do have a working idea of what will be required and we are still currently in pre-production. One thing we do have are producers who understand business, and the details are partially the team's job to supply to them.

We understand the risks involved with the high production costs (though the lisence itself is nowhere near one hundred thousand, DrEvil =]) and long development cycle and are prepared to pay (in dollars as well as hours) what is necessary for professional talent and a sound system.

Regarding our current team, we have two professionals with extensive experience in "high performance network servers" yet none as yet with specific MMORPG "high performance network servers". Your criticism is well, received though, as we will not enter production (i.e. start depleting our funds) until our publisher feels confident that our team is capable of seeing the project through. My purpose for sharing the information on developer sites such as these is two-fold: as I've stated gaining community insight is for us an essential aspect to our production. We have found thusfar, that professionals on sites like this have been extremely, helpful and several have offered their specialized talents and abilities to aid our project. Additionally, more than a few ideas raised over PMs, emails, and threads regarding our project have resulted in a reevaluation, and new direction taken.(not on a whim mind you =P)

I apologize if I have represented our project as a volunteer's hobby or as an ill-planned piece of vaporware, but my lack of complete disclosure has been in part a protection of our assests. Plus, as I have stated I am not a programmer and don't want to sound exceedingly ammateur! =P

"Valve, Unreal, etc are all useless for MMO work, and they know it - you *have* to do all the hard MMO-stuff yourself." We agree that the software architecture (especially on the networking side) will need a complete redesign but the engine is far from useless. NPC interactions (speech included), combat physics, graphics rendering (culling and LODs were a huge plus), scenes, even wave streaming are all beautifully performed by Source, and hopefully our end product will be the result. I understand that these are indeed tools, and not a prepackaged solution as I suspect you're getting at.

"So, I have just one piece of advice: go hire some real ****-hot network programmers who really understand this stuff. Without it, you're dead." I agree 100% .
If any of you "****-hot network programmers who really understand this stuff" are interested contact me or keep an eye out for classified in several online (Gamasutra included) and industry journals (L.A. circulation). =]

I appreciate the feed-back btw, everyone.

Share this post


Link to post
Share on other sites
Just FYI you could actually build a custom MMOG engine and game faster than building one on the Source engine. You basically have to scrap almost every single feature of Source and the way it works in order to support that game genre.

Obviously you are not sure what you are doing either, as you said you would have to change the 'networking' to handle all of those players.. where that is the smallest problem compared to the rendering, physics, logic, etc. Source is made to handle a certain problem space and an MMOG is so far off the radar it isn't funny. This is probably the worst actual engine choice to make in this case, honestly.

EDIT:
Quote:

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

You obviously have no idea what you are talking about now.

Quote:

We agree that the software architecture (especially on the networking side) will need a complete redesign but the engine is far from useless. NPC interactions (speech included), combat physics, graphics rendering (culling and LODs were a huge plus), scenes, even wave streaming are all beautifully performed by Source, and hopefully our end product will be the result.

Just FYI none of the aspects you mentioned are actually usable in an MMOG setting, sorry to burst your bubble. You will have to redo the majority of the core rendering system, the scenegraph and world system, the physics, and obviously a complete network rewrite. To top it off you'll have to redo the majority of sound as you obviously don't want 100 different sounds trying to play at once.

Find the right tool for the job seriously, you chose probably the worst possible engine to work on a project like this with.

Share this post


Link to post
Share on other sites
Quote:
we have two professionals with extensive experience in "high performance network servers" yet none as yet with specific MMORPG "high performance network servers"


Note that writing, say, a high-performance web server has almost nothing at all to do with writing a high-performance MMO server. In fact, some techniques that make web servers fast would actually hurt an MMO server. High-performance database server technology is useful on the back end, but has almost nothing to do with the simulation and networking front-end. So the KIND of networking experience you have is really the most important part.

Regarding using Source: their shader and PVS and basic infrastructure stuff can work just fine for an MMO, as can their art pipeline. Getting a fully working art pipeline is a great boon to get started. Just make sure that you model your characters with lower poly and bone counts than typical Half-Life 2 models, because you'll be drawing a lot more of them. Trying to get the number of draw calls down per character would also be beneficial -- ideally, one per character.

Also, if you want to have a "seamless" world, you'll be in for more trouble than it's worth (IMO). I'd recommend designing for a zoned world (a la City of Heroes, EverQuest, etc).

Share this post


Link to post
Share on other sites
Quote:
Original post by Saruman
Just FYI you could actually build a custom MMOG engine and game faster than building one on the Source engine. You basically have to scrap almost every single feature of Source and the way it works in order to support that game genre.

Obviously, sorry if I seem flippant Saruman, obviously, but I checked out after you mentioned that "almost every single feature" of the engine would have to be scrapped, obviously.

If you took any time to look at our project goals, you would see the necessity of an engine designed to support a plethora of immersive and action-intensive features.

Quote:
Valve
Renderer
- Version 2.0 (and below) shaders, bump mapping, LOD on models and world (check)
- Author shaders with HLSL (check)
- Cube and environment mapping (check)
- Dynamic lights, vertex lighting and light maps, many light types including flickering, pulsing etc. (check plus)
- High-Dynamic Range lighting (check)
- Water with refraction and fresnel effects (check)
- Advanced particle system that can emit sprites or models (check plus)
- Projected shadows allow for a large number of characters per scene (check plus)
- Occluder entities for visibility blocking (check plus)
- Indoor/Outdoor environments (check)
. Deformable terrain (check)
. 3D skyboxes extend the horizon and add parallax on distant objects (check)
. Dynamically rendered organics (grass, trees etc) (check)
- Subdivision surfaces, diffuse & specular bump maps (check)
- Real-time radiosity lighting (check)
- Effects include but are not limited to: particles, beams, volumetric smoke, sparks, blood, environmental effects like fog and rain (check, real-time weather effects baby)
- Scalability (check)
. Dx6-Dx9 hardware supported


Materials System

- Instead of traditional textures, Source defines sets of materials that specify what the object is made from and the texture used for that object. A material specifies how an object will fracture when broken, what it will sound like when broken or dragged across another surface, and what that object’s mass and buoyancy are. This system is much more flexible than other texture only based systems. (check/ this is key to our item system)
- Materials can interact with objects or NPCs such as mud or ice for vehicles to slide/lose traction on. (check)


Multiplayer Network Code
- Time and gamer tested by millions of gamers around the world (N/A)
- Support for both LAN based multiplayer and Internet based multiplayer games (N/A)
- Prediction analysis for interpolating collision/hit detection (check)
- Optimizations for high-latency, high-packet loss 56k connections (check)


Advanced Characters

- Detailed and believable characters (check)
- Realistic eyes (check)
. Focus on player/object, not simply parallel views
. Proper eye “bulge” for realistic eye reflections
- Simulated musculature provides outstanding emotions, speech and body language (check)
- Language independent speech, characters can naturally speak in many languages (check PLUS)
- Skeletal/bone system for animation (check)
- Layered animation system can synthesize complex animations out of several pieces (check)


Physics

- More responsive world with realistic interactions (check)
- Sounds & graphics follow from physics (check)
- AI characters can interact with physically simulated objects (check plus)
- Ropes/cables, machines, constraint systems, ragdoll physics (check)
- Can be controlled by level design (check)
- Kinematic animated bone followers (check)
- Custom procedural physics controllers (check)
- Vehicles (check/ as far as mounts are concerned)
. Wheels slip and skid
. Realistic suspensions with springs on each wheel
. Realistic leaning during acceleration/deceleration and turning
. Individually tunable parameters such as horsepower, gearing, max speed, shift speed,
tire material, tire friction, spring tension/dampening etc.
. Multiple players in a vehicle in multiplayer
. Hovercraft support for cheaper simulation


Advanced AI (important of our "action-game" aspect of combat/ NPC interaction)

- I/O system allowing level designers to control AI
- Sophisticated navigation: characters that run, fly, jump, crouch, climb stairs and ladders, and burrow underground
- AI senses things using sight, sound, smell
- AI relationships determine friend/foe status of other entities
- Battle AI allows squads of AI characters to operate together, know when to advance, retreat, lay cover fire, etc.

Sound (check, all applicable)

- 5.1 surround sound, 4 speaker surround
- High-quality 3D spatialization
- Custom software DSP
- Automatic DSP based on environmental geometry
- ADPCM decompression
- 16-bit 44KHz, stereo wave data with all features
- MP3 decompression (requires Miles license)
- Support for audio streaming on any wave
- Real-time wave file stitching
- Pre-authored Doppler effect encoded waves
- Pre-authored distance variant encoded waves


UI (N/A)

- Server browser - Displays all active game servers and allows a player to choose which one to participate on. Players can filter and sort server lists in order to speed up the display and selection of a server.
- Friends instant messenger - Allows players to message each other both in and out of the game as well as join friends in existing games. No more confusion about what server your friends are on, you can easily join with this feature.
- VGUI – Valve’s custom GUI interface mimics most of the windows controls but is rendered using the Source engine for both in game and out of game uniform UI display. VGUI is platform independent and is Unicode compliant for ease of localization


Programming

- All code written in C/C++ using Visual Studio 6.0. Easily and quickly derive new entities from existing base classes. (check plus)
- Internal context sensitive performance monitoring system (check)
- Graphics performance measurement tools built into the engine (check)
- Modular code design (via DLL’s) allows swapping out of core components for easy upgrading or code replacement (check plus)
- Dx9 shaders all written in HLSL


Tools (check + + +)

- Faceposer
. Facial expression tool used to craft speech and emotions
- Valve Hammer Editor
. WYSIWYG World editor
. Create world brushes
. Terrain editor
. Place detailed world models and AI NPCs
. Set navigation points/paths for NPCs
. Place triggers, clip brushes, logic etc.
. Allows level designer to hook up I/O between entities to control AI within the game|
- Half-Life Model Viewer
. Full model previewer
. Rotate models in any direction
. Setup hit boxes
. View physics hull
. View normals
. Wireframe, shaded or textured view modes
- Studiomdl
. Model compiler
- Vbsp, Vrad, Vvis, VMPI
. Map compilation tools (bsp, lighting and visibility)
. VMPI – distributed compilation tool allowing level compiles to be
spread across many pc’s greatly reducing compile times
- Exporters
. XSI, Max and Maya .smd exporters for exporting 3D models

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Regarding using Source: their shader and PVS and basic infrastructure stuff can work just fine for an MMO, as can their art pipeline. Getting a fully working art pipeline is a great boon to get started. Just make sure that you model your characters with lower poly and bone counts than typical Half-Life 2 models, because you'll be drawing a lot more of them. Trying to get the number of draw calls down per character would also be beneficial -- ideally, one per character.

Also, if you want to have a "seamless" world, you'll be in for more trouble than it's worth (IMO). I'd recommend designing for a zoned world (a la City of Heroes, EverQuest, etc).

Thank you for the more constuctive feedback hp. =P
Yea, I suspect you're right about our zoning challenge, though I think there might be a more clever way to disguise the mechanics of the system, but as I have stated: I am not a programmer.

Anywho, the art pipeline is a huge plus, since we can basically start modeling and doing the 2D/3D work immediately with the engine already in place. Regarding poly count, I think we were playing with making the LOD feature an option for players, with some sort of recommended setting (Source can LOD up to 8 meshes for an object).

Regarding the lisencing info, part of the NDA was hrm... non-disclosure =P, so unfortunately no comment on that. Thank you for the feed-back guys. One good thing about blatant criticsm is that we get a worst case scenario for the project, which our producers like.
("It will be more work designing an engine with your planned features from scratch!")

Once again guys/ I'm a developer so my job is coming up with the big ideas while the egg-heads to the follow-ups with the actual techincalities, but I am trying to learn as I go.

"Jacobo has NO idea what he's talking about" =P

Any other thoughts on the Source Engine for the project? On a recommendation to visit the HL2 mod community, we've found some talented and knowledgeable guys ont he engine so thanks for the ref. whoever that was.

Anywho, keep the polite dialogue coming please. I appreciate everyone's feedback!

Share this post


Link to post
Share on other sites
"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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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 :-)

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest 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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by JJacobo
Quote:
Original post by Anonymous Poster
From what you've written, it sounds terrifingly like you don't have anyone who's highly experienced with building distributed systems
...
So, I have just one piece of advice: go hire some real ****-hot network programmers who really understand this stuff.

Well I do agree with you that IF we're unable to secure more professional network programmers, we WOULD be doomed,


No. Not "professional network programmers" (there's lots of those in the games industry, and many of them are useless for MMO work: they know how to do TCP, UDP, etc. That's circa 3% of what they need to know). Rather, you need specialists in distributed systems - c.f. the recent para by hplus about the questions you need to hire an expert to answer; my own initial list of core questions would be pretty close to that.

Sadly, you're only real option for established consultancies is Themis Group, who are of very variable quality. Again, I cannot exaggerate the importance of having your experts more in-house: at least one game has had Themis advice and ignored too much of it (according to the rumours that reached me) to their peril. It's easy to ignore consultants, it's much harder for your tech lead to ignore himself. So...make sure your tech lead really knows what he's doing here :).


Quote:

One thing we do have are producers who understand business, and the details are partially the team's job to supply to them.


Great on the surface, however in practice it's mostly worthless.

I've done a lot of recruitment in this area for MMO projects and found that the real problem is a lack of supply of suitably qualified people. It doesnt' matter how good your producers are at working out what they need if it's almost impossible to get those kinds of people :(.

So...if you said you have some gorgeous babes/hunks who can charm the back legs off a donkey and persuade some key staff to jump ship from their current projects, THEN I'd say things were looking good. (tongue-in-cheek, but hey - I've seen it work before, and recruit people you'd never have thought would leave their previous job).

Quote:

and are prepared to pay (in dollars as well as hours) what is necessary for professional talent and a sound system.


Here's a figure for you: I was approached recently for a tech-head-of-MMO job. The offered salary was $150k-$200k AAE. Are you willing to spend that much just for one new staff member? You may have to. (for the record, I'm in the middle of something sufficiently more exciting that I wouldn't have taken it - although the salary went a long way towards tempting me :D ).

I'm being a cynical bastard here, but ... I've seen many MMO's start and fail, including a few promising ones that most people never even heard of before funding got withdrawn or the project was cancelled due to the overwhelming difficulties and the lack of certainty that revenues would cover it.

Quote:

Regarding our current team, we have two professionals with extensive experience in "high performance network servers"


Out of interest, what exactly have they done?

Quote:

"Valve, Unreal, etc are all useless for MMO work, and they know it - you *have* to do all the hard MMO-stuff yourself." We agree that the software architecture (especially on the networking side) will need a complete redesign but the engine is far from useless.


Apologies, you misunderstood because I was being too ambiguous: the total effort required to deliver an MMO project is so great that the physics and graphics engine become "small issues": you have bigger things to worry about (there are plenty of graphics/physics engs that can be licensed off-the-shelf with standardized pricing at any point into your project; many of your other issues cannot be solved so easily just with a credit card).

So...those two don't even appear on the risk assessment sheet; hence, an engine that is excellent at them is "useless": it's not buying you anything that you couldn't easily get hold of anyway.

Aside from that, I agree entirely that you can re-use those things, modulo the problems already highlighted by others about e.g. the fact that you cannot possibly run your physics on the client (you have to get cunning and hack into it a bit to make it a slave/ghost of the authoritative server copy). But....where, for instance, are you getting the "distrubuted server-side version" of your phusics engine that is guaranteed to be deterministically compatible with the client-side replay?

(this was one of my big problems 4 years ago: trying to persuade the enigne companies to make fast, efficient, easy to integrate, server-side implementations)

Quote:

If any of you "****-hot network programmers who really understand this stuff" are interested contact me or keep an eye out for classified in several online (Gamasutra included) and industry journals (L.A. circulation). =]


As someone once said, "Show me the money!". I have seen plenty of piss-taking recruitment ads for this kind of skillset, offering e.g. $50k salaries - where outside the games industry the same people would be on $150k base salary. This is not for a head of tech or anything, just for the lead programmer with the right experience and skills - you'll also IMHO need a head of tech of some kind with specialist skills in this area, and they're going to cost even more. Yes, the games industry can pay much lower, but not THAT much lower :).

Bearing in mind also that you will *have* to pay hefty relocation expenses because these people are sufficiently thin on the ground that you are almost certain not to be able to find any in your local area. Unless you can tempt away people from the big local studios...

Anyway, all that is probably pessimistic. With my project manager hat on, I'm only interested in plans and estimates that build-in the ability to cope with the probable risks and the likely bad-luck - otherwise, you die the first time one mildly unlucky thign happens to you :(.

redmilamber

Share this post


Link to post
Share on other sites
Quote:
It doesnt' matter how good your producers are at working out what they need if it's almost impossible to get those kinds of people :(.


It's tough, to be sure.

What seems to work for us (we're slowly growing our group with highly talented people) is a combination of salaries competetive with business jobs, great business potential, family-friendly policies, and a productive engineering process driven by measurable results delivered by a team, not an individual. If you don't have the deep-pocket investors to back that up, starting from scratch is going to be dicey at best. Maybe you're very lucky and have some really good distributed systems people already vested in the project, financing it by accepting lower salaries in exchange for equity/royalties. However, the size of team necessary to actually deliver is fairly big in the end, so once you're rolling, you still have to be prepared to go down that route.

Shooting from the hip, and paying cheaply for people who love doing that, has been a disease of software engineering in general. Distributed systems (MMOs) and to some extent next-generation consoles are likely to turn up the pressure of natural selection.

Btw: the salary numbers that redmilamber is posting are not outrageous, especially for California.

Share this post


Link to post
Share on other sites

This topic is 4592 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this