View source for Talk:LightR/Experiences learned from ScalarR

Good abstractions: Robot, Wave, BattleField

Bad abstractions: Radar, Gun, Wheel

Why? Because once you segment your code into gun & wheel, information sharing gets hard. A large part of wheel & gun can be shared and then you need EnemyHistoryManager etc. A Gun isn't a gun at all, all a gun does is a turret, a bullet plus some powder, and all a wheel does is turning. You don't need a driver or a brain, everything in your code is driver, everything in your code is brain. You just model everything in plain code, no need for extra layer of abstraction.

I was putting everything inside "Enemy" class, now they are segregated again into Radar, Gun and Movement. It turns out that no abstractions are good or bad, only fitting the need or not. The wave processing logic of Gun and Movement is similar, but you never want a change in gun to affect movement, then re-implementing the same logic twice is acceptable.

Whether to go modular or not, this is a dilemma. However, in principle, the less code it has, the easier it is able to fit in brain. So after many years struggling with modularized design, I decided to start from scratch and keep it simple.

Modularized design does come with good part — you don’t need to fully understand the code before you start to hack it. ScalarR’s code is written many years ago and I’m still able to hack some modules, even if how the rest part works have been forgotten. But making big changes is very, very hard because the code has been spread out into many, many submodules.

The point is, making big changes is better than small tweaks. So instead of rewriting so many modules, a compact and yet often rewritten design is supposed to work better. You get punished for writing to much logic in a compact design, so more machine learning and less tweaking ;)