Ten years of Halo 2

Where were you ten years ago? We’re asked frequently in job interviews “Where do you see yourself in 5 or 10 years?” This is a really hard question to answer. I like thinking of where I was ten years ago and see how far I’ve come. Gaming has always been an important part of my life and I occasionally like to think “What was I doing in gaming ten years ago?”

Ten years ago, my life was FULL of gaming. I was working for GameStop. I was a seasonal hire. I was hired in October and my position was over a week after the New Year. I just had a four month spurt of unemployment and was in the middle of my junior year of college. I wouldn’t say I was strapped for cash or anything. I was working weekends at a local paintball store. I ended up being the only holiday hire out of six to be offered a permanent position. I ended up passing and going to work for a local grocery store chain.

The fall of 2004 was an amazing time to work for a video game store. Fable was released a few week before I started. There was a lot of negative feedback due to the game not living up to expectations. We had a lot of trad-ins of the game my first week. I got to experience the Grand Theft Auto: San Andreas, Star Wars: Knights of the Old Republic 2 and The World of Warcraft releases. These games were milestones and set the standards for the games of that generation. World of Warcraft is still a very relevant MMORPG. San Andreas recently made it to the hand held market and KOTOR eventually evolved into an MMORPG that couldn’t live up to the reputation of its predecessor. One game topped all of these for me and it set the standard for my preference of games ever since.

Halo 2 was the only game that was released in the fall of 2004 that had a midnight release. The game was released on November the 9th 2004. There were roughly one hundred and twenty people hanging outside the store at 11:55pm and just about everyone had paid for the game in full. This event was the easiest shift I ever worked. Everybody was excited for the game and we were ready to serve. I took a hint and picked up an XBox the next week.

I tried to do things right. I played through the original Halo and this was extremely challenging for me. Goldeneye and Perfect Dark were the only FPS games I had experience in and the dual control stick layout took some getting used to. Halo was conquered over a weekend and Halo 2’s campaign was destroyed shortly after that. My gaming preferences were drastically changed after this experience.

I’ve never been big into the multiplayer experience. I was much more into the story. The Halo franchise has a very detailed universe and Halo 2 introduced the players to the other side of the story. The first game involved the super soldier, but the second game put you in the shoes of the enemy of the first game, the Covenant. You learn about the different species of the Covenant and experience the tension of the defeat from the first game. I had never played a game with this type of story telling. A lot of people didn’t like the fact you didn’t play the whole game as Master Chief, but I thought it was brilliant.

Over ten years, I’ve played all the Halo games, read most of the books, watched the TV series, and watched a lot of Red vs Blue. I can’t say Halo 2 was my favorite. It was the game that caught my attention and made Halo my favorite game series of all time. Halo: The Master Chief Collection comes out tomorrow. It crams Halo remastered, Halo 2 remastered, Halo 3 and Halo 4 into one game. I don’t own an XBox One, but I anxiously await the day I do so that I can re-experience ten years worth of awesome gaming.

Bootstrap – The framework you hate for all the wrong reasons.

Disclaimer: The thoughts in this article are my own and do not represent the opinions of my employer past, present or future.

I’ve been sick in bed the past few days. I tend to do a lot of reading when I’m down and I stumbled on a several articles criticizing the Bootstrap framework. (I also got going on Single Page Web Applications, but that’s for a different time.) I got pretty motivated to express my opinions from my experience with the framework.

I’ve been utilizing the Bootstrap framework for over a year now. I’ve had a lot of success with it and it always amazes me how much hate it gets. I’ve spent a lot of time in their source code and I have a really good understanding of how everything works. I’ve done a lot of responsive work outside of Bootstrap and I’m pretty comfortable arguing for or against it.

This is one of the tag lines from Bootstrap’s web site. Do I believe it’s true? Yes, I do.

Designed for everyone, everywhere.

Bootstrap makes front-end web development faster and easier. It’s made for folks of all skill levels, devices of all shapes, and projects of all sizes.

There is one big thing that gets overlooked a lot when looking at Bootstrap. Bootstrap is trying to do two big things. It’s a responsive grid framework and a responsive UI framework. The UI part of the framework provides styled static elements like inputs and buttons, and also has a set of interactive components that work well on a smaller screen.

