As I'm closing in on the launch of my first game, I've come across a million things that I wish I had more time to work on. My grand vision when I started this thing has turned into a race to the finish where I drop everything non-essential so I can get it out the door. Recently I'd been feeling discouraged, so I took a few moments to stop and get some perspective.
In everything I've learned about building web applications, "Release Early, Release Often" is the mantra. It's definitely better to get things out in front of your customers early so you can see how they want to use it and pivot. It's also easier to manage a release cycle that's a few days (or hours) long, rather than a six month project. For apps, especially those in hit-driven fields like games, this seems to make a little less sense. It's not like you can put out a half-baked first level and hope your customers will keep it around long enough to update when you get around to putting out level two or fixing your terrible control scheme. These types of apps typically only have one shot of attracting a user. The part I forgot about is that in a hit-driven field, you're banking on the fact that you're going to be releasing frequently. You're also relying on reusing technology, process, or marketing improvements that were factored into your current project.
If you go look through a timeline of releases from some of the top iOS game companies out there, their first games weren't 3D immersive techfests. Some of them weren't even all that fun! The key is that their next titles were usually more complex and better made. It's OK to put out a product that doesn't live up to your expectations, so long as you incorporate as much as possible into your next project.
I recently switched my hours to part-time at my job to dedicate more time to the mobile game company I've started on the side. In doing this, I wanted to make sure the intellectual property I was creating for my games company would belong to me and wouldn't get tied up in the IP agreement I'd signed with my employer when I started. I needed a lawyer. Having little experience working with attorneys before, I had no idea about the right way to go about finding somebody who could help my business succeed while not also bankrupting me. Here are a few things I've learned from going through the process.
The first thing to do is to get a list of possibilities together. I leveraged my personal contacts as much as possible, asking them for recommendations. If you're on (or know people on) email lists of local entrepreneurs, that's a great place to ask for suggestions. Hacker News can be a great resource also. Once I got the list together, I narrowed it down to 6-8 that were highly recommended and seemed to be in line with what I was looking for.
Every lawyer will give you an initial consultation to figure out more about your business and sell you on their abilities. This is a great time to talk about what you're trying to do, as well as specific issues to try to get their opinions. Since you're not paying for this, you might as well get as much advice as possible! They're not going to draft anything for you, but if you've got conceptual questions, this is a great time to get them answered.
You also want to get some basic information about the lawyer you'll be working with and their payment practices. Questions to ask during the consultation:
How much of your time is spent on emerging businesses or startups? - Legal recommendations are very different for small businesses versus the Fortune 500. There are so many lawyers out there focusing on startups that there's very little reason anymore to work with someone who isn't.
How much of your time is spent on technology businesses? - Someone who knows your subject area will know common practices and be able to give you better advice than someone for whom you have to explain basics. For example, there are ways to structure an apps business that make it easier to sell one of your apps to another company. Someone with experience will know when this is a good idea and be able to proactively suggest this. As above, there are so many attorneys specializing in working with technology companies that you might as well find someone who knows your business.
Are you full service? - Some law firms are "full service", meaning they have departments specializing in most issues you'll come across, like intellectual property, M&A, and litigation. That can be helpful, but usually comes at a price. Many startups can do fine (and save money!) with a smaller law firm. Many full service firms have offices in all the major markets, like New York, DC, and Silicon Valley, which can be helpful if you're thinking about moving to or raising money in another city.
Are you the partner/associate that's going to be doing my work? - At big law firms, many times the partner you talk to sells clients on the firm and handles high level details, but for day-to-day stuff you'll be dealing with an associate. If this is the case, make sure you also talk to the associate. They're going to have a lot bigger impact on your relationship than the partner. If you're dealing with a one-person or boutique law firm, odds are good you're talking to the person you'll be working with, but it's always good to check.
How much is your hourly rate? - Every lawyer is going to spin this differently, but there is definitely a case to be made for the rate vs efficiency argument. If you've got an inexperienced lawyer who's going to have to do a bunch of research, they might charge you two hours for something that would take an experienced lawyer 15 minutes. This can add up quickly! If rate is a primary concern, a good balance can be found in somebody who worked at a big firm for years, then started their own practice. They'll have lots of experience, but lower rates.
Is there a retainer required? - If you don't have a lot of work to be done, putting down $5000 for a retainer makes no sense and can be a real drain on your finances. In many cases, you can work out an agreement where the firm will do work without a retainer as long as there aren't an unreasonable amount of hours unpaid. When I was first starting, the initial work ended up getting completed in 2-3 hours, so I wasn't a big payment risk. Obviously if you need hundreds of hours of work, they may evaluate the risk a little differently. This is usually negotiable and if they want your business, they'll find a way to make it work. If you're just starting out and don't have a lot of legal needs, paying a large upfront retainer or a monthly retainer makes no sense.
Do you mainly work with clients who're raising money? - Some of the big firm lawyers can help you raise VC or angel money through introductions to contacts. In many cases, they'll float you the incorporation and setup fees in exchange for getting paid when you raise money, since closing a round generates a boatload of legal fees. This can be very helpful if you're trying to raise money, but result in unwanted pressure if you aren't. I was starting a lifestyle business, so raising money wasn't a goal. One of the guys I talked to told me they mainly dealt with people who're trying to get to a liquidation event, and most of their clients raised money. In that case my interests weren't aligned with theirs, so we both agreed that working together wasn't the best idea.
How much will it cost to incorporate my business? - If you've already incorporated, ignore this section. I was surprised at the variety of rates I heard for this service. If all you need is a standard business set up, it should be fairly affordable. Most lawyers I spoke to were in the $500-$800 range. Obviously if you have a lot of custom work required, it's going to cost a lot more, but there's no way you should be paying $5000 just for a fill-in-the-blanks operating agreement and incorporation papers.
Once you've met with everybody on your list, you should be in good position to decide. I'm no expert on the legal realm, so let me know if there are other issues I missed here.
I'm in the process of writing a simple game engine for the iPhone and have been doing a lot of research about game engine design. I also looked into using a prebuilt iPhone game engine, but decided I'm more interested in writing it myself (because of technical, business, and hacker ego reasons). Here are some resources I found helpful.
Game Engine Architecture - A textbook about game engine design, this presents options and tradeoffs for each piece of the engine. Light on actual coding, so you'll have to be able to develop things yourself, but jam-packed with useful information. I found this invaluable while in the design stage.
Game Coding Complete - Walks through the process of building a game engine and using it to create a full-fledged game, complete with AI and multiplayer networking. Found it useful in tying the pieces together, but only presents one approach to most problems.
Gamasutra has all the presentations from the Game Developers Conference from 2000-2003 (Use the links in the sidebar to navigate year).
Marcin Chady - Theory and Practice of Game Object Component Architecture - The best presentation I found about component driven game object design.
Alex Duran - Building Object Systems - Features, Tradeoffs, and Pitfalls
Scott Bilas - A Data-Driven Game Object System
Rob Fermier - Creating a Data Driven Engine: Case Study: The Age Of Mythology
Doug Church - Object Systems
Mick West - Refactoring Game Entities with Components
Kyle Wilson has a blog with a bunch of strong posts about engine design. Be sure to check out the old posts as well.
Unity 3D - Commercial 3D engine. Combines powerful scripting with a visual editor to dramatically speed up the development process. Hundreds of games on the App Store. Well laid out component model.
Oolong Engine - Open source 3D engine. Uses PowerVR POD for storing meshes and Bullet physics.
SIO2 - Open source 3D engine. Toolchain built around Blender and integrates with Bullet physics.
Cocos 2D - Open source 2D engine. Well organized.
Torque 2D - Commercial 2D engine
Torque 3D - Commercial 3D engine
Shiva 3D - Commercial 3D engine. Windows only editor, but supports iPhone publishing
Engines for other platforms
Unreal - One of the most successful game engines on the market. Worth reading through the documentation to pick up on design considerations. Separates out most game logic into a custom scripting language called UnrealScript.
Source - Valve's engine for Half Life 2 and many mods. Extensive wiki documentation.
idTech 3 - Engine from Quake III Arena, now open sourced. A few years out of date, but shows a lot about client-server programming as well as insane performance optimizations. There are a couple people who have gone through the source and give pointers on things to look at, which is immensely helpful .
Panda3D - Open source engine written in Python and C++. All game logic is written in Python. Does a good job of showing how to separate engine code from script.
OGRE - Open source C++ engine in process of being ported to iPhone
Crystal Space - C++ open source engine
At any new job, there are a lot of things for engineers to learn. It's easy to get distracted by platforms, languages, team characteristics, the industry, business models, etc. One area that gets frequently overlooked is learning your company's core competency or technology. At every company (or department within a large company), there's an area that's their specialty. For Apple, it's building intuitive products. For Oracle, it's organizing huge amounts of data. While you can come out of a job and say that you grew your general software development skills, it's better to do that and gain a new area of expertise.
Your company's core strength may not be part of your job description. You may be working on back-end enterprise reporting for a company that prides itself on brilliant user interfaces or doing interface work for a company that specializes in data analysis. While you may not ever be directly working on the core competency, it's still possible to learn enough to be useful later on. If it's something that can be researched on your own, grab some books and do some reading. Talk to people who are working on it and get their opinions and ideas. Unless your company is highly secretive, you probably have source code access. Look into what tools are being used and read the source. You don't necessary need to know it line by line, just enough that you understand the concepts involved and could participate in a discussion about pros and cons.
Obviously, if you're working on web applications you should be very familiar with web programming. It's going to be assumed in the future that you're an expert in the language and platform on which you spent the most time. While it's essential to learn these things, most companies' core competency is not knowledge of a platform or language. 37signals aren't focused on Ruby on Rails, they design simple, clean products. ngmoco don't pride themselves on knowing iPhone APIs better than anyone else, they're good at making fun mobile games. While learning the platform is essential, it's important not to confuse that with learning the company's core competency.
Being familiar with your company's core competency enables you to be part of the important discussions that go on every day. When you don't understand the key concepts involved, you'll have a hard time participating in conversations about changing the core product. When you have the knowledge and can offer suggestions, you'll get involved more and will be seen as more valuable to the company. If a key project needs another person, you'll be much more likely to get on it. A developer with key domain knowledge is also much more difficult to replace, which can benefit you financially and in terms of job security.
Unless you're staying focused to one specific industry, these things are usually fairly unique. In the first two jobs I've had out of college, I've learned all about call platforms (the software that manages automated phone calls), machine learning, and ad servers. While some of these are more generally applicable than others, I've had all of them come up in conversations about unrelated topics. When you're applying for your next job, every other applicant is also going to list being good at web programming. It's the other interesting details that make your resume really stand out.
Earlier this month, Mark Suster published what I consider to be one of the best startup blog posts of the year in his Earn or Learn article. The first point in the article refreshed something that young, mid-stage startup employees (like myself) frequently forget: your engineer's share of the options isn't going to make you rich. It may be a nice bonus, but there's almost no chance of retiring in the unlikely event of a liquidation.
The second point resonated even stronger. If the job you're in isn't going to make you rich, it needs to be preparing you for the position that will. If you're in a learning stage, keep that in mind every day on your way to work. Since the article was talking about advice for whether or not to take a new job it also left out one possibility: move. If you're holding a job with little possibility of earning or learning, it may be time for a change.