- Jacob Bijani and Pasquale D'Silva.
So Pasquale came and spoke in 2013, about interaction design and animation.
And the story of how he came to speak with us, was that he wrote a post on Medium, that was about that topic, and it's something that I'd been really wanting to get on our stage for along time.
But I'd never found someone who'd be able to combine talking and thinking about animation with interaction design, and Pasquale did that.
Now he'd never really spoken on stage before, and we just jumped on Skype and started chatting, and I realised that you know, he was up to this, so we got him along.
Turns out, despite the fact we found him on Medium, he was living at the time in Berlin, he'd grown up in the Gold Coast.
And so we brought him home.
He now lives in New York, where he's worked with all sorts of interesting folks. But he's currently working with his partner in crime, Jacob Bijani.
So Jacob was the very first product engineer and designer at Tumblr.
And now, and he's worked on many other things as well, and now they work together on really interesting projects. Today again, is something a little bit different. I wanted to kind of get inside the process and the inspiration for how something creative and extraordinary comes together.
And I knew about this project and chatted with Pasquale and Jacob a bit about it.
I thought it'd be a great thing to put on stage. So to hear all about this project, are we ready to go? Would you please welcome, Pasquale D'Silva and Jacob Bijani.
(audience applause) - Yep, understood.
Listen, Mr Barack Obama, President of the United States, I gotta go, I gotta speak at this conference. (audience laughter) Yeah, can I call you back? Yeah I can get it on your desk by Tuesday.
Okay.
(whispers) Sorry, one second.
Yeah, alright.
See you later Doc.
(audience laughter) Alright. Hey, man.
- [Jacob] Hey, buddy.
- Hey, sorry about that.
It's really crazy over in the United States right now. (sighs heavily) So, I wanna take a moment in light of recent events, to address, I think kinda the elephant in the room. I think it's been in the back of our minds, here at this conference.
I think while we've been having a really good time, I can't really let it slide.
Yes, it looks like we're standing on a giant DDR game controller.
(audience laughter) And it kinda feels like all of you are watching me and Jacob and all of the other speakers, compete in this crazy world championship stadium. It's a total trip, and I gotta say, it is an honour. But yeah I just wanted to highlight and articulate what we've all been thinking about, over the last couple of days, and also screw Donald Trump.
- Amen. (audience laughter)
- Moving on.
So, welcome to the 35th annual Twilight fans convention. It is pleasure to have you here.
Thank you so much for coming out.
Shout out to all the vampires, the werewolves in the audience.
I know you're all really excited about the film, we'll be doing a little preview later.
But first we'd like to talk about something entirely different.
Something we've been working on.
My name is Pasquale and this is Jacob.
We're visiting from New York City.
And we've been working on a video game.
It's called Ok, Dracula, and we're here to tell you all about it.
If you've ever wanted to kick a human skull, as far as possible, you're in for a treat.
(audience laughter) - [Jacob] So, it's a game for Apple TV, iPhone, Android.
Pretty much anything that's gonna have a screen. (audience laughter) - So, we're gonna be covering a bunch of topics today.
Here's a list.
We'll be talking about prototyping.
Evolution and iteration.
How a video game works.
Drawing with a computer.
Teaching how to teach behaviour.
Parallels to what I like to call classical software. Creative handles, and some funny GOOFS.
So, why make a video game? Well before diving in the nitty gritty, why do we wanna work on a video game? Why do we work on video games? Well first of all, they're really fun for us to work on. Maybe even more fun, than actually playing the game. And the process of making a game, is actually very enjoyable.
The problems are truly interesting.
The types of problems we're solving, day to day, are pretty ridiculous, like, which hands should our duck hold a sword in? Or, should it have an English or British accent? I mean, I think that they're the same thing. (laughter) Or how much blood is too much blood? There are so many surprising moments along the way, and we're gonna talk about those in a moment. And another point is, of course it's fun for people to play. It's kinda really the point, of a game.
And we're gonna make something that our friends and family and strangers we don't know, can be entertained by.
And it is a perfect outlet for our passions, art and engineering.
That's me.
My background was in classical animation.
Hand drawn, super lo fi.
You know, with pencil and paper.
- I've always been interested in computers. I used to take video games, and like kinda break the levels apart, and try to mod 'em, and figure out how they worked. And when I was in middle school, I taught myself to code. And this really shows you how cool a kid I was. I write my own bulletin board software and then all my friends from school would hang out on it. (audience laughter) - I quickly moved from classical animation into digital animation and computer graphics. I was working on commercial projects and I designed toys and cartoons and illustrations.
And in parallel, I'd been working as an interaction and product designer.
- So when I learned to code, one of the first things that I built, was this site that was called start io.
And the idea was that, you can make a list of the links, like your favourite sites, and set that as your browser's homepage.
And this was like way before Chrome and all the browsers actually had that built into the browser.
But that site never really went anywhere, but through building it, it taught me like most of what I know about making products today. And, sort of indirectly, it got me my first real job as Tumblrs first designer. And since it was a design team of myself, I appointed myself the creative director.
(laughter) And so as it got bigger and hired some actual competent designers, I moved to the engineering team, completely and I've sort of just been an engineer ever since.
- So I first met Jacob in 2010.
We followed each other on Tumblr, while Jacob was working at Tumblr.
And I had a meeting with their first investor. He's a cartoon legend, his name is Fred Seibert. And Tumblr was working out of Fred's office in the first few years of its inception.
And the office was plastered with animation art. And Tumblr had me design a weird, funny landing page for their Japanese website, as well as their mascot, TumblrBot.
And over the years, Jacob and I found excuses to collaborate on projects. And we went onto work together in experimental software studios called Elepath. And our time was spent on lots of little software experiments.
And some of them turned into their own companies. (audience laughter) At some point after Elepath, we went on to start a project called Totally Viable with our friend Allan Yu.
And we worked on projects in the public.
That is to say we made experiments like we did at Elepath, but we documented them with videos, and we shared our code.
We open sourced it, and we even made our entire Slack history, public. And amongst a number of experiments we made at Totally Viable, was the video game which we're about to talk about today, called Ok, Dracula.
And it started with a very slim, maybe even malnourished prototype.
At the time of starting the game, a few very interesting stars had aligned.
The Apple TV 2 had just dropped, which opened the platform for third parties. And we noticed there were very few high quality games on the store.
And the best games were really just cheap ports of iPhone games and they just kind of blown up. And meanwhile, we also realised the Apple TV platform was practically empty.
There was and still is, a pretty big opportunity to make an impact there. Even today, there's only like 2000 games in the app store, which isn't that many.
And many of these games had, and still kinda have, poor user input.
They're designed for a touch screen, but don't really translate well to the input mechanism of the Apple TV remote.
It's very tiny.
Has a tiny touch area, and it's hard to get reliable gestures on the touch pad. And we realised that, the easiest repeatable action on there, was clicking the actual button.
So we set creative constraints around what we'd build. And we wanted to build something that would work well for Apple TV of course. And furthermore, we decided we wanted it to be very easy to play.
So, you know, something that perhaps drunk people could play.
Or children.
Or you know, the Venn diagram overlap of drunk children. (audience laughter) And without really needing instruction, and that's truly a very large segment of humanity. (laughter) We've been influenced and inspired by a variety of creative endeavours, including projects we've worked on ourselves, and projects in the same neighbourhood of creativity. - [Jacob] So at that time, I was working on teaching myself Unity, by building this game, which was sort of a hyper realistic construction simulator, where you get a pile of 2x4's and have to build whatever you want out of it. Which I still want to build.
I think it'd be a really good virtual reality game, maybe. - I was the creative director of an educational games company called MindSnacks. I did a lot of the art and the animation.
And also built the art design team, and spent a lot of time developing a pipeline, to bridge the gap between the artists and the engineers at the company.
Sometime after that, I worked at a music software company called Keezy, a few companies after that.
And it made music tools and toys.
This was a commercial I directed, featuring the amazing Reggie Watts.
The next project I wanted to make at Keezy, was something that kinda returned back to video games, like I was doing at MindSnacks.
Something like a music video game.
So I started exploring Unity, and a bunch of other frameworks.
And I learned that Jacob was already building stuff in Unity, like 2x4, that crazy construction simulator. And naturally, we decided to team up and try out a game. And we looked at our favourite games on Apple TV. There's still a few good ones.
And we realised they all had very simple input mechanics, like you just click a button, like Mr Crab. Or Alto's Adventure, which is like a one click button game, and it had these very beautiful generative levels. So when we got together for our first kinda game jam session, I was making quite a large amount of music, and much of it was inspired by video game scores, or tracks for animation.
And one track I had sitting on my desktop, was a track called Ok, Dracula.
And I made it after having a dream about a cool Dad vampire, who's trying to prove to his kids that he's cool. (audience laughter) And it sent us down this path of riffing on ideas. I played for Jacob, and we settled on a game where you played as a vampire, trying to kick your friend, his name's Jerome, as far as possible.
(audience laughter) And character design wise, I thought it'd be neat to draw inspiration from some of my favourite influences.
So Drac has some of the DNA of Marty McFly, and my musician friend Francis, and this cartoon called Danny Phantom, and sort of a bit of myself as a young 20 something year old, living in Williamsburg, Brooklyn.
So the very first version of the game, that felt like a game.
It featured a LUT camera, it had 3D terrain, and it had a 2D scribble of a vampire. And we were toying with this idea of a mixture of 2D and 3D art in the same space, which was kinda fun, it was fresh.
But it was proving to be too much of a wrestle with the computer.
And we didn't get a lot of progress, game play wise, and it didn't feel right, until we decided to commit to pure 2D art.
So we threw the 3D stuff away, and we tried again in 2D.
And we worked toward a prototype, that was actually fun. The goal of it was to be fun.
And this first version was fun.
There was not really a UI, or environment, but the general mechanic of a skull kicking physics golf, had something special to it.
So we built it up a little more, and we had a basic game play, and added stats, like distance and health, and things you would typically see in a video game. So you could actually have a measure, something to determine the game was over, and compare scores.
We built it up some more, and started detailing, and building more elaborate character puppets, and bolting down the art and environments.
And soon enough, we had the start of a sort of legit video game.
And it got richer, once we blocked out more UI, and added parallax layers, to kinda give it Z depth. And there's still a lot more to do, but now we have this round minimal version which we've been showing off to friends.
And that is something that we've been proud to be able to show off. So anyway, how does a video game actually work? - [Jacob] So the core concept, is called a Game Loop.
And the first piece of that is, that you're always constantly watching for the user input. So, that could be things like, jump, or fire, or main menu.
And when you get the input, you respond to it. While constantly simulating the world at that moment within the game.
And once you've done that, you take the camera, where the camera's currently placed in the world, and simulate whatever it sees.
Render whatever it sees, rather.
And you have to repeat this, at least 60 times a second. As soon as the loop is over, it runs again. And so, as you can expect, it's running so often that performance here is pretty important.
And most of the time, unless you are doing some heavy calculations like figuring out some physics operations like collisions.
The heaviest part of that loop is rendering what's in front of the camera.
And that process is what's called Draw Calls. And that rendering process of Draw Calls, is actually very similar to how you would go about painting an oil painting.
You start with your base colour, the background, and then you paint each layer progressively over the last one until you, towards the viewer, until you get to the front at the top. The top most element.
And, rendering each frame in that game loop is actually very similar to that process.
So, we start with the background, the sky.
And paint one parallax layer, one piece of each parallax layer at a time. One over the next.
Until we eventually make our way towards the foreground and paint the UI on top.
But you can see as we step through these layers, that, the, how big an impact the art choices that we have made, have on how we can split these Draw Calls up and how we need to go about rendering the frame. So this is a pretty good example right here, this mist that separates the two background layers from each other.
In order to paint that mist, we first have to paint what's behind it, and then sort of blend the mist on top.
Just like you would if you were painting this as a painting. And then you can continue forward, towards the foreground.
So, basically, the art style that we've chosen here has a big constraint, a big impact on the rendering that we're able to do.
So, here's the foreground.
- [Pasquale] It's a lot of layers.
- [Jacob] And then, filling in the foreground which is where all the action happens.
Where the skull bounces around on.
The house.
Filling the props in on top.
And here we start to deal with some of the draw issues, where obviously Dracula needs to be on top of the house, so he has to be drawn later.
And then we can start to blend in the UI, and some of the finer details on top.
Until, we finally get our final frame.
And so, why does this all matter? Basically, it comes down to, the faster that you can draw each frame, the more frames that you are able to draw per second. And the more frames that you're able to draw per second, the smoother that the game play will feel.
And the reason that that matters, is it's just more enjoyable.
It's one of those things that when you get it right, it just becomes invisible.
- Alright, teaching behaviour.
So we take a lot of things for granted in reality. When you're building a game, you have to be very explicit about behaviour. Like telling bears, like hey avoid that bear trap.
Or what bear traps should do, when they're triggered. Or how leaves flutter when they're disrupted on the forest floor. Or even just the general effect of gravity. So we need to teach the virtual world and its inhabitants, how to react as a system.
So here's a crazy question.
How do you teach a bear to walk along the ground? - It's a great question.
And actually it's funny that that's something that came up in our development process.
We sat down and realised we needed to figure that out. And when it did, I didn't really know where to begin. But, you sit down, it's like any problem, you just have to break it down to its component parts. So, in this scenario, teach a bear to walk along the ground. You have the bear, you have the ground, and you have walking.
So, the ground.
The ground is made up of a collection of points, that go through space.
And then you can take those points, and draw a line through them.
- [Pasquale] So the actual bear itself.
I take 2D art, which I create, and I split it apart, and I hook it up to bones and meshes, and this thing is called an animation rig.
Sort of a puppet.
And I take the puppet, and I make animation cycles, by plotting down animation knots.
Which Jacob can then manipulate in code.
- [Jacob] So, the bear is an animation.
It's just a bunch of data that Pasquale's put together, that he's designed.
And so that it's got their bones, their skin or fur. And the information on how all that moves.
So, the walk.
The walk is a particular animation loop cycle, within that. The movement of the bones within that animation, dictates how the skin of (mumbles).
And he also bakes in here, something that's called the root motion.
And the root motion is, how much distance, that that cycle can cover, each loop.
So the first step, is to translate the bear along the ground path. But it's easier to start with something simpler like just a cube.
Because that way, you're not distracted by the complexity of the bear.
But once you get that, you can translate anything along the path.
(audience laughter) - [Pasquale] Why not? - [Jacob] Why not? So, try plugging the bear back into that same piece, and it kinda doesn't look right.
You can see that the feet slip around, it's not very realistic.
And that's because that root motion that I mentioned, is not aligned with the distance that this bear's travelling, the speed.
So, if you fix that, you make them aligned correctly to the root motion. You get this convincing effect.
The bear actually looks like it's making contact and moving along the ground.
So, put that all together.
We need a little less though.
And you get a bear that can walk along the ground. - So, another thing we taught, was how to teach a duck how to toss a dagger. (audience laughter) It's a classic design problem.
(audience laughter) We have a duck in our game, like I'm sure all of you do.
His name's Darmite, he's British, he wears two purple boots, he has an eye patch, and he tosses daggers, he's a total badass. And he kinda looks like a yellow potato.
- [Jacob] Chicken nugget.
- [Pasquale] Right now, Darmite doesn't have any targeting logic, but he throws pretty frequently.
And what we realise, that he is already a pretty formidable enemy without having any targeting, without having any intelligence.
He just kinda just goes in and pft pft pft. And why is he a good enemy? Well he throws pretty frequently, and his daggers stick around in the world.
He litters the earth with his weapons.
So if you don't get hit directly, when you're rolling around, you're very likely to fall into his pile of daggers. And this typically kills you.
And he can also do this.
So the bear.
Bear's name Samantha.
Samantha doesn't have a gender.
One of the first behaviours we taught Samantha, was to bite and toss the skull.
This causes you to be displaced and lose health, and you bleed a bit.
And we discovered something cool though.
As soon as we put two bears on a screen at once, they started tossing the skull back and forth. And this wasn't something that we implicitly set up, it was a result of behaviours.
And we effectively created a scenario, where you can get mauled to death, by a pack of bears. Which is really fun.
(audience laughter) Maybe not so much in real life, but very fun in the game.
- So, all this stuff, when you see, it seems like magic.
But the thing is, it's all software.
And they're novel problems, but it's really not that different than any other software problems.
(laughter) And the thing is we know to ship software, we've done it a lot before.
So we can draw from the best parts of shipping software, in making our game.
So, the idea of the MVP, the Minimum Viable Product.
Or in our case, the MVG, the Minimal Viable Game.
So that is to say, what's the smallest amount of the idea for the game that you can build and test your idea.
That early 2D prototype, was our MVG.
So Continuous Integration, which is just a build server, that's constantly building the latest version of your code. So that allows you to always have the latest version of the game, which is working and playable.
You can see if it's still running and playing the way you want it to.
- Right.
So, the concept is starting with version 1. Usually, when you think of an idea, before you even put it down on paper, you've evolved it in your mind to like version four or five. And by the time you sit down and start programming it, the idea has maybe evolved to version 10 or 15. And it's very tempting, when you're building something, to build a wider version of your idea, cos it's so easy to iterate in your head.
You can think of the next feature.
But in doing so, you promote the behaviour of pushing the finish line out.
Which means you never hit the finish line.
And it takes way longer than it should, without the opportunity for iteration.
So it's helpful to consciously break down the progression of an idea, and build it linearly.
To me, this a graphic that, I'm sure maybe some of you've seen referenced. I think 37 Signals was maybe one of the first to send this around.
But it's commonly used to explain the concept. The customers desire in this scenario, isn't necessarily to have a car, but to get around. The desire is to be transported.
So if you just go right into building a car, there's a longer period of time where you just can't get around.
But if you build progressively towards a car, you have these iterative steps, where at each point along the way, each version of the product, or the thing that you're building is useful. And you can evaluate it.
We also use many of the same tools that I'm sure all of you use, if you're in more traditional software.
It's like what I like to call classical software. And we use stuff in building games, like GitHub. It's great, cos there's the community of open source and version control, it's very handy of course. Slack, for easy communication, and integrating bots for building for us, and deploying and other types of automation. And Trello, for like project management flow. All of these tools that exist today, make it really easy to assemble your own pipeline. And of course there's Unity, which we built Ok, Dracula in.
It is a fantastic bridge.
It closes the feedback loop I find, between art and engineering.
It allows both artists and engineers, to work in the same environment.
So you can interface with the code using a gooey, or using a text editor, or some other custom interface.
It's highly extensible, so, say I need Jacob to expose some values for me, he can very quickly do that, without me diving into the code, which is a very dangerous thing.
(laughter) - [Jacob] You don't want that.
- So, adding handles.
A big part of the game revolves around endless play. We have these generative bits of terrain.
So we need to proceedurally generate the terrain, and the flora and fauna that sits on top of it. And total entropy, total randomness, isn't exactly what we wanted.
We wanted to be able to have the computer generate a world, to hallucinate, and create a world, but then for us to be able to augment what kind of exists.
So it typically starts with concept art, so I paint something like this.
And then sit with Jacob and work out how to break the pieces down.
So each piece in this scene, has its own rules about how it should behave on the screen. So the trees need to sit behind the terrain, and the leaves need to sit on top of the ground, and Dracula's feet need to sit on the ground, and the skull needs to be kickable.
But what if I wanted to add a particular arrangement in this crazy environment, into the simulated system where the terrain's kind of waving around.
Well, I sat down and worked with Jacob, and we built some tools which allowed us to do some level design inside this generative environment. So we built this custom interface, this stripped interface, to compose the environment layout.
So I take all the bits of art that I premade, and lay 'em out on the strip.
And then, it allows me to have specific control over where the elements sit, and build things like puzzles or just nice compositions. So here's a couple of strips.
And then we take that, and then we wrap it over the landscape, while simulating the physics, to make sure that the rocks and the logs and other things fall into the ground.
And that the greenery points the right way. So that was a very useful handle, for me to be able to design these levels, without having to touch code.
And there were numerous sub interfaces which we use, which allow us to directly manipulate the data in a visual fashion.
So, adjusting music and sound events, is made really easy with this music picker interface. The sounds can be adjusted without having to touch any code, which is great.
And this audio controller, is just a plugin, and there's plenty of them available on the Unity store for free and for purchase, and of course you can write your own, and it's a very easy way to extend Unity.
We also built a really cool tool, to test animation blending.
I would design a lot of animations separately, so like run cycles and punches and knockouts, and we needed to see how they would stack on top of each other.
They'd work well discreetly, they'd work well individually, but we needed to see how they would blend into each other. So I had Jacob build me a tool, which would allow us to preview how that stuff works. So here's a little video of how it works.
Jacob built a really cool script that allows me to test different animations I made, and watch them blend together.
So for example here in Spine, we have all of these individual animations. And Spine doesn't really stack them, so if I go between this walk, to an idle, to a run, they instantaneously change, without blending. However in Unity, you can blend animation.
So Jacob built a really this cool script that allows us to preview it.
So I can toggle between animation tracks, by just hitting any key on the keyboard, so I have stuff wired up to numeric keys.
And so, on track one, or animation one, he's idling. On two, he's walking, and on three, he's running.
And we can blend between them.
- So, debugging the animations.
A lot of time, when something's not working right, it's very obvious, like this.
But a lot of times, it's not that obvious.
So when it's not, how do you tell? I don't have those animator eyes, that Pasquale has, just hiding from us.
(audience laughter) So for me, to actually look at the numbers and visualise the numbers directly, it's much easier to actually spot the problem. And this is a very good example of that.
Pasquale assures me that this animation is wrong. - [Pasquale] It's wrong, there's some lurching in it. - [Jacob] And to be honest, when I look at it, I have to look really close to see what he's talking about. But when I attach some visual logging to it in Unity, it's much more obvious when you look at the graph itself. You can just tell that that graph is not uniform, as you might expect it to be.
So, using that, using the graph, iterating on the graph itself, we get this, which is apparently different.
(audience laughter) - [Pasquale] Yeah.
- But if you actually look, you can see it, it's a little more, more balanced, and dare I say smooth? (laughter) - That's always the worse feedback, that I see on Dribbble. Like someone puts up a little piece on Dribbble, and they like do little bit of motion graphics, and then someone drops a comment underneath and they're like, smooth man.
- Yeah.
(audience laughter) - Cool.
- Yeah.
(audience laughter) So the graph of the second one, the smooth animation. You can see that the shark teeth of the graph is uniform, and verify that it is fixed.
I believe you now.
- So in working on this game together, we talk about this idea.
This concept of richer and wider.
So, let's talk about the individual components there. What is richer? Well what does it mean to make something richer? For example, we realised, for some technical reasons, we needed to spawn the skull in Dracula on a flat surface, for a few technical reasons. And Jacob asked for the minimum.
He was like, yeah man, can you just like give me a square or a platform, or a deck or something like that? And then I thought like, nah man, wouldn't it be way cooler if we went richer, and instead, Dracula walked out of a mansion? (hip hop music) (audience laughter) So here's his actual house.
(audience laughter) And why do this? For a conference joke? Maybe.
(audience laughter) It actually adds to the story and the aesthetic. It's the first thing you see every level, and it has an impact.
It orients the game play, and it makes the world field richer, and you buy into it more.
Also it's not Dracula's house, it's the skulls house which is a crazy twist. (audience laughter) And here's another example of making it richer, by decorating the terrain by hand, with lots of flora. And it makes the environment feel more convincing and immersive and less computer generated.
I would go in, and hand place all of these things, and it feels organic.
So what's wider? Well, we found that it's better to prioritise building wider things.
Wider things, or things that are cheap multipliers to give you more bang for your buck.
For example, our generative terrain system. The upfront engineering work, resulted in literally infinite game play.
If I were having to draw every level by hand, we'd be limited to how many levels I could draw. And so, we were able to multiply the hard work in the art process of all the hand drawn nature stuff, and have the computer create unique, organic combinations, that give the player this feeling of an endless forest which you're exploring. And, so here's another example of wider, it's a little more subtle.
We had this problem, and that was that we wanted to have these trees, sort of swish by the foreground, in front of the camera, and it'd be really big. But the problem is, especially in 2D games, when something is closer to the camera, it needs to be high resolution, otherwise you start to see all the pixels and it all breaks down.
And if you have too many pixels, if you have too many high res graphics, you start to blow out your texture map, and then the files are too big, and it's something you want to stay away from. So, how did we actually manage to get these foreground trees to work, without having a lot of big files? We wanted variety.
So the solution was just to use a tree, that was just made in 3D.
Took like 15 minutes to model.
And we rendered it in 2D, and rotated it randomly. So that same tree model looks like a unique tree from each angle.
It was very cheap to do in art, but it ended up having a pretty wide impact. It created another plane of depth, which really sold the space.
And, another example of richer, it's sort of like the more detailed stuff.
Right now, we don't have Dracula being able to climb over a rock, or react dynamically to the environment, yet. We want to do it, and it'd be more aesthetically pleasing, but it's a lot harder to build those behaviours. It's something we'd like to get around to, but the amount of engineering required to do these tasks, holds off on our ability to iterate on game play, which right now is more important.
So our solution was just to solve it in the art department by having Dracula vanish and then reappear, instead of walking over, which is kind of cool. And the puff was hand animated, to get the desired look, rather than having to simulate a bunch of particle effects. So, in the process of making this video game and other experiments, we generated a lot of artefacts.
And Jacob and I would send them to each other. It's kinda like, the fun of working on a video game, you send these goofs to each other.
And we thought we'd share some of these, while we listen to some music, by our friend Francis and the Lights.
(funky upbeat electronic music) ♪ Did you sleep ♪ ♪ Did I keep you awake dear ♪ ♪ Did you dream ♪ ♪ Of somewhere in the middle ♪ ♪ Was it great ♪ - [Pasquale] I can't do this one.
♪ Was it what you expected ♪ - [Pasquale] What was the character name, Mr Snake? - [Jacob] Professor Snake.
- [Pasquale] Professor Snake.
♪ Or just somewhere in the ball park ♪ - [Jacob] This one's my favourite.
Agility testing.
(audience laughter) (funky upbeat electronic music) ♪ Somewhere in the ball park ♪ - [Jacob] And I wanna do this one.
(audience laughter) (funky upbeat electronic music) ♪ Somewhere in the ball park ♪ - [Jacob] It's an early version of Darmite, very crude. (funky upbeat electronic music) (audience laughter) ♪ Somewhere in the ball park ♪ ♪ Did you lie for a come up ♪ - [Jacob] This one was taken last week.
(audience laughter) ♪ Was your meaning obscured ♪ ♪ Did you die for a reason ♪ ♪ Not just, not just, not ♪ ♪ Want to think ♪ - [Jacob] This one is a metaphor for the world being very fragile.
(funky upbeat electronic music) ♪ Somewhere in the ballpark ♪ ♪ I want you to shake ♪ ♪ I want you to shake ♪ ♪ I want you ♪ ♪ Not just somewhere in the ballpark ♪ (funky upbeat electronic music) (audience laughter) - So, what's next for Ok, Dracula? Well, there's still a lot to do.
We are planning to ship it, early next year for all of those screens that you saw.
And we realised that we like working on this stuff so much together, that we formed a new company.
- [Jacob] That launching a company is the only time you're allowed to use that. - [Pasquale] That anvil transition? - Yeah, yeah.
- So yeah, it's an effect you can use in keynote, you should try it once. - You get it once.
- The new company's called Thinko.
It's a games and interactive arts studio.
I quit my boring old job, to do this cool new job. And so, we're working on our own projects, as well as doing some consulting, so hit us up. Yeah thanks, we're Jacob and Pasquale.
(audience applause)
