Steven Yau’s Blog

My Journey with LLMs and AI Agents: From Skeptic to Adopter

2026-05-24T00:00:00+01:00

When AI services like ChatGPT and Claude Code hit the scene, I was impressed by what they could do against LeetCode problems and mini projects but was skeptical that they would be able to handle the complexity of an actual product’s project.

We had access to several different AI services and tools at day job at Gather but every time I tried using them for code generation, I wasn’t happy with the results. They didn’t follow existing patterns in the codebase, failed to handle edge cases, or output code that wasn’t even buildable in some cases, especially for automated tests.

It wasn’t until 2026, I started to see a positive uptick with people on my team and developer friends in usage of AI and LLMs - it felt like something had genuinely changed, especially with the recent release of top of line models from Claude and OpenAI. They were frequently referenced as being a marked improvement on previous models, I decided to give it another go to see what I was missing.

The Early Struggles: Too Much Human in the Loop

I had a list of small issues in our app that I wanted to deal with for a while, but couldn’t prioritise hands-on time because there was always a higher priority task to deal with in our backlog.

As I knew these issues well and I knew what the solutions should be, I felt like this was a solid test if using AI would be an overall improvement to my productivity in any way. Gather’s engineering AI tool stack was:

Devin - An AI agent in the cloud that has it’s own virtual computer to work and build projects in using prompts.
Cursor - A code editor with AI powered autocompletes and agent mode for prompt based code generation.
Claude Code - An AI agent for prompt based code generation on your local projects.
Grapevine - Our own internal “ChatGPT” that’s been trained on our knowledge sources in Notion, Slack, GitHub, etc.

Devin was the tool I settled on because it uses own virtual computer and workspace so it meant it could “work” alongside me while I was working on other tasks. It wouldn’t change or interfere with my local workspace in any way.

It did okay at first. It would create a GitHub PR and our bots would leave feedback, but I had to keep sending that feedback back to Devin to make adjustments. Other times it would generate a PR with a solution that was incorrect or not what I had in mind, and I would have to instruct it to backtrack, give it the direction I wanted, and repeat the process.

It required too much interaction with me in the loop to get to a reasonable result instead of the holy grail of being completely hands off.

I didn’t care about how fast it could generate code, but how fast could I produce deliverables that impacts our users. Having me switch problem context between my main tasks and these Devin tasks was slowing me down rather than helping me deliver this value.

The Turning Point: Playbooks and “One-Shot” Workflows

That’s when I discovered we actually had “playbooks” already added to our account that weren’t being actively used by us today. (This was a leftover from our previous AI products team. Read more.)

A playbook (which is Devin’s equivalent of Claude Skills) is a mix between a knowledge base and a boilerplate prompt. It gives the agent a repeatable framework or high-level approach on exactly how to deal with the task it’s been given.

In our case, the playbook splits the workflow into multiple phases. The first phase is research and classification, where the agent investigates the codebase and proposes a plan for me to approve or tweak. Once the plan is approved, it moves onto implementation, does an internal code review and submits a PR to GitHub.

Crucially, the playbook instructs the agent to keep an eye on CI tasks and automated tests. If any of those fail, or if a review bot (or even another engineer) leaves feedback, the agent handles it automatically.

So I tried another ticket, but this time I attached a playbook. The difference was night and day. It managed the full loop, and after a couple of hours, pinged me to say, “I’m done, ready for your human review.”

I no longer had to be involved in the iteration loops at all and this is where I truly felt like a task could be fully handed off to an agent. I could give it a ticket, go off and do my deep work, and whenever I had a clear gap, be it a few hours or a few days, I could come back in to prompt for changes, review the PR and/or pull it down to test locally.

And because the playbooks are reusable from task to task, the input I need to give the AI is minimal. I just give it the task and tell it to use the playbook instead of having to re-prompt the guidelines on how to approach the problem, how to deal with our tool stack, or how to handle the automated feedback loop every time.

The knowledge base aspect of the playbook also ensures the agent follows our specific engineering patterns. It explicitly tells the agent: “This is the specific way we do things. You must run the lint and prettier tasks via these commands.” It provides guidelines on where to look for patterns we use, and just as importantly, examples of what not to do.

We also have a team culture that embraces these tools. If a session produces something worth repeating - a useful approach, a pattern that worked well - you can ask the agent to turn that session into a new skill. It will output it directly into your shared collection, ready to be reused by anyone on the team in future tasks. The playbook and skill library essentially grows itself.

The Parallel Workflow: Compartmentalising AI

I found that the real power of these tools wasn’t just in what or how fast they could generate, but in the impact on how I can structure my work and started treating agents as a parallel workflow.

As Devin operates in a remote computer, I could easily compartmentalise tasks. I have Devin start working on a few small tasks in the background including planning and suggested solutions while I stayed fully focused on a major task on my main computer.

This was the turning point for me to adopt AI more into my workflows. The ability to offload small, clearly scoped pieces or work or chores, without the friction of constantly context switching my own workspace, is where I found the real value.

A good example is a recent week where I was heavily focused on our payment system. Because the payment system is essential to the business and we can’t afford for it to be wrong, this work required my full focus as much as possible. I had to ensure I understood every edge case so we could be confident when it shipped since it directly affects revenue.

While I was deep in that work, I had a backlog of low-priority tech debt piling up included adding confetti to the virtual office and the need for a licensed tool to generate the image files needed for some art instead of a command line tool everyone can access.

I gave Devin the spec for this tasks and features, along with examples of how other games and projects had solved similar problems. It asked me a few clarifying questions, and then I let it go off and work in the background. It didn’t matter how long it took, because I was only going to check on it when I hit a natural breakpoint in my payment system work.

That is what my week generally looks like now: one very deep, high-focus task running on my local machine, with a few bits of tech debt clearance running in parallel via an agent in the background.

What Makes a Task Suitable for Parallel Workflows?

To make this parallel workflow actually useful, a task needs to meet two main criteria:

I must know the relevant area of the codebase well enough. I have to be comfortable reviewing the code output and fully understanding it when it comes back. If I don’t know the system, I don’t have the confidence to review the PR and own the output.
There must be a very clear definition of done. The task needs to have a concrete expected output and a straightforward way to verify it.

If a task requires constant iteration or experimentation to see what works, it is a bad fit for an autonomous agent.

For example, we had a task recently where we needed to add a warning when a user deletes a chat channel (stating that all related data will also be deleted). I ended up doing that manually because I didn’t know exactly how I wanted it to look until I saw it on screen.

Initially, I thought it would just be a bit of text, but that didn’t stand out enough. So I changed it to a box-out with an exclamation mark. That still wasn’t quite right, so I had to tweak the colours further. Because we don’t yet have a clear playbook for UI iteration, and because the task required visual experimentation rather than a strict logical output, handing it to Devin would have been frustrating and slow.

The confetti script on the other hand, perfectly met the criteria for a parallel task. I knew the area well, I knew exactly what the output should look like, and it was easily testable. Even though the final output was visual but everything prior to that was systems work, making it perfect for a Devin task. If it worked, great. If it was close, I could ask Devin to revise it. If it was completely wrong, I could reject the code entirely.

In the end, Devin managed to nail everything but the final visual implementation of how the confetti looked, and that required me to manually iterate on it before I was happy to ship it into production.

Throwing Confetti in Gather 🎉

The Hidden Costs: Mental Bandwidth and Team Capacity

So, am I actually “faster”? That’s the tough part to measure. I definitely feel more productive, and I’m definitely shipping more PRs by splitting my workload this way.

However, there is a flip side that rarely gets talked about: team capacity.

It’s fine being able to spit out so many PRs and generate so much code, but this code still needs to be reviewed. Our system relies on having one person who hasn’t been involved in the code (or the prompt generation) review the PR before it gets merged to main.

My review process for AI-generated code is exactly the same as it would be for a human contributor. If the solution isn’t immediately understandable, or if it overreaches its scope, I challenge it. If it still doesn’t make sense, I completely reject the PR and start again, either by taking over the task myself or using a different tool. I never submit code for a human PR review unless I fully understand it.

In terms of velocity as a company, we have to consider our team’s mental capacity to not only write features but also review them. If I had a whole team of “me’s” doing the same thing, would we have enough capacity to review all the output? Honestly, I’m not entirely sure.

What Needs to Be in Place Before This Works?

I’m actually still trying to find the definitive answer to this.

My current theory is that a major reason this parallel workflow succeeds for me at work is because we have a large, well-managed codebase. The code quality is high, and the standard of quality has been maintained throughout the years. This means the agents have excellent data to work from. When Devin generates code, it’s pattern-matching against a clean, consistent source rather than pulling fragmented examples from the internet.

