Nintendo Community Fangame Convention 2008
Guild Software Q&A

Thanks to everyone for submitting all their questions to the Guild Software Q&A session. Quite a few of the questions asked were repeats, so we were able to consolidate the questions down to only a handful.

These questions were answered by John Bergman, Managing Director and Artwork head of Guild Sofware.

-----

John Bergman : I'll open with a small preface on myself and my background. I am kind of an anomaly within the videogame industry. Prior to starting Guild Software in 1998, I had never worked in any capacity at a videogame development company, or shipped a professional game. Since founding our own company, we've managed to ship our MMO title (in 2004, with full retail presence), and build a small community around it. Thus, I have only ever worked on a single title, albeit for an entire decade, and I founded the only company to hire me. So, every month or so, when some college or highschool student emails me and asks "How do I get started in the videogame industry?", my gut reaction is kind of a bewildered "Well, uhh, I don't really know! My route was.. complicated." So, please appreciate that my answers to any of your questions must be viewed through the lens of my being kind of an unusual, indie developer. That said, let's get started..

Question 1: What do you think is the biggest difference between being an amateur game maker and being a professional?

Bergman: Mostly the work ethic and getting paid, although some "amateur" game developers work just as hard as the pros. Professionals, however, usually have the experience in working together as a cohesive team to achieve a large project. People who are very skilled in game-developer oriented areas (good coders, graphic artists, designers, etc) often tend to be fairly fiery, passionate people with big egoes; after all, they had the necessary drive to become good at whatever they do in the first place. It can be challenging to get a group of these people together under one "roof" (virtual or real), to work on a single project. The required organization, making certain that everyone is aware of the inter-dependencies (if Bob doesn't finish writing X, then Joe can't continue working on Y) is critical. Egoes can take a beating when half-developed features need to be cut in the interest of deadlines, or when major projects need to be totally reworked, and these tough decisions are all realities of professional development.

For my own company, this was an evolutionary process that we had to undergo. We were not a group of people who came to "work" for another developer, nor were we randomly thrown together. We had been building engines and demos as part of the demoscene for many years, with the friendships and history that went with that; but it was not an easy thing for us to "grow up" and learn the necessary cohesion to ship a truly complex project. People and personalities tend to be the biggest challenges in any business, and game development is no different in that regard. It's probably not unlike having a band or a theater troupe or something: a bunch of talented egotistical people who all have to get along and make something together.

Question 2: Is it easier to work in 2D or 3D?