So what’s with all the hate? I have a few reasons I’ve heard and theories I have.

You have to use a bunch of random classes to get it to work.

I see a lot of this. There is a trade off though. Many single class elements end up with countless rules that get over ridden based on it’s parents elements or the current media query. It’s a trade off. Do you want more rules in your style sheet or more classes on your element?

It’s bulky.

The full CSS library is around 130kb and the JavaScript library is around 30kb. Is this heavy at a glance? Yes, but there are three things you can do if you don’t like this.

    1. Utilize a CDN – There are several providers that serve up the full Bootstrap package over a CDN. A CDN will provides speed by caching the content and your browser will download it faster because it’s on a different domain
    2. Build your own Bootstrap package – This is the less obvious choice, but you can really slim down the package by using their tool. You can also download their source code and create a custom build yourself.
    3. Do both 1 and 2 – There should be other static assets in your project. You might as well invest in the service.

It’s trendy and people only want to use it because “Bootstrap” is a buzz word right now.

There is a lot of truth behind this statement. Bootstrap is extremely popular right now because it’s fairly new. jQuery had a similar buzz around it after it hit mainstream.

It’s not not suitable for large scale applications.

I couldn’t disagree more. Bootstrap’s consistent naming patterns make it ideal for large teams working on large projects. A fully custom responsive implementation requires a lot of documentation and communication across the team. The likely hood of a class being misused is pretty high. With Bootstrap, everyone can easily know how the grid works and work through new pages quickly. I’ve seen a large number of backend developers wire up pages using Bootstrap with ease. This introduces a level of efficiency that can be extremely challenging to replicate with a custom responsive implementation.

All Bootstrap sites look the same.

Did you expect to use Bootstrap and not have to code your own CSS? Checkout Wrap Bootstrap and see if you can tell if the sites are “exactly the same”. I roll my eyes at this comment a lot. It is very common to come across websites that look stamped with the Bootstrap CSS, but imagine what these sites would look like without it.

Web Designer: I don’t want to design for it.

Ok, that’s nice. Don’t want to be limited to 12 columns? That can be changed by a couple keystrokes in a LESS file. Don’t like the default buttons and inputs? A little custom CSS will fix that. The only thing we can’t do is recreate a design based on a non-grid layout. Most CSS responsive frameworks have limitations when working with non-grid based layouts. Just do whatever you want. Clever front end developers will figure out how to do it.

Front End Developer: I have spent a lot of time learning to be an expert on responsive.

Don’t worry about this. I personally know several SQL developers that panicked when Linq to SQL/Entity Framework came out. They thought that they would be out of the job because anyone who knew C#/VB would be writing their SQL for them. This is 100% not true. A framework can get you 90% there. Knowledge and experience will get you the rest of the way. The experience you have in the core technology is always relevant. The same can be said about jQuery and JavaScript. jQuery made JavaScript 100Xs easier to write. CSS precompilers can be thrown in this boat too. jQuery and Linq also introduced ways to write really bad JS and SQL if you weren’t careful. Bootstrap is no different. It can help you write simple and quick responsive elements, but can also create overly complicated and complex elements. As an experienced FE Dev, it’s your responsibility to identify the right and wrong ways.

You’re old fashioned and boring

If it ain’t broke, don’t fix it. I really hate LESS. I’ve been using it heavily for a year now. I just hate it. I see too much bad code, improperly named global variables, hundreds of media queries that could be consolidated, and excessively over qualified selectors due to nesting. Bootstrap contains the ONLY LESS files I’ve seen that do something cool. They create loops for generating the CSS for the grid layout and calculate out exact widths with it.

I feel like I have much cleaner and better performing CSS without LESS, but it takes me a little bit longer to do. You could say the same about Bootstrap. A lot of people said the same thing about JavaScript with jQuery and SQL with LinqToSQL. These tools and libraries get widely adopted and we can’t avoid working without them. I’ve seen a lot of bad JavaScript due to jQuery and several websites crash due to bad Linq statements. Why do I continue to use LESS, jQuery, and Linq? Efficiency. I can code with or without them. It doesn’t matter. I want to be versatile and quick. I can get stuff done a lot quicker with them. The same can be applied to Bootstrap. It’s a new tool that introduces a lot of efficiencies. It can also introduce potential inefficiencies much like the tools above, but a good developer should catch these before they become a problem.

