Rachel is an Edinburgh based programmer, who despite working in the game industry, continues her passion for development outside of work. She was kind enough to answer some questions.
In a new series of interviews, I hope to speak with a bunch of Edinburgh based creative types, who are making games in some capacity.
Rachel is a regular attendee at the EdIndies and GameDevEd meets, and one of the first people I've quized on their work. Rachel was kind enough to answer a few questions I had about her studies in game development also.
She recently graduated from Abertay University in Dundee, after studying their popular Computer Games Technology course. Featuring a mixture of practical programming and applied mathematics, the course is fairly well known among those who are looking to work in the games industry.
Since graduating, Rachel has moved to Edinburgh and joined the ranks at Rockstar North as a Junior Network Programmer. She continues to attend and volunteer at local events.
That's a tough question to answer! I remember making drawings of my ideas for games when I was as young as 8 -- does that count? For real, I think the first time I felt like I was actually involved in actual game development was in my first semester of university and participating in the Game Development Society. I'd attempted to make games before then but I think it had always been a solitary, difficult and mostly unproductive experience.
When I was around, the idea was everyone would form teams at the beginning of the semester, then make a game. Each week teams would be invited to present their progress in front of the rest of the society. If there were lots of teams presenting it could go on for ages but many people had a lot of fun doing it. Even if they didn't end up with some incredible new game, they might have gotten some entertaining or educational presentations out of it.
There was also the occasional workshop, for example one about how to use source control. Source control systems (e.g. SVN) weren't taught in any of the university's courses until 2nd year, usually. Even then, coverage was brief and using them was not required.
Quite good, on the whole. I learned tons, from the course, from the lecturers and lab helpers, from my classmates and from whatever I could find in books and on the Internet. The staff were extremely helpful, not just in their roles as dishers-out of knowledge and advice but also as people who genuinely cared about my wellbeing and helped me get through some difficult times.
AMPS is a third year group project. Play it on itch.io.
I think one of the most valuable things I got out of university was exposure to lots of people I felt similar to and could learn from. People who were passionate about playing and making games. People who were also trying to figure out aspects of their identity they hadn't really had space to explore before.
As mentioned before I participated in group projects as part of the Game Development Society. In my spare time, which I had quite a lot of when I was avoiding coursework and other responsibilities, I would tinker on all sorts of things, picking up new game engines or languages or trying to implement particular algorithms or designs. I'd also read a lot about game development, and I still do. One of my favourite books about programming is Game Programming Patterns by Robert Nystrom. I have a print copy of it now and I like to leaf through it sometimes and re-read sections. There's nothing quite like a good rummage through a good technical book.
Linear algebra is fundamental, but you shouldn't go learning it by reading maths textbooks and doing pen-and-paper practice questions. Learn by coding. Write a 2d vector class and a set of operations on it, then make a wee game or two using that (Asteroids is a great starting point). Then go up to 3 dimensions. And so on.
Graph theory is a topic I'm glad I took an interest in. Even the basics are helpful for understanding a host of computing problems. Also Introduction to Graph Theory by Richard Trudeau is the one maths book I would recommend to anybody. It's concise, well-written and explains the fundamental elements of the subject, along with giving useful insights into what exactly maths is.
There is a huge element of trial and error. I think that's simply the way it has to be. When I approach a problem, even one I might have faced before, I like to check my understanding of it and try multiple solutions to see what works and why. I have quite a meandering learning style, so it makes sense to me that my approach to work is similar. On the other hand, I wouldn't be able to manage that iterative workflow without organization. I like structure and I like to know that experiments in one area won't destabilize things elsewhere. I also like to have a general picture of where things are going in a project.
It wasn't supposed to be a huge task. It started as a continuation of some learning exercises I'd done with implementing an old-fashioned pseudo-3D renderer. I wondered if I could use a similar technique to render a 2-dimensional Box2D world (Box2D is a 2D physics engine) as if it were 3D, and it turned out I could. And then I wanted to create some kind of game using this renderer I'd made, so I started adding components to it. Then I realized I needed more functionality, and in order to add that I'd need to rework some of the existing functionality, so I did that. And so on. I'm not sure where it ends, but the process is rewarding in itself. It just doesn't necessarily mean I'll ever finish a game.
A couple of years ago I was worried that I might be one of those people who gets sucked into making The Perfect Game Engine for years and years. One year into this project, I'm afraid to say it looks like I've caught that particular bug.
It's a fuzzy end goal. I can see myself working on it for years, if I find that people (myself mainly) want new features or improvements. The immediate goal, however, is just making one game with it.
I see so other people making incredibly cool stuff and I just want to be one of them. It's as simple as that.
Anyway, motivation is only half the battle -- you have to actually do the work. This usually means planning my time, going along to things like edindies, and using various psychological tricks to ease myself into doing things I don't necessarily want to do or feel like I have the energy for. I believe a big part of being a productive programmer is understanding how to activate focus. What I try to do is make sure that if I'm going to be working on my big project (the engine) I have a long, uninterrupted block of time set aside for it. Then I start with some small, trivial tasks, encouraging myself with a feeling of progress, building up energy. Even if I bail on doing the bigger thing I sat down to do, or only get halfway through it, I'll still have made a little headway on something.
It's also important for me to avoid having a zero-percent day. The longer you're away from a project, the longer it takes to get back into it.
Finally, do everything you can to reduce friction the moment you start to notice it. Those little annoyances -- how it takes a little longer than you'd like to open a file, how your tools might let you do the job but it takes a few more mouse clicks and key presses than it really should -- all add up. They make it harder for you to make progress and find the motivation to open up your project and get to work.
I ask or search for help. Then I ignore the help and do my own thing. Then I listen to the help and eventually I come up with something that works. Then a year or so later I encounter the problem again and I look back and realise I tackled it in a totally ridiculous and crappy way, throw out my old solution and start from scratch.
You will be advised to print a lot more business cards than you'll actually use. Don't fall for it!
Also, get in there and chat to people. Especially people who are demonstrating their games on the expo floor. Such people are probably tired, hungry, sore in the feet and bored from waiting for attention. They will leap at the opportunity to talk about their work or their lives in general. You may make new friends from all over the world.
If you are demoing a game, keep your eyes peeled for people who look like they want to come over and talk or try out the game, but are too shy. Rope them in with a friendly wave.
Finally, San Francisco is very, very large. If you're travelling across it to some venue, especially if it's not central and even more especially at night, get a ride.
Find a mentor or two, people with a lot more experience than you. Also find people who are at a similar experience level to you. Stick to these people like a limpet, ask them about what they're working on, what they're learning, and share your own progress with them. Really the most important lesson you can learn is how to ask the right questions and help other people do the same.
Thank you Rachel! I hope this is useful for those interested in game development. You can see more of Rachel's work below:
As I mentioned before, I intend to interview other local developers and artsts about their projects and their approach. If you're near Edinburgh and looking to get more involved in game making, there are a few different groups which are worth checking out!
GameDevEd is a fortnightly social meet for game makers and enthusiasts, meeting fortnightly on Tuesday from 7PM at OX184. All are welcome, regardless of skill level!
There's also EdIndies which runs every Saturday in Levels Cafe and Lounge from 1PM. Ideal if you want to work on your game in the company of others.
Additionally, there is a growing online community in the Edinburgh Game Developers channel on Discord. New members are always welcome.