Bleeding Skull Programming

I'm certainly not a programmer, but I do understand enough about algorithms,
math and logic to write some code. I always thought that in order to help build
the actual software part of Powargrid, I'd have to learn much more about how
programming works. And that was holding me back. Then, I think about two
years ago, Michiel sent me a link to this blog post by James Hague: 'Write
Code Like You Just Learned How to Program'

The gist of that post is that there is a big difference between writing a program to achieve a specific end result and writing the architecturally best piece of software you can. James' main advice is that it's often better to focus on designing the user experience instead of on writing the program. And while the post was written for software engineers who know three orders of magnitude more about programming than I do, it was still very helpful by making me focus on making stuff work. The central example James uses is from a class in BASIC which he took, where one of his fellow students made an amazing visual demo with, amongst other things, a skull that dripped blood from its eye. So I started to call this way of working 'bleeding skull programming'.

---

And it has been a great boon to me. I just build whatever works. If I know how to improve my code with loops, lists and larceny (a.k.a. 'borrowing' neat parts of Michiel's code), I certainly will. But if not, I don't fret about it and I just keep typing in ugly and unwieldy stuff untill it works. Even, and this is the important part, if I know Michiel has once shown me a better way to get the job done (which I have forgotten the specifics of).

Working this way, I can build missions and test them without having to consult Michiel too often in the process. Since we often work at different times and in different places, this allows me to make much better progress. Once a mission works the way I want it to, I review the code with Michiel. He then usually rewrites or condenses parts of it, so the code ends up clean, neat and efficient. And as a bonus, I get to learn more about programming and about the things I can improve on. Although I must admit that a lot the more complicated stuff still goes over my head. At the current rate, I figure I'll be a full-fledged developer about six or seven games from now :).

An example: In one of the missions, we have a couple of factories; special buildings unique to that mission. In the mission script, I wanted to test whether a certain piece was a factory, but I had no idea how to refer to a factory and couldn't find any similar references in the missions we'd already made. The only way I could figure out to actually perform the test, was by checking if the piece was not anything else. So my if-statement looked like this:

After showing this to Michiel, it turned out that there indeed was no way (yet) to directly check if a piece is a factory. Instead, there was a simpler solution. Factories are compound pieces and none of the other pieces in the scene are. On top of that, there was no need to check who the owner of the piece in question is. So this is the replacement code:

In the same mission, I ended up checking a lot of different things for each of the five factories. All these checks were the same, but I saw no way to loop over them. So I actually wrote all of them out in full (or rather copy-pasted them and then used Sublime Text's multi-line edit feature to save me a lot of typing). Michiel did create loops, combined with sets of attributes for factories in general, and shaved over 100 lines off the code, even while adding functionality.

To conclude, don't be shy to do some bleeding skull programming, whether you're a seasoned programmer or a beginner who knows that a seasoned programmer will look at your code. If said seasoned developer ever tsks at your code (which, I must emphasize here, Michiel never ever does), just say 'bleeding skull' to make him or her see reason :).

-Willem-