Quake was made by id who made the engine... And UT3 is designed and built as a middleware as much as an engine.
The easiest way to get programmers into Source is to just startup a project and let them check out the SDK classes. It's a solid grounding point as you see the highest level player class, gamerules and gamemovement. It's a steep learning curve but having a technical document in this situation isn't really going to be as thorough as taking the time to walk through areas of code that the SDK classes inheret. It's a daunting enough SDK and will take a while to master but so do most SDKs like this, and there's enough on the wiki to get you started including the simple example brush, model and logic entities. Hell the wiki is freely editable so if someone really wanted to start a full documentation section outlining that kind of stuff, they could start a new page there and let it expand from user input and their own explortations. The gist is that learning the SDK is a combination of some examples of features, such as networking tables, and then just working with the code. If you want something that has lots of documentation and is designed and marketed primarily as a third party game development platform then the likes of UT3 might be easier to jump in and get going right away. Source modding/coding is just analogous to learning to code in general, you can read as much as you want but the only way to really harness it is to just work with it and allow for time spent learning some of the systems. Offtopic about that last paragrph Nick wrote. Whatever you're smoking must be rather strong because the logic behind those claims is absurd. Especially since I'm sure Gabe himself wouldn't concider being bought by Microsoft "good", if that were the case he'd have probably stayed with them and never bothered starting Valve in the first place. Open sourcing tools and formats would make no difference as only Valve are going to be the ones handling the engine itself. On Sun, Jan 11, 2009 at 7:20 AM, Nick <[email protected]> wrote: > I am not Valve, I do not work for Valve, but I like Valve, and like a > good friend I like to point out where I think they go wrong. > > There is no such technical design document for source, available to > the modders, but I suspect there is such a design document if you pay > for a license. > > Valve is a good company, and has excellent people. But the top games > released for source have been made exclusively by and for Valve. The > source engine is powerful and highly adaptable, if you work for Valve. > I think other engines are designed to be easier to understand because > the other major game engines are being used by people outside the > original company. Quake/id and Bioshock/ut3 and america's army/ut3 are > some examples I can think of here. > > Source engine is powerful if you know how to use it, Valve people are > the only ones who know how to use it properly. That isn't going to > change unless Valve invests heavily in making it more open or > documenting it more. ( not anytime within the next 3 years). > > UT3 engine is equally powerful, but epic games has gone to great > lengths to make it easier to use, and highly documented. Also actively > encourages scripting instead of forcing everyone to use c++ like valve > does. Bioshock/Americas Army/Gears of War 2. Look at the material > editor that comes with ue3 > http://hourences.com/book/tutorialsue3mated.htm includes shaders also > from almost one and half years ago! > http://www.unrealtechnology.com/features.php?ref=editor > > I hope valve seriously thinks about open sourcing the tools, formats, > and making the engine available on linux. Unless valve thinks it can > exist only by relying on steam sales/distribution. Eventually > microsoft will make steam obsolete(by creating a steamlike replacement > for windows7) or buy valve out entirely, which is probably bad for > most people working for valve, but good for the owners :P > > On Sat, Jan 10, 2009 at 10:29 PM, Walter Gray <[email protected]> > wrote: > > I want to preface this by saying I know it's probably a kind of silly > > thing to be asking for, but on the other hand I feel it would would be > > stupendously useful. > > I'm looking for something akin to a Technical Design Document for > > the source engine, or at least the parts of it which are distributed > > with the Source SDK. Really, any single document that lays out, in a > > concise fashion, the general structure of the most commonly used > > systems, what base classes they use, and enough about how they are > > supposed to work for someone to start messing with them. It seems to me > > that the general approach for mod developers has been to use the code > > itself as the documentation and ask the community or check the wiki if > > they find something they don't understand. This, unfortunately, means > > that there's no easy way to get new developers on a team familiar with > > the engine, which is what I'm aiming to do. I've looked around, and > > there doesn't seem to be anything like this. Am I missing something, or > > does it not exist, and if it doesn't, why not? It seems like it's the > > kind of thing that would cut down on a lot of confusion for new mod > > programmers and encourage 3rd party Source development in general. > > > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlcoders > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
