1. Code For Others
As with most people, styles of anything can differ greatly even if you learned the same thing the same way. Take comments for example, comments normally are used to let you remember what you did when you later come back to the code. It is also used to reference changes in code, dates the changes were made, and by who. This can be very helpful later on in the game creation process when you come to have thousands of lines of code, and tons of different files of code.
2. Integrate Early And Often
It takes time and effort to write code, sometimes it can get the best of you if you aren't keeping up. Thats where source control comes in. Source control is a way to manage files that individuals work on so that the chance that two people are working on the same thing is decreased significantly. This is where integration comes in, people move fast and you have to try to keep up, files can change drastically making it hard to integrate code into the main game build( once its tested and working of course ). Doing this helps with the debugging and crashes that may happen, because you certainly don't want them to happen just before a deadline.
3. Teams Shouldn't Only Work Together
Its very good to do team bonding, something that takes people away from code for a while and let's them relax for a while. Team bonding can be really fun, for example, go bowling. Bowling is a good team activity, regardless of how good you are, the goal is to try to have fun. Event something as simple as going to a restaurant is good, preferably a sit down against a fast food, mostly because of atmosphere and seating is usually more accommodating. Granted, team bonding is incredibly scalable, you can bond by having a field day in really large teams if necessary.
4. Clean Up Memory
This is very VERY vital, when programming, make sure that if ( in C++ at least ) your constructor, copy constructor, assignment operator, and destructor are written, this can be a downfall, and it is very common among those newer to programming or those used to managed languages like Java or C# where all the memory is handled for you. This is just a really good practice to have, and is something that you just have to train yourself to remember to do. This may not seem like it would make a difference to anyone else on the team, but you would be suprised, it is very possible that you could be causing issues with other things in the program.
5. Questions Are Your Best Friend
Always ask questions before changing code that you did not write or help write, even reading comments helps ( depending on the quality of comments ). Try not to go and change other's code as you please, do some investigation first and even ask questions if possible. Its good to be very detective like, and find hidden things like optimizations, but try to look around the code block, because your first thought should be, why was this done this way. There could be a reason that this block was written to be like this, or it could just be an oversight by someone else. Inform the person who wrote it as well, people usually learn by experience so in the future the person would be much less likely to do this again.
Coming Soon On BrainStorm Blog:
β
(beta)
0 comments:
Post a Comment