If you’re like me you’re watching plenty of videos online. I don’t mean funny cats clips or fail compilations. What I’m talking about are lengthy videos about game development, politics, self improvement or the like.
A while ago I was wondering how I could get faster in watching videos. You may be familiar with clicking through suggested videos on YouTube and hitting the Watch Later button (way too) often. Pushing videos to the queue is easy but consuming them takes time.
I’ve already boosted my reading speed as mentioned in my book Game Project Completed. Therefore I wanted to figure out how to do the same for videos.
So, how can you reduce the time for watching all of your videos?
Speed up Videos
YouTube allows you to increase playback speed. Just click the gear icon in the right bottom corner of the video player area and change the Speed setting. If your browser doesn’t use HTML5 for YouTube videos go to www.youtube.com/html5 and activate it. Check out this video for details.
I didn’t investigate other video portals like Vimeo regarding faster playback. Firstly because the majority of videos can be found on YouTube anyway. Secondly, speeding up playback is a minor trick for watching videos in shorter time. The following tricks are way more useful.
Prune by Description
Read the video’s description and decide upfront, if you really want to watch it. Not watching it is always the most effective shortcut.
Skimming
Go through the video by watching just any Nth minute. For example: watch minute 5, watch minute 10, minute 15, and so on. If these samples look interesting you may want to watch the whole thing. Skip it otherwise.
Listen to Videos While Working
Many videos (I “watch”) can be consumed just by listening to them. These can be interviews, talk shows or presentations (many slides just resemble notes anyway).
There are limits, though. It’s impossible for me, for instance, to listen to any speech while I’m writing a blog post or working on a book. The double-language input interferes in the language processing part of the brain. But it’s no problem to listen to interviews while checking my bank accounts.
Another trick is to rip the audio of videos to MP3 files and listen to them while driving, doing housework or going for a run. There are plenty of online services like www.convertmemp3.com you can use for this for free.
Long Tail Decay
Last but not least you may watch your queued videos in order of interest, not by appearance in the queue. In this case the most interesting videos get watched first and the least interesting videos get (left) behind. The videos you delay the most don’t seem to be that interesting, do they? Think about dropping them.
Cheers,
Thomas
P.S.: This blog post is part of my corner cutting experiment. It was written in half the usual time. Therefore, please forgive me for any bad english in this post. 🙂
Nordenfelt’s release date got scheduled to be on December 15th. This means there are only 3 months left. Therefore I boiled down Nordenfelt’s task list as much as possible. Only the most important points on the list survived. Then I applied Parkinson’s law and shrinked the schedule to half its time. This means Nordenfelt should be finished in the end of October. Yeah, right! 🙂
For sticking to this plan I had to get “faster”. Not by skimping but by focusing on the most important aspects and leaving everything else out. This includes fancy graphics, polish, sounds and other details. That’s the 80/20 rule in action.
This week's experiment: finishing tasks in half the time. Not by working faster but by cutting corners like crazy.
— hermitC (@black_golem) August 25, 2014
This experiment went well so far. But then came Squirrel.
I always wanted to integrate a scripting language in Nordenfelt to save compile time. The new bot swarm feature was the perfect reason to integrate Squirrel. The bots were planned to approach enemies and blow them up on their own. The bot AI was perfectly suited for scripting.
As mentioned above, the current schedule is very restricted. And unknown technology turned out to be the natural enemy of a narrow time frame. Figuring out how the scripting language has to be integrated and correctly used takes some time. Don’t get me wrong, binding Squirrel with Sqrat is a breeze. Nevertheless, you have to get an understanding of how it works. This takes time.
To make a long story short, after spending a full day with Squirrel I canceled the “seek and destroy” bot AI and coded a simple “follow player ship” behaviour in C++. The “seek and destroy” AI went to the Kanban backlog.
This is what I’ve learned and/or rediscovered during the last two weeks:
- Parkinson’s Law works! It reduces quality, though.
- Experiments and tight time frames are a bad match.
- Sticking to ideas which take too long is bad.
- “I want this feature to be exactly this way” is childish. Face reality!
- Include weekends, events and vacations in your schedule.
Right now I would love to continue working my ass of for Nordenfelt. Unfortunately, there is this Oktoberfest-like event this weekend. Social connections need to be cherished and beer has to be drunken – the reasons for the last point in the list above.
Cheers,
Thomas
“The road to hell is paved with good intentions.”
In the past, whenever I had to do graphics for Nordenfelt, I wanted to make them super fancy. I spent hours and hours just to make a single sprite as impressive as possible. To be honest: I don’t think it ever worked out.
The problem with perfectionism is that it takes so much time. It’s often hard to say when to stop polishing. There just seems to be no natural limit for improvement.
Perfectionism also serves procrastination. The feature list is too short, the graphics are boring, the AI is too dump, the sound effects don’t fit, etc. You don’t want to release the game in such an embarrassing condition. Therefore you go on improving behind closed doors.
I guess it’s the impression other games create when they suddenly pop out of nowhere with all the bells and whistles. They have a polished appearance from the (seemingly) very beginning. Therefore you feel constrained to bring your own game to the public as sophisticated as possible as well.
Today, after several years of suffering from perfectionitis, I have become an advocate of the bare-bone solution. Sometimes it’s even below bare-bone quality, not to say bad quality. In this regard I like G. K. Chesterton’s quote:
“Anything worth doing is worth doing badly.”
As mentioned in Game Project Completed, bringing up firstborns is usually done by bloody rookies: freshman parents. As they go along they learn what is needed.
When educational underperformance does not harm children, it should work for game development as well. It just takes guts to hit the publish button for a ridiculous version of your game. The good news is that this gets easier the more often you do it. At some point the embarrassment is gone.
Releasing “not so good” versions brings out another fact. Often your own perception of “good” is way above the quality your audience expects. Over-delivery is a concept Seth Godin beats the big drum for. Yet it’s not necessary, especially when you are new to game dev land. The lo-fi version works as well. And if it does not, you can improve on it anytime later.
Cheers,
Thomas
The last 3 weeks of developing Nordenfelt were horrible. It all started with a single task on my Kanban board:
“Create phase 2 of final boss”
This task demanded some code extensions. Usually coding tasks take a few hours in average. But not this time. Each sub-task of the “phase 2” task expanded into days of coding and testing which made the whole task take several weeks.
Working for one week on the same task is OK. The second week already gets tedious. The third week is… well, as said: horrible. Motivation decreases very fast. The light at the end of the tunnel pushes further afar each time you start another sub-task.
Plans were to release a new version of the game each fortnight. That would have been around the 15th of June. But one task was enough to impede the whole project. This made me ponder on how to avoid this problem in the future. Here is what I came up with:
Split it into sub-tasks
This sounds nice but does not solve the problem. If your goal is “make boss X” and it’s a complex endeavor, splitting the task into smaller ones won’t help. It does not matter if you have 1, 10 or 100 tasks to reach your goal. On the other hand, ticking off sub-tasks provides you with a feeling of progress. Therefore I see task splitting as a good thing.
Don’t declare big tasks as release goals
To avoid including costly tasks in your release plans you have to be able to spot them in advance. Sometimes you know that a task will take several days or weeks to complete. Other times you will find out that a task is a Behemoth on the go. It takes some guts to postpone a big task you’re in and continue with smaller ones. The ego often stands in the way because it feels like giving in. I could not fight this feeling and therefore stalled my (felt) progress.
Change release goals
Don’t constrain yourself to a goal or promise. Keep your plans as flexible as possible. Avoid promises. I decided for future tasks to change release goals when a task turns out to stall my progress. But wouldn’t that make big tasks get left behind?
Work on big tasks in parallel
Among big tasks exist many more smaller tasks. Do multiple smaller ones sequentially and one big task in parallel. Having sub-goals for the biggie is helpful. As said, this serves the fuzzy feeling of progress.
Do it badly
This needs balls! Are you ready to release the worst version of a feature? Then you can try handing out a really bad implementation which will take only a fraction of the time of the high-quality version. This is the famous 80-20 rule in action, which sometimes isn’t that easy to carry out.
N+ is your friend
This goes hand in hand with “do it badly”. Start with a laughable version and improve on it iteratively later. Many times your audience won’t recognize that you just integrated a “pile of shit” into your game. They just don’t see it the way you see it. Sometimes this saves you time you would have invested in a higher-quality version which is not necessary.
I’m sure there are more things you can do to not get stuck in the task pipeline. This list is just my personal brain dump. IMO keeping your momentum is just a matter of deciding (to stop) what you are doing at the right time and having the balls to carry out these decisions.
Cheers,
Thomas
This post was originially posted on reddit. As soon as I hit the publish button the post got removed. No clue why. Therefore I share it here.
I’ve written my 2nd book called Game Project Completed. It’s about how to get game projects finished. Now I’m curious what’s the people’s opinion about this book. Therefore I decided to share free copies of it here (pdf file) and would be happy if readers could rate it on amazon.com, amazon.co.uk or amazon.de.
Here you have some download links (they work only once):
- https://1ty.me/zqH4Ts
- https://1ty.me/FBF5Qpeao
- https://1ty.me/QMmqP
- https://1ty.me/m4Kf5s
- https://1ty.me/MeswLHQq7
Thanks a lot in advance!
It’s good to have multiple info outlets when one gets awkward. 🙂
I’ll drop more download links in the comment section of this blog later. Stay tuned on @black_golem
Cheers,
Thomas