GUERRILLA GAME DESIGN: 8 TIPS FOR INDIE GAME DEVELOPERS :2

So you want to become an indie game developer, but you need some help knowing where to start. Take note of these eight tips for independent developers from Tribeca Flashpoint Academy's Antonio Sanders.

1. Get your game on.

"Surveying the scene is one the first and most vital steps to gauging what like-minded professionals are creating and what you can do to be successful."

Spend time playing other indie titles and get inspired. Looking at some finished games will give you a sense of what you’ll want to strive for. Notice the trend toward niche markets and retro fans. Try cutting time back from your Triple-A games as many of them are just old stuff in a new dress. There’s a lot of stagnation in corporate game design at the moment, so indie games thrive at doing what big budget games consider too risky to attempt. Anna Anthropy’s book, Rise of the Videogame Zinesters, offers a great overview of the modern indie game scene.

2. It’s not safe to go alone. Take this.

"Typically, programmers make ugly games. Likewise, game artists often have poor code or weak gameplay. Building a strong, diverse team is a necessary first step."

Game development isn’t a one-person process. It’s time to get used to working with people. Find a reliable, passionate team consisting of a capable artist, designer, producer, and programmer who share your burning desire to make games. It is wise to find diversity in skill; some the best indie titles are made in small groups where each member holds a unique talent.

3. Start small.

"A fun demo, a snippet of gameplay, or a level that is well-thought-out, fun, and aesthetically pleasing is a great jumping off point to pitch to places like PopCap or Activision."

Keeping your ideas simple and tight can be challenging, especially if you’re working with limitless amounts of time. Game Jams are an excellent way to stress the team and develop some quick small-scale projects. If you have trouble finding some in your area, simply hold your own with a few mates. The Game Jam Survival Guide has some good pointers.

4. Learn everything (even the stuff you hate).

"As an indie developer, you'll need to know more and be confident in doing more than the standard industry professional. In smaller teams with less funding no one will have the luxury of specializing. You'll be much more involved over a broader scope of development."

Take some time to study art, business, color theory, marketing, programming, new platforms, new technology, new tools, sound, storytelling, UI design, etc. A good developer needs to be able to function outside of their comfort zone, and it takes a little courage and effort to accomplish this. Even if your team already has a guy or gal taking the reins in a particular area of development, it’s still important to provide help where possible. Your name is on the project, so give it your all.

5. Take advantage of the free stuff.

"Trying to write your own engine, even for experienced programmers can be a massive undertaking that can slow down a project in its vital early hours. Be sure to invest plenty of time in research to see what is worth spending money on, and what the team is most comfortable with creating themselves.”

As with every choice in life, there are pros and cons to each engine out there. To help you do your research, we’ve compiled an incomplete list of free and inexpensive game engines. If you see one you’re unfamiliar with, click through to visit their homepage:

• Unreal Development Kit
• Unity
• Game Maker
• RPG Maker
• Construct 2
• GameSalad

Note: there’s a difference between free software and stolen software. Don’t get mired in legal troubles by using cracked versions of premium software. Buy it, or don’t use it.

6. Commitment is a necessity.

"Stay focused, stay on track, and don't detract from the main project or you'll wind up with nothing to show for months of effort."

It’s happened to the best of us: while working on a project, a new and exciting idea will spring up, and you’ll want to get started on it right away. This is where many amateur game developers make a fatal error and begin project-hopping.

Finishing what you’ve started is a good habit to get into. If the current project is worth completing, then complete it before starting the new project. If the current project just isn’t working out and you feel a fresh idea could reenergize the team, then put the current project on the back burner. Whatever the decision is, it must be a serious, carefully considered one. Don’t let a poorly-formed idea derail months of hard work.

7. Risk-taking is a way of life.

"You need to have faith in your product, but overselling yourself on a project can be very dangerous. It is often wise to work on games as a side project while still pursuing current employment early on, at least until your studio rises in popularity."

As you’ll quickly discover, making indie games isn’t a traditional job, and it doesn’t always yield traditional perks (or paychecks). There is always a chance you won’t see results as big as the effort you’ve put in. Begin asking yourself how much risk you’re willing to accept for a project. Is it worth a second mortgage? Quitting your day job? Maybe it is, maybe it isn’t, but you must anticipate your own limits. Make sure that the possibility of rewards is worth the sacrifices.

8. Start at the beginning. When you reach the end…stop.

"It is very important to schedule out deadlines and stick to them."

Many projects become unwieldy when the industry-coined “feature creep” begins to set in. It’s OK to accept a small handful of innovations, but eventually there comes a time to put new mechanics and ideas on ice; otherwise, projects will grow to colossal undertakings. Knowing when to stop will keep your projects from taking on a life of their own.

(Special thanks to student Bretton Hamilton for facilitating this post.)

SOURCE:www.tfa.edu/

Ranadheeran - Animated Trailer using Open source pipeline

       ..

LAST DAY FOR NORMAL INDE GAME SUBMISSION @ INDECADE

IndieCade 2014 Submissions

CLICK HERE TO SUBMIT YOUR GAME!

