Gamasutra article summary

A two paragraph summary of the article• A list of two things that the author recommends doing in Object-OrientedGame Development, and two things the author recommends not doing
- The author reccomends to prioritise work before anything. Like any crticial
coding or critical-path code are usually discovered at the very end of the
project. This critical error will cause most of the other stable system to
suddenly de-stabilized' and most of the errors in the critical code will cause
most of the other system to have errors and this sudden huge amount of workload to
correct other systems just days before the product relase date will cause plenty
of stress to the whole team.
- The author also reccommends to build and collect every stable build back and
then. This is to ensure every stable build will be collected and saved at and
whenever the management wants to see every stable build of the game, they will be
able to see what have happened. The author also reccommends to show the management
every previous builds to the management and provide eye candy and any latest
development are able to take more time to develop and save. This way allow the
management to feel the programmers are doing work and the programmers can take
this extended time to repair some other bugs and flaws in the programs.
- The author do not reccommend to only do top-down anaylsis to do programming.
Top-down programming is equated to break down harder more complicated stuff into
simpler easier and more mangaeable stuff and most of time this is what most
management are doing. This is very good management and the management adds up the
time for each stuff to do and often neglect the most important thing is that
integration, code learning, code integration, code revision are also part and
parcel of the whole top-down anaylsis. The author agrees that top-down programming
is a good practice and is often essential to break down all the stuff and starts
the whole planning cycle but also gets them to include task times, code
integration, risk-analysis and buffering as part and parcel of the whole
programming and let this time be accounted for. this is what the author meant to
be time-saving contingency plan for the iterative development project.
- The author also do not reccomend to write similar and same coding as this waste
timing. the author agrees though that these codes does help in the programming
part but putting these reusable codes into a library and a basic class
implementation will allow the programmer use this codes and implement into his
three programme. This will help save time for the programmer will allow this
reusable class implementation to put in other part of the codees if needed. It is
the author's experience that is harder to tranpose nominal implementations and
more difficult still to move optimal code in this fashion. The whole idea is to
get a placeholder functionality in as quickly as possible