Bergman: It really depends on the comparison. Ultimately, the difficulty comes down to the amount of detail that is needed in the finished product. Doing "3D" back in the late 90s was a pretty simple thing; these days, with all many layers of shaders and textures and mesh details, it can be on par with doing film-grade special effects work. If one was doing a "2D" project that required a similar level of detail, the amount of time would probably not be that different (although, 2D has the benefit that people can only "see" the one aspect, and can't look at the "back" or whatever).

I think the focus of this question is really "Given a 2D usage, is it easier to develop it via purely 2D or 3D methods," and that really depends on the project. For most people I know, it's easier to mix the two.. throw some bits together in 3D, then work with the resulting output in 2D, and so on. Ultimately, all these things are just tools to achieve a given result; the method isn't that critical, and the more tools available (and understood), the faster and better the result. If one is a really good, fine-artist digital painter, it might be easier to just fire up Photoshop or Painter and churn out the exact desired image. So, I guess I'd have to say it depends on the project and the skillset of the artist.

Question 3: Which programming language do you use to make games?

Bergman: Vendetta Online is written in three major languages. We use traditional C++ for most of the client code, and a lot of the server code. Anything that has to do "heavy lifting" (ie, computationally intensive) is written in C++. This includes areas like: physics, collision detection & response, graphics rendering, etc.

Above this, we have another layer of code written in a nice little scripting language called Lua. Lua has been used pretty widely in the game development industry (if I recall, the Baldur's Gate engine used it pretty heavily, as do others), and for good reason. It's flexible and very fast for a non-compiled language. We use Lua for a lot of server-side AI, as well as client-side for the menu system and user interface. Some of our players have learned Lua, as they can develop plugins for our game using this language, and in some cases, modify the user interface in various ways.

Beyond this, on the server-side we use a language called Erlang. This was originally developed by Ericsson to use with their giant phone switches, and it's kind of a "massively-scalable, networked" language. It's actually designed to run on a big cluster of servers, with lightweight threads transparently passing data to and fro across the network. For the server-side of an MMO, this has some obvious benefits. We use Erlang for a variety of things, but right now it's mostly used for very-large-scale AI, basically on a "galactic" scale, while passing orders to individual NPCs that predominately run in Lua.

To give "scale" examples, if an individual NPC is fired upon, the NPC's reaction, tactics and choices rarely needs to leave Lua. However, if 10 NPCs end up dying as part of a major Nation's trade convoy, Erlang may decide that that route has become more "dangerous", and will consider upgrading the quantity and armament of the defensive escorts sent with successive convoys, along with other repercussions. Erlang similarly manages the large-scale behaviour and reactions of our NPC "Hives": autonomous NPC organizations that the players can group up to fight.

Question 4: What's it like in the mainstream game creation industry? And creating a game from start to finish?

Bergman: Heheh, these are the sorts of questions that always make me feel a little less like the "average" game company. While PC MMOs have become fairly "mainstream", my own company is still kind of an oddball in the industry, as I mentioned in the preface. Plus, MMOs tend to "never be finished", which is why I'm still working on the same title a decade later :).

That said, I would say it's very cool. Designing, building and shipping a game is a very difficult, and very rewarding experience. It will change you. There are upsides and downsides to the game industry as a whole; a little searching will show you plenty of people who love making games, and plenty of people who have trouble with the work ethic and requirements. It is definitely a job you have to love.

However, it is a truly excellent feeling to see other people get excited playing something you made. Truly incredible. I feel lucky, in that sense, being an MMO developer, as I get to interact directly with our userbase and see their reactions on a regular basis. And while I get to see (and deal with) all the less positive reactions as well, it's so worth it for the sheer excitement of the good ones. It's kind of like being elected by a group of people to make their dreams come true. That may sound a little strange, or hokey, but for an MMO.. you're always in development, always building the Next Thing into your game. For a company like us, who actively communicates with our players, their excitement about the Next Thing totally drives our motivation. When they get fired up, I get fired up. The sheer enthusiasm of a population who loves playing your game is just a fantastic thing, and can (and has) carried me through dark and difficult times.

I don't really know what it's like to ship a more traditional game, where it goes out into stores, and you see some gaming press reviews, but you don't really get to talk to the players that much. I'm spoiled: for one thing, I can fix anything that's wrong in another patch; and for another, I get to share in their excitement over the stuff that goes well.

Question 5: How did you get involved in the gaming industry? What did it take to/how hard was it to get in?

Bergman: Well, again, this goes back to my preface. I founded the only company that ever hired me to make games (is that good or bad? I'm not really sure). Anyway, I would say it's not trivial to get into the industry, that it has to be something you're really passionate about. You have to be willing to work towards it over a long period, and to get up and keep going after periodic failures or difficulties.
Almost everyone I know in the games industry has gotten there as a result of pushing themselves fairly hard in some particular direction. Programming, or graphics, or whatever else (or a combination). One of our coders started programming when he was five years old; by the time I met him at 13 (I was 14) he had mastered C and was starting to write in pure x86 assembly. Andy is a bit unusual, but that kind of focus and dedication is fairly common within the industry.

I don't want to dissuade anyone by saying these things, learning to program at five is *not* a requirement, but passion and dedication are. People who have the dedication to develop the skillset will find their way into quality companies in the industry. For example, I had a friend (of whom I've since lost track), who, back in the early Quake2 era, got started by re-creating the Quake1 engine on his own. He didn't use any of Carmack or Abrash's code, which I don't think was even public at that time; he wrote the entire thing himself, and made it completely compatible with Quake levels and so on. This is a pretty impressive feat, obviously, writing a software game and rendering engine that's only slightly behind the current "cutting edge", by himself. He had no highschool diploma or other education, but he went on to work in the games industry on the strength of his accomplishment.

The moral being, if you really want to work in the industry, be very good at what you do, and push yourself to learn as much as you can about everything related. A good graphic artist who understands some programming can be a huge boon, as can a good coder with an "eye" for graphical quality, and so on. Being able to communicate clearly with others is a requirement no matter what your desired job (but especially for designers). One more thing for designers: learn as much as possible about what everyone else does (coding, graphics, music.. try it all). It makes for a much more realistic perspective on what the time requirements are for a given gameplay goal.

Question 6: Do you enjoy developing games, or has making them professionally become a chore?

Bergman: I love developing games. Running a company has become a chore, frankly. I would be happy handing that off to someone else, at this point, and just focusing on game design and maybe project management. We're a small shop, so we all have to wear a lot of hats. For a long time, I wore way too many hats, more than I should have taken one, but I'm trying to hand off some of them at this point.

Game development is great. Yes, it's challenging and can be difficult, but after my last 10 years of accumulated ups and downs, I've finally reached a point where I'm no longer really afraid of much anymore. I've negotiated contracts with publishers, dealt with retail launches going awry, managed explosive confrontations between players in our community, kept a development team moving forward.. I've "done" enough that I'm not so worried about handling the inevitable issues (even new ones), and I still love making games. So, I think that's a pretty good point to reach, at least from my perspective.

Going back to an earlier response, one of the big things that keeps me fired up, even after tough times or burning out, is player enthusiasm. Seeing players get so excited by some new aspect of gameplay or some change that I'm putting in, the feedback of that is a wonderfully positive thing. It makes the good times excellent and the tough times easier to bear, and it almost always motivates me and gets my creative juices flowing.

Question 7: Entrepreneurship vs. joining a team: is it enough to look into a degree in video game design and join a team, or would creating my own games be more realistic?

Bergman: Joining an existing team is probably easier and more "realistic", although I'm not really one to talk.. since I've never done that. Heh. But either way, the focus should be the intense and passionate pursuit of whatever areas interest you. Schools and colleges are great, they give you more tools, more experience, more interaction with groups of other people (the cohesion/communication thing being one of the core areas I mentioned earlier). But generally speaking, if game development is something you want to do, it's something that you should just try and "do" as much as possible.

I am periodically asked to speak at schools and such (middleschools, universities, whatever), and the questions often match some of the common themes here.. "how do I get started", "what should I do", etc. One of the things I often say is.. if you want to make games, just try and DO that. It doesn't matter how trivial or stupid the game, there are so many wonderful tools now to let you try actually *making* something. And frankly, I think the reality of making something is worth far more than all the theory of object-oriented programming or whatever else. The most highly esteemed videogame university is probably Digipen, and they spend a lot of time putting their students into little groups and having them make games. Usually a bunch of games with different groups over the period of time. This is something a lot of people can probably do on their own.. find some like-minded friends at school, on messageboards or chat rooms, whereever, and say "Hey, let's try making stuff". That was how my company got started: back in 1993 we used to get together in my parent's living room, with all our computers, on Saturdays. Yes, some of it was playing LAN games, but we also *made* a lot of stuff. Little demos and intros. Our first network game project was a redux of the classic "SpaceWar", written for DOS to run over a Netware LAN. This was not something we planned to sell to anyone, it was simply something we made for fun and the experience of "making stuff".

Now, whether you should take these groups and conglomerations of friends and then try turning it into a company? I can't answer that, it'll really depend on the group, your skills, and whether you want to try making it on your own. All I can pass along there is: EXPECT IT TO BE DIFFICULT, and START SMALL. For gods sake, don't try making a gigantic space MMO with a few friends ;). You might get there eventually, but you'll get a lot of gray hairs in the process.

Question 8: What software do you use to develop games?

Bergman: We use Photoshop for 2D art, and 3D Studio Max for most art-asset development. One of our guys develops on Windows, and uses Visual Studio, but the other two develop on Linux with normal GCC.

Back when we started, it was a requirement to use professional software.. there wasn't anything else. Now, you could probably bootstrap a pretty cool game using free programs like The GIMP (open source Photoshop, essentially), and 3D tools like Blender and Wings3D. They may not have all the bells and whistles of the fanciest pro software, like Max or Maya, but a lot of game developers don't even use all the bells and whistles anyway.

Aside from that, a lot of our other tools are developed in-house, which is pretty common in the industry. Big companies like EA or Midway will have whole teams dedicated to nothing but building libraries (graphics engines, etc) and toolkits to work with them. For some things, we use a mix of the two: we've written some proprietary plugins for Max that serve various functions and export into our own formats, areas where we didn't need to re-invent the wheel and make our own "3DS Max". Sometimes, however, this can be helpful, the editor for the Unreal engine being a good example. We also have standalone apps for tools that really require working directly with our engine (effect development, for instance: explosions/weapon shots/particles, etc).

Question 9: As far as education goes, what would you recommend learning to break ground in game creation?

Bergman: Follow your interests. If you're starting from absolutely no basis at all, maybe consider learning to program in Flash or another web-esque language, and play with some graphics/drawing programs. Try making some simple games. Start really basic.. think "pong" or "nibbles". Then move up to puzzle games, 2D RPGs, whatever. There's a temendous amount that can be made in a browser these days, with a little knowledge of Flash, or even Javascript. Hell, the entire MMO "Dofus" was written to run in a browser, and that's a pretty complex game.

This all goes back to my general statement that, to succeed in the industry, you need to have the drive to pursue stuff on your own. Colleges and classes are great, but this industry changes very quickly, and there is a strong continuous learning requirement. If you plucked a person out of an SNES game development team and stuck them onto a modern console title (ie, not mobile), they'd probably be lost/terrified. Things change, fairly quickly, and the people in the industry have to be adaptive and excited about learning as they change. On the leading edge there is usually no structured college to take a class from, at best there might be a Siggraph paper to read, or just a post from some other game-developer on a messageboard (or, most often, something new you have to invent yourself). Self-education is a must.

For more traditional (but very valuable!) areas.. graphics people benefit fine art skills and digital painting, but also from general "graphic arts" / "photoshop trick" stuff to quickly generate interesting textures. 3D modeling, texturing/coordinates and shaders are their whole own.. ball of wax, but there are a lot of free tools and tutorials out there. Programmers should focus on mathematics (lots of algebra! but also calc, etc) and getting experience in structured languages. Fundamental understanding of optimization is important, but shouldn't be approached until after the foundations of structured programming have been laid. Computers are so fast these days, programmers can be lazier.. but this has no place in the game industry. We need all the work we can get out of a given processor cycle. This actually goes for graphics people, too. Everyone should know what "optimization" means.

Question 10: How difficult was it to get your game published?

Bergman: It was very, very difficult. "Practically impossible" would be an apt answer. We suffered from a number of issues.

One, we were developing an MMO in the late 90s, a genre that was not yet considered a "proven business model" by the publishing establishment (UO was a highly qualified quasi-success, EQ was a real success but still New and Scary to most publishers). The whole concept of selling something that doesn't necessarily "come in a box" and has this "pay-to-play" thing going on was at odds to the traditional "selling widgets in a box" brick-and-mortar retail publisher model.

Secondly, we were looking for development capital as well as a publisher. I never intended to take us all the way to shipping a game, with just the four of us and less than $300k. I figured we would build the engine and underpinnings, make a good tech demo, and then get added funding to fill out the team and "really" develop the game. But, this never happened, so eventually I was left in the icky position of trying to make a tech demo into a shippable product, since that was the only option left to keep our company alive.

Lastly, we were an "unproven" team. This basically means that we had not shipped a finished product. Being "Unproven" is kind of the kiss of death: it doesn't matter how talented you are, or how great your tech-demo looks, or whatever else.. you're still a risk because the publisher isn't sure you'll finish the game. Their skepticism is not really misplaced, a great many games are not finished or run over budget due to developer-related issues (organization, skillsets, poor development choices by inexperienced teams, etc).

This is why I recommend that other people try Starting Small. Make something relatively simple that is cool, and polished, and shows high production values. Even a flash puzzle game that looks really great and has nice sound and music and is bug-free is a big step over having no history at all. Of course, the irony is that any "major" project, like an MMO, will often cause a publisher to demand an experienced team, and in 1998.. there were few experienced MMO teams. This can also be a problem when switching to newer hardware. A good friend of mine shipped a lot of GameBoy and GameBoy Advance titles, but when the PSP launched, Sony and many publishers were not convinced his company could deliver "3D" games. Kind of a frustrating situation for him.

Anyway, getting a publisher to ship our title was a.. fascinating ordeal. I would set up meetings at E3 every year, usually starting a few months in advance, and once there I would wander around in my suit feeling rather silly and having awful, 15-minute meetings in an extremely noisy booth somewhere, talking to some hung-over publisher rep who had been out too late partying the night before. Every year I would go out, and pound on as many doors as I could, with tech demos and sheets and blurbs and business cards and realtime demonstrations (our original "Vendetta Test" public alpha shipped in May of 2002, so I could demo it to people at E3). Each time, they would say "unproven team" or "thanks" or "space games don't sell on console systems" (?!) or whatever else. This was tough, and very disheartening, but I learned a lot from the experience. There were a few cool meetings, like Jeremy Gaffney of NCsoft (and formerly of Turbine), who continued to give us a lot of great advice about how to launch an MMO, even after he had chosen not to pick up our title (his advice was a big help to us).

Eventually, we finally shipped with a publisher who was going through some tough financial times (which made our complete-looking title somewhat attractive, along with the near-zero-investment on their part), but it got us a real launch into retail stores, and we all got to go into a local Gamestop and buy copies of "Vendetta Online".

In general, it is easier to get published under two circumstances: 1) You have a finished game and want zero development money. And 2) You have the most proven, awesome team in the universe and have a super-cool game concept in the works. Situations that are not 1 or 2 may encounter difficulty. On the upside, the internet has made it possible to self-publish smaller titles, although this may not be easy and you'll need to have something really cool to garner to gaming-press attention (all-important if you have no money for marketing).

