Thursday, December 29, 2016

One Game A Month: Off And On Again

Off And On Again is a series of light puzzles. You must turn all the lights on, but you must do so by flipping them in patterns. If you turn one light on or off, you'll be flipping lights around it, too. If you can find the right combination, you'll brighten up the board and move on to the next challenge.

This was more than just a game. This was a public project in putting light on the hobbyist game development experience. Created over 25 hours, every single minute of the development of Off And On Again is available as part of a YouTube series Let's Make A Game. If you're interested in learning from this process and seeing what came out of it, you can watch the entire creation of Off And On Again and then play the game for yourself.

Tuesday, December 27, 2016

Why Am I YouTubing An Entire Game Development Project?

For a few weeks now I've been posting new episodes of a YouTube series I've been doing this month called Let's Make A Game. Now that I'm most of the way through the project, I wanted to think a bit about why I'm doing this, what I think people might get out of the videos, and what I hope to get out of it for myself. The best way I know to do that reflection is to write about it, and to share those thoughts.

So, Why am I YouTubing an entire game development project? Why would I put myself out there so publicly for anyone and everyone to look over my shoulder for twenty-five straight hours as I stumble, typo, and mistake my way through a skill I'm still learning and still very green on? And, why exactly would I think anyone cares enough to watch me code, mostly in silence, for twenty-five hours?

Why would anyone care to watch?

The truth is, I don't really expect anyone to. And that's okay. Part of this project required that I be okay with my own definition of success. So far, I have gotten some people watching the videos. I don't know if anyone will continue to watch more of them, and I'm positive that no one will watch all 25 episodes. But that's okay.

Maybe some people are just curious. Or, maybe someone will just be energized by the idea of someone doing this, even if they don't care to site through the whole thing. I'm sure everyone has better things to do with their time than watch me code for over a full day.

But, watching me code isn't actually the point.

Why do this when I'm not very good at it yet?

Because I'm trying to better. Of course, that's a very shortened answer. I hope that the process makes me better about scheduling. I want to practice this sort of video creation, because maybe I'll do more of it when I'm better at this in the future, and I want to know what I'm doing so I can produce semi-decent videos when they actually have good content.

Why do this in the first place?

The genesis of the project wasn't actually a desire to share any part of the process at all, though I consider that a fun plus. Instead, it was entirely for myself. I've been doing this One Game A Month thing for a few months now, the goal being to release one game a month of any quality or scope, and its gone well. But, I realized, I don't really know what's going into these projects. Sure I released one a month for about three months, but I don't know how much time I was actually working on each of them.

The episodic nature of the video series was a good opportunity to do one of these projects in a rigid time-box that I could track, document, and scope within to both practice and observe how I'm able to estimate what I can complete and what I can accomplish in a specific number of hours.

Hopefully this will feed back into my ability to plan these projects, and larger ones.

What's next? Will I do more?

I'm sure I'll do more video content about game development, but I'm just as sure that it won't be in this format. It has been very demanding, to be honest. Later, I might look at a series of Unity tip videos, for example. And in 2017 I hope to work on larger projects, putting a lot more time into them. But this video project has been a big time sink. I spend a lot more than an hour making each one-hour episode!

It has definitely been worth it, but I'm looking forward to wrapping it up.

If you found this post interesting, you can find all the episodes at my Let's Make A Game playlist.

Let's Make A Game Passes the Half-way Mark with Episodes 12 and 13

Interested in my process for making a monthly game? I've got two new episodes up of my series Let's Make A Game! for a total of eight episodes to enjoy, so far. The project should include a total of 25 episodes by the end of the month.
If you want to start from the beginning, you can find a playlist of all the current episodes with all the future episodes added when they're available. Of course, you could also subscribe to my Stonebird Games YouTube channel.

Friday, December 23, 2016

Let's Make A Game! Off And On Again, Episodes 9, 10, AND 11 Available!

