It has been quite some time since I last posted here, hasn't it? A little over half a year, in fact. Truth be told, I've wanted to post here long before now, but despite having an abundance of things to write about, none of them really gave me enough motivation to do so. Not to mention in the last two months, my life has been so hectic that this is the first weekend I've actually been able to just sit down and rest. But I digress.
A lot has happened since the last time I made a blog post on this site: I've participated in four game jams (for one of which we won the best game award), I graduated from university (again), I made a great deal of progress on several of my personal projects, and perhaps most importantly, I got my first job in the industry. Though there are a great many things I could say about all of these things, the last one is the one I really want to talk about. After all, this blog is by and large about my professional development, and what bigger thing is there than my first position in my desired career?
Granted, it's only a 6 month internship, but being placed as a technical game designer at a major studio (Gameloft, if you're wondering) is certainly a huge step for me. It's quite potentially that foot in the door that I needed. Either I make myself invaluable enough to them that they choose to keep me on after my contract is done, or I have a very nice addition to my CV. And that's not even accounting for the connections and experience I gain along the way.
Experience. That word has perhaps been at the core of all of my challenges so far. As someone just getting into the industry, there's a fairly major issue with the fact that almost every single posting you can find requires some form of experience. You need work experience to have your application recognised, if even looked at at all (I know many recruiters deny this, but I've yet to see evidence to convince me otherwise). And even if you choose to go the networking route, that requires a certain level of social experience (in other words, useful contacts). On top of that you need the luck to be in the right place at the right time, and have exactly what they're looking for. Of course, all of this makes a certain degree of sense; a company has needs, and they can't just hire a complete unknown in the hopes that they'll turn out to be good. That's a huge risk. On that front, I had the good fortune of being at exactly at the right place at the right time and having both social and skills experience I could leverage to get in. After all as I've said before, I know I have the abilities needed to be a good designer. I just need people to know it.
And that's where my new challenge lies. I've gotten into a company, at least for a few months. I've been assigned to a project. A new one at that, with a much smaller team meaning I get to have much more input than I might otherwise have had. It's intimidating, but at the same time, it's exactly the kind of opportunity I should be hoping for. But there is a snag there. I can only prove myself if I get the chance to demonstrate my skill, and in order to do that, I have to get people to listen to me.
You see, even though I've gotten in, I have no authority, seniority, or rapport with the people I work with. In other words, I have no experience. Not in this context. As a technical designer, my job more or less is to figure out the structure of a given task, and then tell the programmers what tools or features I need to execute that structure. The problem lies in the fact that even though I can easily define a system, I have to get the programmers to go along with it. This is the part that is difficult. As of the present moment, I don't think the programmers on the team fully understand just what my role is. Truth be told, I'm not entirely sure I do myself. What I do know is that on at least two occasions, I've noticed early on that an existing system I've been asked to work on was flawed and pointed out the thing that we needed, was subsequently told by a programmer that this was not the way things were built, and a week later found out that the programmer was told by someone higher up to essentially do the same thing I suggested a week earlier.
Now don't misunderstand. This isn't me complaining about my coworkers or even stroking my own ego for ultimately being right. At the time there were very valid reasons for building things the way they were built and not accepting my proposals. After all in these instances what I was proposing were akin to massive overhauls of how the existing systems worked. And I am a junior with no real authority after all. What would I know of how their systems worked? These guys not only have technical knowledge that I don't, but experience with the engine that allows them to know that certain solutions I might have taken as obvious choices to be impractical and unstable. These are fair criticisms that can be levied against me and my proposals, and I have no real defense against them. In fact, I can think of a lot of young boiterous designers who might come in and say everything is wrong and needs to be redone, when in fact they have no idea what they're talking about. There's yet to be any evidence that I'm not one of them (I mean, I know I'm not, but I do have something of a bias on the subject so its not like they can take my word for it). In the end however, the fact of the matter is that time was wasted, either by me or the programmers, on trying to force a system that didn't meet our needs to work. It's an inefficiency that has lost a modest amount of time and energy, and it's a problem I know can be fixed. After all, I've done it quite a few times before.
Something important to point out here is that I'm not entirely ignorant of how programming works. In all of the aforementioned game jams I participated in, I was the lead programmer. Part of what helped us get so far in those jams was the simple fact that being both a designer and a programmer, I could future proof and structure my code in a way that made it easy to build on as time went on. I could define the scope from both the perspectives of what we needed to make a functional game and what I could program in the time we had. But in the context of a larger company, there are way more things you have to consider. There isn't only one programmer, or one system. Sometimes the code defines the structure, and all the designers supply is the stats for it to parse. Sometimes even when both of things are working together, there's an element from another department that throws a wrench in the mix. I'd love to give more concrete examples, but I fear doing so pushes the edges of what I can say with my contract, and the last thing I want to do is jeopardise that.
Naturally, it would be easier if I had the authority to simply say "do it like so" and have everyone follow my authority. But of course, that's not how things work, at least not here. All of the problems I mentioned are natural in a team environment. One can expect toes to be stepped on, and for communication to lapse here and there. But these downsides are worth it for the wealth of benefits that having a dynamic team grants. It allows individual parts of the whole to be self sufficient and solve their own problems, in a way that's much more creatively liberating and efficient than it would be with a single dictatorial entity. The difficulty I see is when the communication between these parts is limited, and one side can see a problem than another can't or won't, either because they have a blind spot from their perspective or there are other implications that the other side might not even be aware of. How do I broach that gap to point out issues so that they can be resolved without being dismissed? Is it simply a matter of seniority? Is it a question of how I approach the subject? Or perhaps it's about whom I approach it to? Maybe it's just power politics? These are matters I still need to work on.
In the remaining month (almost exactly. The 26th of December is when I'm slated to have my first day of vacation, not including Christmas day and the weekend prior), things are going to be very hectic for me. A major deadline is looming and though the issues I've pointed out have by and large been resolved, it doesn't stop the fact that I'll have my work cut out for me rearranging things in light of these new structures. Somewhere in between that, I'm going to have to try my best to seek out an answer for that challenge of mine. If I do figure out what the magic recipe is, I'll be sure to let you know. Until then, I'm open to suggestions.
P.S. It isn't lost on me that the subjects of my recent game jams and how I got the position might also be a compelling subjects to discuss. I certainly have a fair bit to say on them. But that's probably best saved for future posts.