IndieCade was established to create vibrant festivals and showcases dedicated to independent games and open to the public. It is our goal to showcase exciting and innovative new work, host productive networking environments, hold important discussions, and have fun.
IndieCade invites independent game artists and designers from around the world to submit interactive media of all types for inclusion in our 2014 Festival. Works-in-progress are encouraged.
A diverse jury of leaders from industry, academia, fine arts and indie development will select our annual finalists and assign top awards at the IndieCade 2014 Festival. All entries for the Festival will also receive consideration for presentation at IndieCade Showcases.
It is IndieCade's ultimate goal to bring the eye of the public and industry to your games. IndieCade is an independent organization. All submission fees are used specifically to cover the costs associated with processing your submission and you are also provided with a Festival pass that provides complimentary particpation in the IndieXchange and feedback on your game. Regular submissions is $ 80 USD and late submissions $ 110 USD. Read below to find out what you get for your fees in more detail.
For more details about the submissions process and qualifications please read below or check out our Frequently Asked Questions (FAQ).

Submission Dates

IndieCade will be accepting game submissions March 1, 2014 through May 15, 2014.

Late submissions will be accepted from May 15 to June 15th for an additional processing fee.

What do I get for submitting?

• All games submitted are considered by the jury to become finalists for the IndieCade 2014 festival and awards.
All games submitted are eligible to be considered by IndieCade curators for display as an official selection at the IndieCade 2014 festival.
• All teams who submit a game will receive passes to IndieCade’s IndieXchange and are eligible for participation. The IndieXchange has two components, the first being a individual matchmaking service for networking and meeting with publishers, arts leaders, and potential funders. This includes both a remote and an in person component. The second is an invitation to a series of practical workshops held on-site the day prior to IndieCade’s main conference, October 9th, 2014. To opt into this program you must indicate this on your submission form. This invitation-only program is free-of-charge for developers who submit to IndieCade. In-person meeting and workshop space is limited so you must RSVP. For more information about the IndieXchange, please visit the page on our website for general information Questions? Check out the FAQ).
• All teams who submit a game will receive one complimentary pass to the IndieCade Festival ($200+ value). Finalists will also receive a free conference pass.
• IndieCade has instituted a new system for feedback. This year we will provide a solid detailed review from a hand selected reviewer..

What do I get if you are selected for a showcase?

• All of the basic benefits listed above for submitting your game.
• Gamemakers and their teams will be supplied with passes to any showcase event to which they are selected. They will also be invited to all related social events.
• Games and gamemakers will be featured on the IndieCade website and promoted though IndieCade social media and traditional publicity channels (media releases, publicists).
• IndieCade will provide finalists with standard PC computers/consoles, monitors, headphones, and signs for your game. Developers of mobile games may be asked to bring their own devices. Developers of custom installation, pervasive, performance, or other alternative genres should plan on bringing their own specialized equipment, although standard equipment such as projection and display monitors may be provided by IndieCade. Board game developers are expected to provide a playable copy of their game.

What do I get if I am selected as a finalist for the festival?

• All of the basic benefits listed above for submitting your game.
• All finalist games are considered for all award categories.
• Gamemakers and their teams will be supplied two VIP all-access tickets to IndieCade 2014 and the accompanying awards celebration.
• Gamemakers and their teams will be invited to all social events associated with IndieCade, as well as featured VIP receptions and gatherings.
• IndieCade will provide finalists with standard PC computers/consoles, monitors, headphones, and signs for your game. Developers of mobile games may be asked to bring their own devices. Developers of custom installation, pervasive, performance, or other alternative genres should plan on bringing their own specialized equipment, although standard equipment such as projection and display monitors may be provided by IndieCade. Board game developers are expected to provide a playable copy of their game.
• IndieCade will feature all finalist games and teams on the website and promote them via social media. This includes an online developer profile as part of IndieCade online festival promotion. IndieCade’s publicists will promote the games via traditional strategies prior to the event and will be on hand at the event to promote the games.

How do I submit?

Standard submissions close May 15, 2014, and Late submissions close June 15, 2014. To submit your game you will follow the process outlined below:

1. Fill out the online entry form.
2. Agree to the terms and conditions.
3. Submit the processing fee prior to the deadline.
4. Upload, postmark, or supply a link or a minimum of three download codes for your game by midnight (end of day) May 15, 2014 or June 15 for late submissions. For games that require custom builds, UDID, console accounts for gifting, or other such information, you must clearly a) provide required information and b) state the information you need to submit the playable build, and you will be supplied with this information as jurors are assigned to your game. For iOS games, we have an anonymous process for transferring UDIDs through the jury system anonymous email and then ask you to create a custom builds of your game for these unique UDIDs.
5. You may save and edit your submission as many times as you want; please know, however, once the initial juror begins to review your game s/he may not see the same version as a later juror.
6. Once you hit the submit button, you may continue to update your submission until the deadline, May 15, 2014 or , June 15, 2014 at which point all submissions will close and no further changes may be made to your submission.
7. IMPORTANT: Only paid submissions will be considered. Be sure and pay for your submission prior to the deadline. Unpaid submissions will not be marked as complete and will not be eligible for review or inclusion in IndieCade’s Festival or Showcases.

Submission Processing Deadlines and Fees

