The night after the inaugural PTBO Game Jam event, I started looking at creating a new website for the event. One which could be maintained by the growing community. In order to grow the event, I would need a marketing machine and staff that I could delegate too. Hindsight, it’s very easy to delegate to paid staff, you’re paying them after all. Asking someone who is volunteering their time to do something presents its own unique challenges.
What about existing platforms?
Recent security exploits had turned me off of the traditional CMS architectures (WordPress, Drupal, etc.). I started thinking we could use the Blueprint system I had previously built to statically generate the dotBunny website. It’s not that I don’t like CMS systems, reapazor.com, for example, runs on WordPress. There is something just nice about the blistering speed of a statically generated website. Blueprint could definitely handle the task set before it. However, it had been an internally used tool up until that point. The process to actually generate the static files was a lot more complex than it needed to be.
Previously in my browsing, I had stumbled across Jekyll and GitHub’s Pages system but had overlooked it in favour of rolling our own system. This time around I decided to take a 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 limited (it is not as awesome as the non-GitHub flavour) version of Jekyll and have it do 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.
We are not web developers.
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, that is not how we roll. It also did not solve my problem of wanting to update the dotBunny website either.
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 person, 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.
Get the job done
I was left with an interesting position that needed filling. Both the PTBO Game Jam and dotBunny really needed a facelift to their web presences.
It was around this time that we were rolling off a large project, and pivoting on to others (GCAP, NeXT, etc.). dotBunny operates in a non-traditional management structure, where project tasking is based on who is excited by a project. Both Robin and myself were going to take on SceneTrack production work. Now to be called GCAP, we were both really excited by the technical challenges it presented. This project, however, wouldn’t eat up all my time, and that gave me the opening to pick up the torch, on the whole, making the PTBO Game Jam a website.
#GameDev does #WebDev
Jekyll’s 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 PTBO Game Jam 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.
Wait, another website … hire a web developer?
Why didn’t I hire a firm to do our company site? Sadly, most web development shops warrant the bad reputation that they have in the general tech community. Folding 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. That ended with us having to spend our own time fixing their shortcomings 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.
Get it done
After hours’ work started mid-March on the new dotBunny website. 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 the 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.
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 true web developers face when it comes to browser compatibility. This really isn’t any different from hardware compatibility issues that the games industry faces. On the game development side, we have a finite number of established frameworks. Over the years they have 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 of them 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.
The Forgotten Soul 