Judy Tyrer would have decided to become a game developer had she known that was an option at the age of 9 when she tried to figure out how to build a robot that would play games with her. She did not succeed, but her passion for games never faltered. After graduating from SMU with a double major in English Literature and Secondary Education, Judy started in the Serious Games Business at Control Data Corporation where she had the unique privilege of working on PLATO, a computer based education system.
From there Judy moved into the computer industry working on distributed UNIX operating systems, specializing in File Systems. During this time she served on the File System Committee for the Open Software Consortium and published a USENET paper on "Adding Tightly Consistent Replication to OSF's DFS".
During the "www.yourjobhasgonetoindia.com" period which decimated the enterprise software industry in the US, Judy decided to go back to her game playing robot fantasies and joined the game industry working at Ubisoft on the Ghost Recon series as a networking engineer and multi-player engine specialist. From Ubisoft, Judy moved to Sony Online Entertainment as Lead Engineer for Magic the Gathering: Tactics. She was then tapped by Linden Labs as Senior Engineering Manager of the Engine Room, the team responsible for server related software and simulations for Second Life.
Jillian Mood, IGDA: You've had a great career, staring with Red Storm, an Ubisoft Studio now a CEO of your own company, 3Turn productions. Can you tell us about your journey and why you picked the video game industry?
Judy Tyrer: I have been an avid gamer my entire life with much of my childhood spent chasing down family members begging them to play games with me. So after a fantastic career as a computer scientist in the UNIX OS work began to dry up in my area so I decided it was for a career change. My 12 YO son was talking to me about potential careers and I told him, "If I were your age, I'd go into the video game industry."
A little voice in the back of my head said, "So why do you think you're too old to do the same" and I decided I wasn't. And the industry agreed.
JM: What are some of the biggest differences you've experienced from working at a large studio like Red Storm or Sony compared to a smaller start up?
JT: Large studios have highly specialized talent which can be good but limiting. It is much more difficult to be seen as anything other than what you were hired in as. I never saw a lateral transfer and even promotions seemed few and far between.
The sizes of the team also become insulating. At one point one studio broke out of the "all programmers in one room, all artists in another" model and built teams combining disciplines which I thought was really great. I was on the game engine team. We were all engineers.
There is also a name recognition that I think plays a part when it sits on your resume. Whether looking for work or looking for investors, that name recognition opens doors. When I say I was Lead Engineer at SOE, I don't have to jump through quite as many hoops as I would if I had been Lead Engineer at Tiny Failed Game Studio.
On the other hand, if you're more of a square peg and don't like being stuck in round hole always doing the same tasks ad nauseum, start-ups offer no shortage of opportunities to try new things, learn new skills. There is always more work than there are people to do it so anyone willing to try something is usually able to do so.
Start-ups also don't have the insular team limitations of large studios. All teams are interdisciplinary because there is only one team. And you are all working with jerry rigged, duct-taped tools and equipment sharing hardships. (Small budgets have their disadvantages). There is less process and formality but that sometimes translates into more chaos rather than more creative freedom.
In large studios, the majority of the team crunching is doing so because "There are 100 other people out there that would just love your job if you don't want it." In small start-ups people are crunching because they are choosing to do so because they want to. Though in the interest of full disclosure, that could be because I will never ask people to work overtime. However, the two start-ups I worked at in the computer industry also never had mandatory overtime. We had deadlines, we were expected to meet them. For 3 Turn Productions, working overtime is a Founder only privilege. I want my team well rested so they don't make dumb mistakes from being tired. If you wouldn't let someone check in code drunk , you should not let them check it in tired.
JM: Tell us about 3turns first production, Ever, Jane: The Virtual World of Jane Austen? Sounds like an incredibly interesting project!
JT: Ever, Jane just entered Closed Beta. During this period we are refactoring two of the major systems and starting to optimize as well as bringing all the art up another level, adding new art, etc. All the core game play is in the game, but the players don't really know how to use it yet so the tutorial is being constantly expanded.
You start the game at one of two small academies similar to those in the Regency period, mostly just homes run by those in distressed financial circumstances yet still of the gentry. We use a magazine to provide the instructions for what to do through the tutorial and Stories to help give players guidance in their role play. The first four stories are designed to teach the player most of the game play systems.
The stories allow players to choose what role they want to play. Each player in a story has a different role with different goals and in some cases, only one of them will succeed. (One story not yet implemented involves two sets of parents racing to Gretna Green before their children manage to elope).
In our current Sabotage story, the object of one person's affection appears infatuated by someone else. The protagonist's role in that story is to spread a rumor destroying the other person's reputation in order to win her love interest back. The second chapter will be entirely based on whether the love interest hears the devastating story before the player can find out the lies being told about them.
We are hoping these stories will facilitate the role-play in the game and help people socialize more.
As the players move through the game they must choose personality traits they wish to improve and those become their motivations for certain activities. Some stories will require strong or weak traits which can be modified through interactions with the characters. If you invite someone of a higher status to visit and they accept out of happiness, your status will improve. If they accept out of a sense of duty, however, it will not increase nearly as much. And if they don't accept, it might actually go down.
We also acknowledge that one doesn't get something for nothing. So you must also choose a trait to sacrifice. In Sense and Sensibility, Marianne sacrifices duty for happiness. In our game that might result in not being invited to tea with a great aunt who could introduce you to society. Or if there is a Happiness ball, no doubt Marianne could attend but Mr. Darcy might well be left out.
The ball is the only mini-game we had time to put into the game. It is still a little hot pink for the Closed Beta, but it allows players to play with AI and learn the basic dance steps. We should have that polished up with a dance instructor for launch, but the first actual ball will not take place until a few months after launch. We want to give our players something exciting to look forward to.
JM: I understand you're also developing a new software to help the industry with game development? This sounds awesome! Can you explain how it will work, what it will help studios with and when it will be available?
JT: Yes, we are building Ever,Jane with a process called Fuzzy Development. The name comes from Fuzzy Logic and the process is based on the premise that "All Work Days Are Not Created Equal". By leveraging the emotional state of developers during the phases of the project and working with their natural energy flow, we can waste less time and the less time we waste, the smaller our budget. Ever, Jane will launch with a development budget of < $500K which is pretty astounding for an MMO.
At its core, Fuzzy Development is really about not wasting time. We don't do work we may throw away. We accept technical debt as a part of our process. We start the next task before we've finished the last one (that is probably the hardest part). Instead of deadlines, we have start lines and in the first two phases of the project, they never move. So where in a normal process you'd be expected to finish and if QA found a bunch of bugs you'd slip the date, in Fuzzy Development, you wrap up all the work that didn't get finished, document it, accept the debt and move on.
This purpose and the results is working the entire game as a whole unit. It is similar to oil painting where you start with a wash. At the end of the wash all you have is colors and some basic rough shapes. At the end of our "wash" we end up with all the features of the game in the game, but at proof of concept quality with giant swaths of technical debt.
And this is where Fuzzy Development saves time. We are looking just at the big picture, just at the colors and shapes and we can say "too much yellow, we need to pull some yellow" and we pull a feature or two that aren't going to work. The POC worked. If you were just looking at the POC and not the entire big picture, you might finish it because it worked. But it doesn't work in the big picture, it doesn't fit a united whole. And therefore it must go.
Voila, I just didn't spend 3 mos. working on a feature I'm not going to end up wanting in the final product!
And that is the main gist of Fuzzy Development. We have a lot more details listing the various phases of the project, the work that should take place during those phases, a discussion of "just in time design" and other features that make this process actually work. We still need to live through the final phase to launch before we can prove that part works. We are doing that now.
JM: So, with your awesome experience what advice would you give to people in the industry that want to branch off from a studio to start their own company?
JT: Take care of your finances first. Get out of consumer debt. Move someplace really cheap to live. Learn to cook. Make sure you can live for as long as you'll need to without any income. My ability to not take income for 3 years is a huge part of why our budget is so low.
Learn business. Any business. All business. Don't just focus on the game industry, it is a business like any other and you'll find so many amazing resources.
Hire a lawyer and an accountant. Your lawyer is your sword and your accountant your shield in modern warfare!
Decide how you are going to fund your business. And regardless of if you are crowd funding or going for equity investors, make sure you have the chops to convince people you can follow through. Great ideas are a dime a dozen. Can you ship product? That's what investors are going to care about.
Watch Shark Tank. You can learn so much from how they decide to invest and not invest.
If you still have your job, hang out more in the CEO office. I spent too much time in the CTO office and not enough in the CEO office. Talk to them about the decisions they are making for the company. If you are IN a studio you have such a great opportunity to learn from people doing it. Take advantage of it.
JM: A little birdie told me IGDA helped you get your first role in the industry! That's amazing to hear, is it true?
JT: Yes, it's true. I was working on my demo and I wrote a question in the engineering forums explaining the pros and cons of a push v a pull model and asked what most games do. The response to my question was, "Send me your resume" from the networking engineer. I did, they hired me. He told me that my question showed that I knew the right kinds of questions to ask and the issues that we had to deal with.
JM: Final question! If you could go back and tell yourself one thing on your first day in the video game industry what would it have been?
JT: "We can't use traditional software development techniques because fun is not a well-defined requirement" is not a myth. It's totally true.