Regular submissions open March 1 and late submissions will be accepted until June 15, 2014.
IndieCade is an independent organization. All submission fees are used specifically and entirely to cover the costs associated with processing your submission. Please see the FAQ sheet for more specific information for exactly where the money from your fees pay for.

Submissions require a $80 processing fee and close May 15, 2014, late submissions will be accepted from May 16 – June 15, 2014 for a $110 processing fee.

If you have a discount code you may apply only one code per entry. Discount codes are only applicable for the regular submission. If you are in need of a scholarship, please fill out the appropriate form in the submission form or send an email directly to scholarships@indiecade.com.

Why do you charge so much money to submit a game and where does my money go?

IndieCade is an independent organization and volunteers-based organization, - no one is getting rich on this. We are probably as indie as you are, if not more so. Fees are directly applied to the cost to do the best job we can to review, respect, and jury your games. Game processing fees are applied directly to the following; 1) Submissions and jury software development: IndieCade has built a custom system and continues to build and maintain this system; 2) Reviews: Developers have asked for better reviews and based on your input we are initiating an expanded review process and true coverage system, you will get a solid detailed review from a hand selected reviewer, but this costs us a substantial part of the fees to be able to provide this; 3) And finally a percentage of the fees go to the annual server and storage fees, as well as payment system fees. Note; For more information please visit the FAQ.

Eligibility

To be eligible for IndieCade, your game must not have funding from a major publisher (for a list of major publishers see http://www.theesa.com/about/members.asp) You can have other deals with these publishers, but the game you are submitting may not. Your game can have funding from other sources, including investments, grants, crowd sourcing or other funding apparatus.
Submission to or inclusion in other festivals does not preclude eligibility in any way. Previously submitted games may be resubmitted provided they: 1) Were not finalists in a previous IndieCade Festival; 2) Have undergone significant changes since the last submitted version; 3) We suggest a new or altered name that clearly indicates a different version.
There is no age requirement for submission.
IndieCade has an inclusive submissions policy and invites submissions of all styles and genres of games, including PC, browser-based, casual, puzzle, mobile, ARGs, Big Games and installation-based games (submitted via video if not playable on-site), mods (provided they conform to game engine licensing agreements), serious games, documentary games, activist games, art games, virtual worlds and "sandbox" style games, and more! We also welcome student games and games developed by universities, schools and non-profit organizations. All types are not only welcome; they are encouraged. Innovation is the name of the game.
Works in progress are permitted and encouraged, but they should include at least one finished, playable level.
All game content and copyrighted material must be fully owned by the designers/developers; if outside material is used, legal permission must be secured or your game will be disqualified. If you plan to submit a work that is on a non-standard game operating system (e.g., Linux, Atari), please plan to submit review hardware and have a representative on-site to be responsible for installation, or to supply hardware with the game fully installed to the Festival.

Submission Schedule

All games may be updated until the deadline, at which point all submission close (at midnight PST on May 15, 2014 and June 15, 2014 for late submissions). Submissions will be confirmed within one week of completion.
Entries will be selected by a diverse jury consisting of game designers, artists, curators and academics.
Finalists will be contacted by August 30, 2014. All entrants are informed of their games’ status before any official announcement is made. Rejection notices will be accompanied with feedback from the jurors if it is available.

From Ludum Dare to Molyjam, how game jams became part of game development

                    Game jams have captured the imagination of an industry. Hardly a weekend passes without one somewhere in the world. Every Friday evening, a quick scroll of Twitter reveals groups of developers hunkering around a chatroom or hashtag and preparing to spend the next 48 hours working on their outlandish game ideas. Many are organised between groups of friends, while others have become global events drawing the attention of tens of thousands of participants.
               
                  It’s not just the indies: game jams are also starting to creep into studios, with developers such as Double Fine and Ubisoft incorporating them into their work schedules. But just what is it that is so alluring about game jams? Are they a magic bullet of innovation? Or is this just crunching taken to its inevitable conclusion?
One of the 30-odd developers who took part in 2002’s inaugural Ludum Dare 0 was Mike Kasprzak, who today is one of the competition’s head organisers. “Geoff [Howland, founder] didn’t really have the time to keep running the event,” he explains. “But all of us who participated craved this. We were really excited [and] really enthusiastic about Ludum Dare, so we literally took it over for him.”
             Kasprzak and a ragtag group of developers knew that Ludum Dare had tapped into something special, and they did whatever they could to make sure it continued to run. “It kind of floundered for a while before we got our act together,” he explains, but that all changed after Phil Hassey’s creation for Ludum Dare 8,
            Galcon, became a critical success. Kasprzak recounts how Hassey was instrumental in finally getting the Ludum Dare competition a proper home on the web. “Phil was like, ‘Dude, I want to do this. I want this to keep going, because this is important.’”
Now, after 11 years and 26 events, Ludum Dare is perhaps the best-known game jam in the world. “Today it is super big and huge – thousands of games per event. It’s madness. The idea of Ludum Dare, to just make a game in such a short period of time, just resonated with people and created something else. It snowballed until we were able to make this happen all the time.“