The frontier models certainly help, and the tools built around them are getting better, but my gut feeling-based on my own experience and anecdotal conversations with other developers-is that the underlying quality of the codebase matters immensely.

The part I’m trying to figure out now is what happens when you don’t have that foundation. If you start from a new codebase, or a messy one, what do you need to put in place for these agents to work well? That’s something I’m currently testing myself on a personal project, and I’m hoping to get a better understanding of it soon.

In the End…

Is the 100x or 10x developer actually true? Honestly, I don’t think so. It’s not about the speed of work; it’s about the speed of deliverables that actually reach our users.

I want to understand why my experience at work has been so different from developers who are experimenting and struggling to get satisfactory results. What is needed to bridge the gap here?

Asking whether a candidate is cheating with AI is the wrong question

2023-01-14T00:00:00+00:00

Original article: “Why You Need a Company-Wide Point of View on Candidate Cheating”

Asking whether a candidate is cheating with AI fails to address the real issues that companies have.

If interview questions can be easily answered by AI, what are we truly assessing? In the realm of Software Engineering, existing resources like ‘Cracking the Coding Interview’ and Interview Cake already equip candidates for FANG-style interview loops.

Companies need to reassess their interview process and rethink what information they truly want to uncover about a candidate. Adjusting the process can better unveil crucial insights.

Some of the most effective technical interviews I’ve experienced as a candidate involved engaging in mini projects beyond scoped, leetcode style questions.

Whether with existing code or APIs, these projects allowed me to showcase problem-solving approaches, planning ability, communication skills, and even provided a glimpse of what collaboration with me would be like.

Let’s shift our focus and enhance the hiring process by evaluating candidates without imposing artificial restrictions.

A better Fantasy Premier League table

2020-12-30T00:00:00+00:00

Me and a bunch of friends have a tradition of playing Fantasy Premier League (FPL) every season with the top 2 would get treated to dinner at the end of season social. Usually involves of fun, competitive banter in our WhatsApp group on the weekends. 😄

(TL;DR on the FPL: A management game where each user has to create a team of football players in the Premier League within a limited budget. As the players do well, they accrue points on the users’ teams that they are on.)

We use the official web app at fantasy.premierleague.com and it suffers from one major issue: we only know how well we’ve done relative to the other users at the end of the match day.

I assume this is for performance reasons given the sheer number of users and tables that they have.

Throughout the match days, to see how everyone is progressing in terms of points, we used to have keep a mental note on how many points every one got. This involved constantly going to the table page, clicking on each user, seeing how many points they got this week, etc.

Working out who captained whom and what football players each user got was also a huge pain.

This was very tedious and killed some of the flow and banter in our WhatsApp group. 😞

Then the thought occurred to me.

“Surely, I could make our own page that would live update the table throughout the day? How hard could it be? 🤔”

R & D

I started to look at how the official FPL page retrieved the data via Chrome Devtools and saw that there were a number of REST API calls being made.

Digging into the response by these APIs, they all return JSON and with relational data sets.

For example, here is the response from entry/2154506/event/16/picks

As the API URL name suggests, it returns the team player picks for a particular user and gameweek including the cost of player transfers, points accrued prior to this game week, captain and vice captain choice, etc.

The football players are identified by ‘element id’ which is related to the player data set from the API bootstrap-static. This has information such as the player’s name, their injury status and which team they are on.

After some trial and error, I’d managed to work out how which APIs I could access without needing user authorisation:

entry/{user-id} - Information about a user such as their name
entry/{user-id}/event/{gameweek}/picks - A user’s team player picks
bootstrap-static - Information about players and teams
event/{gameweek}/live - The current stats of the player such as how many points they have accrued this gameweek
entry/{user-id}/history - History of a user and needed to get last gameweek’s scores

The league page used to not need authorisation which allowed to retrieve all the user IDs from a single league ID but that was changed last year. I now hard code the user IDs for our league into the webpage which is fine as the page is specifically for us.

Minimal Shippable

The first minimal shippable looked like this:

The user order is updated throughout the match days and username has a link to their team on official FPL site.

The high level logic was:

Get every user’s total points from the prior weeks
Get every user’s team picks for the current game week
Calculate the points for each football player accrued so far this gameweek
Apply an point modifiers such as captain choices, chips, transfers, etc
Calculate the current score for each user
Sort all users into a table

With the minimal version working and fulfilling our main point of frustration with the official FPL site, I excitedly uploaded the page to my website host, only to be faced with this error:

🤦‍♂️ It makes sense for there to be a CORS policy in policy as they would want prevent abuse from webpages like mine spamming their servers.

However, there was still hope as the API was shown to be accessible if I just entered the API address to the browser or use CURL on the commandline. Although I had made the decision earlier to not use a server due to cost, I decided to see if a Node.js server was able to access the APIs.

I did this via Glitch as I was still very new to Web Development at the time and had little exposure to the Node and NPM ecosystem.

Glitch is a fantastic free service where users can host Node.js applications for free and starts/stops instances based on their usage. It also provides an online editor which meant I didn’t have to setup my own local instance.

After fumbling my way around setting up my own REST API with the express module and accessing the FPL’s API using the request module, I was able to access the FPL’s API without CORS errors and also be able retrieve that information from my web page.

I effectively created an API ‘relay’ where all the Node.js server did was forward the data from the FPL’s API as is back to the webpage of my custom league table.

Now we are back in business! 🎉

This did come with the major drawback of having to wait for the Glitch services to start a new instance when someone accessed the webpage, but this was more than enough for now.

Feature Development

After I posted the link to the WhatsApp group, it wasn’t long before I started to get feature requests. 😅

Over several seasons (I have kids, free time is a luxury!), I started to add/remove/improve features to the page, including:

Showing captain and vice captain choices
Listing the whole team
Separating the points awarded in the week from the transfer costs
The number of players that have played so far in the game week
What chip was played (if any)
Showing differentials (football players not commonly chosen by the league)
Button to quickly update the points
Bonus point ‘predication’

Minimal and detailed view

Now it is possible to get almost all the information we needed on a single page, without needing to navigate across several pages. 👍

Keeping the design and layout simple was a conscious decision, with the use of font weight, colour and size for emphasis.

The important elements of information on the page are bigger and darker, such as the username and total score. Even when there is a lot of information on the page, the name of the users and total score still standout.

Details like the team picks are in a smaller font but the names of the football players, points and captain choice are in a darker colour so they are easier to pick out at a glance.

Future planned improvements will include:

Auto substitution
User rank changes
Use/Find an 24/7 Node.js server
Speed up the time it takes to make a process all the REST API calls

Closing out

This is one of my favourite side projects to work on, although it is not a large project nor my best code, it solves a problem that me and my friends have. That in itself is hugely rewarding, especially when I see them use it too in the WhatsApp group!

Enjoyed this blog post? Let me know what you think on Twitter @yaustar! 👋

Lessons learned from 10 years in the Games Industry

2019-03-26T00:00:00+00:00

I was thinking the other day that I wish I had learned before my first job in the games industry.

Surprisingly, most of it was from working as part of a team, rather than specific areas of knowledge. Although there had been group projects during my time at university, there wasn’t much guidance about how to effectively run them or what to expect when working as part of a team.

Below are what I consider to be important lessons during my career as a games programmer.

Keep the team moving forward

During my time at EA when I was still a junior, there was a huge amount of effort ensuring that the team (which varied from 50-100 people in size) was always able to move forward and not be blocked from working on the game.

The core principles were:

Everyone is able to test their work locally and quickly.
Everyone is able to run the game at any given time and on any platform.
The game should not break, even when given bad data and all errors should be made clear to the user.
All work should be tested locally before being given to the rest of the team (e.g. through version control or builds).
Be aware of the potential impact of your work to the team and talk to them about it, especially if you are not sure.
Finding bottlenecks and issues (e.g in workflows, processes, performance drops) and raise awareness to help find a solution as a team.

Baby steps and iteration cycles

I was introduced to the concept of ‘baby steps’ at EA by my lead/mentor during my time there and it has pretty governed my approach to work since then.

At its core, it’s designing through iterative prototyping and follow these rules:

Work one small step at a time. Start with the core mechanics or the largest unknown (e.g. a control scheme) and work outwards to build up the game or feature. Move onto the next step once you have ‘finished’ or have answered the unknown.
Don’t be afraid to quickly hack something together if you want to see if something works. Feedback from something that people can play is much more important than the implementation being ‘right’. It can always be tidied once it has been proven.
Let the feedback help drive the design. Although there would be a goal or design in mind at the start, keep it as an iterative process and review/change the design regularly based on feedback from the build.

