Skip to main content
GameDev.net gamedev.net
🔒 Locked

Source Engine

Started by Diton Aug 23, 2006 at 7:34 PM 22 replies 4k views
Original Post
Diton
Diton
I'm fully aware of the work needed to make an MMORPG, so don't tell me it isn't possible, or that I should start with something easier. My question is, how much modification would be necessary to make the Source engine capable of running an MMORPG? I'm assuming most of the network code would need to be updated, but I'm not sure about anything else.
Diton
Diton
I know it's possible, because it's already being done - http://pc.ign.com/objects/702/702586.html. I'm asking because if the engine is not capable of supporting it without a large amount of modification, it would probably be easier to either write an engine, go 2d with it, or find another existing engine designed for it.
Ging
Ging
The network code would need re-doing, as would the physics code (so it's more or less completely client side), you'd need to do something about how the levels are loaded and then balance that against server requirements. That's just stuff off the top of my head - basically, I'd go for a custom / MMO dedicated engine rather than get in deep with Source.
Diton
Diton
Would it be feasible to rip out the network code from an MMO engine and try to merge it into Source? Also, I think the physics code from CS:S would be acceptable for an MMO - it performs collision detection a little earlier to prevent the player from going through walls and fixes other problems like that.
ToohrVyk
ToohrVyk
Quote:
Original post by Diton
Would it be feasible to rip out the network code from an MMO engine and try to merge it into Source?


Yes, although make sure licenses are compatible. Making the two interact together will require skill, though.

Quote:
Also, I think the physics code from CS:S would be acceptable for an MMO - it performs collision detection a little earlier to prevent the player from going through walls and fixes other problems like that.


No, potentially too much bandwidth usage if you do it server-side for everyone, and too unsafe if you perform it on the client.

Being able to run an MMO requires a large scaling down of resource usage: where CS:S uses all resources to handle 30-ish players, you want your code to handle 3000+ players. This means that each player gets 100 times less computation power. What are you going to remove?
Diton
Diton
Pointless anyway, since I just did more research and realized that the HL2 SDK (which I do not currently have) does not give full access to the code to the source engine, and that I'd actually have to license the engine. There's no way I can afford that, and I don't even know how much it would cost, because Valve only discusses licensing under NDA.

Looks like I need to find another engine.
dbzprogrammer
dbzprogrammer
Quote:
Original post by Anonymous Poster
I won't tell you it is not possible. I will tell you that you don't even have enough money to get a developer license of the source engine so don't even bother. And you contradicted yourself...


This was discussed at the beginning of the article....

Wow...

Yes, it's very expensize, it's a popular & powerful engine.
We should do this the Microsoft way: "WAHOOOO!!! IT COMPILES! SHIP IT!"
smitty1276
smitty1276
Quote:
The network code would need re-doing, as would the physics code (so it's more or less completely client side)


Not only that, but the physics would probably have to be reduced to simple eye candy with no ability to affect the world (or damage players, etc). With hundreds or thousands of players, it would present enormous new challenges, at the very least. Any physics done in hardware (GPU/PPU) would probably be out of the question.
Diton
Diton
I've considered this, and I've decided to make a single player version first, and see what happens from there.
CTar
CTar
Quote:
Original post by Diton
I've considered this, and I've decided to make a single player version first, and see what happens from there.


You are going to make a single-player MMORPG? I don't think anyone have done that before. The big challenge of MMORPGs, is the MMO, you can't just do some modifications to a single-player RPG to make it MMO, you need to change the whole design and architecture.
Diton
Diton
No, I'm going to take an MMORPG and make some modifications to turn it into a SP game. At that point, the basic gameplay mechanics will be done, and it will be easier to turn it into an MMO if I want to.
dbzprogrammer
dbzprogrammer
Best of luck, I recommend you start off with some 3rd party libraries and work off of that, personally, using an engine for what it wasn't designed for seems a little counter intutive, and the last time I did that, it ended up in a mess. It's possible, but it's probably not the best/easiest way to go about it.
We should do this the Microsoft way: "WAHOOOO!!! IT COMPILES! SHIP IT!"
Spoonbender
Spoonbender
Trust me, you don't want to work in Source. Ever. Maybe if your ambition is to change the speed of rockets in Half-life 2, you could consider it. For anything else, find a different engine... [grin]
ToohrVyk
ToohrVyk
Quote:
Original post by Spoonbender
Trust me, you don't want to work in Source. Ever. Maybe if your ambition is to change the speed of rockets in Half-life 2, you could consider it. For anything else, find a different engine... [grin]


From what I had seen at the time, Source was advertised and hyped as the modder-friendly, developer-friendly next-generation licensed game engine, so what you say is a bit surprising. I'm pretty agnostic about the matter, so could you please add more details?

Diton
Diton
Considering the variety of mods developed using the source engine, that strikes me as untrue. These mods include such various games as: dodgeball, mario kart, the hidden, etc. It is clearly possible to make changes that are more than just minor adjustments. My experience with Valve is that is a very mod friendly company - the same variety of mods was developed for HL 1 - counter-strike was a HL mod.
ToohrVyk
ToohrVyk
Quote:
Original post by Diton
Considering the variety of mods developed using the source engine, that strikes me as untrue.


Not quite what he meant. A mod uses the unmodified engine to build a game supported by the engine. The Source engine is not really efficient for supporting MMO games, and is more aimed at small numbers of participants. I believe Spoonbender referred to actual modifications of the Source engine (which, by definition, are not mods, but independent games), which is what you would need to develop an MMO.
Diton
Diton
Quote:
Original post by Spoonbender
Trust me, you don't want to work in Source. Ever. Maybe if your ambition is to change the speed of rockets in Half-life 2, you could consider it. For anything else, find a different engine... [grin]


Sound to me like he meant that the only modifications you could make using the SDK (not full independent games, just mods) were superficial tweaks.
ToohrVyk
ToohrVyk
I understood it as if working within the Source engine was possible, but a deadly hassle. I guess we'll have to blame him for ambiguous statements, and wait for his clarification [grin]
Diton
Diton
Quote:
Original post by ToohrVyk
I understood it as if working within the Source engine was possible, but a deadly hassle. I guess we'll have to blame him for ambiguous statements, and wait for his clarification [grin]

... which appears not to be coming.

Spoonbender
Spoonbender
Oh right, sorry... Ambiguous is my middle name... [grin]

Anyway, what I meant is closest to Diton's guess, I think, but probably somewhere in between.
I'm not talking about modifying the engine, but about the mods you can make given the "standard" Source engine. And while it is possible to make a wide range of mods based on this, even the simplest tasks are, yes, deadly hassles.

The SDK doesn't give you access to the core engine, so you can't really manipulate or mod that anyway.

What I meant was that while the SDK is technically speaking reasonably powerful and allows you to make a range of different mods (using the unmodified engine), the only task I'd want to use it for is really trivial stuff like, say, changing the amount of health for a certain type of monster, or changing the speed of rockets in Half-Life 2. Anything more complex is a major pain to work with.

As I said, it is in theory a lot more powerful than that. It's just not really possible for anyone who hasn't spent at least a year at Valve, to really do anything useful with it.

Quote:

From what I had seen at the time, Source was advertised and hyped as the modder-friendly, developer-friendly next-generation licensed game engine, so what you say is a bit surprising. I'm pretty agnostic about the matter, so could you please add more details?

Well, to give you an idea, their idea of documentation is a wiki (No, I don't mean a wiki in addition to the official documentation so that modders can add their own tips and tricks. Just a wiki. A small one, even)
where Valve has provided maybe 15 basic articles, mostly in the form of tutorials like "How to make an entity that flies around at random". Everything else is provided by the modding community. And "everything else" isn't as extensive as it sounds. "Everything else" refers to another handful of tutorials on doing slightly more advanced things, which have been found out solely by debugging the SDK code, changing a few bits to see what happens.
If you're lucky, an earlier modder has managed to discover a way to implement the feature you need, and if you're *really* lucky, he's written a tutorial about it. And if you want to deviate from that tutorial, or just want to understand how things actually work, you're on your own.

What you won't find anywhere in the documentation is, well, documentation. Stuff that tells you "How does this class work?" or "How does the engine actually fit together? Which parts of it should I look in if I want to locate functionality X?", or even just "This class is implemented in this way because.....", or even "How does the server/client architecture of Source relate to single-player mods?"

They don't even tell you what each VS project in the SDK is for (Ok, a few, such as VGui2 is kinda obvious, but Tier1? How about the "Everything" solution vs. the "Game_SDK" one? If Game_SDK contains the SDK, what's left for "Everything" to contain? When do I need to use each?

The actual code? Macro hell. They use macros for everything, and apparently believe that runtime errors if you screw one of them up, is so much more fun than compile-time ones. And it's so intertwined with various compiler-specific bugs and extensions and implementation details that you might as well forget about getting it to compile on anything other than VS2k3.
As far as commented code goes, the best you're going to get is stuff like "// Hack hack hack! Blame Yahn for this one" [lol]

Trying to find out what some code does can be a daunting task. Sure, setting a breakpoint and checking the call stack or following the execution path from there helps... Right until you reach a call into "Engine.dll" which you don't have the source code for, and which is just as undocumented as everything else.

Based on my experiences, I'd say that making another FPS based on basically the same gameplay mechanics as Half-life 2 or Counterstrike or something, would probably be fairly straightforward. A lot of the work would simply be swapping models and sound effects, and tweaking the numbers for weapons stats and such, and then building new maps.

I know they hyped the engine as all that you said. That's just not really the case. [grin]

Just for the record, I should probably explain my experiences with the engine in a bit more detail.
Back in march I was involved in a project at college to make a game (or a demo consisting of a single level from one), using Source, in 1 month. We were a team of 10 or 11 total (two of us programmers, the rest artists, animators, designers, producers, sound engineers and whatever else you can think of)
We decided to make a medieval swordfighting game, with a pretty unusual (and imo actually really good) combat system, which required a lot of changes compared to "standard" Source gameplay. Couple of other features were the ability to chop limbs off your enemy during battle, and a couple of puzzles in or out of combat.
All in all, we had to figure out ways to implement a fair number of features that either weren't in HL2, or weren't exactly trivial to reproduce.
If you're interested, you can download the result here (Probably requires Halflife 2 to run)
While we managed to make the game within the given time, it's still a bit unpolished. (We should have had some ingame help/tutorial to get people started, but... no time for that. There are also one or two bugs that crash the game. And the map itself is horribly unoptimized)

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.