>From an actual game architecture perspective I agree with you, but for ease of development I don't. CSDKPlayer is like a second layer BasePlayer. It provides the basics, as you say.
If you wanted to keep it at the same level, you should make your own extension to the BasePlayer and just copy over any code that you are going to use. If you're just renaming it you are just accomplishing the same thing as extending the class (you get all the same functionality), but your code will mixed in and hard to maintain. Extending will provide one extra level of inheritence which will provide no noticable difference in performance but will allow your code base to be cleaner and more easily maintained. -Skyler Clark On Sun, Dec 21, 2008 at 7:27 PM, Tony Sergi <[email protected]> wrote: > Olly is right though. > > The SDK layer is the same level as CCSPlayer, CTFPlayer, CPortalPlayer, > CHL2MPPlayer, etc. > > The most ideal thing to do would be to either just leave it as CSDKPlayer > for porting later, or replace all SDK with your mods prefix. Inheriting it > is actually rather silly, since all it is at the moment is a sample player > that inherits CBasePlayer and does the basics. It's like a template. > > > -----Original Message----- > From: [email protected] [mailto: > [email protected]] On Behalf Of Skyler Clark > Sent: December-21-08 7:11 PM > To: Discussion of Half-Life Programming > Subject: Re: [hlcoders] Best way to mod scratch SDK > > The SDK stuff is not a bunch of empty classes, there is code and logic > provided there. If you don't need that code, you should remove any code > from > the SDK layer and only use your own code. > If you are planning on using the SDK level's code, you should extend the > class. > Sure, you're adding an extra layer of overhead, but what you gain from that > is complete isolation of your mod's player code. > > Every architectural decision has tradeoffs. And in this case, I have found > that creating my own SDK_Player extension allowed my team to isolate our > code and greatly helped to increase our productivity, which greatly > outweighs the slight extra overhead. The difference in overhead is marginal > when you consider the depth of inheritance already present in the source > engine. > > -Skyler Clark > > On Sun, Dec 21, 2008 at 6:43 PM, Olly <[email protected]> wrote: > > > The SDK stuff is there to be renamed, its the same class level as > > CCSPlayer, > > CTFPlayer, etc. If you extend CSDKPlayer, you are just adding more > overhead > > that doesn't need to be there. The SDK files don't contain any base code; > > so > > there is no need to inherit from them. > > > > 2008/12/21 Skyler Clark <[email protected]> > > > > > Olly, what a terrible suggestion. There is much to be gained from > > extending > > > the sdk_player rather than just renaming it... > > > To do it, you just need to extend both C_SDK_Player and CSDK_Player. > > > The player is instantiated in ClientPutInServer in sdk_client.cpp, line > > > around line 80... So make it instantiate your extended player there > > instead > > > and you're solid. > > > > > > -Skyler Clark > > > > > > On Sat, Dec 20, 2008 at 3:59 PM, Olly <[email protected]> wrote: > > > > > > > rename the classes/files > > > > > > > > 2008/12/20 Michael Chang <[email protected]> > > > > > > > > > Hey all > > > > > After months (years?) of failing to fix HL2DM I've finally switched > > > over > > > > to > > > > > scratch SDK, thank heavens for that. > > > > > > > > > > I want to know how best to mod scratch SDK. For example I want to > > > > implement > > > > > my own player type that inherits SDKPlayer. Where in the code do I > > tell > > > > > gamerules to instantiate my own player type instead of CSDKPlayer? > > > > > > > > > > On that note, even after I traced the calls and hierarchy all the > way > > > up, > > > > I > > > > > end up at sdk_client. Who calls/instantiates sdk_client? How do I > > > > implement > > > > > my own mod_client? Should I even bother? > > > > > > > > > > Basically, I want to use everything sdk_ etc but inherit it into a > > new > > > > > class > > > > > instead. I want to try limiting my edits to SDK_etc and do > everything > > > in > > > > > the > > > > > "proper" OOP way. So instead of sdk_gamerules, I want my own > > > > mod_gamerules > > > > > that inherits that. My own mod_playeranimstate... etc > > > > > > > > > > But where does it start? Where is the very beginning of switching > > over > > > to > > > > > my > > > > > own objects/codebase? > > > > > > > > > > Thanks. > > > > > _______________________________________________ > > > > > 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 > > > > > > > > _______________________________________________ > > 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 > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