Bootstrap is a very capable front end framework that makes responsive easy and quick to implement. This is much like what jQuery did with JavaScript. Is Bootstrap something I’m going to implement on every one of my projects? No, but it will be my goto framework when a project fits the mold and I can save time. It’s another tool to add to my toolbelt that will allow me to be innovative and more versatile.

Debug your AngularJS app with AngularJS Batarang

I’ve been fortunate enough to be able to start working on several AngularJS applications and I can honestly say I haven’t had more fun geeking out on a project. They are internal projects so I can’t really show them off and brag about them, but I am really happy with my work. It’s not perfect, but I feel like they are pretty good for the first few runs.

On this last project, I hit a really big snag on performance. I was working on a grid with inline editing that required specifically formatted inputs. I cannot deny I’m an Angular rookie, but I really wasn’t sure where I should start with debugging the issue.

I stumbled on AngularJS Batarang while looking at a couple of Chrome extensions. Long story short, this is exactly what I’ve been looking for and more. Check out this video that shows the features.

Checkout this extension if you are new to Angular or are looking to optimize your Angular app. It’s really easy to use and extremely helpful.

So you want to program for a living?

I love coding for a living. I’ve done a lot in the job market since I started working. I’ve worked at a video game store, a paintball field, several small business, several grocery stores and other random jobs. Nothing can compare to coding. I get to build really cool stuff and it’s never boring.

I’ve really wanted to be involved in this part of the computer industry for as long as I could remember. I’ve always loved video games. In 3rd grade I wanted to be a video game tester. I got a VHS tape from Nintendo Power that showed the testing process of Donkey Kong Country. I thought this would be the coolest job in the world. This is essentially called “QA” for Quality Assurance. I didn’t know that this has very little to do with making games and I didn’t really want to do this. I eventually realized I wanted to actually program the video games. It’s been a real long journey that had taken many delays, but ultimately led to the greatest career I could ever dream of.

I get shadowed by a lot of high school students who are interested in the programming industry. The number one question I get asked is “How do I get started?” This is a very loaded question that doesn’t have an easy answer.

The first and most important question you need to ask yourself is: “Do I have the right personality to be a programmer?” Wanting to make a video game or making the next big iPhone application isn’t enough. This breaks down into several smaller questions.

  • Do you have good problem solving skills? You’ll spend a lot of time looking at a blocks of code that don’t work and you will be expected to fix them in a timely manner.
  • Are you good at working behind the scenes with other people? Programmers are more like roadies than rockstars. We make sure everything is working and setup correctly. The rockstars are the ones who sell what you work on to clients and present your projects at conferences.
  • Are you wanting to do this for the fun and excitement of the industry? A programmer’s compensation varies severely due to many different factors. What region of the country do you work in, what is the demand of your technology, what is the quality of your work?
  • How do you handle pressure? There is no room for procrastinators here. Deadlines are very important. Pushing them back isn’t always an option.

You have the personality? Great! The next step is to learn to code. My recommendation is to start early. I took Visual Basic in the 11th grade and C++ in 12th (this may not be early by today’s standards, but it was for 2000). I had picked up a little HTML along the way too. I learned about project planning and databases in college. I had a small amount of knowledge in a large number of fields. I see this as really the best way to go. You will have professionally trained instructors who are available to help you out. This may not always be an option for everyone. You can get similar instruction now a days from online courses. Code Academy and Microsoft Virtual Academy offer great courses to get you started.

You need to have an idea of what you want to program before trying to get into the job market. Coding a video game isn’t always a direct hire situation. It’s frequently a hobby thing that turns into a real job if you are really good and lucky. iPhone and Android programming is very targeted and you may have difficulty finding a good job in it right off the back. Most iOS and Android devs that I know got started in server or web development. Learning a flexible language like Java or C# will make you versatile enough to be able to apply for many different types of programming jobs.

I think getting hired at your first job is the hardest part of wanting to be a programmer. Most places want several years experience. How can you get experience when no one wants to risk hiring a greed developer? The easiest answer is to find an internship when you are in college. The second is to freelance. A lot of developers I know love to freelance. It’s not for me.