Midas was created for Ludum Dare 22 by Harry Lee and Jarrel Seah.

            Ludum Dare isn’t alone in its success – thousands of games are produced at such events each year. One of the biggest is the Global Game Jam. Founded in 2008, the 2013 event attracted 16,705 developers from 63 countries, who produced a grand total of 3,248 games.
          But why have game jams become so popular? What do they offer game
developers? “The thing that stops a lot of people making games is expectations about levels of polish, about a certain level of quality,” explains developer Anna Anthropy. “If you only have hours, you don’t give a shit about any of that. You just have to keep making it if you want to get it done. So in that way I think it helps a lot of people get over their insecurities about making shit. They just make it.”
                
         Kasprzak also highlights the way that game jams offer a safe space for developers to create something that isn’t finely honed. “You don’t have time to create the perfect system. You’re running out of time every minute. It forces you to just sit down and do what you can quickly, which is a really good mindset to get into.”
          Independent designer Harry Lee is a prolific jammer. At 2011’s Ludum Dare 22, his team’s game, Midas, won four medals. For Lee, one of the strengths of game jams is that they motivate developers to actually finish a project. “That helps a lot of people, since they fall into a trap of not ever finishing a thing, or even starting a thing, so that works really well.”
         Lee also highlights the way jams work to help developers hone their craft, teaching them about their voice and how to set the scope of projects. “I have dozens of game prototypes that I’ve produced from jams, and I think that body of work is necessary for finding a style that suits you. Jams are about volume, about making a volume of work to hone your skillset and craft.”

Bossa Studios’ Surgeon Simulator 2013 emerged from this year’s Global Game Jam.

         Game jams give developers a reason to start a game, the obligation to finish, and the safety net to fail. But perhaps most importantly, they surround participants with others who are doing the same.
         
        “I really like the energy of being in the physical room with the people,” says Anthropy. “You just shout out ideas at each other, and if I need sound effects I can just pull someone over and have them talk into my game. Yeah, the energy is real good when you do it in the same physical space.”
         But even for game jams held primarily over the Internet, such as Ludum Dare, that sense of community is a driving force. “By [Ludum Dare] existing, it gives people enough extra inspiration to make that step, that extra push to sit down and do something, because you are participating in this event,” says Kasprzak. “I’m not just doing this myself. We’re all doing it together, and that’s inspirational.”
       The traditional game jam model sees teams given a theme – typically a word or phrase – from which they’ll spend the next 48 hours prototyping an appropriate game, often at the expense of sleep and personal hygiene.
         
           Lee, despite his own enthusiasm for jams, is concerned about just how passionately and uncritically this one model has been embraced by developers. “I think [game jams] serve a very important purpose, but I think it is a very specific purpose, and I think sometimes they are extended beyond their use. Every game jam, the way it is set up and the format it has, will directly lead to the kinds of games that come out of it.”
        The concern is that only participating in a certain kind of jam means you can only make a certain kind of game. “When new people go into a jam, they are learning all these fundamental and important ideas about what games are, but that can also be really normative if they aren’t coming from an experimental angle,” says Lee.

Bossa Studios’ Surgeon Simulator 2013 emerged from this year’s Global Game Jam.

      Fortunately, then, the last 12 months have seen a proliferation of jams that break away from the traditional model. Jams such as Molyjam, The 7 Day FPS Challenge, and Fuck This Jam all constructively deviate from the norm. “I think it is great that the structure and definition of a game jam is crumbling and diversifying,” says Lee. “We need to see different kinds of jams.”
      When Anna Kipnis, senior gameplay programmer at Double Fine, casually tweeted that there should be a game jam to bring to life the outlandish ideas of Twitter parody account @PeterMolydeux, she sowed the seeds for Molyjam, one of 2012’s most popular and unusual jams.
       While Molyjam still followed the traditional model insofar as teams had 48 hours to make their game, the nature of it meant participants knew the theme well in advance. For Kipnis, this was one of the jam’s major strengths: “I’ve always wanted to be in a public jam, but [not knowing the theme until you show up] was always really intimidating, in that often I would find out the theme was just one word like ‘extinction’ or something. It’s only enough to tip you in the right direction, but not enough to really push you towards something… So I thought, ‘Hey, I would totally be a part of [Molyjam], because even if I get stuck, I can just pick another idea.’”
   Even further departures from the traditional jam model are The 7 Day FPS challenge (organised by Vlambeer’s Jan Willem Nijman alongside Sos Sosowski and Sven Bergström) and Fuck This Jam (organised by Vlambeer’s other half, Rami Ismail, alongside Fernando Ramallo). While traditional game jams might tempt developers to rely on normative ideas as a crutch, both 7DFPS and Fuck This Jam, much like Molyjam, force their participants to think beyond their usual boundaries.
      
        Nijman had the idea for 7DFPS after he spent time working on Vlambeer’s own Gun Godz. “A lot of indies have this preconception of firstperson shooters being dumb, triple-A shit,” he says. “Getting indies to start making things in that genre gave it more new ideas than the last ten years of big budgets did.”

Zero to 95,688: How I wrote Game Programming Patterns

source: journal.stuffwithstuff.com

About an hour ago, in the quiet of my living room, alone except for a sleeping dog next to me, I accomplished the biggest goal of my life. I finished writing Game Programming Patterns. It’s a book on game programming (it would be a weird title for a book ornithology) that I started writing about four years and a lifetime ago.