Question 11: How do you go about creating fun gameplay and levels that compliment it well, and how do you know when you've successfully done that?

Bergman: Well, "Fun" can be difficult to define, as different people find appeal in different ways. Our own game tries to balance various playstyles and perspectives. We're one of the few MMOs that still pushes completely non-consensual PvP combat, but we still try to keep it in balance with other, more peacable playstyles. However, I still get angsty emails from people who don't like PvP, or who *only* like PvP; you can't please all of the people, all of the time.

Anyway, more specifically, keeping a fresh perspective is good when testing any new gameplay you make. Making gameplay is like anything else. Like writing a song, or painting a picture. After staring at something for 8 or 10 hours, or worse, months on end, you really lose perspective on whether it's any good or not, and it becomes a lot more difficult to pick out the flaws. A fresh perspective is useful in this case. Bigger companies use professional game testers to come in and give them a sort of "focus group" response, and that's probably very helpful. I read somewhere about the intense testing/tweaking process that one of the recent Halo games went through, with the every-movement and action of all their testers being recorded for intensive analysis.. "Why are most of them getting hung up here?" or "Why are they getting confused about what to do next over there?", etc. This is easier to define a linear FPS, but the principles are all the same.

For my own part, I try to start a new character and play through parts of our game periodically (from scratch, without dev-cheating, etc). I also try to have friends test the game, every so often, and give me feedback. Probably the most beneficial is the active, communicative relationship with our players.. we have a "Suggestions Forum" where various problems and solutions are debated, and the feedback provided is very useful to us. Beyond this, we also record data about how people are progressing, and periodically use in-game polls.

