Design Philosophy
In an earlier epoch I designed embedded system hardware, software, and development tools in two different areas:
- Pro Audio
- Digital Signal Processing
Both of these fields are 'real-time' programming. It's not dissimilar to what you have to deal with in Unity3D:
-
A frame in pro audio at 44.1 kHz doesn't allow much time per-sample to process much, about 22 microseconds.
-
A frame in a game at 60 Hz is about 17 milliseconds which sounds quite generous by comparison.
Either way, you have a certain amount of time to do your processing or:
- Audio ==> Audible 'artifacts' such as clicks and pops
- Game ==> Dropped frames
This is all to say that this biased my approach to coding: performance and memory are #1.
So I tend to eschew the modern programming idiom of write first optimize later.
- If using a little more memory increases overall execution speed: use the extra memory.
Messaging Service's messages.
Tightly hardcode things that by nature have to be optimized, such as the Tweener Service and the internals of TpLibTasks.
Extensively pool class instances and other objects.
Extensively cache tile instances in the layout system.
No acronym-based coding style will be found anywhere :-)