What I see now when I run the script that converts my Markdown manuscript to HTML.

It feels weird writing a blog post that doesn’t have any real content beyond my own personal story, but what the hell. It’s not like I have anything better to do! I get some vicarious pleasure mixed with globs envy when I read about other people finishing their books, so I’ll try to add to the canon.

The Call to Adventure

Like most stories, it starts with the hero having something bad happen to him. (Did I just call myself the hero? Seriously? God, this is already going my head.)
About five years ago, I was a game programmer at Electronic Arts in sunny Orlando, Florida. That’s the studio that does Madden, NCAA Football, Madden, Tiger Woods Golf, Madden, and also this football game you’ve probably heard of. They did a few other one-off games too.
I’d been there seven years, which is an impressively long time to actively dislike football while working in an office that lived and breathed it. The last game I worked on, Henry Hatsworth in the Puzzling Adventure was an absolute blast, the kind of dream project you imagine game development to be all about. Just seven dudes hanging out making a cool game they all loved.

My pixel art alter ego in the end credits.

After we shipped, EA decided to never make that kind of mistake again and refocused on
suckling the withering teats of its aging cash cowsthe shareholder-friendly profitability of beloved annual franchises. My entire team quit except me. I ended up bouncing around onto a bunch of different projects.
I was so burned out chunks of char were falling off me, and I was really frustrated by how hard it was to ramp up every time I was airdropped into a new team and its disorganized, deeply coupled, inconsistent code. I’d find bits of real elegance sitting just a few source files away from some hairball that would have benefitted from the exact same structure. People just weren’t talking to each other about their craft and weren’t learning.
Game dev culture, at least at the studio I was at, is kind of weird. One quirk of it is that a lot of the programmers I worked with didn’t give credence to ideas from the larger world of software. Things like Design Patterns were for Nancy-boy enterprise programmers, not real game coders.
On top of this stress, I’d just had a kid, an eventuality I did not plan for when I purchased a 900’ house at the peak of the housing bubble. One frustrated drive home from work, I had an idea: I knew some basic software architecture. I liked writing stuff down. What if I wrote a book specifically targeted towards game developers about this? If I aimed it straight at them, maybe they wouldn’t dismiss it out of hand.

A few notes from when I first started thinking about the book. Note that even then I was pandering to the masses on reddit!

(Also, let’s be honest, it’s not hard to write a more enjoyable read than Design Patterns. I’m pretty sure the Addison-Wesley style manual explicitly demands crushingly boring prose.)
Now, I am a world class project starter. I’ve got hard drives full of stories, videogames, art, music, screenplays, photography projects, table-top games, hell, there’s probably some poetry in there somewhere. But virtually none of it’s done. About the only thing I’d been able to get out the door at that time is the occasional blog post.
I was fully aware that taking on this project was pretty much doomed to failure. But, after visiting the Pacific Northwest, my wife and I really wanted to move, and a book would make for a nice bit of résumé padding to help me find a new job.

How could you not want to live here?

I felt like the book could be our ticket out west. So I needed to figure out every psychological trick I could play on myself to actually get it done.

The structure

If blog posts were the only thing I could finish, why not take a cue from that? Design Patterns is a stack of mostly unconnected chapters. I could organize my book the same way. Then instead of writing a whole monolithic book, it would feel more like writing a few dozen separate articles. Less novel and more anthology.
Likewise, each chapter in Design Patterns has the same top level headings and organization. I could do the same thing, so I didn’t need to come up with a unique outline and narrative for each chapter. They’d just be recipes with different ingredients and instructions.

The workflow

I’m an inveterate tinkerer and I knew if I didn’t put the kibosh on that, I’d spend all day futzing with CSS or some other stupid thing that wasn’t writing. So I spent a day or two putting together a minimal script that would take a file of Markdown for each chapter and convert it to HTML. Once I got it worked, I swore to myself that I wouldn’t monkey with it (much).
Now I couldn’t get distracted by design, style, editors, or anything. Just me, Sublime, and a handful of markdown syntax.

The shame

One thing I’d heard was that telling your friends and family that you intend to do something is a good way to keep yourself honest. So I totally made myself look like an ass and told everyone, “Hey, I’m gonna write a book. Because I’m so awesome. Don’t you wish you were as erudite as me?” Maybe I didn’t word it exactly like that, but I’m pretty sure that’s how it came across.

After working at EA for seven years, they give you seven weeks off. I used some for my honeymoon and then started writing.

The incentive

I’d been blogging for a year or so and one thing I’d learned is that the possibility of a good reddit discussion about my writing was incredibly effective at getting me to complete something and put it out there. So I planned to put each chapter online as I finished it instead of waiting for the entire book to be done.

One of the first chapters posted.

Crossing the Threshold