The type of environment you work in is very important. I like to work with a lot of other developers in a relaxed environment. Not all jobs are like this. You may have to wear a suit and you are the only developer in the company. You may have to work in a cramped cubicle farm with fifty other developers. Make sure it’s in a environment you are happy with. You wont produce quality work if you aren’t happy where you are working.

Your resume and interview are extremely important too. Don’t bloat your skills on your resume. I read a lot of resumes and it’s pretty easy to spot. You can’t have 9 years of relative experience in a programming language if you just got out of high school. Separate out your academic experience and what you feel is truly professional experience. I outlined my academic programming languages in my interview with my current company (COBOL FTW). They greatly appreciated the modesty and asked a lot of questions about the work I did in the classes. These turned into discussions about my passion to code and build applications. Modesty goes a long way in interviews. Focus on your passion for code and don’t boast about being a code “rockstar” or “ninja”.

Ok, so lets say you scored that awesome first job. Welcome to the club, now it’s time to keep the ball rolling. This industry never stops and you can be kicked out quicker than you got in. You don’t want to go from coding to sacking groceries because you spent 15 years coding a legacy language and not ever learning anything new. You need to build a reputation for yourself and prove your long term worth. You can do this by expanding your knowledge in new programming languages, networking with other developers and most importantly, learn how to do your job the absolute best way possible.

My journey to this point in my career has been pretty amazing. I’ve gotten very lucky with the opportunities put in front of me and I’ve been very fortunate to work with some very inspiring and talented people. I wouldn’t say it was perfect, but I tried to fail forward the best I could. Your career is ultimately what you make it.

So, do you think you have what it takes to be a code monkey?

I am a Web Developer

I am a web developer, and we could be the most complicated and strange people you have or ever will interact with.

We grew up building LEGO models asking ourselves the question, “How can I make this bigger?” We played videos games thinking, “How can I build this?” We were fans of both Star Trek and Star Wars, because we knew the only thing they remotely had in common was the word Star. We wore bow ties before the Doctor said they were cool.

Now we work in the dark corners of our offices, ruling over the kingdom that is our code. We take other people’s ideas, bring them to life and at times lack the ability to explain how it works. We find it difficult to integrate with our co-workers because our interests are typically polar opposites. We try socialize, but it usually ends in awkward situations.

We use different web browsers and read news from different sources. We see viral videos before they went viral; we bought the latest tech gadgets before they were announced (and we never show it off); and we already know which console will be the best in the next generation.

We frequently fix bugs with descriptions of “It’s broken,” and we still somehow manage to find and fix it. We work off general ideas and play the guessing game instead of working with structured documents telling us what to build. We are left off the ending credits, and we don’t mention it. We celebrate with other developers and brag amongst ourselves.

We thrive off complex problem solving and we do not have an off switch. We go to sleeping thinking about what problems we left at work and wake up eager to get back to make it better. We fight internal struggles to throw our work out the window and start from scratch to make it perfect. We don’t ask, “How can this make more money?” Instead, we ask, “How can we make this better?” We don’t ask, “Why?” We ask, “Why not?”

We don’t get always along with other developers. Our code is our art and we think our own art is perfect. Our brains are answering the same questions with different paths to the solution. Some of us code for scale, some for maintainability, and some for complexity. We always feel that our way is the right way. We will bang our heads on our desks for hours and not ask for help because we are too proud. We will say “Oh yeah” or “How did I miss that?” when someone walks over to us and bravely asks us “What’s up?” or “Can I help?”

Some of us try to get ahead by boasting abilities and using the terms “Ninja”, “Guru” and other technology buzz words. The humble among us know that our work speaks volumes above the words on our LinkedIn profiles. None of us know everything, but all of us are eager to learn as much as we can.

United, developers can do anything. They will build a global e-commerce platform and then build you a social network capable of handling millions of users. We don’t care if it reaches that number, but we do care that it can.

We are here to build what you need, and we patiently wait for the next challenge.

Disclaimer:
My right eye was swollen shut when writing this. Please be sympathetic on spelling and grammar

WorthyD’s CSS guide for Rookie CSS Devs and Backend Devs