Everything is done for a reason

E.T. on the Atari 2600. Why was it the 'worst game ever made'?

Every past piece of work or decision that is done or made would have been for a reason at the time. That reason may have been ‘wrong’ or no longer valid but it will exist. I found that identifying that reasoning helps with finding common ground when looking to move forward.

This may sound obvious but it is so easy to forget, especially when encountered in the middle of current work and stuff just needs to get done.

“This is dumb”, “Why is it done this way” and “This is wrong” have been said more than once by myself. Once I got into that mindset, I would start to get fixated on proving that it was ‘wrong’, potentially even trying to fix it than working on the actual task I was meant to be doing.

Once I started the mindset of find the reason or context of code via curiosity rather than irritation, it was a much smoother experience. It would often give me a common point of understanding and appreciate the decisions and/or context, which usually lead to better and more complete work from myself.

A great example is E.T on the Atari 2600. It has and still is being branded the worst game in video game history. However, once you read about the how and why the game was developed, the game mechanics that were implemented and the very short time frame that the developer had, it becomes a lot harder to call it a ‘failure’.

Another developer has since taken the game and fixed some of the gameplay issues and bugs present; it has become a lot more playable.

You don’t have to know everything

With an increasing number of different engines, languages, tools, etc. to help make games, it is almost impossible to know them all from the very start and nor is it expected.

Most of the time, companies are very understanding of this and will allow some flexibility as long as you have an understanding of the fundamentals, an awareness of the other possibilities and a willingness to learn.

For some of my previous roles, I outright didn’t know the main programming language or the tool that they were using but managed to demonstrate my core knowledge and previous experience in some way.

One in particular, I passed an on-site programming test in a language I had not used before with the use of the internet to check the syntax. This was largely due to working with similar languages either in previous roles or in my spare time. They knew that it was the first time I used this language and were willing to train me on some of the nuances on the job.

I usually try to emphasise more the ‘why’ than the ‘how’ when I explain solutions to problems I get asked for this reason. The ‘whys’ are more likely to cross over to other technologies than explicit code snippets or tool specific techniques with explanation.

The user isn’t you

There’s a good chance that if you have implemented a feature, UX, UI, game mechanic, tutorial or even a how-to document, it most likely only been tested along the ‘happy path’, the path that you expected it to be used or played.

As soon as it is put into somebody else’s hands, it’s common for them to do something that you hadn’t expected someone to do. E.g. Go backwards on the race track, use two fingers on the touch screen or simply not understand what’s going on.

And this is simply because the user isn’t you. They have no idea on what the requirements were or how it should be used or played.

Anticipating the unexpected path is something that gets better with practice, but nothing beats just simply putting it in the hands of someone else or discussing the problem and proposed solution with them. They could be a co-worker or just someone random. One team even went to a local pub and brought drinks for those that would help try their game.

Use emojis and images for tone and context

Team communication can be difficult, especially as teams get bigger and/or are distributed in different locations. Communicating via text with emails, wikis, bug reports and instant messengers have become the norm.

Unfortunately, it’s very difficult to convey nuance and tone over plain text. It’s all too easy to read something in a different way to how the writer intended it and completely misunderstand.

Emojis can help a lot with tone and inject some personality.

Consider the following:

“What is it with you and Steven using long words that no-one understands?!”

“What is it with you and Steven using long words that no-one understands?! 🤣”

One could easily be taken as criticism and the other would more likely be seen as friendly banter.

A picture is worth a thousand words and GIFs, even more so. I’ve seen people trying to talk to each other on instant messaging without realising they have a different screen in mind.

An image as the first message of a conversation helps so much in establishing the context.

If all else fails and a text conversation feels like you are talking past each other, try to get on a call with them or have a face to face chat. I’ve found that most of the time, this clears up misconceptions in record time.

Wrapup

I really would like to expand on some of these in detail of some of these lessons in a future post. There are lots of juicy details and examples that I would like to share.

If you have any lessons of your own, please share them with me on twitter @yaustar. I would love to hear them!

How I live streamed on Twitch with my 1Mb home connection

2018-08-16T00:00:00+01:00

I previously wrote an article series about my game development live streaming adventures but omitted my first hurdle in starting.

Problem:

I had a connection of only 1Mb up and Twitch recommends 3-6Mb for a 720p or 1080p stream broadcast 😱.

Solution:

Well, that took a little while to find 😅.

Getting a faster connection would be simplest solution but neither fibre or cable was available to our building. 4G home connection was next on my list but was not viable either due to coverage and/or usage caps.

Moving home was too extreme for a potentially short experiment. Renting a flat or private office was too expensive. Hot desking was cheaper but not practical as I would be talking most of the time and that wouldn’t go down well in a shared environment.

I did wonder about borrowing a friend’s place but unfortunately didn’t know anyone close enough within a sensible commute.

🤔

With the obvious ideas out of running, I started to wonder about feasibility of it all.

After a few more weeks of pondering, Googling and more crazy ideas (this included having multiple phone lines and bonding them to create one faster line), came the epiphany.

Realising that I was able to watch full HD videos on my connection and my measly 1Mb upload was just about capable of Skype/WhatsApp/Facebook video calls, I should be able to ‘stream’/remote desktop to myself while video calling back.

This would allow me to have the benefit of the bandwidth of where the PC was and be able to stay in the comfort of my own home for the broadcast!

Cloud Gaming providers OnLive and Gaikai have already proven this would work (with some latency) so the theory was sound, I just need to find a way to replicate this for games development environment.

Remember these folks?

Without the restriction of needing a private space for streaming, I was able to use the local co-working space and rent a corner for a headless PC for about the cost of a broadband connection.

Now I had to work out what software setup was needed to actually make this work.

Bear in mind that this was in 2016 so some of the solutions available today weren’t around back then (more on that later).

I ran through all the mainstream remote desktop software that I could find and they all suffered from one or more of the following issues:

Not all keyboard shortcuts worked from my Mac client to the remote Windows host (e.g. Ctrl + Space to bring up intellisense wouldn’t work)
Costs money for a commercial license
The framerate was too low to do any realtime editing such as 3D modelling

Eventually, I found NoMachine which could capture the mouse and keyboard input completely, was free and supposedly fast enough to play games with.

NoMachine remote desktop

The local LAN tests worked really well. I was surprised that I could play a First Person Shooter game like Counter Strike without too much trouble. Working in an IDE and the Unity3D editor remote was fantastic. There were some compression artifacts on full screen changes, but not enough to make unusable.

However, as with anything, there was a catch.

NoMachine required (and still does) a direct connection so for it to work across the internet, the host’s router needs port forwarding to be configured and the WAN IP address to Internet to be known.

As I was renting space in a co-working office, configuring the router wasn’t an option.

(This was starting to be a gift that keeps on giving… 😒)

Knowing that I had to use NoMachine, I looked for to see if this was a solvable problem. This wasn’t something I’ve come across before and it took me a while to narrow down the search terms to find relevant results.

Turns out that I needed the PC to ‘phone home’ in some way and setup a network tunnel (known as ‘reverse tunnelling’) or have a known server that both the client and host could connect to.

Top of my list of services to try were:

ngrok - exposes a port on the local machine via an URL
Hamachi - Mesh VPN service

Both were free to use and easy to setup on Windows and MacOS. There were several others but they were primary geared towards Linux.

While they both worked, unfortunately they shared the same problem. A server in the middle was used to route traffic through and for both services, it was located in the US.

This led to large latency times that when typing, I would be a character or two behind which led to typos and having to mentally cater delayed visual feedback of what I was doing.

On the bright side, this did lead me down the path that a local VPN service would work and luckily, my home ASUS router had this feature built in.

Enabled the feature, created a few accounts (both the client and host had to connect) and amazingly, it was working as well as it could be with minimal latency.

My home Internet connection didn’t have a static IP address but this was solved using a free dynamic service like noip.com that would continuously update the DNS of an URL to my IP address.

🎉🎉🎉

Finally, there was some light at the end of the tunnel. I could now stream at full HD while being physically at home on a slow connection. How awesome was that? Even I was surprised by this!

All that was left were some finishing touches to complete the streaming experience and some housekeeping for managing the remote PC.

I used Skype to ‘forward’ my webcam and voice to the remote PC by calling myself. I’d set the account to auto accept calls from my primary account to streamline the setup process. The only fault would be that the video would occasionally drop but solved by a quick recall.

