|
Hmm, I don't think there's anything in the current architecture stopping the input or HUD from dealing with the brakes, clutch, etc directly. The reason I didn't do that and instead routed everything through the CAR object was to provide a layer of abstraction. The abstraction allows the CAR to present a standardized interface to the brakes/transmission/etc for the rest of the game. It's nice because it allows stuff like auto-clutching if you don't have a dedicated clutch input, for example. If you take that sort of code out of CAR, then you have to start putting it somewhere else, either inside the clutch (which I don't like because then the clutch has to know stuff about the game's controls) or in whatever was previously delegating that functionality to CAR (in this case I think it would be GAME, which is even larger and more crowded than CAR).
However, I do agree though that there are a lot of useless functions in CAR that merely call functions in CARDYNAMICS. We could break out the CARDYNAMICS from the CAR, so the CARDYNAMICS handles all non-visual aspects of the car, then turn CAR into some sort of CARINSTANCE or even an abstract OBJECTINSTANCE that handles placing one or more textured models at one or more offsets, and updating those models appropriately when given a CARDYNAMICS object. The driver input code that's currently scattered between GAME and CAR could be put in a new CARCONTROLLER object that calls functions in CARDYNAMICS. The HUD would also communicate with the CARDYNAMICS object. The idea is to be more like a model/view/controller architecture.
|
