Powargrid
  • Home
  • Blog
  • Buy
  • Demo
  • Media
  • Press
  • The Daily Blobbie
  • Blobbie Meme Maker
  • Forums

Bleeding Skull Programming

8/1/2014

1 Comment

 
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
'
Picture
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 :).
Picture
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:
Picture
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:
Picture
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-
1 Comment
Michiel link
8/1/2014 06:32:40

Bleeding skull FTW!

Reply

Your comment will be posted after it is approved.


Leave a Reply.

    Author

    We're Michiel and Willem. Hi!
    This blog is about the development of Powargrid and our experiences in doing so.

    Archives

    June 2017
    May 2017
    November 2016
    October 2016
    September 2016
    July 2016
    May 2016
    April 2016
    March 2016
    February 2016
    January 2016
    October 2015
    September 2015
    August 2015
    July 2015
    June 2015
    May 2015
    March 2015
    January 2015
    December 2014
    November 2014
    October 2014
    September 2014
    July 2014
    June 2014
    May 2014
    April 2014
    March 2014
    February 2014
    January 2014
    December 2013
    November 2013
    October 2013
    September 2013
    September 2012
    August 2012

    Categories

    All
    Game Design
    Marketing
    Progress
    Slacking
    Tech

    RSS Feed

© Wee Free Studio | Steam | Twitter | Facebook | RSS feed | Press | Contact