I’ve dug around for a long time for CSS best practices. I’ve found tons of contradicting and wishy washy rules. Most of these only make sense to people who are in CSS every day and are highly debatable. I’m going to try to give an overview of what I see as most important and explain why in a way most developers can understand. This should point you in the direction to get you into more advanced CSS and not drive your cut out people insane with sloppy CSS.

I’m going to go ahead and throw out that I firmly believe that you should easily be able to completely re-skin your web content without needing to roll HTML updates. I believe class names being specific to the content and not packed with a bunch of generic classes.

Know the basics

Know the best way to include style sheets.

There are two ways to include style sheets.
Method 1 – The Link Tag:

<link rel='stylesheet' href='a.css' />

Method 2 – Import:

<style>
     @import url('a.css');
</style>

For performance, only use method 1. Method 2 will block parrallel downloading of style sheets and slow down the rendering of the page.

Do not use any inline styles. Period. EVER!

Inline styles kill re-usability and maintainability . It’s super easy to tack on inline styles if you don’t want to dig through a thousand line CSS file.

Avoid using style tags at a page level

This is mainly for tidiness. If you need to modify styles specifically for a page, create a style sheet for that page and reference it with a link tag.

Stay organized

Combine & Compress your CSS

Personally, I like having multiple CSS files to keep things organized. For production, I’ll combine and compress them into one file. This helps avoid having a CSS file several thousand lines long that is difficult to maintain.

@if(IsProduction()){
  <link rel="stylesheet" href="main.min.css" />
}else{
  <link rel="stylesheet" href="reset.css" />
  <link rel="stylesheet" href="base.css" />
  <link rel="stylesheet" href="forms.css" />
  <link rel="stylesheet" href="buttons.css" />
}

Keep your CSS Selectors organized

Section off your style sheet so people know what they are looking at. You can use comments to help identify what section they are looking at.

/*==========
    Header
===========*/
.logo {/*RULES*/}

/*===========
    Navigation
============*/
#nav{ /*RULES*/}
#nav li {/*RULES*/}

Selectors

CSS selectors are the key to having clean and maintainable CSS. There are some pretty simple rules you can follow to ensure you don’t end up with a bunch of messy CSS.

Classitis and Specificity

Classitis is having to rely on many class rules to select your element.

<style>
.nav .navItem .navElement{
     color:#fff;
}
</style>
<ul class="nav">
     <li class="navItem"><a class="navElement" href="#">Home</a></li>
     <li class="navItem"><a class="navElement" href="#">About</a></li>
     <li class="navItem"><a class="navElement" href="#">Login</a></li>
</ul>

The example above contains a lot of classes in the HTML that can be condensed. The selector also is longer that needed. You can clean up like so.

<style>
.nav a{
     color:#fff;
}
</style>
<ul class="nav">
     <li><a href="#">Home</a></li>
     <li><a href="#">About</a></li>
     <li><a href="#">Login</a></li>
</ul>

Now this is only ideal if the ul.nav element will never have additional child a elements.

It’s also important to keep your selectors as short as needed. A selector with 5 or 6 selector elements isn’t ideal. You can control this by understanding CSS Specificity. Here are two articles that do a better job explaining it than I could. CSS Specificity: Things You Should Know & Specifics on CSS Specificity

Naming Conventions

Selector naming conventions are another religious argument that can be debated all day long.

.navMenu {margin: 10px;}

.nav-menu {margin: 10px;}

.nav_menu {margin: 10px;}

All of these are valid by the W3C and pass CSSLint. The important thing is to STAY CONSISTENT!!!! Personally, I camel case because jQuery UI uses hyphens. It’s easy to see what rules are mine and what is theirs.

Utility Classes

Avoid use of utility classes. The class names aren’t always descriptive enough and relying on them could cause you to need to roll both CSS and HTML in your site updates.

/*Common Utility Classes I see that bug me*/
.fr {float:right}
.fl {float:left}
.mb15{ margin-bottom:15px;} 
/*what happens if you're asked to move the content? 
Make another class for margin-bottom 13 and update your HTML?*/

Using utility classes will speed up your coding, but will hinder the maintainability of you code. You’re HTML elements could also end up with 4 or 5 classes on one element.