Interested in my process for making a monthly game? I've got three new episodes up of my series Let's Make A Game! for a total of eight episodes to enjoy, so far. The project should include a total of 25 episodes by the end of the month.
If you want to start from the beginning, you can find a playlist of all the current episodes with all the future episodes added when they're available. Of course, you could also subscribe to my Stonebird Games YouTube channel.

Tuesday, December 20, 2016

Let's Make A Game! Off And On Again, Episodes 7 and 8 Available

Interested in my process for making a monthly game? I've got two new episodes up of my series Let's Make A Game! for a total of eight episodes to enjoy, so far. The project should include a total of 25 episodes by the end of the month.
If you want to start from the beginning, you can find a playlist of all the current episodes with all the future episodes added when they're available. Of course, you could also subscribe to my Stonebird Games YouTube channel.

Monday, December 12, 2016

Let's Make A Game: Three New Episodes Available

My game development video project, Let's Make A Game, is still underway. There are three more episodes available, for a total of six episodes released so far.

The game is shaping up well, and I'm getting a better handle on how to put together the videos. At the end of this project, I expect to have two useful results: Primarily, a finished game that's actually going to be fun to play. Secondly, but actually more important for me,  I'm hoping that the structure and transparency of building the entire game while recording will help me learn to better focus, budget, and scope my game development projects.

From here on out I'll continue to post a weekly update of the new videos to this blog, but you can subscribe to my channel if you'd like to see the videos sooner.

Friday, December 09, 2016

Let's Make A Game! Watch me make "Off And On Again"

Let's Make A Game! I've been making games to one degree or another for a few years, and I've really gotten into a rhythm in the last few months. This month I'm trying a new experiment and posting the entire process of building the month's game development project. I'll be publishing a stream of every single step I take in the process, broken down into 25 one hour episodes.

I'm doing this for a few reasons.

Firstly, I'm doing this for myself. The one hour sessions and the focus recording gives me on the task at hand are helpful. I think this is an interesting way to go about a project. I'd also like the strict schedule to help me study and learn more about the aspects of budgeting and scoping game projects that I have too little experience to be very good at.

Secondly, I'm hoping someone out there gets some value out of this. My skill level as a game developer is still pretty low, but maybe its helpful for someone to see how someone learns to solve problems, rather than only watching experts that already know the answers.

Thirdly, I want to see if I like the idea and to figure out if I'll keep doing it. Maybe this will be the only time I do this. Maybe I'll scale back the number of hours and continue it on a monthly basis or just occasionally, in the future. Or, also likely, this may be a one time thing.

If you're interested, check out the Youtube channel for my one-man game studio, Stonebird Games.

You can watch the first three episodes right here!

Thursday, December 08, 2016

Finding "One Game A Month"

I was really excited about the One Game A Month challenge as soon as I heard about it.

For about two years I've struggled in fits and starts to make my way into game development. This hasn't been productive in any of the ways I hoped when I started. Its really difficult to be fairly experienced as a developer, which I believe I am in my day job as a web developer, while struggling really hard at an area in which your experience just doesn't exist.

Its like being a pilot who doesn't know how to drive.

But this challenge provided a new breath to this little hobby of mine. It gave me a scaffolding to experiment, to learn, to reflect on finished projects. I had spent far too much time on game projects that stretched on far past their exciting phases, bogged down by bad decisions and regret.

And it has worked.

I have a lot to learn. I have a lot of experience to gain through trial and error and mistake and discovery. I have a lot of fun to be had making more small games that scratch the little itches that have been building up. I have a really exciting 2017 planned for game development!

I've been doing One Game A Month for three months now. I've released three small games. These aren't great games by any stretch of the definition, of course. But they're games that I'm learning from. They're something I'm really excited about and I have needed something personally exciting as a developer for a long time. These are good times for me, and I hope to have more to share about them soon.

Tuesday, December 06, 2016

ReactJS Tip: CSS Transition Groups and Vendor Bundling

