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.
