You can create and name properties in shader graph using the Blackboard
These names really just serve as labels, so if you want to access these properties via code (to use material.SetColor, for example) then you need to peek at the shader code.
Right-click the master node and select 'Copy shader'
Paste that into text editor of choice and look at the Properties code block at the top
My property was named _ColorTest and the actual name of it is Color_A2.. etc
The yield statement is used by iterators to make life easy for them (this part could potentially be explained better. Iteration is the act of repeating a process. Usually, when people talk about working iteratively, they are talking about working, making a small change or fix, then continuing to work and repeating that process, as opposed to doing it all in one go and fixing everything at the end. In this case, I think the sentence is talking about iterative functions and loops.).
To make enumeration possible, you'd need to keep track of your progress. This involves some boilerplate code (boilerplate code refers to code that has to be included in lots of different sections without being changed eg declarations or the basic empty template in HTML) that is essentially always the same. What you'd really want is to just write something like return firstItem; return secondItem; until you are done. The yield statement allows you to do exactly that.
So whenever you're using yield, an enumerator object is created behind the scenes to take care of the tedious bits.
Alternate definition: 'The yield statement is a special kind of return, that ensures that the function will continue from the line after the yield statement next time it is called.'
How do coroutines work?
When you're creating a coroutine in Unity, what you're really doing is creating an iterator. When you pass it to the StartCoroutine method, it will get stored and gets asked for its next item every frame, until it is finished.
The yield statements produce (return) the items (actions?). The statements in between – the stuff that you want to happen – are side-effects of the iterator doing its job.
You can yield special things like WaitForSeconds to have more control over when your own code continues, but the overall approach is simply that of an iterator.
Alternate definition: 'A coroutine is like a function that has the ability to pause execution and return control to Unity but then to continue where it left off on the following frame.' (source)
If you notice that I'm posting more regular blogs, it's because I want to also use this blog as a sort of personal notebook where I store things that I find useful, but other people might also like (inspired my friend Ming Wai's blog)
I will still post bigger blogs every now and then, but I also want to write about smaller things to remind myself about them or understand them better.
Disclaimer: I have worked at Unity since September 2016, but this is not a marketing blog or anything like that. This is my personal blog with my genuine experiences and reactions. Also, my boyfriend works on the Shader Graph team, but he wasn’t actually even in the country when I was making these.
***THIS IS NOT A TUTORIAL***
If you’ve ever played any of my games, you will know that I am definitely not an artist. Art is fun and I appreciate it, but I’m not good at it.
For those new here; hello, I’m Sophia. I’ve been working as a programmer for a few years (in various roles/companies). I studied Physics at university, and I’m pretty good at maths, so I have been asked to help when my friends have had issues writing their shaders before. Small stuff like figuring out relationships between variables etc.
While I’ve always wanted to make shaders, I never really knew where to start. It felt very counterintuitive to write code relating to visuals but with no visual feedback.
During Scenario Test Week at work, my team has been working on a golf game. I was working on pickups/modifiers, and I wanted some cool effects to happen when certain modifiers turn on. My initial thought was ‘I need fire’. Since 2018.1 is the release that includes Shader Graph, it felt like the time had come for me to finally make my first shader.
I was going in pretty much completely blind. I just started adding nodes.
I’m not sure why I thought the Hue node would be relevant at all, but it turned out pretty fun. It's not included in the gif, but the Time node is definitely involved here.
I came back to this “Disco Fire” later. I didn’t want to get distracted before I even started.
Time and noise were definitely relevant, but I just didn’t really know how. Most of these connections are definitely irrelevant, but I wanted to show what I actually made.
So this sort of resembles fire, but it’s definitely not great.
At this point, I went back to the Disco Fire, because it was way more fun. This ended up being used on the golf ball when the speed boost is applied, so I was pretty happy with that one and moved on.
I don’t know why I didn’t include all the nodes for this one :( sorry. It's meant to be lava-ish.
I guess with this one I was going for like a… moss… thing? Idk. shaders, man. The checkerboard node was because I wanted to input more than one colour, and the Voronoi noise was because I wanted it to be sort of blobby (like lava).
This one is definitely my favourite, and I actually started to kind of understand what I was doing. As you can see, there are a lot fewer pointless noodles, and the final look is a lot closer to the lava effect I was trying to achieve. I ended up using this one for the slow ball pickup because it made me think of stone.
Here’s each of them before I added shadows. I was backporting these shaders to a Unity project that wasn’t using the Lightweight Render Pipeline, so I had to make a few changes to the shader file (I don’t want to go into this in this non-tutorial, but happy to make a separate post showing what I did, if anyone wants.)
Aaaand here's my lil test scene showing the fast ball in action (with shadows!)
So that was my experience with using Shader Graph to make my first ever shader! Hopefully this will encourage more people to try using it because it's really not as scary as it looks.
Yep, that's right. I've been thinking about custom Unity editor windows so much that I had a dream about them.
I originally wanted to make editor windows to create some in-editor tools, and automate certain processes. I had been experimenting and playing, but I hadn't really made anything functional. Then I had the dream.
Making an editor window itself is pretty simple. I was able to follow the Unity docs to make one when I first started learning. If you follow that documentation, you will be able to create an editor window. It won't do much yet, though.
Unity editor window scripts derive from UnityEditor.EditorWindow as opposed to UnityEngine.MonoBehaviour, and I needed to figure out how to get clicks and events from the custom window to affect game objects and other UnityEngine objects. After a lot of searching, I found a tutorial on The Knights Of Unity, and I was able to use the examples they provided to help me.
Since I already knew how to create editor windows, I had gotten as far as:
Apologies for the weird Gist formatting.
This gave me an editor window with a toggle (defaulted to false/unchecked), but it didn't actually do anything.
Obviously, I needed a way to find a way to make this toggle's event actually trigger an action in the scene. For this, I needed to make use of EditorPrefs. Making use of what I had learnt from The Knights Of Unity's blog, I created the following script:
The script has a public bool (with some editor-only properties), as well as a public reference to a GameObject which gets turned on and off in Update(). This is great, but it means I need to change the window script from
mangoEnabled = EditorGUILayout.Toggle("Mango Toggle", mangoEnabled); to ClickToMango.mangoEnabled = EditorGUILayout.Toggle("Mango Toggle", ClickToMango.mangoEnabled); which references the bool in the ClickToMango class/script.
My Click To Mango dream became a reality.
Could I have done this just using a regular script in the inspector? Yes, probably. Did I learn more about how custom editor windows by doing this? Yes, definitely.
Disclaimer: I started working for Unity in September 2016. When I reccomend Unity resources, it's because I genuinely use/love them, not because I work for them.
I get asked this a lot; "How did you teach yourself to code?" (or at least, variations of the question). There are a lot of guides out there, and everybody is different, but I'm going to talk specifically about what worked for me.
I thought about separating this into sections based on age and desired programming language, but I am not an expert, and like I said, everybody is different. However, if you have any questions about teaching yourself (or your kids!) to code, I am always happy to help :)
In this post, I'll talk about what I actually did and what I used. There may be a few tangents, but that's why it's a blog! This won't necessarily be chronological (certain things I used don't exist anymore, or I discovered things later on which would have been useful to me in the beginning).
I will start by saying that yes, I did get the very basics in school, but I didn't take special classes or anything like that. I have no formal computer science qualifications. It was just ICT classes.
The basics
The truth of it is, I started learning to code before I was even trying to learn to code. For me, the first step was logic. I remember using a program in primary school which involved giving commands to a little shape so it could move around the screen. I can't remember what it was called, and I barely remember what it looked like, but Scratch is a much cooler, better version of it.
Scratch is totally free and it's really fun to use. It's aimed at kids, but it will really help anyone get to grips with programming logic.
There's also games like Lightbot (also available on mobile) which I used in the very beginning. A perfect way to turn commutes/waiting rooms/lunch breaks into a quick programming session.
More recently, I discovered Human Resource Machine by Tomorrow Corporation (they also made World of Goo and Little Inferno). It's a really fun game and you don't need to know how to program to play it.
If you're new to programming, this game is great for learning some logic. If you're already comfortable with coding, this game has several levels which get progressively harder, and it's really good for stretching your programming muscles :) I like it a lot.
The first language
For me, picking my first language was easy. While studying Physics at university, we used a program called MATLAB (I'm not linking to it because I'm not recommending it). We used this program for data manipulation etc. It wasn't the most fun thing in the world, but I found myself enjoying it. MATLAB is actually its own programming language, apparently, but I never got too into it.
One semester at uni, we started working on a magnetometer for geomagnetic storm detection. It was really cool (I wonder if I'm allowed to post the paper I wrote for it...) and my tutor was using Python for some of the data manipulation on the back-end. I thought it was so cool. I applied to do a summer internship with him, but they weren't allowed to have unpaid interns, and couldn't pay me. This was shortly after the Raspberry Pi came out, so I bought myself a Raspberry Pi 1 B.
Pictured: Raspberry Pi 3
I've written about Raspberry Pi before, but I basically used it as my Python machine. I didn't use a fancy IDE (integrated development environment) or anything. Just a text editor, the command line, and IDLE (which is bundled with Python).
I can't remember if I used any Raspberry Pi specific tutorials (if I did, they haven't stuck with me) but I know that I spent a lot of time working through Invent Your Own Computer Games with Python and I loved it. Whenever I want to practice my Python skills, I go back to this book.
While I was learning Python, I graduated uni and got a job at Reloaded Productions as a QA tester. Basically a dream job for any lover of video games. The office had around 22 people when I joined, so I got to know everyone pretty quickly, and soon enough everyone knew my deal- I was a physics graduate using Raspberry Pi to teach myself Python. I had the elevator pitch down.
Eventually, I moved onto Learn Python The Hard Way. People seem to have really varying views about this. I thought it was okay; I just wanted to learn from a different angle, just to make sure I covered everything.
I was very lucky in that some of the engineers at work took an interest, and were happy to look over my work and give me tips. They basically became my mentors. If you can find someone willing to do this, definitely take them up on it.
Soon enough, I was given small tasks and bugs to fix. My mentors told me that one of the best ways to learn to code is to read other peoples' code, and they were right. Looking at old code and figuring out what was happening was really helpful. You start to see patterns, and you become more comfortable reading and understanding the code.
The next steps
So I had Python under my belt. I wasn't an expert, but I sort of knew what I was doing. For me, the next language was C#. The tools we used at Reloaded were mostly WinForms, and I had been wanting to get into Unity, which also uses C#.
The resource I recommend to EVERYONE who wants to learn C# is Microsoft Virtual Academy. C# is developed by Microsoft, so they are very trustworthy :) My favourite tutorial series is C# Fundamentals for Absolute Beginners by Bob Tabor.
The series is well paced and very easy to follow along with. I didn't have dual monitors at the time, but I would pause when I switched to Visual Studio to type out the code he was going through. I did this every day after work for at least an hour, and at weekends too. Learning C# got me promoted to Tools Engineer at Reloaded.
One of the best things about working as a software engineer was coding every single day. I know that seems obvious, but my first 6 months or so were spent fixing other peoples' bugs. Like I said in an earlier section, reading other peoples' code is a really great way to learn. I also got to look at so many different projects and work with different developers, which then gave me ideas for creating my own tools from scratch. Some of those tools are now hosted on my GitHub (after being re-jigged a bit).
So at some point during all this, I went "Hey, I started all this because I want to make games. I should learn how to make games by myself". Working at Reloaded taught me so much about the development process and working as a team, but I wanted to know how to make games by myself. When I first started learning Unity, the tutorials were mostly user-made, but there were some good ones, and I made do by experimenting.
I think this was my first official Unity tutorial (but I think it was an older version because I'm sure I did it in 2014..) and then when Roll-A-Ball came out, I worked through the whole thing. If you've never used Unity, I recommend starting with Roll-A-Ball. It covers so much ground and it's really good at showing you the basics. When I volunteer at CoderDojo, I work through Roll-A-Ball with the kids who are new to Unity.
When I was still figuring out which engine I wanted to use, I played around a bit with RPG Maker.
RPG Maker uses very little code, but you can write scripts in Ruby. I didn't go back to RPG Maker, but I did start learning Ruby. I can't remember where I found the tutorial for this, unfortunately, but I think it was on Steam.
I'm going to pause a bit here. I nearly forgot to mention Stack Overflow! Stack Overflow is the saviour of so many programmers. If you've got a question, either it's already been asked and answered, or you can ask it and someone will help you out. It can seem a bit scary to ask (the moderators are very strict), but here's an example of something I asked, in case that makes it less scary.
Of course, I need to mention MSDN, too. Writing or reading code, and confused about a method? Highlight it in Visual Studio and press F1, or google the method name followed by "C# msdn" and you will find Microsoft's excellent documentation. I've even cited MSDN in my code comments before. I use it all the time.
Before I left Reloaded, I was the lead engineer/architect on a project called Foresight. This was the largest tool I ever created, but it got me used to working as part of a very small team. As tools engineer, I kind of got on with my own thing, but with Foresight, I was working one-on-one with a UI/UX designer, and figuring out how to make this tool desirable to QA teams. A lot of my previous work was not super user-friendly, so working with a UX designer was really eye-opening. Part of being a good coder is making your end-products usable, I think :)
The present
As mentioned in the previous section, I started learning Ruby. The best resource I've found to start this is TryRuby.org. When you finish it, you get recommended courses on Code School to continue your training. The Rails For Zombies courses are really great.
After starting to work at Unity, I took the Unity Certified Developer exam. At the time, I had the fastest time to beat (I took 26 minutes, the exam is meant to last 90 minutes) but I have since lost my crown. The certification is a nice way to be like "Hey! I know what I'm doing!", especially for people like me with no formal qualifications :)
I mostly use Unity is during game jams or when I'm prototyping an idea. A recent jam game I made was Fox Forest - this was meant to be a vertical slice of a larger game we wanted to make, but doing the game jam made us realise that the project was too large for two people with full-time jobs to make alone. I still learned so much from making it (and from failing to turn it into something larger) and I know that I'll continue to learn more in future game jams. I do use Unity to make tools too, but I'm going to write a separate blog about that.
I'm still learning to code. I think everyone is. No one has mastered everything- there's always something new to learn. I practice as often as I can, and I recently found an app called Streaks which I've started to use to keep track of my coding practice (mark on the calendar when I've done an hour of code, and try to keep the streak up) and I post on GitHub fairly regularly, but not as regularly as I'd like to.
My goals for the future are to keep working on my own stuff. If I have an idea for a game mechanic, I'll prototype it. Cool app idea? Prototype it. Basically, I'm just not going to stop working. I don't think engineers ever do, really.
I used to draw all the time. As a kid, I wanted to be an artist. Studying art at GCSE kinda beat that out of me, and I haven't really drawn for fun since. It's hard to find time to sit down and make art happen. Work is long and tiring, and I don't ever feel like doing much when I get home.
But, the games I wanna make need art, and I'd like to do it myself without resorting to crappy MS Paint drawings. I know I'm capable to drawing, I just needed to get back into it.
Some of you may know that I'm a huge Harry Potter fan. I've got a Deathly Hallows tattoo, and I read the books around twice a year.
On Monday, I'll be visiting the Warner Brothers studio in London to go on the Harry Potter tour. Needless to say, I'm really excited. My excitement spurred me to get out my sketchbook and draw. I could've practised just by drawing anything, but I know Harry Potter so well, and I have such a clear picture of what they look like in the books in my head, so why not draw them?
It didn't start out well. I kinda wanted to see what I could do from memory, and without any real practice. As in, I just went for it. It was mostly just random sketching so I could remind my hand what it feels like.
Gryffindor common room
Harry in the cupboard under the stairs
Later, I decided to actually look up some tips about how to draw people, and I tried to develop my style. Realistic stuff is fine, but it can look really bad unless you're 100% amazing at it, imo (I've always thought cartoonish drawing are cuter anyway, and I think they're fun).
Not bad, I guess?
I kinda wanted to draw this picture of Emma Watson; partially because I love it, and partially because I wanted to practice facial expressions. I started out wanting to make it cartoon-like (hence the eyes), but I kinda felt like the shading in this photo is most of what brought across that expression? Idk but I went with it, and it kinda turned out weird.
Tbh I started to get bored, Realistic drawing is not really my jam, and it didn't even look good. Instead, I decided to bring together all the practising I'd been doing and see what I could do with Harry. I wanted to do something that looked bold and cartoonish, but not chibi or manga... Idk, I just wanted to see if I could develop my own style.
And I'm not that mad at it?! Even if he does look a bit manga. I wanted to do something distinctive with the eyes, because Harry's eyes are such a big part of the books (and I remember reading that they were almond-shaped, so I wanted to emphasise that). Obviously I still need a lot more practice, but I'm actually okay with the Harry drawing. I mean, look at how grumpy and disinterested he looks! That's what I wanted! I was aiming for pre-Hogwarts Harry, you see.
I'd like to get out my watercolours at some point and add some colours to these drawings. Bold lines with a soft palette could look strange, but meh, I wanna try! I love painting with watercolour.
Anyway, I just wanted to share my doodles. I don't know.
