Catlike Coding's C# and Shader Text Tutorials

I have now joined Patreon and bound the future of my tutotials to the generosity of patrons. Will you become a patron?
Let's see how it goes!

 

I published a new tutorial. This is the first one that has been supported via Patreon!



Constructing a Fractal, using recursive logic, coroutines, and randomness
Use recursion, a coroutine, and randomization to grow your own 3D fractal.

 

I'm working on my next tutorial. It's not written yet, but you can already try the concept web player.



Maze, creating confusing office space

I'll include a first-person mode as well, if my 4th Patreon goal is reached before the end of the month. So if you like to help, become a patron today!

 

Maze, my second Patreon-supported tutorial, is now done!



Maze, building your own randomized place
Generate a maze with different room types, then walk around in it.

 

Here is my third Patreon-supported tutorial!



Curves and Splines, making your own path
This tutorial will take you from creating a simple line all the way to editing your own Beziér splines.

 

The tutorial for August is all about pseudorandom noise.

 

There's a new tutorial that is about analytical noise derivatives and neat things you can do with them.

 

These are great Jasper, some really interesting ideas here. Thanks for sharing!

 

@MattSchell My pleasure! Made possible by my patrons.

 

Here is a new tutorial! It has been commissioned by Binpress, so it's published on their website.

Octahedron Sphere
Create an approximation of a sphere by subdividing the faces of an octahedron. This tutorial was commissioned by Binpress.

 

Following the previous two noise tutorials, I have written about Simplex noise.

Simplex Noise
Discover how to create alternatives for Perlin and Value noise, based on a simplex grid.

 

I've started a new tutorial series about Marching Squares. Here's the first one.

Marching Squares
Build an editable 2D voxel grid, then triangulate it with the Marching Squares algorithm.

 

The second Marching Squares tutorial is now online!

Marching Squares 2
Add vertex sharing and flexible edge crossings to Marching Squares.

 

And here's the third part of the Marching Squares tutorial series!

Marching Squares 3
Enhance Marching Squares with Hermite data, then reconstruct sharp features and resolve ambiguous cases.

 

On to the fourth part!

Marching Squares 4
Refactor Marching Squares a bit, then add walls to give it some depth.

 

The fifth and final part of the Marching Squares series is now available.

Marching Squares 5
Make Marching Squares more colorful by adding support for multiple materials.

 

Swirly Pipes is my first tutorial specifically for Unity 5. It can be considered the spiritual successor of the old Runner tutorial.

Swirly Pipe
Create a prototype racing game where you move through endlessly twisting pipes.

 

You can now also try Swirly Pipe on your iOS device. Touch input delivers quite a different experience compared to desktop.

 

Change of approach! From now on I'll release more frequent, smaller tutorials.

This time it's a dedicated tutorial about the basics of meshes.

Procedural Grid
Create a simple grid of vertices and triangles.

 

Not as soon as I hoped, but here's the next one!

Rounded Cube
Use your knowledge of grids to build a rounded cube.

 

@Jasper Flick

It's seldom I find tutorials that genuinely impress me. Well done!

Your explanations, demo animations, and organization make it enjoyable to read and digest.

 

Thanks @Rick Love! It's good to hear that my tutorials are useful.

 

Really enjoying the vertex manipulation tutorials. Very cool. Thanks for sharing!

 

@renaissanceCoder1 My pleasure!

 

This time it's all about math!

Cube Sphere
Turn a cube mesh into a sphere, then use mathematical reasoning to improve it.

 

Great tutorials. They are great to work on if you can only put an hour or two in at any one time. One thing I would change though is where your variable names are often the same as their type, or method. For example, from the Fractal tutorial:

Code (CSharp):

1.     public Mesh mesh;
2.     public Material material;
3.    
4.     private void Start () {
5.         gameObject.AddComponent<MeshFilter>().mesh = mesh;
6.         gameObject.AddComponent<MeshRenderer>().material = material;
7.     }

Too many meshes and materials! This might be a bit clearer:

Code (CSharp):

1.     public Mesh fractalMesh;
2.     public Material fractalMaterial;
3.    
4.     private void Start () {
5.         gameObject.AddComponent<MeshFilter>().mesh = fractalMesh;
6.         gameObject.AddComponent<MeshRenderer>().material = fractalMaterial;
7.     }

 

The context of a variable or field gives you all the information that you need. In the context of the fractal, when we talk about a mesh, it is the fractal's mesh. And if we access the mesh of a MeshFilter, it is the MeshFilter's mesh. It is beneficial to get good at parsing these contexts.

If we were to explicitly mention context in the field names themselves, then MeshFilter would have a meshFilterMesh instead of just a mesh, and a MeshRenderer would have a meshRendererMaterial instead of just a material.

 

If thats the case, why not call 'mesh' 'a', and 'material' 'b'? By your argument those variable names are just as valid because everything you need to know about them can be derived from how and where they are used.

Calling 'mesh' 'fractalMesh' makes sense because it is the mesh we want to build our fractal with. The same goes for 'material'. It makes each line of code more readable because one does not need to refer back to other parts of the code in order to determine what those variables are for.

 

The context of that quote is about prepending stuff to a sane variable name; comparing "mesh" with "fractalMesh", not "mesh" with "a". Single-letter names can be perfectly fine, but usually not as field names for complex types.