Understand Child Selectors

Using child selectors can help prevent the need of overwriting parent element styles. These aren’t supported in IE7 and below. Use when you can, because they can help prevent a lot of headaches.

 
<style>
ul li {color:blue; margin-bottom:15px}
ul li ul li {color:#fff; margin-bottom:0px}
</style>
<ul>
	<li>Blue</li>
	<li>Blue</li>
	<li>Blue
		<ul>
			<li>white no margin</li>
		</ul>
	</li>
</u>

We can re-write the CSS selectors and not have to overwrite the margin-bottom rule by doing it this way. It’s a real primitive example, but I run into this issue daily.

 
<style>
ul > li {color:blue; margin-bottom:15px}
ul ul > li {color:#fff;}
</style>

Read more about Child and Sibling Selectors

Chaining Classes

Chaining classes can be really helpful. But like child selectors, it doesn’t fully work in IE6 and IE7. You can also end up with an element that has a ton of classes attached to it.

<style>
   .icon{background-image: url(sprite.png);}
   .icon.save {background-position:-10px 0}
</style>
<input type="button" class="icon save" value="Save" />

Read more about mulit class selectors

Have Clean Properties

Your selectors are really only half of the CSS you have to really pay close attention to. You need to have clean CSS properties. Here are something things that will help cause less grief for the person coding after you.

Alphabetize Your Properties

.selector {
	width: 100px;
	margin: 10px
	border: 1px solid #000;
	padding: 5px
	float: right;
}
.selector {
	border: 1px solid #000;
	float: right;
	margin: 10px
	padding: 5px
	width: 100px;
}

You can find properties a lot quicker when they are alphabetized. Web browser tools will also alphabetize them in your DOM inspector. It took me a long time to get this down, but has helped out a lot.

Use Shorthand Properties

Short hand will help out on your file size and makes it more readable.

.selector{
	margin-bottom: 5px
	margin-left: 10px;
	margin-right: 10px;
	margin-top: 5px;
}
.selector{ /*Same rule, but in shorthand*/
	margin: 5px 10px;
}

Read more on CSS Shorthand Properties

Zero Values

Don’t use px on zero values. Several reasons to do this, but it’s just a lot cleaner code and the “px” isn’t required.

/*discouraged*/
.selector {
     margin: 10px 0px 5px 0px;
}
/*better*/
.selector {
     margin: 10px 0 5px 0;
}

Image Reference

It’s important to use caution when referencing CSS. This isn’t an issue if you are 100% sure where your site is going to live. If you do your development on blah.localhost and your site ends up being hosted on blah.localhost/blah/ your image references will be broken if absolutely referenced.

/*image reference will break if app is moved to a sub directory or file is hosted on cdn*/
.img{
    background-image: url(/content/images/img.png);
}
/*this image reference makes  your CSS more portable*/
.img{
    background-image: url(../images/img.png);
}

Do not use CSS hacks and avoid using !important

Back in the day, it was really common to use browser hacks to fix IE specific issues. This should be avoided at all costs. You can use conditional comments to target specific versions of IE if you need to. In the last few years, I’ve only had to use conditional comments a couple of times.

Using !important after a CSS rule jumps the specificity all the way up. Learn about CSS specificity to avoid using !important. ONLY use if if you have a nasty javascript plugin that writes out styles you don’t like.

Frameworks

There are tons of CSS and Javascript frameworks to help you out with layout, feature detection and all sorts of other fun stuff. There’s Mondernizer and Bootstrap to name a few. Out of the box, these frameworks are potentially dangerous for the performance of your application.
Modernizer has a TON of feature detecting, but lets say you aren’t using Canvas or Video tags. Do you really need Modernizer to detect those and include all the code to detect them? Go get a custom build of it to plug into your site.

Well that turned out a lot longer than I had initially expected. I hope you found something useful. Please fell free to leave any feedback and I’ll do my best to keep good stuff coming.

My opinion on the events around the Fez 2 cancellation

If you’ve been keeping up with recent news in the gaming industry, then you have probably heard that Fez 2 has been cancelled. This is the result of a bunch of exchanges over twitter and stuff. Totalbiscuit (TB) summed up the situation pretty well on his Content Patch for July 29th and gave his option from a gaming media perspective. I’m going to come from a different side.

The high level overview of the situation. “AnnoyedGamer” Marcus Beer calls out a couple of indie gaming developers for not providing an opinion on some of recent updates on the XBox One Indie publishing announcements. Beer insults them pretty thoroughly. One of them is Phil Fish, designer of the game Fez. The two exchange a bunch of tweets and Fish “rage quits” game development and cancels Fez 2.

I knew nothing of the situation going into watching the Content Patch video. TB mentions that Fez was featured in Indie Game The Movie. I own a copy of it on Steam and it’s available on Netflix. It is a pretty good movie. The movie primarily features three games. Braid, an early and very successful game, Super Meat Boy, a game that was in the process of being published, and Fez, a game in heavy development. You get to see all the aspects of success, failure and all the struggles with indie game development.

Phil Fish really caught my attention when he was on screen. He is very animated, opinionated and pretty vulgar. His game, Fez, was first demoed in 2007, and wasn’t released until the middle of 2012 on XBox and 2013 on Steam. In the interviews he mentions getting a lot of hate for continually delaying the game. He also demoed the game at a convention. The build of the game for the convention was a new build from the previous day and had a game breaking bug that resulted in the game needing to be restarted anytime someone played it.

I know game development and design is difficult. It’s something I’ve always wanted to do, but my programming journey took me into another direction. I do understand the development life cycle and management of projects.

Delaying the release of a product over and over will only spark frustration to your potential client base. I remember seeing the 2007 game footage of Fez and was pretty excited about the game. The lack of a solid release date really killed my attention span. It’s not appropriate for every game to have a “beta” version that that can be purchased and played. I purchased Minecraft while it was in beta and the full release date was heavily ignored by me. The continuous updates to the game kept my attention. Fez may not have been a good fit for that model. Fez’s delay may have been due to continual scope creep (addition of features), lack of discipline, or having too high of standards for your work. A product that is in development typically doesn’t have income outside of investors. Investors will only invest for so long before pulling funding. A product can never be successful unless it’s published.

Bugs will happen. One of the greatest things about the software industry now is patching. Video Games consoles didn’t have patches or updates until the more recent generations. That means your SNES and NES games had bugs the whole time you owned the game. Developers had to make sure that their code was 100% before the game was physically made. Now, developers are very use to being able to push out bug fixes quickly. Starcraft 2 has had a ton of patches for bugs and game mechanics. With all that being said, you can’t let that ease of fixing destroy how you code. If you have a demo or any sort of public showing of your product, make sure it’s buttoned up. I typically use source control branches to keep a stable version of what I’m working on. I can publish a working product at any given time using this strategy. I’m not an expert at presenting stuff, but I would feel a lot more confident in a demo if my product lacked a few features and didn’t crash.

Something that is unique to indie game developers are their target market. Gamers can be and frequently are some of the most immature, critical and evil people on the planet. Don’t believe me? Go play some ladder games of SC2 2v2 or League of Legends and see if you get out without being raged on. Trying to please the masses in this industry is darn near impossible and you have to do your best to accept that. You may see your game as art, but they are going to play it and see it completely differently than what you expected. They will berate you for simple things like not being able to change the controller scheme or character dialog. You can’t wear your heart on your sleeve when dealing with gamers on Reddit, forums or anywhere else on the internet.

Finally, arguing on Twitter is the dumbest thing ever. Three years ago, I was told by one of the co-founders of Joomla that I didn’t know HTML. I had complained on twitter that the editor wrapped my content in 4 font tags and was going to switch to WordPress (this was for the Boy Scout Troop’s website I was working on). I tried to reply saying I’d rather use a text area field than a wysiwyg editor and he retorted back saying “garbage in garbage out”. I then realized that arguing on Twitter is REALLY dumb, especially between adults. How can you make a valid argument about something in 140 characters and it be civilized?

Anyway, It’s 2am right now and I’m really tired. Lily has been rolling around in her crib all night. Side Note: Get a camera in your nursery if you have a little on in a crib. Its kinda cool watching them sleep ^_^.

Yay, for indie game developers! It’s definitely not for everyone.