For the first week or so, I would walk over to the co-working space to turn the PC before each stream. As you could imagine, I got bored of this pretty quickly and was looking for ways to be able to flip the switch remote.

Yep, these exist!

The search brought up products like smart home button pushers or home solutions such as using a Raspberry Pi as the switch itself to close the circuit via the GPIO pins.

In the end, I enabled WakeOnLan on the PC and used an always on Raspberry Pi connected to the same network. I logged into the Pi using SSH via VPN and used it to send a magic packet to wake the PC.

Perfect!

🎊

The final concern was from a security point of view. As the PC was going to be left in a hot desking, shared space, I was worried that someone could just simply pick up the PC and leave.

As I didn’t want someone to easily game access to my home network, I didn’t store the home VPN credentials on the device.

I ended up using Hamachi Mesh VPN for both the Pi and on startup of the PC. This allowed me to have an extra layer of security, so that if either the Pi or PC was stolen, I could just remove the accounts that they use from the VPN group.

Once the PC was started, I could then remote in and connect to the home VPN for better latency. It’s an extra step during the stream startup process but the peace of mind is worth it.

And finally, I was done! I had a setup where I could stream and manage the PC remotely and even better, no one was the wiser when viewing the stream.

These days, it is now a lot easier to create a similar setup. Parsec now provides a similar remote desktop experience to NoMachine but doesn’t need a direct connection so the home VPN setup is no longer needed and reduces the complexity.

"Simple, low-latency game streaming" that also does desktop applications!

The two major downsides are that it doesn’t capture the keyboard input completely but it comes close enough that I’m now using it over NoMachine when possible.

The second is that it isn’t installed as a service unlike TeamViewer or NoMachine. This means that unless it is running on an account that it is logged in, the PC is not accessible.

On top of this, you can now rent a decent spec gaming PC in the cloud to remote desktop into which would have solved my need for the co-working space.

Thankfully, I have since moved house to somewhere that has a much faster connection that I wouldn’t have to go through this again if I took up streaming again.

So as happy as I was to persevere and find a solution to all of this, I’m much happier knowing that I can now just stream at flip of a switch 😁.

Learnings from streaming Games Development on Twitch.tv

2017-03-17T21:38:45+00:00

Preface

Between May and July 2016, I was live streaming games development on Twitch to see if it was possible to generate enough revenue to sustain continuous game development.

I wanted to break out of the hit driven loop of games development and reduce the financial risk which traditionally came with it. This post is talks more about my thinkings, research and the outcome of this experiment.

If you want to know more about the actual hardware and software stream setup, check out my previous posts:

Part 1 (Hardware)
Part 2 (Sofware)
Part 3 (Learnings) - This article

Introduction

I’ve been working in games for almost 10 years now, developing AAA games, slot machines, Facebook and free to play (F2P). It got to the point where I was burning myself out professionally working for large companies, getting agitated with procedures and decisions that I couldn’t change and really needed a break from it all.

Once my project was finished at King, I handed in my notice and started to really think about a question that has been on my mind for some time: What’s after F2P?

It’s not that I think F2P as a concept is bad as a whole, it’s more that the majority of implementations have treated the player experience more like retail rather than games.

A typical F2P game is usually crafted and implemented towards encouraging the player to buy items, usually to help progression and/or remove waiting time. I.e to remove friction. Developers try to leverage any opportunity to encourage users to convert ‘free’ users into buying something. Research is shown that once they have made that initially purchase, they are more likely to continue spending in the future.

This is done to compensate the game being free and as a result, only 1.9% of users spending real money, averaging $24.66 per month according to Swrve’s Mobile Monetisation 2016 Report.

Nintendo only saw a 3% conversion rate from free to paid in Super Mario Run over the first 2 weeks of launch.

Mobile users now have an expectation that apps (especially games) should be free which makes it difficult to not consider F2P in some form or risk losing potential revenue and users.

I wanted to find out if there was another way for games to generate revenue and also retain the low barrier to entry of F2P.

Thinking outside the Box

Games development is ultimately a debt first process. They take time and/or money to create and until they reach a playable, presentable state, crowd funding, early access and publishers are not an option.

It’s not even guaranteed that the game will earn back the cost of development. In a lot of ways, it’s a gamble and there are only so many bets that can be made before running out of time and money.

A lot of the work in running an independent games studio is managing these bets and keeping a consistent cash flow. Companies such as Rovio, King, Space Ape, Supercell and Introversion all have stories on how managing cashflow and new titles.

While I was brainstorming what I could do to minimise or mitigate the risk, Twitch.tv have started to focus on live streaming non-games such as cooking, art, music and more relevantly, games development and programming.

I knew that games streamers has become very popular with a quite a few making significant money much in the same way YouTubers have. However at the time, I couldn’t imagine watching people developing games live has the same appeal.

Yet it looked like it be an interesting way to solve the debt first issue mentioned above. What if the development process could be used to provide entrainment value and viewers could donate and/or subscribe to the channel?

Doing the Research

The possibility was enough to investigate further on what was possible and look into the current state of streaming games development.

Prior to Twitch, LiveCoding.tv (now LiveEdu.tv) started in 2014 and positioned themselves as dedicated site for people to stream themselves coding. I remember visiting the site around the time it first started and not really understanding the point.

At the time, there was no revenue stream available beyond donations and the number of viewers was very low.

Fast forward to March 2016 when I started following a few streams on Twitch, some of the more popular game development streamers on Twitch average between 50-100 viewers per stream. Still relatively small in streamer terms (at time of writing imaqtpie has over 18,000 viewers on his stream) but encouraging as at time of writing, those streams have increased their average viewer count to 100-200.

The number of streamers in game development was and still is very low compared to the games section. This meant that even if someone started now, the potential of being noticed by potential viewers is still high.

What really surprised me was the viewers ‘paying’ for content. During one of HardlyDifficult’s streams, he managed to receive between $100-200 in donations during a 2GB upload to a git repo.

HardlyDifficult Twitch stream

At the time, I couldn’t understand why viewers were donating to watch someone watch a loading bar. It just didn’t make any sense.

One donation managed to trigger a series of others wanting to join in, regardless of what was happening on stream and just left bewildered and hopeful at the same time.

If viewers were willing to part with money for a git upload, then what would happen when there is actual work being done?

What I naively didn’t realise at the time and only a lot later in my own experience, those donations are ‘thanks’ for value of the stream so far. It usually has little to do with with the content that is being shown at the time of the donation.

There are also more revenue streams available beyond donations including subscriptions and ad revenue share. Twitch also continue to look for more ways viewers can support their favourite streamers. The most recent being ‘Cheering’, donations using Twitch’s virtual currency of ‘Bits’.

Twitch Cheering

The caveat is that these revenue streams are only available to Twitch Partners where the criteria to become one is rather vague.

The key criteria listed is to have an established and growing audience. How big and how fast seems to be judged on a case by case basis. Although from what I have seen, all the live game development streams that become partnered consistently have 50+ viewers.

Coincidentally, a friend of mine (Danny Goodayle from Just a Pixel Studios) was also looking to stream development of his game on Twitch for motivation to finish something.

As I wasn’t in a position to start my own stream just yet so this gave me a great opportunity to observe how his channel world fare over time.

Watching Danny’s stream

Danny was fed up of starting small projects but never really finishing them. To help him break out of this, he set himself a 30 day challenge to create a playable version of his game that could be submitted to a Steam Greenlight like process to help further fund the development.

Around the end of the first week, one of his friends suggested to start a Twitch channel to help with keeping him on track as well as help with motivation.

He set a schedule to stream every weekday from 9am-5pm (a full working day) and as with any channel, it only started off with a few viewers looking for different content to watch. Over the 30 day period, this grew to between 30-50 concurrent viewers during each stream.

The game itself looked visually interesting and the genre choice of survival was popular niche. While a lot of the growth was organic within Twitch, there were several factors that helped viewers return to the channel on an almost daily basis:

Advanced features that are interesting to learn more about such as procedural level generation and networking
Speed of feature implementation
Viral images posted on imgur to drive traffic to the channel
Deadline countdown timer on stream overlay

The last factor was one of the most important as it provided a ‘story’ to the experience and helped build anticipation towards the end product. The viewer count increased at a higher rate as he got closer and closer towards the deadline and consequently, decreased in streams after the deadline had passed.

Story of a Nomad

Making Plan

I set myself a timeframe of 3 months, both to complete a game and to see if live streaming games developing would be worth pursuing further.

