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.

Webpack

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.

Redux

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.
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