Who Wants To Be A Web Developer?

The night after the inaugural PTBO Game Jam event (the repository tells me that was August 14, 2016), I started looking at a way to create a website for the event which could be maintained by a variety of different people. I immediately knew at that first event that I was on to something awesome, but in order to grow the event, I would need a marketing machine (website, briefs, press releases, etc.) and staff that I could delegate too. Hindsight, its very easy to delegate to paid staff, you’re paying them after all. Asking someone that is volunteering their time to do something presents its own challenges. Recent security exploits had really turned me off of the traditional CMS architectures (WordPress, Drupal, etc.), so I started thinking on the website front that we could use the Blueprint system I had previously built to statically generate the existing dotBunny website.

While it was clear it would be able to handle the task set before it, I wasn’t so sure it was going to be easy for every possible user to pick up and use. The process to actually generate the static files was a lot more complex than I really wanted it to be, and could potentially be daunting to some individuals. One critical feature was that I wanted participants to be able to make additions and corrections to the driving data, and push PRs with changes to our team for inclusion. I needed something a little more mainstream (heh I hate that term), but I still was not prepared to go to something with a runtime backend. Previously in my browsing I had stumbled across Jekyll and GitHub’s Pages system but had overlooked it in favor of rolling our own system. It was a new day, and this time around I decided to take a much closer look at its capabilities after a year of development (v1 to v2). It was quite impressive right from the start, from its collections, to the fact that I could build out Liquid based templates in a gimped (it is not as awesome as the non GitHub flavor) version of Jekyll and have it accomplish 95% of what I wanted it to do right out of the box. It was not hard to see the immediate benefits over the standard CMS at that point. There was only one problem, none of the dotBunny staff are really “web developers” by trade, nor was I going to bring on a “web developer” just for our not-for-profit event. In hindsight, I could have found someone willing to volunteer their time to make the website, maybe an intern or something. Nope, not how we role.

There seems to be a running joke in the games industry, where “web developers” are looked down upon. I’m not exactly sure where this originated, but I’ve seen it a few times at different studios. There definitely are some individual’s that identify themselves as “web developers” which make many of us shake our heads, but that’s more a reflection of the individual, not the title. That old adage of “one person ruining it for the rest of them” maybe applies here. There is also appears to be a definite difference between a “web applications developer” and a “web developer”; again, not my space, purely opinion right there. Anyways, I was left with an interesting position that needed filling. It was around this time that we were rolling off a large project (Torment), and pivoting on to others (GCAP, NeXT, etc.). Without going to heavily into the corporate structure of dotBunny, I will disclose that we operate in a non-traditional management structure (Corporate Speak? Eww!), where project tasking is based on who is really excited by a project. Both Robin and myself were going to take on SceneTrack (that was the R&D name I had come up with almost a year ago?) production work, now to be called GCAP, as we were both really excited by the technical challenges it presented, as well as the backing technology we would have to make. This project however wouldn’t eat up all my time, and that gave me the opening to pick up the torch on the whole make the PTBO Game Jam a website.

The learning curve wasn’t terribly steep; there were a lot of fantastic support articles provided by GitHub on how to use Jekyll with their repositories, and within no time I had something going and it started to come together. The website was well received by the community, and has since proven to achieve my goals of creating something that easily maintainable and extensible. Of course, instead of people pushing PRs for review, they still just tell me something is wrong … maybe one day?

All of this was just a training ground it would seem to rumblings internally about how our own website really wasn’t that amazing and lacked content about all the cool things we do in the community. This lead of course to the inevitable “well you made the PTBO Game Jam one, why not remake the dotBunny one using the same tech” (Thanks Cal!). There was no argument in my mind, everyone was right, it just was a matter of finding the time outside of the normal work day to put together something.

Why didn’t I hire a firm to do it? Sadly, most web development shops warrant the bad reputation that they have in the general tech community, and fold just as quickly as they pop up. I just didn’t feel comfortable that I could trust a firm to deliver at the quality bar I expect when paying for something. Add to that, many years ago, we did source a respected firm to recreate our brand and website, which ended with us having to spend our own time fixing their short comings on delivery. Disappointing as that was, it was an eye opener to what I will call my attention to detail and always wanting to over deliver to a client or user.

After hours’ work started mid-March on the website, where I would spend some time in the evenings seeing what I could do based on my previous experience with the PTBO Game Jam website. There were a few hang ups that I ran into when working on that site to do with how to handle inclusion of frameworks and arranging dependency checks that I wanted to work out cleaner this time around. I also started experimenting with using Jekyll to strip whitespace and compress files. It became more of a fun side project where I would push the limits of Jekyll and see what came out. One of the added benefits of redoing the website, was that I opted to put back a blog section, against the current, as a place where we could post random things, articles and tutorials. I say “we”, but what I really mean is me, because I’m pretty sure no one else is going to jump at writing 1500+ word text blocks.

Looking back over much of the time I have spent on this website, I can see where I’ve transferred patterns from what I’ll refer to as “good development practices” into the web sphere of things. Keeping things simple and modular seemed to be a very good practice. I’ve definitely grown to appreciate the crap that web developers face when it comes to browser compatibility (again this really isn’t any different then hardware compatibility issues that the games industry faces). On the game development side, we have a finite number of established frameworks that over the years have really made headway in creating robust and versatile systems to build on top of. Whereas on the web development front, it seems that they have 10 new frameworks every month all doing the same thing, but claiming to do it better than the others. I don’t envy those trying to decide on a backing technology; as for JavaScript, it is still an ugly mess, no matter how you package it.