Running on the popularity of ‘Twitch Plays Pokemon’ and the support by Twitch themselves, I decided to create a Twitch Plays only game to capitalise on the popularity and for a potential angle to build a relationship for support or promotion with Twitch.

To make it different from the traditional s where the viewers are voting for a single player input in an existing game, I wanted to create a new game where every viewer has control of their own avatar.

Chat Wars

Taking the basic concept of Risk board game and Dice Wars where players move to occupy territory, I adapted it to work with the Twitch chat system so all players could move freely in the map during each round.

The team with the most players on the each area at the end of the round gains control of the island and the game winner is team with the most islands at the end.

I was also looking at popular YouTubers such as Casey Neistat, LinusTechTips, Austin Evans and Devin Graham to see how they sustain themselves outside of the YouTube revenue.

To help build trust with their viewers, LinusTechTips had uploaded a video that breaks down how they make money from their videos. These include:

Amazon affiliate links
Project sponsors
Pre-roll ads in the videos (both technology and non-technology related)
Event coverage
Branded merchandise

While sponsorship was common on games streams, I haven’t yet seen one for a development stream yet. I assume either the streamers hadn’t yet attempted to approach potential sponsors or that the viewership was too small for them to consider.

That said, it was something I wanted to attempt as it could really help provide a stable increase in the revenue with the right sponsors.

TL;DR, my plan was:

Build an audience developing a s game
Attempt to get in touch with Twitch to pitch them my game
Approach potential sponsors
Profit!

So, how did it go?

The whole experience was an incredible amount of fun but unfortunately didn’t go according to plan. I did manage to complete the game by the deadline and it was released to the world but didn’t meet the rest of my other targets:

Averaged 10 unique viewers per stream
0 sponsors
2 concurrent users playing the game when released
Donations £17 (GermGamesTV: £10.00, ericmuir123: £5.00, ThatRainMan: £1.00, Portrawr: £1.00)
WASD Code Keyboard donation from XForceP

As you can see, the numbers didn’t show that this was sustainable for the long run in terms of making a reasonable living.

Here are some of the observations I made:

Making a Twitch Plays only game

I got so wrapped up in the positive press from Twitch about s and the popularity from ‘s Pokemon’, I made the classic mistake of not checking if I have a player base.

About halfway to three quarters way into the project, I decided to check out the Twitch Plays Channel. It turns out there are only 300 or so players and 90% of them are playing the Pokemon stream.

Twitch Plays Section

This meant that there was a very low possibility that viewers would even see the game let alone play but as I was so far into the project, I couldn’t really stop as my current viewers were vested in the progression of the development already.

As the game could only be played via a Twitch stream, I couldn’t sell it either or have a WIP build for viewers to play. The latter was huge blow for me as it’s very hard to become interested in something you can only see the development of but can’t play yourself.

Additional revenue could potentially be gained by selling advertising space in the game stream but as you can see from the numbers above, the number of players never reached point where I could approach companies.

Streaming everyday increases your chance of viewership

I underestimated the importance of streaming every day. My streaming schedule was 3-4 times a week for 6 hours I don’t think that was enough.

If I kept a Mon-Fri schedule (potentially for less hours), the channel would be more likely to be picked up by new viewers if they knew it was going to be back the next day. I had a public streaming calendar but that’s an extra click away. The expectation from viewers is that streamers are there every day.

Building a ‘story’ for the channel

Unlike Danny’s stream, I had no public ‘story’ or theme to my channel for my viewers to emotionally invest in. Danny always made it quite clear that he wanted to force to make and release something by setting an arbitrary time limit.

I really should really have made my aims more transparent and open up part of my personal life to help build that connection.

Viewers want to contribute to the game

Some of the more popular streams such as HardlyDifficult and RobTheSwan expressed that their viewers could contribute to the game in terms of art, game mods, testing, server hosting or even code.

One of my regular viewers, Zalosath offered to help out with creating some of the sprites being used in the game which saved me quite a bit of time,

The chat is generally self sufficient

Unlike games streaming where there are natural breaks between rounds, it isn’t with development. Generally you are always working or thinking about something so it’s really hard to engage with the viewers on chat without breaking chain of thought.

Usually the viewers do a good job of managing themselves but occasionally you will get a new viewer that wants to know more about the project. At that point, it is worth stopping to answer them as the first impression is going to be the most memorable.

Streaming takes up more energy then you think

When I first started, I attempted to do a full working day’s worth of hours streaming (about 8). After doing this for a week, I realised this was too much as at work, you will take physical and mental breaks.

When streaming, I was fully focused on the work and that took a toll on me mentally. I found myself much more fatigued than expected, more so than after a day of work. Additionally, I didn’t factor the time needed outside of the stream to maintain Twitter, tweaking the overlay, etc so I was working 10 hours days for the first couple of weeks.

I almost instantly dropped the number of hours to something much more manageable and made sure that I took regular breaks during the session using Programmer’s Break Timer.

What would I change if I did this again?

Even though it was almost a year ago since I stopped, I always kept thinking about what would I have done differently if I consider game development streaming again.

Develop a game that I could sell

This is the big one. Now knowing that the stream itself wouldn’t generate as much revenue as I had hoped for before, I would now work on a game that I could either sell, contain IAPs or even was ad supported.

Having more potential revenue streams is always desirable and also creating a packaged product would give me a potential long tail.

Have the build available to be played by viewers

Similar to the point above, having a version of the game available to play by the viewers would help increase engagement and also give me quicker feedback loops.

Initially I was planning to use a Continuous Integration system such as Jenkins to make regular builds available for downloads or make accessible to paid viewers only.

However, since my last job at PlayCanvas, I’ve been impressed in the performance of HTML5 applications/games and also the accessibility it can provide.

Any game I develop for HTML5 could be played through virtually any browser on any device and on any OS. Viewers wouldn’t have to go through the friction of downloading and installing the game, it would just be available via a URL link.

With that in mind, my next game is likely to done with HTML5 as even if I didn’t want to make it a browser game, it can still be packaged as a standalone app with Electron and Cocoon.io.

Develop less ‘on screen’

This is a bit controversial as ideally, you would stream for as long as possible. Realistically, it’s very difficult to always be engaging with the viewers when trying to do deal with a difficult task and visa versa.

Two ways I can think of to tackle this:

Stream frequently but for less time (e.g 3 hours). Use other social channels like Twitter, Discord, SnapChat etc to provide intermittent updates during the rest of the day.
Stream the same hours but put aside some hours of the day as ‘quiet time’ where the focus is on the work and not the viewers.

Both of these would allow me to have time to myself to really focus on being productive and then I could use the time with the viewers to focus on design and/or more visual elements of the game.

Make my (business) plans more transparent to the viewers

Ideally, I would like to make my thoughts and plans as transparent as possible. There’s always interest in blogs like devMidgard’s and TrueValhalla’s where they break down their earnings each month and how they intend to move forward with their plans.

It’s rare to get this information but it’s incredibly useful to know from an independent/company owner perspective. Similar to how the video from LinusTechTips that I linked earlier is useful to anyone thinking on creating their own YouTube channel.

Ending note

If you managed to read this far, thank you! I hope this has given a bit of an insight on streamer’s side of Twitch and if you considering doing something like this yourself, save you from making the same mistakes I did.

My Twitch experience as a Live Games Developer — Part 2: Software Setup

2016-12-16T10:38:45+00:00

Introduction

During the summer, I wanted to experiment with live streaming games development to see if it could become a workable career path in the same way as live streaming playing games has become over the past few years.

On paper, it shouldn’t really work. Watching someone write code for hours at a time isn’t exactly the most exciting of prospects for a viewer and yet before I started this, some of the top game dev streamers on Twitch were averaging 50-100 concurrent viewers.

This wasn’t huge by any means but was promising as most of the viewers were engaged with the streamer or with the rest of chat. This contrasted the game playing streams with thousands of viewers who lurk or fill chat with emotes.

I wanted to see if it was possible to create a games development Twitch stream with enough viewers to generate a big enough revenue to become a full time job. Inspiration came from the Double Fine Adventure documentary series where the company created revenue documenting how they developed the game, which would normally be the byproduct of games development.

You can find my profile on Twitch, past broadcasts on YouTube and stream highlights.

Over the next month or so, I will be writing about the whole period over a series of posts covering different areas. These will include the hardware setup, the software/services used and my experience of being a live streamer alongside what I would change.

Part 1 (Hardware)
Part 2 (Software) - This article
Part 3 (Learnings)

Screen Capture

Open Broadcaster Software (OBS) is the default choice for anyone new to streaming or even to screen capture. It’s well supported, mature, extendable via plugins and completely free.

