Fellow programmist on polish gamedev site Warsztat once writed an advice for beginners about three steps in programming:
Make it -> Make it work -> Make it work well.
The first step Make it is simply about making it work. It’ll can (and probably have) bugs, there’ll be errors, but it shows how you approach a problem. You make drafts and prototypes at this stage.
Second is to Make it work, it’s all about fixing problems, and taking care of boundary conditions. At this stage we want to create something that works perfectly with given assumptions.
Last but not least is to Make it work well, and that step is all about optimalization, fixing and tunning app for proper customers. This step finally results with a stable relase.
I still don’t know exactly where refactoring should be made when taking these steps (so I assumed that it should be done all time), but Pongoid I showed yesterday was clearly still in first step.
For those who didn’t check the commit, there are several bugs with phisics listed down:
-> From time to time ball goes inside a paddle and oscillate over the entire length,
-> It looks like bricks dissapear on they own if ball hit it’s two neighbours (maybe from fear, but it should not happen…)
-> I’m not sure if ball bounces in correct way all the time.
And code is organized inside 3 classes:
– Game that manages all input events, logic and so on.
– Item, who controlles both paddle, and ball.
– Brick derived from item to controll many bricks in field.
Goal for another few code sessions is to finish second step of game mechanics.
Fix physics problems, and clean up code.