I rolled this all by my wife and, unbelievably, she agreed to it. Even though it meant she’d have to spend even more time taking care of our infant daughter while I wrote. Even though she knew I’d never finished much of anything before.
I’d like to think she believed in me, but maybe she just really wanted to move out of that tiny bungalow. Seriously, that house was so small we had to move the stroller into the living room every time we did laundry.
With her OK, I started working on a plan. Since padding my résumé was a primary motivation, I needed a real publisher. I figured putting my self-published book on my résumé would sound about as impressive as that “World’s Best Son” mug I got from Mom.
I spent a bunch of time reading submission guidelines. They usually want an outline (check) and some sample chapters (oops). So I spent a couple of weeks writing and revising a couple of chapters. This was a nice trial to see if I could actually write something that looked like a book chapter. Miracle of miracles, I could! For the record, the first chapter I wrote was Object Pool.
I carefully looked at a range of different publishers and their compensation packages before making an educated choice about which ones to submit too. And by that I mean I sent it to O’Reilly because OMG having a book with an animal on it like Perl’s camel book would be SO RAD.
I emailed them the submission with butterflies in my stomach which, when you think about it, is an absolutely pointless physiological reaction given that I was in my house all alone staring at my computer and not being attacked by a sabretooth tiger. A heightened sympathetic nervous system does not actually make email arrive faster.
Unbelievably, they got back in touch. They were interested! I had an editor! He had feedback! He talked to me like I was an actual writer and not some jackass who decided he was an author because he thought it sounded cool. There was talk of a (small) advance. I felt like hot shit.
And then… somehow… it sort of fell through. I don’t remember the exact details, but at some point they decided to not move forward after all. I reached out to a few other publishers and found another one. I signed a contract with Apress and was super pumped to be back in business. We had a writing schedule and everything.
During all of this, I was still writing and managed to get a couple more chapters done. Unfortunately (but unsurprisingly and understandably) my publisher was a little hesitant to have me put them all online, so I didn’t get that jolt of dopamine every time someone on the Internet acknowledged my existence.

The Ordeal

I thought I was back on track but then something funny happened. It turned out I didn’t need to pad my résumé after all. I got a new job. Outside of the game industry and in the city we were desperately hoping to move to.
All of the sudden, we were packing up our belongings, kid, and pets; saying goodbye to friends and family; and moving along what is practically the longest straight line move you can make in the continental US. I was plunged headlong into learning all sorts of new stuff at work that had nothing to do with games. We got another dog and had another kid.
That writing scheduled was looking a little, uh, unrealistic. Eventually, I realized my heart just wasn’t in the book anymore. I called my editor, apologized profusely, and backed out of my deal. Without the pressure to write, I forgot about the book almost completely. I hadn’t abandoned it, really. I told myself I’d get back to is some day. It languished for a year. Then another.
It would have gone into my overflowing bucket of unfinished projects if it wasn’t for one thing: people kept emailing me about it. You see, I’d put the entire table of contents online along with the handful of chapters I had written. Every now and then I would get a long, wonderful email from someone telling me how a chapter really helped some abstract concept click in their mind and how they couldn’t wait for the next chapter. Good god, their enthusiasm made me feel terrible.

Resurrection and Rebirth

About a year ago, I had an unpleasant realization: as I got farther and farther from my days as a professional game developer, my expertise was getting out of date. I was losing the ability to finish the book.
While all my other unfinished projects didn’t bother me that much, the book was special. I’d only ever tried to write this one, and to have it die would break my heart. I figured it was now or never.
Around this time, I’d stumbled onto that article about Jerry Seinfeld’s trick for staying productive. It’s pretty simple: work on it every single day. Don’t break the chain of sequential days. I also met Chris Strom who’s been blogging this way for something like a million years.
Without putting much thought into it, I figured I’d give it a try. I hadn’t written a word on the book in well over a year, but on June 7th, I started a new chapter on Game Loops. I wrote 777 words of first draft, less than an hour of work.
The next day, I wrote 489 words. Then a meager 178. But it wasn’t zero. This weird desire not to break the chain made me drag myself off my ass and at least write something, and once those 178 words were done, I was that much closer to the end. The next day, I did 889 words. The day after that, I finished the first draft.

Interlude: How a Chapter is Made!

I got so wrapped up in my own little narcissistic narrative I forgot to tell you anything useful about the actual mechanics of how I write! Since I decided to post chapters online as I completed them, I knew I couldn’t just do a first draft of the whole book before revising anything. Trust me, no one wants to read a first draft. Instead, I treat each chapter like a little standalone piece of writing. I do it like this:

1. Outline the chapter

Most of the chapters have the same top level structure, but within those headings, I do a pretty detailed outline of what points I want to cover and how they flow together. By the end, I have basically all of the material for the chapter, just with no actual punctuation or grammar. It’s everything I want to say, said really poorly.
Here’s a chunk of outline from the Game Loop chapter:

- old programs used to be batch: ran and quit
- then came interactive programs. these ran forever, which meant loop
- if you write gui app, the os has event loop
  - you receive ui event, handle it, and return to event loop
  - js is a great example
  - you don't see loop, but it's there
  - when app isn't handle user input, it isn't doing anything, just sitting
    there
  - this can work for simple games (minesweeper, solitaire)

I don’t think those bullet points or indentation even mean anything. It’s just word salad.

2. Write the code

