Skip to main content

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.

Comments

Popular posts from this blog

Interrupting Coders Isn’t So Bad

Here’s a hot take: disrupting coders isn’t all that bad.

Some disruptions are certainly bad but they usually aren’t. The coder community has overblown the impact. A disruption can be a good thing. How harmful disruption might be a symptom of other problems.

There are different kinds of disruptions. They are caused by other coders on your team, managers and other non-coders, or meetings throughout the day.

The easiest example to debunk is a question from a fellow developer. Imagine someone walks over to your desk or they ping you on Slack, because they have “one quick question.” Do you get annoyed at the interruption when you were in the middle of something important? You help out your teammate quickly and get back to work, trying to pick up where you left off. That’s a kind of interruption we complain about frequently, but I’m not convinced this is all that bad.

You are being disrupted but your team, of which you are only one member of the whole unit, is working smoothly. You unstuck …

Announcing Feet, a Python Runner

I've been working on a problem that's bugged me for about as long as I've used Python and I want to announce my stab at a solution, finally!

I've been working on the problem of "How do i get this little thing I made to my friend so they can try it out?" Python is great. Python is especially a great language to get started in, when you
don't know a lot about software development, and probably don't even know a lot about computers in general.

Yes, Python has a lot of options for tackling some of these distribution problems for games and apps. Py2EXE was an early option, PyInstaller is very popular now, and PyOxide is an interesting recent entry. These can be great options, but they didn't fit the kind of use case and experience that made sense to me. I'd never really been about to put my finger on it, until earlier this year:

Python needs LÖVE.

LÖVE, also known as "Love 2D", is a game engine that makes it super easy to build small Lua…

CARDIAC: The Cardboard Computer

I am just so excited about this.


CARDIAC. The Cardboard Computer. How cool is that? This piece of history is amazing and better than that: it is extremely accessible. This fantastic design was built in 1969 by David Hagelbarger at Bell Labs to explain what computers were to those who would otherwise have no exposure to them. Miraculously, the CARDIAC (CARDboard Interactive Aid to Computation) was able to actually function as a slow and rudimentary computer. 
One of the most fascinating aspects of this gem is that at the time of its publication the scope it was able to demonstrate was actually useful in explaining what a computer was. Could you imagine trying to explain computers today with anything close to the CARDIAC?

It had 100 memory locations and only ten instructions. The memory held signed 3-digit numbers (-999 through 999) and instructions could be encoded such that the first digit was the instruction and the second two digits were the address of memory to operate on. The only re…