13/08/2014 - Meet the Team #4: Raspo Fabs, Programmer

Gems 

I thought they were very well behaved.

Do you read those books cover to cover, or read bits and bobs and skim through them? I usually do the later, and always wondered how other people read those kinds of books.

I agree with Ba'al; the music drown out Fabs voice, annoyingly so - why use music at all? It's like they're trying put us in a trance with the lullaby music (foster complacency via subdued subconsciousness)

The series was good, which is why I stopped collecting them. They wanted a shot with me and some books (so the interview was as geeky as possible) and grabbed the ones they could find from my collection. To be fair, I've not bought any programming books in five years, mostly because the good stuff isn't in books any more.

Oh, and the book I'm destroying is my copy of Design Patterns. I don't agree with burning books, but I find it therapeutic to reduce the thickness of that book.

Read that back yourself. Wasn't OO meant to provide a safe place for inexperienced developers? A simpler more intuitive way to program without getting muddled up? I think we can both agree that it doesn't do that. And when you think that a Methodology is impractical for juniors, or inexperienced developers, why is it seen as a good way to do things?

I've not spent any serious amount of time outside games development, but this one is one I know to be a major reason why OO survives in the finance and engineering fields of programming. I've got acquaintances that relate to me how different it is working for them with their design docs and customer specs. It's not like that when you don't even have a defined goal. It is not possible to spend enough time at the start thinking things through. It's a fundamental difference between game development and non-game development. A game designer cannot know what the game will be like three to five iterations down the line. It's just a complete fallacy if anyone thinks that it's possible to take an idea, and write out a full design document that caters for all the corner cases, explores all the game mechanics, and will not change. If the game is worth writing, then it can't be written in a design document, it needs to be designed alongside an evolving live version of the game. You can't have a live version of the game without writing some code.

There are some game types out there that are "done", such as 2D JRPG, point and click adventure, racing games, for the most part first/third person shooters (we'll ignore the ones that have USP mechanics such as portal, or grappling hooks, or bullet time), and notice that those games can be designed up front (technically) and don't get so far behind schedule (unless you decide to massively increase the scope of the game Tim Shafer). But even them, if it's not the code that's changing, it's story lines, character skills, etc. But sure, you could safely develop one of those games in an OO manner, as there's not much in the way of technical design surprises.

In games that are new ideas, with new elements, there is always going to be the problem of exploring new ideas inside the existing framework, and OO is not well suited to design changes. The class system of C++ doesn't work well with objects that need to grown and shrink in both size and number, and hardly works at all when you try to combine sub elements of classes. Interface inheritance almost works, but we suffered a great deal of performance issues on the consoles due to virtuals causing horrible cache miss effects. You don't feel the effect of those things on desktop as much, so It's gone pretty much unnoticed over the last decade or so. The only hardware that pointed out the issue with virtual calls and other indirections, was touted as being bad hardware. The pentium 4 was a very fast CPU, but the random memory accessing, branching all over the place way OO works, was bringing the machine to its knees. The PowerPC chips suffered the same issue and it's probably why Apple moved to Intel. Not because the hardware was cheaper, but because programmers didn't have to try so hard to make their apps work well. So much good hardware has been ignored because of data-driven code flow promoted by object oriented design.

Firstly, a good programmer knows that sometimes you cannot solve a problem until you have failed to solve a problem.


Secondly, the difference between a good developer and a bad or inexperienced one is that the good one knows his enemy. A bad developer will decide to start coding early when there is a concrete design that they should be analysing, and would also be guilty of trying to gather technical designs and make careful decisions about how to solve the problem when they don't know what the problem is.
We had a "good developer" at 22cans, he was really good at programming, made a lot less mistakes in his implementations than I did, and was very good at reading documentation and taking advice from external sources. He was the one in charge of the login servers for Curiosity. And the reason why those servers didn't work was partially because of a decision he made very early on, and it affected the development in a negative way throughout it's entire lifetime. 

You can not make hard and fast decisions in game development and then stick to them forever. That way lies madness and we need a way of coding that allows for rapid recoding of minor and major systems alike without the fear of introducing bugs. We also need a methodology that doesn't require all the developers to already be senior. Where in the world do you actually find a company, of any stature, where all the programmers are senior level experience and capability? Probably only Indie developers who are working on their own.

Being 90% done and bouncing of a little thing is pretty common because by the time you are 90% done, the design has changed and that decision that is now wrong, was actually perfectly correct when the implementation began to be developed. For example, we have a 32 bit unique ID for the entities in the game. 32 bits is enough for anything we would ever have. Up to 8 gods (if you are Tim, or 32 if you are me) and 8 different main resource types, gave us scope for millions of IDs. And now, the number of gods is slightly higher with hubworld, we've got to account for >1M. That combination is not going to fit in a 32 bit type, not going to be able to even store a deterministic unique ID generator for each of those gods now. That's pretty fundamental, and was totally correct assumption at the beginning, and is leading to major changes in how store, interogate, and generate IDs. Another example? The UI system was interfacing with Scaleform. All the UI elements were designed to handle Scaleform controls, but then we found out how slow Scaleform was (it was crippling the Windows builds, and all the mobile builds, only the Mac seemed to be fine with it) so we rewrote the UI. So much code was ripped out and rewritten then. There was no way we could have known that Scaleform was a bad decision at the time, in fact all the performance checks we did showed it to be fast, but as the art style changed and it started to use Scaleform code that wasn't as fast, the requirements of the UI framework changed, and that was how a 90% complete UI, not just one module, or one little function, the whole UI was redone. Data-oriented design might have made this easier, but Scaleform enforces object oriented thinking (as far as the UI developer describes it to me), so there was never going to be a simple fix.

Where you work, maybe the 90% bounce is down to bad programming, but in 90% of the cases here, it's because things change.

I'm guessing the original Kickstarter pitch/promises would be a little different if Molyneux was aware of this from the get go... or was he? <rhetorical mode disengaged>