Getting back to more basic concepts, one of my litmus tests for intial ideas is "Does this sound Fun to me?" and then "Will other people probably think this is Fun?". This sounds.. ridiculously obvious, but you might be amazed how few people seem to ask the second question (not an easy question to ask, but few even bother). The ability to step outside your own perspective (such as you can) and examine a gameplay concept critically, is very useful in game design.

For instance, every year we seem to get a new PhD economics student blowing through our community, who thinks that the greatest and coolest thing we could possibly add to the game would be separated currencies for all our Nations, with inflation and deficit spending for each. And, this would certainly be an interesting addition to the game, and would have all sorts of deep ramifications. However, it would mostly be interesting to other economists. Probably not that wide of an appeal, compared to say.. large scale capship battles. For a game like ours, adding "Everything" is always cool, but I only have so much development time to go around, so I need to spend it wisely.

Another way of putting it is that there is a lot of stuff that would be "Neat" that isn't necessarily "Fun". Always ask yourself which is which, and try to be aware of the difference. You have to develop an ability to determine what is likely to be "Fun" well *before* doing the work. Everyone, amateur or pro, has a certain "budget" of development time that's viable; for amateurs it's simply the point where people start to burn out and give up on the project. The best games are those with a cohesive design that creates a fully-formed product (whether big or small, fully formed is most important!) using the resources available. The ability to do this is the most critical difference between professional game designers, and the general public. Look at the games from Sid Meier and Shigeru Miyamoto and so on, they're all compact and elegant. They do *exactly* what they set out to do, they do it very well, and they don't over-reach. This is just as true of "Bejeweled" as it is of "Civ IV", the game's complexity isn't what's important, achieving the optimal rendering of the given vision is what's most critical.

John Carmack once updated his .plan file to say that the general gaming public is probably just as good at coming up with game-design ideas as most of the pros, and I *TOTALLY AGREE*. However, the difference comes in the ability to take an idea and shave off different pieces to make it work for a given development scale (time, people, skillsets, etc), and to end up with a polished product. It's really more of "project management" at that level, but having a designer who can do that at fairly early stages (and throughout development, reacting to change) is.. critical, in my opinion. If the person doing the chopping doesn't understand the philosophy, the "spirit" of the design, then you end up with a bunch of jumbled "stuff" rather than a cohesive game. I've learned most of these lessons by personally making most of these mistakes.

At the end of the day, I always design the game that *I* think will be fun, and that fundamentally appeals to me, which is really based on my own tastes and my experience as an actual gamer. But I try to balance it across what I think is "best for the progress of the overall game" and our greater community. Like any MMO developer, I cannot be a slave to the wants of the community.. large committees can be terrible at designing things (like the famous joke about the Camel being designed that way: it does everything, none of it well, and has a bad attitude). However, I do try to stay aware of the pulse of the community, and what excites and interests people.

-----

Thanks once again to John Bergman from Guild Software for answering these questions. We hope these answers have helped you and your game development aspirations!