- ARPDAUPosted 2 years ago
- What’s an impressive conversion rate? And other stats updatesPosted 2 years ago
- Your quick guide to metricsPosted 2 years ago
What do employers look for when recruiting game developers? [Gamesbriefers]
Free-to-play game design is iterative, responsive and agile. That changes the nature of the programming skills and attitudes that you need. What are the attributes that you look for in a game developer when recruiting?
This applies as much to products as to services and as much to developers as to all your team. You should be building iteratively and agilely – waterfall produces junk. Coders, designers, artists and everyone else involved should be able to create, review then amend throughout the process.
The challenge has been more on the designer side than on the engineering side. Dev Ops will deploy frequently and regularly, but the engy side seems about the same as with any software project. The big changes are for the designers. They/we need to learn to build mechanics that can be tuned while live. Lots of analytics to see the state of the game and server side data to make changes.
Open-ness and curiosity along with intelligence and fearlessness.
We are very early into this new model, and even in the rare circumstance that you have some experience, you will guaranteed still have an enormous amount to discover and learn.
Scattered is a blend of experienced F2P people looking to improve their chops, along with traditional games development veterans who want to learn, try something new and future-proof their careers.
Anyone with a hint of cynicism or closed-mindedness is not going to be comfortable.
Provided you know the skillset needed from a tech perspective we look for someone who is open minded, willing to learn and unlearn, able to collaborate and share. We also want people who are nice to others, can raise a smile and want to be part of a team, not their own team. ‘Seen it all and done it all before’ need not apply.
Moving from “traditional” game development (demos, retail launches, maybe occasional patches) to a live-serviced, constantly-changing, free-to-play model can definitely be difficult for some developers. We’ve seen this a few times with great quality developers who approach free to play in a similar way to retail and create very fun games but ones that aren’t able to build audiences or revenue. I agree with Bernard when he says the biggest difference is on design; engineers and artists who are used to agile programming should be able to apply those skills to a variety of projects somewhat agnostically.
While we’re generally not hiring game developers, at Kongregate we do evaluate them closely when getting into publishing relationships with them and look for similar qualities that would make a great hire. Beyond the usual points (has strong aptitude in the field, is enthusiastic, communicates well, and is someone you would want to interact with daily), you want to work with someone who understands how to free to play works and who is interested in metrics-guided (not necessarily metrics-driven) iteration and design. When I talk with someone who believes design trumps metrics entirely, that’s a red flag for difficult discussions in the long run.
You also need developers who understand and are willing to embrace the free-to-play model. It is often difficult to wrap your head around just how crucial the first time user experience is and how transient traffic can be. Then, feelings of “pay-to-win” can irk some designers to the point of making them incapable of designing, maintaining, and optimizing a successful monetization model. Yes, you want some balance of fairness for free players, but I’ve talked with developers who are completely unwilling to offer any paid items that give an advantage, and that’s a nearly guaranteed sign of financial failure. The free-to-play model is not about exploiting players, but it’s about allowing players who love and support your game to pay you for a better and more advanced experience, and some designers just can’t get on board with that.
And from our perspective, we look for developers who understand that this is a long term relationship, who are willing to continue to work with the game, potentially for years to come, to keep it growing and improving and to strengthen the audience. Launch parties have a different flavor these days – they’re less like graduation and more like a wedding. :)
This question is hard to answer as it depends on job type. As the f2p model is young with most developers the “problems” you will face are yet unknown.
Example: we do online games which last 10+ years if they are successful. So which programmer is used to write code which is maintainable for 5-10 years? Hardly any in the industry as most are used to fire and forget approach. This also includes multithreading server side. Hard to understand, not very many programmers who mastered it. Enterprise programmers are more used to this than game programmers.
For designers there needs to be a brain reset, than it works pretty much.
OOP Methodologies for creating stable software that allow it to be expanded in certain areas without falling over under the weight of bugs. This is very important. This is where whilst companies in this space might be young, there is no substitute for having an experienced tech-director/lead. Credit where credit is due, this is where a lot of coders who have worked in the console space know what they are doing and where a lot of indies don’t
My favourite thing about F2P development is that we don’t have milestones, we have releases, and that mindset is crucial: what you work on today is in front of players in a couple of weeks.
Console teams have the following but as much smaller proportions of their team: we value people with Unity knowledge; people who understand servers and databases both in functionality and when operating under continuous heavy load; people who get that the build needs to work all the time; people who understand that the core gameplay is often quite simple, finished early and (once it’s proven) not monkeyed with, so you may never touch it; and that there are many tasks that are not sexy and scream ‘I’m making a game!!!’ but which are hugely valuable – user acquisition, ads, metrics, monetization mechanics.
I’d also echo this earlier point: F2P devs need to accept the need to ask players to pay for stuff from time to time. Progress is going to be based on money as well as skill, and that’s OK. If ‘pay to win’ makes you puke, F2P may not be for you.
Increasingly, we’re looking for people who are multidisciplinary – game design, marketing, sales, technology, art and statistics are all merging into one to make a modern F2P game. Although people we hire may focus mainly on one of these areas, a broader understanding of all the things that go together to make a game are essential. With smaller team sizes and service-based projects, as a small team we think hiring extremely skilled but very specialised people is not just a luxury we can’t afford, but one we wouldn’t want to indulge in anyway. Above all, we look for people who are intelligent, curious and creative.
Of course it’s important in F2P for engineers to understand and appreciate agile methodologies, but I believe most engineers are at least familiar with agile / scrum development at this point. I think a bigger bottleneck for F2P recruiting is finding product-side employees who are qualified to operate in a data-driven design and marketing environment. Almost everyone involved with product design for a F2P title should have at least a basic understanding of statistics and the test -> design -> measure feedback loop, and the marketing group needs a fairly sophisticated grasp of quantitative methods in order to efficiently run user acquisition. Those skill combinations, in my experience, are hard to find and time consuming to teach.
I just want to have a tiny rant, aimed at anyone in this thread who claimed ‘really it’s the designers who need to change/have the new skills, everyone else is fine’ (or words to that effect – I’m sure I read a few)…
In this brave new world of digital delivery, games as a service and (particularly with independent studios) the kind of transparency in development that builds a great community – everyone on the team, without exception, must be 100% on board with the demands of fast iteration, mvp and all the rest of it.
This is doubly true in smaller teams where a single weak link can really cripple a project, but the idea that programmers, artists, musicians and the like can get away with maybe not really ‘getting’ the new wave is bonkers to me, even in larger setups.
Sure, you might be able to ‘get away’ with having just your designer (or project lead) buying into freemium/digital/mvp etc. – but a company built around ‘getting away’ with stuff is not going to last long at all in this wonderful industry of ours. We need to excel at all times.
Sorry if I’ve caused any offence, but it’s just barmy (and short sighted) to think otherwise.
That’s certainly a fair point. From my experience I’ve clashed heads more often, and harder, with designers than other members of the team, but those are admittedly my primary contacts too. The times when I talk with engineers they are generally ready to fix or change whatever is needed, but perhaps they spoiled me.