/diy/ - Do It Yourself

>>407669
Ah yeah, forethought and planning goes a long way in coding. And if anything, if you do just dive into something, practice making things abstract enough that they can do whatever you want them to.

My general philosophy with scripts is to make each script completely independent. Each script should be able to exist on it's own, without crashing or throwing errors. All my classes are more or less self-contained, until they need to interact with one another.

For instance, I have all of the code that runs the movement, turning, orientation, systems, etc. of the mechs in this game all in one self-contained script. If I put a mech together and attach the mech script to it, the game will compile and run fine; the mech will just slump over and sit there doing nothing. But then I also have a "PlayerControlScript" and "EnemyAIControlScript" that I can attach to a mech. PlayerControlScript forwards user input to the mechScript (in the form "this is what they player wants to do", and it's up to the MechScript to try to accomplish those things--the MechScript is responsible for the physical limits and such of the mech parts, etc.) The EnemyAIControlScript does the same thing, but runs off of AI (duh).

So basically the MechScript is the actual physical system of the mech, and the ControlScripts just say "the user wants to turn to turn left" or "the user is aiming (here)", and the MechScript interprets these inputs and moves the mech around, within its own constraints.

This kind of coding theory is handy because, for instance, what if I want to make the game multiplayer? I won't have to write a whole new 2000-line script for moving every part of the mech and handling the weapons, headlights, damage, etc... I just write a NetworkControlScript or w/e that interepets network data and slap that on a mech.