Step 1: Delete Unity Step 2: Do an afternoon’s research
into new Engine choices. Step 3: Choose Godot (or Unreal, or Cocos2D, or RPGMaker) Step 4: Implement the Pixelart Effect
in the same way we did 3 years ago. We have 2 low resolution render textures (here they are called Viewports) one for colour, one for depth each with their own camera
that matches the main camera exactly. Then in our main view, we use a post processing effect
to reintegrate the colour and depth data back into the scene. It’s little hacky by hey it wo- Oh. Oh for god’s sake. Step 5: Identify the problem So the depth texture we’re writing to
does not contain precise enough data, so the reading is inaccurate. Now in Unity, this would
be a complete deal breaker, and from the looks of some of
my comments over the years, it has been, but there’s a special thing about
Godot is that it’s open-source, so not only can I edit the engine code but I could submit those changes
to update the engine itself, improving the experience for everyone. So all I’d need to do is write some code in C++… Step 6: Consider going back to Unity. For all of 5 milliseconds. C++ is more of afraid of you than you are of it. I’ve 2 ½ years of professional
experience in the language and it was the first programming
language I ever learnt but I can’t exactly expect you lot to
be able to make those changes yourself, so let’s consider another option. Step 7: Pet my new cat Ruble. Say hi Ruble. He loves the camera... Step 8: Implement the Ultimate Pixelart Effect For the past 3 years, I
have been working on and off on an Ultimate Pixelart Effect tutorial in Unity but it’s been a struggle. The implementation has been messy, buggy and I’ve had to fight Unity’s rendering pipeline
every single step of the way. And it’s hard to have
motivation to write something for an Engine that you don’t like the direction of and have several moral
qualms with the business of. But as of last week, that
motivation is in the toilet, so let’s see if I can implement
the base concept into Godot. Essentially, my plan is convert every mesh… into a sprite. Now obviously, that’s what we’ve been trying
to do from the start, but hear me out. Instead of taking mesh data,
sending it to the camera and infiltrating that process
for the pixelisation process. What if I removed the mesh entirely? Imagine the mesh in its own little world,
with its own little pixel camera. Then, back in the main world,
we replace the mesh with a sprite, a sprite that shows the
output of that pixel camera. All we have to do, is match the rotations
of the pixel camera and the sprite, we’ll have an incredibly simple but incredibly
versatile version of the pixelart effect! And hilariously, this is way easier to accomplish
in Godot than in Unity! One problem is that with hundreds of these objects in the world, performance could take a hit,
seeing as they’ll all need rendering all the time. But Godot has already fixed this issue as you can setup Viewports,
to only ever render if they’re being perceived. Another problem is that you need
to make sure that each pixel camera only renders the mesh it’s been assigned to, otherwise other meshes would
show up on your sprite. In Unity you’d have to use layer culling
and you’d quickly run out of layers to use. But Godot allows Viewports
to define their own world, which means they’ll only render
the objects you place inside! This will make things a bit trickier with
lighting, but we’ll keep things basic for now. So in order to get this to work, I’m going to
set it up for one object and then span it out. Setup your scene like this, with an empty PixelArtManager
node, a MainCamera for rendering, some scenery with the
character you want to Pixelate and a separate node that contains
all the lighting in the scene. We’ll start off by creating a
new script called PixelNode. It doesn’t do anything but it will
store the data we’ll need for setup, and let's us know which nodes we are pixelating. We can add this script to the Character. Now we’ll need a manager to handle
the setup and execution for us. Let’s extend the base node class and start coding. It’ll take the node we just made
as a parameter, and on game start, creating a new viewport and camera for it. We’ll also add the lighting node for good measure. First we’ll need to check to make sure that our script parameters have been
set to avoid any errors. Then we’ll setup the relevant
values for our sprite, such as the resolution and the physical
size of the sprite in the game world. I’ve also created a bounds calculation
function which Godot sorely lacks. This will help us find the true
centre of the entire object, which is where we’ll place the sprite. Next it’s time to setup the viewport, making sure it’s background is
transparent and it’s using it’s own world. And then, we’ll create the camera with some
preset parameters to make it look nice. Once that’s done, we’ll need
to create the actual sprite, which will use a standard
material to display our viewport. Just make sure that the shading is unlit, and the texture_filter is at Nearest
to give us those crispy pixels. Finally, we’ll place the sprite in the
same location as the centre of the mesh, and move the mesh into our viewport. With the setup complete,
let’s focus on the process. In order to produce the results we want, the camera will need to be at
the main camera’s position, pointed towards the centre of the sprite. It’s Field of View will
also need to be turned down so that the edges of the camera line
up with the edges of the sprite. This is a pretty simple calculation
if you remember your Maths. Then we just need to copy over the exact
rotation of the camera to the sprite, ensuring that it is always
facing in the same direction. That way the effect is never distorted. And hey presto, the effect works! And it’s the best results, we have
ever had for the Pixelart Effect. The pixels are a consistent size, this works with depth, transparents,
lighting and best of all, this allows the best artistic
expression out of all the effects. You can mess around with the
direction of the pixel camera, or the direction of the pixel sprite to give
these really interesting looking effects, reminiscent of Heaven’s
Gate or Octopath Traveller. And it’s incredibly easy to add
post-processing or whatever you want. And since this process is the same for every mesh, we only need a bit of extra code to get
it work for a whole series of meshes. There are still some caveats
in terms of the lighting and it still might not be
the most performant method but I’m still incredibly proud I
finally got this done after 3 years. All I have to do was wait for a major
corporation to lose over $1 billion in value. Don't check my maths on that... YouTube desperately wants me
to make these videos longer, but I refuse to waste anyone’s
time so the tutorial ends here but if you want to stick around,
I’ll put in a surprise at the end. I know this video has a jokey tone, but my heart genuinely goes out
to everyone affected by these major changes that Unity has decided to implement. I’m sure I don’t need to explain anything here but even if they decide to walk back the changes,
the trust has gone. If you can afford to pivot away from it,
I would pivot sooner rather than later. In terms of choices of engine, I used Godot here for simplicity
but really is dealer’s choice. I think Godot is incredibly lightweight
and surprisingly easy to learn, plus its open-source nature really opens up
its functionality if you know what you’re doing but it’s still got some time before
it’s matching Unity’s features and it doesn’t have the same Asset Library and wealth of tutorials that
Unity has grown over the years. But that’s a big part of the
reason I made a tutorial in it, because the more of us that reach
out to teach people how stuff works, the easier it will be for people to avoid a
potential financially compromising situation. Godot’s biggest problem is the
lack of support for Consoles which is a major bummer and
doesn’t have an easy solution. Godot might be open-source but the APIs and
SDKs for getting games onto a console are not, which causes the two to be somewhat incompatible. You can get a third party team to do
the porting for you, which costs money. I hope a solution is settled on soon but it’s one of those things that’s really
hard to predict, personally. The other big option people
are choosing is Unreal, an engine I have a lot of familiarity with
despite never working in it professionally. I genuinely love Unreal and it’s
a delight to make games in but it is the complete and utter opposite of lightweight, taking days to install, hours to setup
and using all of the space on my SSD. It’s nowhere near as pick-up
and play as Unity and Godot. That’s not necessarily something
Unreal needs to fix, but also why not? Fork your engine! Make a Lite version!
I don’t know, it’s just a thought. In terms of personal updates, as of July of this year,
I no longer work for Cloud Imperium Games. I am now a Gameplay Programmer
at Creative Assembly. Again, I’m under NDA so I
can’t talk about any of it but I am genuinely really excited for
people to see what we’re cooking up. I’ve moved to London, because I’ve always wanted to explore
the setting of my favourite TV show, Lee Mack’s Not Going Out. My partner and I recently adopted a Cat. Here’s Ruble again. Expect more Ruble content. Or don’t. He does not care. He has seen everything… Oh, and I recently started
playing Professor Layton in a fandub playthrough of
Professor Layton vs Ace Attorney. If you thought my impression was
half decent in my Layton video, then come on down and see if I
give the man himself some justice. Now for the surprise... Working on this video has actually made me draw up a list of additions to the
Godot engine that I want to make. I don’t know how easy of a process this will be but I’m hoping my C++ experience
will carry me through. Maybe if some of them get through,
I’ll make a video on them! But I will say that writing tutorial
videos while navigating the NDAs of 2 different companies is
something of a nightmare, so I might focus on my
video essay stuff for a bit, unless inspiration strikes, or a ton of people get into the comments
and tell me to keep making tutorials. Like and subscribe and thanks for stopping by.
