[MUSIC].
>> William Furlong is a developer behind Keyboardkommander.
I'll show you a quick preview. This is the game here.
[MUSIC].
As you guys can see, that's a fast pace zombie type'em up game.
The game tells a story of a conspiracy theorist vindicated.
This was released as a Beta in November 21st, 2021.
It's also available for free if you guys want to check it out.
William managed to do this while having
a full time role at Microsoft.
He'll have some great information to
share to those of you who want
to be making games on the side of a full time job.
Story behind it. Let's bring him on.
We'll do a soundcheck and start
asking him some of those questions.
Let's start the call.
Hi, William. Thank you first of all,
for joining us today.
We're looking forward to hearing about your process
with Keyboardkommander.
Would you like to start off by telling us a little bit about
yourself and your game development journey?
>> Also, thanks so much for having me here today.
My name is William Furlong and I
work for Xbox on the developer experience tools.
I also make indie games in my free time,
including my game Keyboardkommander,
which is currently available in early access on Steam.
I work primarily in Unity with C-sharp.
>> Oh, thinks that's a great intro.
Sounds like you're involved in a lot
of different development areas, so that's really cool.
Let's start with Keyboardkommander.
First of all, where did you come up with the idea of
combining a typing game with a zombie game?
Did that come from something specific? It works really well.
As you can see, it's fast pace,
and interesting way to learn typing.
>> In terms of where I got the idea to combine
a typing game with a zombie game, I'm just going to be honest,
I was a huge fan of Typing of the Dead,
and I get a lot of flak for
basically blatantly copying the game concept,
but I prefer the term spiritual successor.
That is to say, I was a big fan of Typing of the Dead.
>> Can you tell us a bit about the story in the game?
>> Yeah, sure. The stories are interesting.
Social media has effectively turned
everyone in the world into zombies.
The players are dropped into the zombie apocalypse,
and they have to gradually find out what happens.
It took us a lot of careful design work to come up with
a way for us to type out the story of the game in a way
that players could actually understand what was
going on and learn about
the world around them and why they
were typing lots of words very fast.
>> That's a really cool approach.
You're basically typing out the story as you're learning it,
you probably feel more connected to
it than if you were just reading it
because you're actually typing it out.
>> One of my main sources of inspiration,
when I was talking to the writer about
the kind of story I wanted to do
was I said I wanted effectively a dark comedy.
I would say that it's comedic.
If you play through my game, you'll see a game that is very
comedic and not very lighthearted.
>> That's a good explanation. Do you want to
share a little bit about how you made it?
>> In terms of tools and process,
we use Unity and we use game stacks tools.
I write all the code in Visual Studio.
I'm using the code editor there and I
actually very impressed with the new tools that
just came out for Visual Studio 20 for the new tools with the art.
We mostly use asset kits and then we use
shaders on top of that because we don't actually
have a full time artist on the project.
Then in terms of other tools that we use,
we're using a lot of
the Unity Cloud tools for build and test running.
This project so old. When I started in 2015,
I think we actually still had JavaScript code in there too.
>> I can imagine having the language you're
using to make a game no longer supported by the engine.
That must've been very annoying.
>> On that note, Visual Studio's code coverage tools
are extremely helpful
for managing a lot of the craft
and helping you know what to refactor out,
what duplicate code to attack and remove.
They have great tools for that,
so that's been really helpful.
>> You mentioned we. Can you talk about how the team is,
how it was when you started and how it's changed over time?
>> The biggest struggle with the hobbyist game where no
one's getting paid and you're not trying to make
money is getting the right people who actually want to do it and
actually want to work for free just for the sake of
making an educational piece of software.
Decided that the way I was going
to onboard new people is I was just
going to give them a really hard task right off the bat.
If they completed it,
then I would give them more work to do.
That was a really hard lesson for me because
it's honestly feels like a mean thing to do.
But I had spent a lot of time
basically training these people who would drop off,
and so I stopped doing that.
>> How do you manage doing
the actual hands-on work and doing the people management,
the hiring, the working communication?
How do you manage that part?
>> Think it's interesting that you say
hiring on a volunteer project.
I must feel more conscripting is a better word.
But honestly, I try to offload as much
of managing other people to my PM as I can.
Back when we were doing serious rework on
the game engine and the game input systems,
I spent a lot of time in code review and I spent
a lot of time basically
making sure we had a good process for that.
That was a lot of the people management and mentoring that I did.
Definitely, code standards are
a thing to talk about on this project.
They've definitely risen over time because as I said,
I started this as a college student
so a lot of the work I had to do over
the years just involved fixing up what was effectively bad code.
But as soon as you had other engineers into the mix,
you really have to make sure your code
is understandable, commented,
modular and adheres to solid design principles
so that other engineers can work with what you're laying down.
Really reorganize things to the point
where we could respond to player feedback.
I guess that's a really important thing.
Can I talk to that for a little better?
>> Absolutely, yeah.
>> When I was in college, they told us iterative design
and agile development for games was king.
We were in a position for a while
where the game was getting a lot of
player test feedback that we couldn't respond
to because the code base was too disorganized.
I had to make a lot of
decisions that I just honestly didn't want to make.
That is to say I had fallen in love with my purity of design.
It was hard for me even once I had
architected the game in a way that I could change it,
for me to go back and rip out these mechanics that I really like.
I think there's two key lessons there,
which is one you need to be able to change
your game on the fly to respond to player feedback and two,
you have to be willing to respond to that feedback.
Even if you like something,
if your players don't like it,
you just got to take an ax.
It's really hard to change your own game when you like it.
But that was something I had to do.
>> I remember with my last game,
I was putting it in front of people and getting
feedback where I would just afterwards be like,
"I have to change so much."
While it was painful in the moment,
it led to, I think,
a way more polished game and something that was way more
coherent and you can understand how
to go around things and navigate things.
That's a really good point to make sure that the code allows you
to work with that feedback in a way
that it's going to be hopefully,
the work can be minimized to change things.
>> I'm sure you can relate to the idea of really
loving a complex mechanic that you've created in your game.
Then players not being able to learn that mechanic.
Even though you love that mechanic,
you have to slaughter it because otherwise
players are just not going to be able learn your game.
I'm sure you've run into that.
>> You have to find the right balance
because I let my scope get so
big that my project is now
a huge project when it wasn't meant to be originally.
>> Well, this is just the dilemma feature creep,
developers always want to add new things to
their game after it's too late.
I think if you wind up adding things last minute,
you will effectively and if you don't stick to deadlines,
you'll effectively never get your project finished.
>> You're a good role model because you show
people that you're sticking through and you have a Beta out,
so you have some to show for it.
How do you handle the source repo with Git and Unity?
Do you use GitHub, Azure,
DevOps, GitLab, which you use for that?
>> I actually really appreciate that question because lately
I've been using Visual Studio tools for Git.
It's really quick, I think a lot
quicker than using the command line interface.
I'm a big fan of the UI
that comes with Visual Studio for managing.
>> That sounds really cool.
I want to check that out no. Now that you describe it,
it sounds it's really valuable.
>> Git is really powerful.
I feel like most engineers, myself included,
need to be protected from the full complexity of all Gits tools,
except when they absolutely need them.
That is to say, there's a lot of very powerful things you can use
in Git that I don't want to try to do on a daily basis.
>> What are your plans for the future of Keyboardkommander?
Do you have a release date for the full game?
What will you do when it's fully released?
Let's hear what you've got in store.
>> In terms of when I'm releasing the game,
there is one person who has to get
their work in and then the game will be released.
I need to do a lot of testing and
potentially a very slight amount of gameplay tweaking.
The end is in sight.
We're very close.
>> It sounds like you've got yourself a pretty solid plan.
>> Working on a game for this
long you really have to have a lot of
dedication to still be working on
a game all the way to its completion.
More than excited,
I am exhausted at this point.
I mean that in the best way possible
because I really do love what I do,
and I really love making games.
But it takes a lot to make a game.
I'm really ready to move on with
my life and move on to another game.
>> I've been on my current game for about two years,
so I can understand how
challenging it must be after
that amount of time you've been putting into this.
A question I get a lot that I'd love to ask you is,
how do you stay focused on the one project?
How do you not get distracted at that kind of thing?
>> An interesting question to ask.
Obviously I have a full time job.
The work that I do on this game gets parceled out a lot because I
wind up at least at
this stage of development where we're wrapping things up,
waiting on other people to get their pieces in.
I think the answer to that is you just really have to care
a lot and there has to be
a reason why you're doing what you're doing.
I really want to make a game that makes people think about stuff.
I really just like the process,
and I really just like making games.
For me that, plus a lot of dedication and a lot of stubbornness,
is how I manage the focus to work on this project.
>> Think having a reason to make your game is
definitely a great way to stay committed to it.
>> Interaction you have with the game should have
something to say about the design of the game
and should make the players think
about what they're doing in an interesting way.
Sometimes I don't always see that,
and that's just my philosophy.
A lot of people,
probably have a different philosophy about how they make games.
That's how I feel about stuff,
and I've tried to carry that through every game that I've made.
>> That's a good way to look at it.
I'll try to spread out the learning of the games I'm
making through more interesting storytelling
or interesting challenges that you're doing rather than
here's how you do a bunch
of things and now go play the whole game.
It's can you learn a little bit here.
Now you learn a little bit through this interaction.
You mentioned that you volunteer work with Seattle Indies.
You want to tell us a little bit
about your work there and what they do?
>> Yes. I'm actually a board member for
a 501c3 called Seattle Indies which is a
local nonprofit to Seattle buts basically for
supporting independent game developers in the Seattle area,
as well as across the world.
It's great, it does a lot
of great things for the game development community.
I love being a part of it and I love
the sense of community that we get from that.
I've been very fortunate to be given this board position and I'm
really hoping I can serve the 501c3 well over my time there.
>> Sounds like a great initiative.
It's nice to have more game development networking events since
a lot of us sit at home by ourselves when working on our game.
It's nice to connect with others doing the same thing.
We better wrap up any last tips
or advice for people getting into game development.
>> You got to be willing to make sacrifices,
that's what this is all about. You got to love it.
Game development is about sacrifice and
loving it and making sure the sacrifice is worth it.
Thank you so much for having me here today.
This is a lot of fun. I could talk for literally hours.
>> Well, thank you for joining us.
There is a lot of wisdom in some of the things you said,
and we'll all be able to take that
and continue to learn from it. Thanks for sharing.
>> Thank you so much.
>> Take care.
[MUSIC]