Usability is a bit rough around the edges but is more then enough for someone to get started with. The popularity of the tool also means that there are plenty of guides and help on Internet if you run into problems.

OBS now has two versions, OBS Classic (Windows only) and OBS Studio (cross platform).

OBS Studio development is still in progress as it has been rewritten from the ground up to enable further development of features and more importantly, multi-platform support.

I personally used OBS Classic as there was a specific plugin that I wanted to use (more on that later) as there wasn’t a feature advantage at the the time.

Some streamers have favoured XSplit over OBS for usability and they offer different subscriptions tiers for features, ranging from free to $4.17 a month at time of writing.

OBS settings

I use the following settings for OBS:

Base resolution at 1440 x 900 (16:10) at 30fps with no down scaling
QuickSync Encoder at default settings
Bitrate 1800 kb/s

OBS Settings

The alternative setup is to use the H.264 software encoder reportedly can produce same or better quality encoding at lower bitrates then either QuickSync or Nvidia NVENC at the cost of CPU usage. Ideally you need a hefty CPU like an Intel i7 or use a second dedicated PC purely for encoding.

Plugins

There are two plugins that I used throughout all my streams, CLR Browser plugin and OBS Remote.

CLR Browser is incredibly powerful as it allows you to place a browser window any where on your stream which opens up accessibility to use any web page including ones that are self developed.

In my case, I couldn’t find a simple clock plugin to show the local time. Using basic Javascript and HTML, I quickly put together a webpage which displayed the time using Javascript and used the CLR Browser to overlay it on the stream.

Overlay/Composition

OStream Overlay

I ended up spending too much time on overcomplicated overlay for my stream. The original idea was to keep new viewers on the stream long enough to find something of interest that they could engage in rather then channel jump to another stream.

My attempt was a scrolling ticker of RSS feeds that pulled headlines from related news sites such as Wired, GamesIndustry.biz and Gamasutra. I was hoping that during a quiet period in the stream such as when I was working through a problem, that the viewers would be able to pass some of the time reading the headlines. The idea was taken from the tickers on news programmes where they display general information over top of the current news story.

Unfortunately, I have had mixed feedback on it. A couple of viewers said that they found it interesting and others say it was a little distracting to the main content. I’m still on the fence about this as I do need something to keep the audience engaged while I’m in deep thought and currently thinking of other solutions.

Over time and from watching other streamers, I found that all I really needed was desktop capture, a face cam and chat on screen.

The actual content matters more and is something I completely overlooked when I prepared the channel. The time I spent creating the overlay should have been spent on preparing and creating great content.

Clock

The clock was a late addition to the overlay as I often was asked my local time. It was easier to say when I would be back from breaks as I could give a time rather than saying, ‘Be back in 10’.

As mentioned above in the overlay section, the clock is within Javascript code as a web page.

<!DOCTYPE html>
<html>
  <head>
    <script>
      function startTime() {
        var today = new Date();
        var h = today.getHours();
        var m = today.getMinutes();
        var s = today.getSeconds();
        h = checkTime(h);
        m = checkTime(m);
        document.getElementById('txt').innerHTML = h + ":" + m;
        var t = setTimeout(startTime, 500);
      }
      function checkTime(i) {
        if (i < 10) {i = "0" + i}; 
        return i;
      }
    </script>
    
    <style>
      body {
        background-color: rgba(0,0,0,0);
        color: #FFF;
      }
      
      div.clock { 
        font-size: 44px;
        font-family: tahoma, sans-serif;
        font-weight: bold;
      }
    </style> 
  </head>
  <body onload="startTime()">
    <div id="txt" class="clock"></div>
  </body>
</html>

Donation/Recent Followers Ticker

At the bottom of my overlay, I have scrolling text that shows my top donations, recent donations, recent followers and a custom message.

I was using Muxy as an all in one service that covered analytics, donations/tips page and on-stream alerts for follows, donations, etc.

(Twitch have added ‘Cheering’ which allows users to donate ‘bits’ since I last streamed which Muxy does not have an on-stream alert yet).

Muxy has a program that can be generate text files with different groups of information such as Follower Count, Top Tippers, All Tippers etc. These can be overlaid in the stream via a Text Source on OBS very easily.

As I wanted a single line of scrolling text, I had to write a Python program that took the contents of text files I wanted to use and copied it to a single line in a new text file. Once I had that, I could then use the file as a scrolling Text Source on the overlay in OBS.

from sys import argv
import time

while True:
  ticker_string = ""
  muxy_dir = "C:\\TwitchFolder\\Muxy\\"
  root_dir = "C:\\TwitchFolder\\"
  
  total_donations = open(muxy_dir + "total_donation_amount.txt")
  ticker_string += total_donations.read() + " | "
  total_donations.close()
  
  all_time_donators = open(muxy_dir + "all_time_top_cumulative_donors.txt")
  ticker_string += all_time_donators.read() + " | "
  all_time_donators.close()
  
  recent_donations = open(muxy_dir + "recent_donators.txt")
  ticker_string += recent_donations.read() + " | "
  recent_donations.close()
  
  recent_follows = open(muxy_dir + "recent_followers.txt")
  ticker_string += recent_follows.read() + " | "
  recent_follows.close()
  
  special_mentions = open(root_dir + "special_mentions.txt")
  ticker_string += special_mentions.read() + " | "
  special_mentions.close()
  
  ticker = open("MuxyTicker.txt", 'w')
  ticker.write(ticker_string)
  ticker.close();

  print(ticker_string);
  time.sleep(60)

Screen Size

Typically on Twitch, 1080p (30fps) and 720p (30fps) are the most common resolutions and framerates that are used as they are the most common monitor resolutions and console output. This is also due to limitations with residential broadband upload speeds for the streamer and download speeds for the viewer.

Sometimes streamers will drop the resolution to 720p when they do have bandwidth to cope to increase the framerate to 60fps for a smoother viewing experience.

I bucked the trend to use an unorthodox resolution of 1440 x 900 which is an unusual screen resolution since there is no monitor with this resolution.

I was considering I was watching game development streams and after talking to a few other viewers, most would put the stream on a second screen with the chat open while working on their own work.

Given the most common screen size is 1080p (although 1440p and 4K is becoming increasingly popular), after taking the chat and window toolbar into account, there isn’t a lot of screen estate left for the stream itself.

Since no-one would be watching the stream full screen, it seemed to be a waste to stream at 1080p 16:9 resolution so I started experimenting with different resolutions and aspect ratios.

I found that the 16:10 aspect ratio filled the screen space best and a 1440x900 resolution was low enough that there wouldn’t be too much scaling and I large enough for me to comfortably work in.

I found that the 16:10 aspect ratio with a resolution of 1440x900 filled the screen space within the browser best without being too small to work in.

Screen Size in Browser

Working with Audio

To help with managing the audio sources such as separating the music stream from the general desktop audio, VB-Cable really helped. It allowed me to control audio levels of within OBS rather then having to swap between different applications to adjust volume.

It’s really straightforward to use as when installed, it comes up as an output device and redirects to an input source that OBS can add.

Virtual Cables Output Device Setup

Virtual Cables OBS Input Device Setup

During test recordings of the stream, I saw that the audio was just slightly out of sync with the camera. This is a common issue with a lot a streams that I have seen but easily fixable by adding a small audio delay within OBS.

Adjusting the Microphone Audio Offset

Bots

I previously thought bots were essential so I spent a long time researching and setting one up. In practise, they were more problematic by timing out users with their default rulesets such as posting just a link or emotes.

With a small viewership, it is more than manageable to deal with users yourself and/or appoint a few moderators to help out. Twitch have also recently announced ‘AutoMod’ to prevent hurtful and troll like messages from reaching the chat at all.

That said, the one good use for bots for any viewership size, is the ability to assign custom commands such as ‘!software’ and ‘!design’ to deal with FAQs from the chat.

With time, the regular viewers will use those commands to help answer the new viewers’ questions as well.

The one I used was NightBot and it was really straightforward to use. Adding new commands was a breeze and it was hosted in the cloud which gave me one less headache to deal with.

It is thin on features though so if you need something more extensive, Moobot and Vivbot are popular alternatives.

Epic Pen

This was one of the best software tools I had for the stream as it allowed me to draw and highlight parts on my desktop like a virtual whiteboard.

It allowed me to describe and explain parts of my game design, high level logic, algorithms, etc much more effectively than without.

Best of all, it is free to use! It is Windows only but there is a paid Mac equivalent called Deskscribble that has similar features.