That something makes sense doesn't mean that it is necessary. When looking at code, you must know its context. Which class? Which method? Usage of a mesh field inside the Start method of some fractal class tells me all I need, provided the code is structured well. I do the same with speech. If I were to talk with someone at length about the fractal class, I would just talk about its mesh. I wouldn't explicitly say "the fractal's mesh" each time. And if the other person is paying attention, they will understand.

But that's just me. If many people had trouble with my approach, I might change it; but this is not the case. Of course you're free to code in your own style; that's much better than copying my code verbatim.

 

In your code you have a variable 'mesh', of a the type 'Mesh', which gets assigned to another variable also called 'mesh'. Do you not see how this might be a little confusing, especially to someone learning to code? And why is having a variable name the same as its own type a good idea?

 

Are you personally confused, or are you speaking for a hypothetical newbie? I won't change my ways, but I can always add clarifications to tutorials when needed.

The name and type of a variable are two separate things. The type has no control over the name. Without context, it is neither bad nor good.

 

No, I'm not confused. Far from it. I have a degree in computing, and have programmed in Basic, Pascal, Fortran, C, C++, and assembly for Z80, Intel, Motorola, and Atmel procesors, so I find your tutorial straight forward and easy to follow. The point I'm making, and one which you seem intent on ignoring, is that your naming conventions go against what is considered best practice, or at least what I was taught as best practice.

All programming courses I've taken stress the importance of clear, readable code, which includes how one names ones variables. I can tell you that if I'd made an int called int, for example, or a Mesh called mesh I would have lost marks on my coursework.

I'm well aware of that, but can you really not see that having a variable named the same as its type is bad practice?

 

You didn't make your point explicit until now. I go against what you were taught, apparently. Yet my code appears straightforward and easy to follow.

 

Yes, you're right. I should have pointed out the difference earlier between how you write code and how I was taught to write code.

Oh for goodness sake! It makes sense to me because I have experience as a programmer and because your code is quite short, not because of the way you name your variables. I imagine that your style of naming variables would make things un-necessarily harder to follow on a larger project.

 

Noted. End of discussion.

 

This time we're smashing nucleons together and measure our frame rate while we do it.

Frames Per Second
Design a test scene to tank your FPS, then measure it with your own counter.

 

While I do think these tutorials are great and unique, I admittedly have been coming back to this thread to watch the gyro-Jasper argument.

 

Here's the next tutorial! I had to cover the object pools subject at some point.

Object Pools
Create a fountain of stuff, then feed it with your own object pools.

 

Here's a new one.

Mesh Deformation
Take any mesh and turn it into a deformable stress ball.

 

I have published the first part of a new tutorial series! It is a series about hexagon maps. Lots of strategy games use them.

Hex Map, part 1
Creating a Hexagonal Grid

 

The second hex map tutorial is now available.

Hex Map, part 2
Blending Cell Colors

 

I'm now also producing a tutorial series about rendering.

Rendering, part 1
Use matrices to transform space.

 

Hi there, having fun with your tutorials as always. Ran into a problem here, the script would not create the rigid body component, had to add it manually through the editor to both prefabs, any idea why that might have happened?

 

@Cainebog The RequireComponent attribute makes sure that the required component is added when you attach this component to an object. However, if you add the attribute later it won't retroactively enforce it. So you might've added the component before you included the RequireComponent attribute (or saved the script only later). In that case, you'd have to add the rigidbodies manually, or delete and reattach the component.

 

Thanks for the feedback, Working through another of your tutorials, The object fountain. Proving tricky as well. Thanks for the help.

 

Hi Jasper,

Coming unstuck quickly on this one, was fine with previous particle generator tutorial but quite soon into this one had issues with the following error and am a little puzzled.

IndexOutOfRangeException: Array index is out of range.
StuffSpawner.SpawnStuff () (at Assets/StuffSpawner.cs:23)
StuffSpawner.FixedUpdate () (at Assets/StuffSpawner.cs:17)

here is the code from relevant script, not sure where the problem is.



using UnityEngine;

public class StuffSpawner : MonoBehaviour {

public float timeBetweenSpawns;

public Stuff[] stuffPrefabs;

float timeSinceLastSpawn;

public float velocity;

void FixedUpdate () {
timeSinceLastSpawn += Time.deltaTime;
if (timeSinceLastSpawn >= timeBetweenSpawns) {
timeSinceLastSpawn -= timeBetweenSpawns;
SpawnStuff(); //this is line 17
}
}

void SpawnStuff() {

Stuff prefab = stuffPrefabs[Random.Range(0, stuffPrefabs.Length)]; //line 23
Stuff spawn = Instantiate<Stuff>(prefab);
spawn.transform.localPosition = transform.position;
spawn.Body.velocity = transform.up * velocity;
}
}

Any insights would be appreciated.

 

@Cainebog You have to put the prefabs into the stuffPrefabs array, via the inspector. Just like with the nucleons. Otherwise, there isn't anything to spawn. See the relevant screenshot in the tutorial. I now mention this explicitly in the text as well.

 

Another Hex Map installment is now available!

Hex Map, part 3
Give cells different elevation levens and connect them with terraces.

 

Rendering, part 2: Shader Fundamentals
Write your first shader, from scratch

 

Hex Map, part 4: Irregularity
Perturb cell edges and elevations to produce a more natural map.