The outline will hint at the example code so I know what blocks of code need to be written. Then I come back and write the actual code. Sometimes I’ll interleave this with writing the text, other times I’ll do all of the code up front.
I write the code in separate C++ source files so that I can compile it and makes sure it’s free of errors. For some chapters, I even wrote unit tests. The script that converts the Markdown to HTML pulls in the code snippets directly from those files.
Here’s a bit of markdown for the prototype chapter:

To create a ghost spawner, we just create a prototypical ghost
instance, and then create a spawner holding that prototype:

^code spawn-ghost-clone

One neat part about this pattern is that it doesn't just clone
the *class* of the prototype, it clones its *state* too...

The little ^code tells my script to hunt in the C++ code until it finds:

void test()
{
  //^spawn-ghost-clone
  Monster* ghostPrototype = new Ghost(15, 3);
  Spawner* ghostSpawner = new Spawner(ghostPrototype);
  //^spawn-ghost-clone
  use(ghostSpawner);
}

It stitches in those two lines of code and we’re good!

3. Write the first draft

I hate first drafts. I hate the blank page. I do a detailed outline up front to try to make this easier. And then I rush through this as quick as I can to get it over with. Even so, this part takes the longest and I usually only get about 500 words a day on it.
I try to silence my internal critic during this phase so I can keep making forward progress. I rely heavily on later revisions. Knowing I will edit later gives me the freedom to not edit now.

4. Do the second draft

As soon as the first draft is done, I circle back and do the second. This involves fixing all of the mistakes, bad grammar, and poor flow of the first draft. Sometimes, there’s major surgery here when I decide something I crammed in just isn’t working. I make a lot of changes:

A chunk of the diff from the first to second draft of the last chapter I wrote.

The second draft is shorter than the first. I treat writing like pottery. I slap all the clay on the wheel in a big blob and then iteratively refine it down to the final work. I can get about 1,000 words of this done a day.
I love this part. Feeling the prose get tigher and clearer is exactly as satisfying as refactoring messy code. It’s less stressful because I feel like anything I do now just makes it better but the chapter is safely complete regardless. There’s no more blank page so editing is just pure goodness.

5. Do the third draft

This is the home stretch. At this point, the chapter is almost in its final form. For this last pass, what I’m looking for is mistakes and rhythm.
I read the entire chapter out loud. I can’t stress enough how helpful it is. You can read something ten times and think it’s fine but the first time you run it through your lips you’ll find all of the wrinkles. This fixes awkward repetition and bad cadence. If the prose reads naturally and easily, that’s not because I wrote it naturallly and easily. It’s because I edited the hell out of it.

6. Illustrations

The last thing I do is draw a few illustrations for the chapter. I think visuals are hugely important for making abstract concepts concrete in the user’s mind.
I spent a lot of time trying to figure out how I wanted to illustrate the book. I’d done a few illustrations in Photoshop, but didn’t like how the text looked pixellated. It also made at a real pain to change the design of the site, and looked terrible when retina displays came on the scene.
I thought about doing something like SVG, but that seemed like a huge time sink to get the level of quality I wanted. Eventually, I hit upon the idea of going in the other direction. I decided to hand-draw and scan the illustrations. I could scan them at a high enough resolution to look sharp on a retina screen. More importantly, their intentional imperfection would help turn off the OCD part of my brain that would be unsatisfied with anything less than perfect Edward Tufte-quality diagrams.

Some of the 66 hand-drawn illustrations.

7. Publish and fix bugs

At this point, I think the chapter is done. I put it online and tell the world, and immediately they point out a bunch of glaringly obvious bugs that somehow survived several rounds of editing. I fix those, and now the chapter is mostly solid.

The Long Road

OK, where were we? I started logging each day’s work in a little text file. Less than two weeks later, the chapter was done:

2013-06-18 - Finish third draft of Game Loop
2013-06-17 - 1,280 words revised in third draft of Game Loop
2013-06-16 - ~1,000 words revised in third draft of Game Loop
2013-06-15 - Finish second draft of Game Loop
2013-06-14 - Revise couple of paragraphs of Game Loop
2013-06-13 - Revise ~500 words of second draft of Game Loop
2013-06-12 - Revise ~900 words of second draft of Game Loop
2013-06-11 - Finish first draft of Game Loop
2013-06-10 - 489 words on first draft of Game Loop
2013-06-09 - 178 words on first draft of Game Loop
2013-06-08 - 889 words on first draft of Game Loop
2013-06-07 - 777 words on first draft of Game Loop