Programmer Break Timer

One of the toughest parts of streaming is remembering to take computer breaks. General guidance from Health and Safety Executive is to take 5-10 minute break for every 50-60 minutes of computer use. It is so easy to get caught up in the stream and not realise that you have been sitting and staring at the screen for hours.

I found this little tool, Programmer Break Timer which keeps me aware of time. It’s a simple tool that alerts you when a set time has passed which really helped me to take the necessary breaks away from the desk.

Programmer Break Timer

Chat Client

The default chat client in Twitch is fine as a casual viewer but can get unwieldy to use when using it as a broadcaster with dozens or hundreds of users.

This is where BetterTTV and Chatty can help.

BetterTTV is a browser extension that adds extra features on the existing Twitch Chat, most notable are:

Recent chat history on chat load
Desktop notifications when people send messages, mention you in chat and when channels you follow go live
Broadcast dashboard that prioritises chat and auto-updates channel statistics

Personally I prefer the standalone, cross platform client Chatty for two main reasons:

Displays when users enter and leave the chat
Clicking on any name in the chat shows all the messages they have posted so far in the session

Both are incredibly useful from a broadcaster’s perspective in engaging with multiple viewers. Knowing that I had the ability to backtrack through a conversion with a particular user during a session took off some mental strain and allowed me to focus on the stream.

View from Chatty

It is also worth noting that Twitch Chat is just IRC in the backend and it is possible to use any IRC chat client like the popular mIRC or Colloquy.

Background Music

There are three approaches that streamers take with background music:

No background music at all so the viewer is free to play their own
Use only copyright and/or royalty free music
Play anything regardless of copyright

There is an even split in opinion with streamers and viewers about playing background music with some saying it’s a distraction to both the viewer and streamer. Others find the silence during bouts of deep thought uncomfortable and prefer some ambience.

Personally, I’m in the latter and generally play non vocal tracks at a low volume. The lack of vocals make the music less distracting and the low volume ensure it is just ambience.

If you do choose to play music in the background and would like to keep or upload the broadcasts on sites like YouTube and Twitch, use music that you have permission to broadcast. If not, the sites will generally mute the areas of the video that it flags as copyright breach rendering the broadcast useless.

Brands and sites like No Copyright Sounds (NCS) are great to use as like the name says, they are free to use without limitations and are very popular with YouTubers as background music.

Twitch, realising this would be a problem that streamers would have, has a pre-cleared selection of music available to use on their site which is awesome.

Another record label, Outertone allowed use of their music, royalty free for YouTubers and streamers which is very generous. They have a wider range of music then NCS and I found having a mix of both in the same playlist gives a nice variance in the background.

My streaming playlist is publicly available for anyone to use on SoundCloud. Just be sure to turn on ‘shuffle’ as SoundCloud will play related tracks after it reaches the end of the playlist which does include copyrighted music.

Gif grabber

Everyone loves gifs! They work really well on social media for demoing your work and viewer engagement. There tools available are:

ScreenToGif - Available for Windows, feature rich allowing for captioning, clip trimming and more.
Giphy Capture - Available for Mac, features clip trimming and resizing.
LICEcap - Open source, available for both Mac and Windows, simple to use but lacks editing features.

During my time streaming, I was using LICEcap as I saw it being used by some of the streamers I watched. Since it was cross-platform and I work on both Mac and Windows, it didn’t occur to me to look for alternatives.

It was only recently that I found Giphy Capture and GifCam and the clip trimming feature is incredibly useful. It was really difficult to get the timing right with LICEcap and usually ended up with some extra frames at the beginning.

My next post will be the final in this series which will cover my original intentions, motivation and experience of being a streamer.

If you would like me to cover something specific, let me know below by tweeting me . See you in the next one!

Part 3 (Learnings)

My Twitch experience as a Live Games Developer — Part 1: Hardware Setup

2016-08-24T13:38:45+01:00

Introduction

Over the last few months, I wanted to experiment with live streaming games development to see if it could become a workable career path in the same way as live streaming playing games has become over the past few years.

You can find my profile on Twitch, past broadcasts on YouTube and stream highlights.

Over the next month or so, I will be writing about the whole period over a series of posts covering different areas starting with the hardware setup and later, the software/services used and my experience of being a live streamer itself.

Part 1 (Hardware) - This article
Part 2 (Software)
Part 3 (Learnings)

My desk layout

PC

The streaming PC with a gorgeous Phenom MATX Cube case

Being completely new to this, I had no idea what the minimum hardware was needed for streaming. Google gave varying results and most people wanted to stream playing games rather than development which has different requirements of the hardware.

My main concern was that my current PC build was very much on the low end. It was built for the living room as a Steam Machine and was looking for the cheapest way to get it ready for games development and to stream with.

(For reference, my PC spec was: Intel Core i3 4170 (Dual Core with Hyper Threading), 8 GB RAM, 256 GB SSD with a ATi 5870)

The two most common methods used by streamers are:

Nvidia NVENC supported card (Nvidia’s onboard video encoder)
Encode on the CPU using x264

As I have an ATi card, the first option was out and encoding on the CPU also wasn’t viable as games development can have all the cores of the CPU under full load during building of the game which will lead to frame drops/lower stream quality.

At this point, I was considering all the possible solutions including:

Upgrading to a Nvidia graphics card
Upgrading to an Intel Core i7
Buying a second PC to do the encoding
Buying a capture card with hardware encoding

All of which required me to spend money that I ideally wanted to be saving as none of these were particularly cheap. It wasn’t until a few weeks later of looking through eBay, Gumtree and the like that I found a solution that required no extra hardware.

Open Broadcaster Software (OBS), the most common software used to transcode and stream to Twitch, supported Intel’s Quick Sync. Quick Sync is hardware video encoding and decoding technology integrated on the on board graphics that is normally part of Intel’s i series of CPU. All I had to do to was enable the Integrated Graphics Processor (IGP) on the motherboard’s BIOS settings and select the Quick Sync option under ((check where this is on OBS)).

I was initially confused as the option in OBS was greyed out and it took me a while to think of looking in the BIOS settings where the IGP was disabled when I installed the graphics card.

Being able to use Quick Sync gave me several benefits as I no longer had to upgrade the PC specifically for streaming, there was no significant impact on the main hardware used for games development (the CPU and GPU) and the encoded stream quality was excellent.

Lighting and Camera

The masking tape may not look pretty but does the job holding stuff together!

I kept the lighting setup really simple, LED daylight desk lamp under the webcam with a diffuser in place for a general fill light and whatever lighting the room provides. Not perfect but good enough taking into account that little of the stream screen estate used for the face camera.

It also helps that the Logitech C920 webcam I choose had auto white balance and auto focus and coped incredibly well with a range of lighting conditions including low light.

This review from Laptop Mag is what really sold it to me with the comparison of image quality between the built in webcam and the C920 and it was definitely worth spending the little extra to save time and space dealing with multiple light sources.

The webcam is taped to a cheap mic boom arm from Amazon and positioned it at an angle so I’m not always looking at it straight on. It doesn’t look great from an aesthetics point of view, but it was cheap, stable and wasn’t visible to anyone watching the stream.

I found the off centre camera angle gave the viewers the feeling that they are sitting with me rather than directly in my face and personal space. It also allowed me to distinctly show on stream when I am concentrating something on screen and when attention is directed to the viewers.

View from the webcam

Chair and Desk / Ergonomics

My Humanscale Freedom Task office chair which I got on eBay for around £200

The desk and chair are the best and underrated non-tech investments in a setup that you could make especially if you spend a significant amount of time at the computer.

Given that I would be streaming for up to 8 hours a day, I had to ensure that my physical setup was as ergonomic as possible. I cannot stress how important this is for anyone that works at a desk and any discomfort should be looked at. It all builds up over the years leading to constant aches and pains so dealing with this early can reduce this a lot later down the line.

My existing setup was already pretty decent prior to streaming. I had an IKEA motorised standing desk, an ergonomic HumanScale Freedom Task chair (brought off eBay), Kensington Trackball and Grifiti Wrist Pad.

I previously used my computer a couple of hours at a time and it was only after a few days of full-time streaming (6-8hr sessions) that I realised I had neither configured my chair properly nor considered the distance to the screen, as I was frequently getting back and shoulder aches.

I found myself either straining my eyes at the screen or leaning forward with an elbow on desk which caused me to slouch my back.

Once I moved my chair, keyboard etc closer to the desk and screen, succumbed to the fact I was getting older and increased the font size by a couple of sizes, it was so much more comfortable to work and really wished I’d done it a lot sooner.

