View source for Talk:LightR/Experiences learned from ScalarR
- [View source↑]
- [History↑]
Contents
Thread title | Replies | Last modified |
---|---|---|
Anyway, OOP is your friend. | 0 | 09:42, 18 March 2023 |
Do not make abstraction - hell, yes | 1 | 08:49, 1 February 2022 |
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.
I totally agree. My earlier and super messy bot, which I could not understand today, had significantly more brain and overall sense of the battlefield. It was somewhat easier to hack too (when I was able to keep it in my head).
Downside, I cannot understand it now. It was easier to write a new one that perfect the old one.
But I notice that modular approach goes same route, too many modules which I cannot keep in the head to understand fully.
You do not have permission to edit this page, for the following reasons:
You can view and copy the source of this page.
Return to Thread:Talk:LightR/Experiences learned from ScalarR/Do not make abstraction - hell, yes/reply.