I spent some time redoing the design of the site not to be totally busted on mobile devices and then started the next chapter. Now, if this was a movie, this is when the eighties instrumental rock would start and the montage would kick in. Before you know it, the book would be done.
But, I tell you what, I lived that montage, and it did not pass quickly. Working on this damned book was a pain in the ass every single day. I work full time, and have two small kids. We bought a house and all of the work that that entails and it turns out that, holy crap, it’s pretty easy to fill an entire day with stuff that’s not writing a book.
I started getting up early in the morning before the kids so I could have some quiet time. Ostensibly, I would write then, and sometimes I did. But, more often than not, I’d just drink coffee and stare at the Internet while I slowly roused myself. Then, after I’d worked, made dinner, gotten the kids cleaned up and ready for bed, read them books, gotten them milk, cleaned up a bit and gotten them in bed, then, I’d still have to write.
Yet, strangely, I would. I’ve never demonstrated an ounce of self-discipline in my entire life, but for some reason I just didn’t want to skip a day. Even though I was often dog tired, I would scrape up just enough energy to put in a barely half an hour of writing. I would look at the pathetic word count and feel bad before going to sleep exhausted.
But here’s the thing. Even tiny amounts of effort add up if you keep at it. I’d have entire weeks where I felt like I didn’t have a single good writing day, but after two of those weeks… that’s a whole chapter.
Because I was writing every day, it made it easier to build it into the routine. I never had a chance to get used to not writing. It was just this thing that must be in the schedule, like brushing my teeth or eating, even when I traveled or did outings with the kids. I gave a talk at Strange Loop last year, and every evening after dinner, while others were out at bars socializing, I went back to my hotel room so I could write. When I flew to another office for all-day meetings, I wrote on the plane.
The only insurmountable problem I ran into was a camping trip. I couldn’t imagine bringing a laptop to the woods and charging it in my car or something. Instead, I did what comic strip artists do: I banked some days. For two days leading up to the trip, I wrote two sessions a day. Then I wrote early in the morning before leaving, so I only ended up skipping one day. I basically loaned myself the time, with interest.

Refusal of the Return

Once I started putting chapters online again, people started noticing. I got that feedback and encouragement that I thrive on and I was delighted to have stuff to talk about on reddit again.
Around this time, an editor at another publisher reached out to me. Now that I was working on the book again, would I be interested in a publishing deal? She was super nice and was very willing to work with me. I could keep the book online, I could be involved in the design and layout. It could be everything I wanted and more.
I kind of dragged my feet for a while before I finally realized my reluctance was trying to tell me something. When I’d had publishers before, the power relationship felt really strange. O’Reilly and Apress were both great, but I felt like they were in charge, which is really bizarre when you think about how much effort the author puts into it compared to the publisher.
What I was finding was that I really liked it being my book. I’m not doing this for the money, which means I’m doing it for my personal satisfaction. And what’s most satisfying to me is feeling like I got to put as much of my own creativity into it as possible without someone else calling the shots.
That’s not to say I don’t like collaboration. I’ve gotten about 130 bug reports along with a bunch of pull requests, not to mention lots of comments and email. I absolutely treasure all of that, and the book is way better than it would be without that.
I really like working with readers and contributors, but I’m not really interested in working for a publisher. About half-way through the book, I decided to self-publish. That meant I needed to start doing the things a publisher does. In my mind that’s:

1. Developmental editing. When you get a book deal, this is what the editor you work with does. It’s their job to guide the overall direction of the book to make sure it lines up with what audiences want.
   
2. Marketing, advertising, and distribution. Basically, getting the book in front of people and in stores. Making sure people know it exists.
   
3. Copy-editing, proof-reading, illustrations, and design. The sort of blue collar stuff that turns a manuscript into a book.
   

I’d been putting chapters online and interacting directly with my audience since I started the book, so I felt like I had a better handle on what they wanted than most editors would. Having an inbox with hundreds of emails from people is pretty helpful when you’re trying to figure out what they want.
All of the manual labor side of things—editing and design—are some of my favorite parts. Before I was a programmer, I was a graphic designer, and I’ve dreamed of typesetting and laying out a book. Bug reports from readers helped do some of the work of copy-editing. (Special shout-out to mystery superhero colms who basically line-edited the entire book free of charge.) Finding a freelance proof-reader didn’t seem too hard.
Of course, distribution is a mostly solved problem now. Especially with technical books, people buy them from Amazon or get eBooks. I can do those just as well as any New York publisher. You don’t need deals or shelf space any more (though it certainly doesn’t hurt).
That left marketing and advertising—making sure people knew about the book. So I created a mailing list. I added a little blurb to the top of each page saying the book was a work-in-progress and to sign up if you want to know when chapters come out. As of this morning, I have a little over 3,000 subscribers, which is probably more reach than a “real” publisher would have given me.

Finishing the Damn Thing

Once I had that decided and squared away, all that was left was to write the rest of the chapters. So I wrote. And wrote. And wrote. Every single day. I wrote while my wife gave the kids a bath. I wrote at five in the morning before we went on day trips. I wrote when I was sick. I wrote on Halloween, Thanksgiving, Christmas, and New Year’s.
When I finished a chapter, I’d spent a few days where “writing” consisted of fixing bugs, responding to email and other minutia. But then I’d get to the next chapter.
After a while, writing the book receded into the back of my mind. It wasn’t something I thought much about during the day. When people asked what I did outside of work, I’d forget to include it sometimes. It was just ever-present background noise. Exactly 322 days after I started the first draft of Game Loop, all of these little slices of low thread priority background work on the book added up.
95,688 words. 21 chapters. 66 illustrations. 133 fixed issues. Hundreds of commits. Yesterday, I committed the third draft of the last chapter and the manuscript was complete.
I’ve wanted to be able to claim that I’ve written a book for so long that it feels weird to finally be on the other side of finish line. I wrote a book. Not “want to write”. Not “will write”. Not even “am writing”. Wrote.