Every developer finding their way around ReactJS is going to come across CSS Transition Groups sooner or later. These helpful components built by the ReactJS team but distributed separately help to manage animations related to adding or removing elements from a list. This is important in ReactJS, because the virtual DOM reuses nodes as much as it can, meaning what seems like a new element but really be reusing nodes underneath.
You can read all about the ReactCSSTransitionGroup at the React documentation, but I want to note about one way you might trip integrating it with your project: building vendor bundles for your dependencies.
If you use Browserify to bundle your own code and its dependencies for distribution, you may be using the vendor bundle pattern. This is the practice of separating your distribution into two bundles: one containing your dependencies, including ReactJS itself, and one with your own project code. This is a good pattern because you can rebuild just your project bundle during development, allowing you to iterate much faster without rebuilding a large number of non-changing dependencies.
This tip is about what happens when you move to add ReactCSSTransitionGroup to your project by first installing the package.
npm install --save-dev react-addons-css-transition-group
and import this in the packages where you need to use it.
import ReactCSSTransitionGroup from 'react-addons-css-transition-group';
And now you have fundamentally broken your project. Why? Because the react-addons-css-transition-group module itself depends on react creating a second copy of ReactJS in your application bundle, in addition to the copy already in your vendor bundle. Operations through the CSS Transition Group will fail in strange ways, as happens when you have multiple copies of ReactJS in a single page.
The solution is simply to add this new module to your vendor bundle.
var vendor = browserify({
    debug: false,
    require: ['react', 'react-dom', 'react-addons-css-transition-group'],

Comments !

Web Technologies I Need To Learn More About

I like to think I'm a good web developer. Getting here was the result of experience, practice, and constant curiousity. Lately, I've wondered if the passive nature of that curiousity has run its course. The pace and breadth of changing technologies as a web developer can be both breathtaking and overwhelming at times. What do I need to know about WebAssembly, WebGL 2.0, or the differences between Browserify and Webpack?
Do I need to know about any of them at all? How do I learn enough about each just to understand if its something I need to understand even more deeply?
Beginning an effort to make that ever driving curiousity more directed, here's a list of things I don't know enough about, but would like to study better.


I know that Webpack can replace Browserify and recently have understood it may replace some (or all?) the ways I use Gulp today.
I don't know if the change would impact more projects beyond the build scripts or how much time or effort would be involved with the change.
I want to know what solid advantages Webpack would bring other than just being "new and shiny". I'm specifically interested in how Webpack can handle non-Javascript assets, and how this might make it easier to isolate collections of componenets that pull in both behavior and styling together.


I know redux is a novel tool for managing all the data in a React application in a single store, focused on immutable operations that enforce consistent operations on your data to make testing and working with your componenets supposedly much easier.
I don't know some details about how to use Redux, like how to combine multiple components from different sources if they have to share a single giant store.
I want to know if I can introduce Redux into projects without creating a huge learning curve for teammates that may have less interest in the whole ecosystem than I.

Material UI

I know that Material looks clean (at the very least I know it doesn't just look like Bootstrap) and that Material-UI provides an implementation via React and could give me a big boost getting started on building larger applications.
I don't know if Material-UI's reliance on Sass would impose a requirement on me, which might be a problem because we've been a Less shop for years.
I want to know how easily we could use Material-UI as a basis to build collections of styled components for each project, especially how much we can customize Material widgets, build more complex widgets out of them, and style them without mucking with the original Sass.

Web Workers and Service Workers

I know that Web Workers and Service Workers bestow amazing new abilities to web applications and I know a little about the lifecycle of a worker and its communication with the host page.
I don't know anything about Service Workers, other than their building on the foundation the Web Workers laid out.
I want to know more about using Service Workers to control offline support, caching, and optimizing page load times. I'm especially interested in using them to get a handle on long load times on mobile and for larger, complicated Single Page Applications.

Sass and Stylus compared to Less

I know that Less has served me well and been my preferred CSS precompiler for a long time, but that decision and the environment it was made in was a half a decade past. For the same reasons I needed to evaluate and focus on one options then, I need to do the same thing now that the landscape has changed.
I don't know if the comparisons I made between Less and Sass five years ago are still valid today. I don't know how Stylus, the new kid on the block, measures up between them. I don't know if my preference for Less is holding me back because, despite what I'd prefer, its definitely the least popular and the move of Bootstrap from Less to Sass might be a nail in the coffin.
I want to know what might have changed about Sass and how it compares to the evolution of Less over the last few years. More so, I want to learn about Stylus. In the end, I want to figure out if either Sass or Stylus are improvements enough to be worth the effort and pain of jumping ship.

Becoming a Better Developer on Purpose

I’ve become a much better developer than I was when I began working professionally a decade ago. I feel confident enough in my abilities to recognize that I have improved the breadth of my skill set and the depth of understanding I’ve built in the areas I have poured the most focus into over the last few years, especially. One of my strongest, most developed abilities is the ability to recognize and pick apart my own skills critically. I feel good that I can say this is not Impostor Syndrome, something that has certainly afflicted my professional career for most of the years I’ve been at this. What this is, rather than irrational undervaluing of my skills, is finally getting to the point that I realize I’ve spent years getting better passively and accidentally, and I need to develop my skills into the future actively and intentionally.
So to start this new focus on developing my skills, I’m writing this as a starting point, an exploration, and an invitation to anyone who identifies with the intent.
I can characterize the path I took from fledgling to, I believe, experienced developer as passive with more accuracy than any other single word. Passively developed skill happens when you absorb through experience, colleagues, and material that comes your way without specific and focused intent on what you’re getting better at. I’m better today than I was ten years ago, largely, because it is nearly impossible to do what I do for this many years without learning something. I can say with confidence that I’m a much better developer today, but I cannot say that I had much of a hand in that.
The past ten years of experience were littered with an almost obsessive absorption of material from the wider programming community. I’ve dozens of programming texts, listened to many podcasts, and read what must be thousands and thousands of blog posts that simply drifted my way through feeds and social media. With such a huge amount of material I’ve sifted through over the years it is inevitable to accept a distressing outcome: the majority of programming material I’ve consumed has been completely forgotten. There might be a book or two I still remember and can recommend, and I can recall and find you a link to maybe ten blog posts that actually stick out in memory. There are probably hundreds of posts I’ve read from which I’ve integrated some information from. I am sure I’ve learned from this flood of programming material, but I can’t say the ratio is very impressive. To be honest, I can’t say the pay off for the time and effort I put into finding, tracking, and consuming all the fascinating things I’d like to learn.
This has also been one of the most useful ways I’ve randomly come across ideas and technologies that have changed the course of my interests and even my career. I’m distressed over this for two reasons. First, I’m pretty sure that I can trace many of the major turning points in my career to things I came across entirely by accident. Second, there has been awful lot of equally fascinating things I’ve encountered and dived into that, today, do not really have any value to me as a developer. With a lack of direction I have wasted an immeasurable time on interesting development topics that I’ve walked away from with nothing of value. This isn’t something I can allow to continue. I don’t have the time or energy to continue being so ineffective with my self-improvement as a developer.
My new effort is to both spend less time and get more out of my self-improvement as a developer. I don’t want to rely on stumbling across the important things I need to learn and I don’t want to coast through self-improvement as a by-product of habit and the ingrained interest in the newest and greatest developments in the field. Instead, I want to be an active participant in my own self improvement. I want to rely on actively made plans and goals rather than passive habits. This means reading less random posts shared on Twitter and found on RSS feeds, and more structured learning and practice.
Active self-improvement has to replace the casual accidents of discovery.My hope is to replace what is moved me along at a casual pace with setting goals to learn things intentionally and making hard choices about not only the next topic, but precisely what I want to get out of it.
I’m not sure, yet, exactly what form this change in focus will have. I expect I’ll need to figure that on the way, and see what works and see what slows me down. I know my more immediate intentional improvements will be expanding my knowledge and experience with the wider ReactJS ecosystem, but soon it will go beyond that to other endeavors.
The thing I can say with confidence is that I expect to feel better about the progress I make in the next year than i do about the progress I’ve made in the past ten.

Sunday, April 24, 2016

Evernote: a Landscape of Experiences

I’m going to take some time out of absolutely loving Evernote for keeping me on task and organized throughout the day to talk about what, I think, is absolutely the worse thing about it.
Evernote is a completely different application on every platform and device it supports.
For a product who’s main gimmick is keeping you organized and your data synced between all of your platforms and devices, that’s sort of a really hard knock against them. The Evernote for Windows application is great, but so is the Evernote for Mac application. These are quite different, and not just in the ways that usual differ between Windows and Mac to fit the platforms well. They are just fundamentally different applications which coincidentally happen to be sharing your data.
Beyond the two desktop Evernotes, the problem only gets worse. Evernote for Android is yet another experience, with yet other features different from the two Desktop versions.
The most jarring differences between these versions are differences in the editing of your notes themselves, something that (given the nature of the tool) seems like being consistent should have been priority number 1. How am I supposed to work on my notes everywhere if my notes may be different everywhere?
Perhaps the most frustrating part of all this comes down to what is definitely the most overlooked face of Evernote from their development team: Evernote for the Web. This version of the product has, by far, the most missing features found at least in some form in most of the other versions.
This Web version being so limited is especially troubling because, would it be better supported, the differences of all the other versions would barely scratch my notice. I’d just use the web version everywhere.
Moving forward, these discrepancies are killing my loyalty to Evernote and I can’t see there is anyway I’ll be able to continue as a user much longer. Honestly, I’ve gotten a lot out of it, and I’d hoped this situation would improve. That hope is what kept me around this long. As it continues to only appear more divergent over time, not less, it seems my hope was misplaced.
I’m still looking for the replacement, but I’m going to find it (or make it) and then it’ll be “so long” to Evernote, I’m afraid.

Sunday, April 10, 2016

Publishing ES6 Modules on NPM

I had an adventure over the last couple days with ES6!
There was a pattern I'd already used in a few of my React projects to make ES6 classes a little nicer. ES6 did a lot to make working with this mechanics nicer, but there was a still a gap that bit me: the sugar provided by ES6 classes don't extend to keeping method bound to instances of the class.
Maybe you, like me, would expect this to work:
class Counter {
    constructor() {
        this.count = 0
    onClick() {
        this.count += 1
counter = new Counter()
document.querySelector('#add-button').onclick = counter.onClick
But, like non-class methods on any regular Javascript object, onClick will loose its binding to the Counter instance. There are a few existing solutions to this, but I wanted one that didn't change the syntax of defining a method on these classes.
Enter AutoBind, via my new NPM module es6-class-auto-bind:
import AutoBind from 'es6-class-auto-bind'

class Counter extends AutoBind() {
    constructor() {
        this.count = 0
    onClick() {
        this.count += 1
counter = new Counter()
document.querySelector('#add-button').onclick = counter.onClick
You can read all about the AutoBind class [at its NPM readme]( and you can read on to learn about what I learned to publish this ES6 module on NPM, consumable by other ES6 (and even ES5) code.

The Problems of ES6 on NPM

For the moment, NPM is a tool for distributing and installing ES5 modules. While you can point it at any types of files you want (some people have even used NPM to distribute C libraries!) the mechanisms that install and then import those modules in NodeJS (or Browserify) are expecting ES5 modules, so they won't do your users any good.
There are two problems we'll face shipping ES6 code directly.
First, most of the ES6 code we might ship would be completely useful for consumption by ES5 code. My choice of ES6 shouldn't prohibit anyone from consuming my libraries. We want to publish something that both new ES6 and legacy ES5 code can make use of without caring much about what's inside. And, we want to do so without carrying build constraints on our users, like requiring they integrate BabelJS into their pipeline when they haven't done so already.
Second, for those consumers of our module who already are using BabelJS or another transpiler to ship their ES6 to ES5 runtimes, importing ES6 code installed by NPM is probably not going to work out of the box! Browserify here is a big culprit, refusing to apply configured transform plugins to packages installed from node_modules/, only to those from your own local project.
Now, I understand Webpack may be better about enabling this usecase, but I don't want to impose that move to people still on Browserify (and I still want to support ES5 users), so I wanted a solution that works for everyone.

How To Combine Packaging and Transformation

The solution is to tranform our ES6 module to ES5 before publication, and idealy to automate this. We want to transform it into an ES5 version of itself and tell NPM to publish that version of our module, instead of the original ES6 version. Here's how we do it.
We'll put our two versions into a src/index.js and build/index.js. Transforming the first to the second is straightforward with BabelJS, which we'll install first:
npm install --save-dev babel-cli
npm install --save-dev babel-preset-es2015
npm install --save-dev babel-runtime
node_modules/.bin/babel src/index.js > build/index.js
Now we have both versions, and we only need to tell NPM what we actually want a consumer to get when they require()or import it.
"main": "./build/index.js",
Great! But we still need to make this happen automatically any time we issue an npm publish, never allowing us to publish a version that isn't compiled from the most recent version of the ES6 source.
"scripts": {
    "compile": "node_modules/.bin/babel src/index.js > build/index.js",
    "prepublish": "npm run compile"
We've defined two npm run scripts now: compile and prepublish. We can run npm run compile to test our preparation any time, and NPM itself will invoke prepublish before any new version you attempt to upload via npm publish. We've now configured our module to transform from ES6 to ES5 before publication to NPM, where it is consumable by any other project that needs it!
We're almost done at this point. There is a last step we can take to make the whole process more consistent between ES5 and ES6 norms. The ES6 module syntax's export statement is largely comparable to exports.member = somethingstatements in NodeJS' ES5 modules, and BabelJS will transform them appropriately. But export has a special form for exporting one member as a default, to be handed to an importing module when it only asks for a single thing from the module.
import AutoBind from 'es6-class-auto-bind'
export default class AutoBind {
The problem is BabelJS transforms this by exporting these defaults with the obvious name "default", and accesses the .default member of a module when performing a default import. But, this means ES5 code would need to access the .default member explicitly, with the unfortunate requires() invoking as require("es6-class-auto-bind").default. We'd like to get rid of that ugly .default at the end, obviously.
It turns out this is a behavior BabelJS did have but changed. It is also a behavior we can restore through a plugin that re-implementes the deprecated behavior. I think allowing it to be optional like this is just fine. We just need to install the plugin
npm install --save-dev babel-plugin-add-module-exports
And change our compile script to enable the plugin
"scripts": {
    "compile": "node_modules/.bin/babel src/index.js --plugin add-module-exports > build/index.js",
    "prepublish": "npm run compile"
And, that's it. Everything works great now. This is how I was able to ship my ES6 AutoBind class via NPM and install into other ES6 classes, seamlessly building my ES6 code across packages. Very exciting!
Here's the whole portion of the package.json necessary to make this work.
"main": "./build/index.js",
"scripts": {
    "compile": "node_modules/.bin/babel --plugins add-module-exports src/index.js > build/index.js",
    "prepublish": "npm run compile"
"devDependencies": {
    "babel-cli": "^6.7.5",
    "babel-plugin-add-module-exports": "^0.1.2",
    "babel-preset-es2015": "^6.6.0",
    "babel-runtime": "^6.6.1",
Stay subscribed for follow up posts on the subject, as I dig into how to expand this to:
  • Ship a copy of the ES6 code in parallel and pull that into the project's own transform options
  • Understand how to expand this approach to packages with more than one module
I write here about programming, how to program better, things I think are neat and are related to programming. I might write other things at my personal website.

I am happily employed by the excellent Caktus Group, located in beautiful and friendly Carrboro, NC, where I work with Python, Django, and Javascript.

Blog Archive