3 ms·
I would say it worked pretty well. We also had some pretty dogmatic rules that were revised once per project and people didn't argue about until the end of a pr
by grogenaut 8y ago
I would say it worked pretty well. We also had some pretty dogmatic rules that were revised once per project and people didn't argue about until the end of a project. This was good and bad. It made the devs who had been there 3+ years super effective with like no mental overhead. It was very difficult on new poeople to learn the system and the company AND fight with a lot of other rules at CR time. The company was biasing for lots of long term happy programmers who were super effective so I understand why they did it. The average tenure was 5+ years on the dev staff.
we wrapped it into our engine language. Even though we were a sony only shop we still just talked our stuff. For instance we didn't use any reference to any of the input apis, we just had a global input class g_Input and Input that did all of the input logic. It was pretty easy to make this work for direct input on windows vs the state machine polling system on PS3.
- lifeisstillgood 8y agoMy takeaway here is surprise that a game development company biases for long term employees (my understanding was to push for long weeks and early burnouts)
- grogenaut 8y agoIt depends on the company for sure and can change over time. I think there are also often 2 tiers of employees at game companies. The ones who are there for the project (their choice or the company choice) and those they feel are the nucleus and treat well. And well if you're at a place like EA the size of the nucleus may be differen due to shifting across projects vs at a single project shop where there are no other projects and loss of the nucleus means the next project fails too.