If you are looking at upgrading your desk setup, I strongly recommend getting a desk that is height adjustable (doesn’t have to be motorised or be a standing desk) as it makes the setup much more flexible to find the right height for you.

Chair-wise many people swore by certain brands and models such as HumanScale, Steelcase and Herman Miller Aeron, all of which are common at tech companies but are eye-wateringly expensive (upwards of £800) and out of range for the average consumer. However, they are usually readily available on eBay, Gumtree, etc at a quarter of the price, as offices tend to cycle through chairs and the older ones are sold/given to resellers or refurbishers. Wirecutter has a great guide to existing chairs on the market today.

Get your desk setup right and your body will thank you years down the line. There are also some exercises you can do to help you de-hunch and stretch out the back.

Headset and Microphone

Retro inspired AKG K240 with ModMic attachment

Headsets are more down to personal choice. I wanted comfort more than anything else as I would be wearing a set for hours at a time and ideally open back so I could hear myself speak and keep voice levels constant.

In the end, I purchased the Semi Open, Over Ear AKG K240 Studio as I quite liked the retro look and thought that the gold accents would stand out quite nicely on stream. I also replaced the ear pads with Brainwavz Hybrid Memory Foam Earpad for extra comfort.

Other sites such as Wirecutter, Trusted Reviews and What Hi Fi have good roundups for headsets at various budgets and form factors.

As for the mic, that was really difficult to decide on. Every video, article and roundup recommended the Blue Yeti with a shock mount. A couple of roundups also suggested Blue Snowball iCE as a cheaper alternative.

The Yeti reviews incredibly well from my research, boasting many features such as controls on the device, different recording patterns (Omnidirectional, Stereo, etc) and headphone monitor jack.

The problem was that they were very sensitive and had a huge range which normally is great but as my streaming setup is in the living room, I actually wanted something with a much shorter range.

I ended up buying the Unidirectional ModMic 4.0 after watching video reviews on Linus Tech Tips and Hardware Canucks. As far as I can tell, the audio quality isn’t as good as the Yeti but good enough for streaming as the voices are still clear, the range is shorter and it is also a fair bit cheaper. Just make sure you get a USB Sound Adaptor to get rid of the background hiss.

If I had a dedicated room or area for the stream, I would have gotten the Yeti, as it is more versatile as a recording device and the recording quality is noticeably better.

I’ve also seen a streamer use a Rock Band Mic that was placed in a mug with a t-shirt to act as shock mount and it worked surprisingly well in terms of audio quality.

Next Article…

The next article in the series will cover the software and services used for my streaming setup. In the meantime, you can check out my directory of other regular game development streamers where there are some very interesting projects going.

Or if you want to know anything more about my setup, please tweet me and I’m more then happy to answer!

Part 2 (Software)

Open Plan Offices are here to stay, so how do we make them more productive?

2016-06-09T10:38:45+01:00

Mention open plan to office workers and usually you get a few grumblings in return. Typically, these are about general noise or distractions around the office and have been the same complaints for almost as long as these type of offices have been around.

Below are some of the solutions I’ve either experienced or have implemented that really helped keep the team focused on the project.

(Disclaimer: This article is written from my experiences working in open plan offices as a games programmer over my career, so some of these suggestions may not be applicable to all offices. Feedback is welcome and I am really interested in how other workplaces have improved their environment).

Everyone should have the right equipment for the job

Although this is true for all office environments, in an open space, small everyday grumblings can spread quickly through the office become a bigger distraction. There is no ‘one size fits all’, so ensure that people have the right equipment that fits them rather having a standardised set.

This could involve getting different ergonomic chairs for everyone, properly spec’ed PCs/laptops/monitors specialised for the role or ensuring that people have suitable and comfortable headsets for the environment (wired/wireless/noise cancelling/etc). Given the many parts that make up someone’s workspace, it is may be easier to let them buy what they need and reimburse afterwards (at Basecamp, everyone has a company card for business expenses including equipment).

Have good amount of space between desks

Lack of privacy is one of the productivity’s biggest killers and the usual setup in offices is to cram as many people in one areas as possible. Not only does this increase ambient noise, it can feel claustrophobic having that many people around each other.

Spacing desks apart helps alleviate this feeling, reduces distractions and increases a sense of privacy.

Keep desks as far away from foot traffic as possible

Having a constant flow of people moving pass your desk can be incredibly distracting and can take you out of your zone.

Keep teams’ desk areas separate to minimise cross team disruption

There will be times where a team will be audibly and visibly busy (e.g servers have crashed and customers can no longer log onto their account), which is acceptable as it’s an issue that can involve the majority of the team.

The problem is if another team is nearby, they will be affected by an issue that is unrelated to the work that they do purely by location. By separating teams, either by space or a sound proof barrier, they are focused on their own tasks and they are also free to own their space around them without affecting other teams.

In the cases where space is at a premium, look for ways to muffle sound from or prevent it from travelling, such as tall plants, soft walls/barriers, audio isolation or high back office sofas (which can nicely double as phone booths for a quick call).

Provide a separate breakout area for each team

Every team will need at least one area (pending on the team size) where people can collaborate without disturbing the rest of team. To do this, it has to be separated from the main work area at least acoustically. This can be a large meeting room where there are sufficient facilities where users can bring in their laptops or remote desktop to their machine. This is to encourage spontaneous use of the area rather than a place that has to be set up deliberately.

Keep the environment of the office consistent

The environment of the office is one of the hardest areas to control as everyone has different preferences. The best that can be done is to to ensure that temperature and lighting is consistent throughout so there aren’t any cold/hot/dark/light spots throughout the office. If this cannot be done due to the existing building layout, then supply fans/heaters/lights to help compensate.

Trello has a great article with the extent that the environment can have on people’s productivity alongside other suggestions to help.

As an example of some of these ideas in practice, I have included an annotated photo of one of WeWork’s co-working spaces below (assuming those glass walls are sound proof). The only addition I would suggest is having the option of blinds for the offices for extra privacy.

One of WeWork’s Offices (annotations mine)

Ultimately, creating a good open office is about doing what you can to minimise distractions and give the teams room to focus on their work. If you have a suggestion or improved your own office in another way, please tweet me . I really would like to keep updating this article as a central resource to improving the everyday open office!

Steven Yau’s Blog

My Journey with LLMs and AI Agents: From Skeptic to Adopter

The Early Struggles: Too Much Human in the Loop

The Turning Point: Playbooks and “One-Shot” Workflows

The Parallel Workflow: Compartmentalising AI

What Makes a Task Suitable for Parallel Workflows?

The Hidden Costs: Mental Bandwidth and Team Capacity

What Needs to Be in Place Before This Works?

In the End…

Asking whether a candidate is cheating with AI is the wrong question

A better Fantasy Premier League table

R & D

Minimal Shippable

Feature Development

Closing out

Lessons learned from 10 years in the Games Industry

Keep the team moving forward

Baby steps and iteration cycles

Everything is done for a reason

You don’t have to know everything

The user isn’t you

Use emojis and images for tone and context

Wrapup

How I live streamed on Twitch with my 1Mb home connection

Problem:

Solution:

🤔

🎉🎉🎉

🎊

Learnings from streaming Games Development on Twitch.tv

Preface

Introduction

Thinking outside the Box

Doing the Research

Watching Danny’s stream

Making Plan

So, how did it go?

Making a Twitch Plays only game

Streaming everyday increases your chance of viewership

Building a ‘story’ for the channel

Viewers want to contribute to the game

The chat is generally self sufficient

Streaming takes up more energy then you think

What would I change if I did this again?

Develop a game that I could sell

Have the build available to be played by viewers

Develop less ‘on screen’

Make my (business) plans more transparent to the viewers

Ending note

My Twitch experience as a Live Games Developer — Part 2: Software Setup

Introduction

Screen Capture

OBS settings

Plugins

Overlay/Composition

Clock

Donation/Recent Followers Ticker

Screen Size

Working with Audio

Bots

Epic Pen

Programmer Break Timer

Chat Client

Background Music

Gif grabber

Next article

My Twitch experience as a Live Games Developer — Part 1: Hardware Setup

Introduction

PC

Lighting and Camera

Chair and Desk / Ergonomics

Headset and Microphone

Next Article…

Open Plan Offices are here to stay, so how do we make them more productive?

Everyone should have the right equipment for the job

Have good amount of space between desks

Keep desks as far away from foot traffic as possible

Keep teams’ desk areas separate to minimise cross team disruption

Provide a separate breakout area for each team

Keep the environment of the office consistent