Having worked in games for 13 years, at studios large and small and projects of the same variety, source code access has almost never blipped on the radar. The few times when we had issues with various engines for which we didn't have source, our support contracts gave us the changes we needed to ship on time. On occasion we modified the engine, only to be hit by tricky merges with subsequent releases. In general, I've found that modifying an engine should be done by engine programmers (and if a game company does enough engine development to have such specialists, it's probably not licensing any of these options).
The latest Unreal is a wonderful piece of engine software. Their blueprint system as well as their material editor and best-in-class renderer really are something to talk about. They also have a gigantic learning community. And I think their licensing terms are a good approach.
However, Unity has blazing fast compilation time on the order of seconds, a properly built play-in-editor mode, large asset and plugin ecosystem, seamless asset pipeline, and support for a modern programming language in C#. Each of these could arguably be considered a game changer in isolation, but in aggregate they are an efficiency avalanche. Nothing makes a better game, faster, than being able to go from idea to prototype in five minutes rather than two hours. It's possible to try more things, to discard ten or even fifty bad ideas for every good one, and still come out ahead. This is what it all comes down to, in my experience. And when you're done, you can port your game to over a dozen platforms (in some edge cases by simply changing a dropdown value).
That said, I'm happy that both engines are so good, because it means neither will rest on its laurels. Unreal's marketplace and Unity 5's renderer are no accidents.
I understand what you're saying, but as someone that has followed various game developers closely, especially those that do porting work, source access is a huge win in many cases.
Imagine your game shipped on a version of Unity that's no longer supported but you want to continue using it for projects or bring back an old game to a new OS platform. Without the source, your only option is to port the game to a new version of Unity. That's not so great.
But again, I'll readily admit that all of this is only a win if you have the right team with the right skillset. There are definitely tradeoffs involved.
I think at scale, that's true. But what if you're a small team, or a solo developer? Let's face it: there's no way you'll be able to port Unity or Unreal to a new platform by yourself, so that might as well not even factor into it.
I think Ryan Gordon (aka 'icculus') is proof that the right solo person can do such a port :-) Nevermind Casey Muratori or others I could name...
There are many small, talented indie developers that definitely have the right set of skills to bring an engine to a new platform, or to one that's just slightly different.
For example, porting an engine from Linux to FreeBSD or some other UNIX should be trivial, but impossible without source code access.
Now I doubt many games are going to be ported to those platforms, but imagine a 3D walkthrough program for an architectural client or manufacturing facilities where UNIX is still found.
My experience is entirely different, 3rd party middle-ware without source is almost always a pain to work with (even a pain to evaluate, sometimes you get a license-key which locks the evaluation copy to one machine, for a limited time, etc). When bugs show up you cannot simply debug-step into the middleware libraries, instead you have to do a lot of guess-work trying to reproduce the bug, and then follows endless ticket back-and-forths with support. Having the source code is also always better when integrating the middleware into your own build process, since you need binary libs that match exactly your compiler version and build settings (exceptions disabled? link-time-code-generation? etc...) I could rant on forever of how much not having source code access sucks ;)
I disagree with the importance of source code. I've saved weeks of time diagnosing issues when given the 3rd party source code compared to attempting to work with the 3rd party vendor without source access.
Also, Unreal 4 compiles in less than 30 seconds on my laptop and has a play-in-editor mode, seamless assets, blah. Also support for a modern programming language in C++11.
I've worked with Unreal Engine 3 for a few years in various companies and in all of them we modified the source code to better suit our needs and never really had much of a problem merging new releases.
As for Unity, I like what they have done, but they are falling behind recently. They are VERY slow to fix bugs and they are late on releasing needed and promised features (GUI system took them what? 3 years from announcement to release?). Also, retina macs are what, almost 3 years old and there is still no support for that (I don't know how unity works with Windows Hi-Dpi support, anyone wants to chime in?)
To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such), I might see this as a pretty substantial benefit of working at a company that uses this method. Given that, I might be willing to participate in this kind of interview process. It would probably have to be a company I already know and admire for some reasons up front, but I really want to find a place to work where everybody is pulling their weight.
I haven't seen a decent-sized shop where "everybody is pulling their weight". Different developers at are different points in their careers, and have different levels of productivity. As a junior developer, I was very slow when I first started. As a senior developer, I have produced 50% of the work for a project on a team of 8. There are only so many developers that want to work for [insert company] out in the wild.
I do sympathize with the big damage done by poor hires & problems getting rid of them - I have seen similar as well. However, a process like this will select against a lot of quality developers and not necessarily select for the ones you want to work with. It just selects for the developers that that company wants to work with who are willing to jump through such an extra set of hoops. It also tells me as a candidate that the people who are working there don't have the courage to speak out against such a process selecting against candidates not willing or able to go through the process or the leadership is too weak to figure out that this sets up a bias that isn't intended to be selected for, thus being a bad hiring mechanism.
Right, I meant "pulling their weight" in a relative sense, with the understanding that a more experienced and talented employee will do more work or do it more quickly. Maybe my desire is simply to increase the proportion of coworkers who make roughly appropriate contributions to the team effort. I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.
A trial process like this would select against lots of quality developers, true, but that isn't the real question. Instead, I want to know whether the developers who wind up being hired represent a more talented subset. I can't prove that it would, but I feel that this system would be more accurate in letting the right people through.
All that said, I like some of the gray area solutions proposed in this HN thread, including after-hours or weekend remote work on a project already in production. Not a perfect solution, given the inability to evaluate things like culture fit, but it combines many upsides of the alternatives.
>> I once had to explain how splines worked to a graphics programmer with 20 years of industry experience.
Is the knowledge of splines a major predictor of a graphics programmer's success? I don't understand why it appears to be a point of denigration here. The details of your story are foreign to me, of course, so maybe I'm missing context. But it's always helpful to remember that time is finite when compared to the seemingly infinite amount of things to learn. No one comes to work and says, "I want to suck today!"
and the amazing difficulty of getting rid of them once they're identified as such
Everyone always talks about how "amazingly difficult" it is to get under-performing people to leave, but really, why is that so? I find that simply saying
"You know, we don't think this arrangement is working out for either of us. Can you please do us a huge favor, and resign? BTW if you agree, here's $X, a perfectly respectable severance package that acknowledges that you are human being, and that this was just as much our mistake as yours."
pretty much always works (provided the company is willing to swallow $X, which if they have any integrity they should have no problem doing). You don't have to say the "this was our mistake part" of course, but that's what the $X is for, because it says it implicitly (and in a more substantial way than mere words ever could).
Of course, there's also the task of getting other people to see that someone is under-performing, which can be quite difficult sometimes -- but that's a separate issue (and if it really is especially difficult to have these kinds of conversations with persons of authority in your group, then maybe you should be moving on, as well).
Yes but by doing this they have shifted all the risks to the candidate. Unless the company is super hot or they substantially compensate financially for that risk.
"To be honest, having experienced the tremendous damage done by poor hires (and the amazing difficulty of getting rid of them once they're identified as such)"
And yet companies will still let good engineers walk out the door because a competitor is willing to pay them 20% more.
Absolutely right. I've gone through the dark times of wondering how to get the linker to stop exploding on me. And when speaking about developing a game engine, it's not just the work required to create feature X, it's the entire ecosystem. Making a sound play or wiring up PhysX is not difficult. Making fifty modules work correctly with each other is the foundation and is not easy or quick. Then there are editor tools, with modern engines providing a full editor suite that would take a team years to make. In the case of Unity, you get correct play-in-editor as well as truly live editing, which allow for incredibly rapid iteration (part of the true secret of efficient game development is being able to go from your shower "ah ha!" moment to a working prototype as quickly as possible). Then there's their asset store with a proliferation of not only art and sound but valuable scripts and entire systems or engines. And while I'm making my game, the middleware company is making my tech better by fixing bugs and adding features, with nearly-push-button support for over a dozen modern hardware platforms to boot.
I can see lots of reasons to develop a game engine from scratch, but they become less compelling every year.
The series is pretty good overall, but his endless tirades against OOP (many of which are specious) drained much of my enthusiasm for his blog. Regardless, it's still good reading and this new game project is a great idea.
Great feedback, marred by a pointless "Iron Man reference was juvenile" comment. I for one found the example spreadsheet entertaining, and it made the product more appealing to me as a result.
Well as someone in their target group (or maybe not, as someone above remarked, I don't know) I did find it juvenile. What's wrong with saying that? Or do I need to carefully construct everything I say with 'this is just my opinion' etc - this is just an off the cuff report from a first time user to help these guys out, I don't think it's reasonable to expect I'm going to be all touchy feely.
I got a chance to try this out with a first-person shooter. I was not very happy with it. It felt worse than mouse+keyboard and simultaneously worse than dual-analog gamepads. Everybody in the room had issues calibrating and re-centering themselves. I'm sure it gets better with more use, but that's just the problem: it fails a fundamental usability test, because the initial experience of using it is pretty awful and requires a significant learning curve to achieve results that aren't necessarily or obviously better than either of the current standards.
My first impression on viewing the controller is that reporting the 'location' of the thumb is going to be hard. Unlike a joystick or mouse that has a well-defined point, the thumb touches over a large area. You can find the centroid of this area - and the area will change size and shape as the thumb is rolled around. Different people will roll their thumbs differently, and there may be a mismatch between intent and physical interaction.
It'll be interesting to see how well they manage to deal with this.
I suspect that will be a feature, not a bug. I already use finger-rolling on my laptop trackpad when I need pixel-level precision. For noobs, the difference probably won't be noticeable; for experts, I expect they'll be using that technique on purpose.
To be fair, dual-stick FPS gaming and mouse+keyboard gaming has a vicious learning-curve the first time out as well. The question is whether it's worth struggling through that.
Out of curiosity, was the haptic tech in the build you tried out?
Keeping thumbs oriented seems to be the biggest challenge of a controller like this, but I as hoping the haptic feedback would help keep your thumbs in place.
This is extremely accurate based on my 11+ years of experience in the industry (across two studios). After some large AAA projects threatened people's relationships and overall happiness, many steps were taken to improve things, such as near-elimination of crunch and a high overall amount of respect for people's personal lives.
Note that I actually fit into the article's title as a 35 year old guy who doesn't plan on having kids. I will often spend a few extra hours polishing something up because I relish the end result and because it energizes me to come in to work every day. Sure, I could make "double the money for half the work" in some other industry, but I love making games and can't imagine sacrificing my passion to make some equation look better on paper. But I never pressure others to stay late, and from what I'm seeing these days, more and more studios are converting to a reasonable outlook on developer productivity and happiness.
Basically everything this guy wants is at odds with my own desires for a social network. Facebook's previously countless virality loopholes were what almost turned it into some bizarro version of MySpace, with polluted News Feeds and endless wall requests to send people coins and sheep. If G+ goes down this path, I will certainly not follow.
This "lab report" always brings back good memories because it indirectly launched my career in the game industry. I was finishing up my CS degree at UW Madison and working in Mike Gleicher's computer graphics lab in Spring '02. I had previously met Lucas through a fellow CS student (Alex Mohr, now at Pixar). At some point, Lucas was contacted by the AI programmer at Ensemble Studios (Mike Kidd). Mike, a UW alum, had seen the Germanium treatise and wanted Lucas to apply at ES. A month later, knowing how eager I was to join the game industry, Lucas mentioned Mike's email to me and forwarded him my info. Long story short, I got an interview at ES and was hired straight out of college into a dream job.
I look forward to seeing this link pop up again in a few years. :)
The latest Unreal is a wonderful piece of engine software. Their blueprint system as well as their material editor and best-in-class renderer really are something to talk about. They also have a gigantic learning community. And I think their licensing terms are a good approach.
However, Unity has blazing fast compilation time on the order of seconds, a properly built play-in-editor mode, large asset and plugin ecosystem, seamless asset pipeline, and support for a modern programming language in C#. Each of these could arguably be considered a game changer in isolation, but in aggregate they are an efficiency avalanche. Nothing makes a better game, faster, than being able to go from idea to prototype in five minutes rather than two hours. It's possible to try more things, to discard ten or even fifty bad ideas for every good one, and still come out ahead. This is what it all comes down to, in my experience. And when you're done, you can port your game to over a dozen platforms (in some edge cases by simply changing a dropdown value).
That said, I'm happy that both engines are so good, because it means neither will rest on its laurels. Unreal's marketplace and Unity 5's renderer are no accidents.