If you’re looking for a more general post about what EA looks for in new applicants, check out my other Electronic Arts UCSC Presentation post. If you’re aiming to be an engineer, you’re looking at the right post already, although it wouldn’t hurt to read the other post for other information like where to apply for jobs, other employment opportunities, and more.

Game Development Stages

The first thing Duke talked about was the stages a game goes through from start to finish. He also remarked that most AAA game developers other than EA follow a very similar process.

1. Ideation: Coming up with an idea for the game. It usually involves a small team and creative director. The idea can really come from anywhere, in or out of work. It can be a new intellectual property (IP), expansion pack, anything. Talk to a senior producer about it.
2. Green Light: Once the ideas are set, build a powerpoint to pitch game explaining how long it will take to build and how much money you think it will need. What usually happens is you define what you need for the next 3-6 months to prove that the game will pull through and then come back to get it screened again with specific information like ship dates and costs.
3. Pre-Production: If the idea passes the green light, the game goes into this pre-production. 5-10 people on the pre-production team start building the prototype. Most teams don’t pass this stage. The keys to passing are a solid prototype, good plan, and an actual market for the game.
4. Production Green Light: Your game is checked again. You now have to have concrete numbers rather than estimates for information such as budgets, team plans, and ship dates.
5. Production: Once you get your production green light you go into official production. Unfortunately, this is not a guarantee your game will actually live to see a shelf or digital download. If team doesn’t meet “intervals” (specific wording he used… not sure if there’s any difference with deadlines?) they promise, the development of the game can be cancelled by the company. The development team still has to worry about staying within the budget, on schedule, with the plan, and really prove themselves that they can make the game succeed. Essentially production focuses on building all of the planned features to get to what they call “alpha functionality”.

   A bit of time is taken out of production to evaluate the development and forward changes not originally in the plan to change review. Everyone on the development team is encouraged to send their new ideas to change review (ex. UI change). The production and design team constantly look through the change review and order the list of ideas that should be worked on during the change review development stage. Each requested feature is calculated a cost (development time, difficulty, etc.) which determines its placement in the change review, or if it is even included in the change review at all.

6. Change Review: Time is taken out from following the original plan and development deviates a little by following the change review. This addresses problems and requested features that came up after the plan was defined during the actual development process. This stage is more about refinement and polishing.
7. Alpha: The game is considered to be in “alpha” when all of the features that were planned are finally in the game. However, everything is very buggy. No longer is the development driven by features, now it is driven by bug-fixing. Quality assurance (QA) starts bug testing the game and sending feedback to the development team. Engineers get hit the hardest during this stage. You might realize that bugs are not coming from your own code, so you have to communicate with those who coded it and find solutions.
8. Beta: The game is considered to be in beta the first time the team reaches zero bugs. Duke comically, yet at the same time seriously remarks that zero bugs in the bug list might only last for two minutes. (QA apparently finds bugs really fast!) Some bug fixes are pushed passed the release date as patch fixes since they might be too risky to ship the game with as bug fixes often bring newer bugs. Ideally they want patches to just be things like game balancing or like “little enrichments”, but the reality is a lot of times the games are just too big and they can’t get enough test coverage in. From Duke’s experience, some of the worst bugs are from bug fixes at the very end of beta, so it’s best to avoid fixing bugs as the deadline comes unless they are particularly game breaking.
9. Final: This is the first hope that this will the last time they think they will develop the game since the game should be in an acceptable state to ship. The game stays in this stage for at least 2-3 weeks as QA constantly tests the game and and reports any issues they come across. Again, if the problem is not game breaking, then a fix for it will be pushed later on as a patch fix. If the problem is significant enough they will go and work on it.
10. Gold: After about 1 week or so with QA tests, if there are no bugs coming up that require immediate attention, then the game finally reaches the point where the main development cycle ends. This version of the game is the version that consumers get on the shipment date.

The development team does postmortems (evaluations of their own game) after the game is released to figure out what they did wrong and how they can learn from their experiences to make better games in the future.

Perforce

The next thing Duke talked about was Perforce. Perforce is a revision system that EA uses manage their code. (If you’re used to Subversion or Git, it’s in the same realm as that.) According to Duke, most AAA game development companies use Perforce.

EA keeps three different code lines (or more officially, “sandboxes” since each code line is technically a sandbox):

• Development Line: Where the developers check-in their most recent, working code. It is the main build that QA tests.
• Main Line: The code that stays a little more clean and only gets the code from the development line when they are ready to go into the final stage.
• Release Line: The exact copy of the code that is built and shipped to the consumer. It is generally used for emergency fixes that shipped on release.

An important concept Duke emphasized is called personal sandboxing. This is where you separate the code you personally work on from everyone else. The problem is that if you work directly on the development line, you can potentially break the entire game for the entire team (which can span up to hundreds of other people), slowing down development and angering a lot of your co-workers. By personal sandboxing, you keep your code to yourself until its ready to be checked into the development line. Also, it saves your work so just in case if your harddrive fails (which according to Duke happens to someone on his team every couple of months or so), so instead of losing months of work on your computer, at most you’ll lose maybe about a day’s worth. You can also share your sandbox with other people on the team which makes your personal sandbox into a shared sandbox.

Another note about EA’s code management is that they rely on many automated builds which will will run off your code. These builds are run by build machines which take your client specifications, sync to them, and run automated tests on your code and assets to let you know if anything broke. This is to help prevent anyone from breaking the development line.

Feature Workflow

Duke went on to talk about the workflow on a feature as an engineer.

1. Pre-FAMES: The first step is called Pre-FAMES (FAMES stands for Effect Animation Modeling Engineering and Sound, what EA considers the main disciplines are required to make a game). Every discipline gets to see the features in the design document and determines how much work each feature will take. It gives the designer and producer an idea of how much work needs to be done and how long it will take. During the planning process, a process called design iteration is considered where people leave room for feature fixing and refinement from feedback.
2. Design Review (DR): The team sits down and designers explain the design and goals. Everyone throws around ideas. Only about 10% of the ideas actually make it into the game, but it’s the time where people start saying, “Wouldn’t it be cool if…?” and stuff.
3. Implementation Review (IR) Preparations: Any of the questions in the design with regards to implementation are worked out by the engineers. For advice you can talk to your lead or you can talk to other department to get more specific information on the feature. If the feature is technically impossible, find other possibilities to achieve the feature instead.
4. IR: Everyone who is involved in a feature meet up and plan how they will work together. Before this all estimates are rough, but this is where the numbers, dates, and tasks are finalized since details from everyone becomes clear. If there’s any last questions on design this is the time to ask.
5. Code: You finally get to code! You still spend a lot of time communicating with a lot of people, making sure you guys are on the same page and that your work will come together the way you want it to. When you make changes, you must communicate those changes to everyone else involved.
6. Demo: Demo to it to the designer/producer! A lot of little changes are made from feedback.
7. Suggest Chain Review: If there’s any big suggestions that come up in feedback, forward the idea to change review.

Check-In

1. Code review: Code review is the process of checking your code for any bugs or problems. Most people prefer in-person code review. There are also online options where the code is posted online and other people can log-on to a system and give you feedback digitally. Duke says that surprisingly while you talk to another person about your code, you yourself catch so many bugs.
2. Check into sandbox: When you check into your personal sandbox, leave detailed comments in logs. It is extremely important to go into detail on what exactly you’ve done, because someone might be looking at your code years down the line! (As an example of how long code can be used, Duke states that The Sims 3 codebase is currently 8 years old and will live on to probably be around 10). Also you yourself will forget about the code you wrote, so comments will greatly help jog your memory if you ever need them. You can never be too careful.
3. Run a check build on your code: To ready the work in your personal/shared sandbox for the development line, run a check build on your code. If it fails, then you have to go back and fix your errors until it passes the tests. Then you have to start the check-in process all over again at the code review step.
4. Smoke test build: Run a smoke test locally. A smoke test is a manual test of about a minute or less that proves the baseline functionality works. This is to make sure all code in the development line is functional for any engineer on the team to continue to build on. (People who break the development line get publically shamed! Doing it a lot gets it marked on your performance review!)
5. Integrate sandbox to development line: If your code passes both the check build and smoke test, integrate it into the development line!

Development Methodologies

EA’s engineers development methodologies differs depend on what team and features they are working on. Generally there is no single dominant methodology and there is usually a mix that Duke calls “extreme agifall.” On some occasions there are some teams that are well suited for a specific methodology though. The three main methodologies that are used and mixed in EA are:

• Agile development: The core principle is always be building shippable software and focus on specific features for periods of time. It assumes that projects have interchangeable resources and that engineers can do the same work at the same speed, but with engineers with dramatically difference disciplines (ex. one specializes in shaders and rendering while the other specializes in UI) it’s not possible.

  One example of this methodology working is its application to tools developers. Since they are a support group to the rest of the team, they always need their tools in a shippable state since the development team is constantly using them.

  One example of this methodology not working is in gameplay engineering. It just doesn’t work for it because designs are always changing and there’s always a lot of feedback and iteration involved. Plus, gameplay engineers heavily rely on other resources from other departments such as textures and animations from other artists and animators.

• Waterfall development: Everything is sequential as the work goes through different teams. The problem here is that in games people will be waiting for work to come to them since the work comes through a pipe process. It is just too slow and is too difficult to manage properly.
• Extreme programming: The idea is that programmers work in pairs since ideally they will catch more bugs. Maybe this occurs on a task or two, but a whole project dedicated to this methodology doesn’t work since having multiple people programming on one computer usually slows the process down dramatically.

A common practice used in EA is called stand-ups. This is where every morning people who are working on similar features stand in front of task board and talk about what everyone is working on. From these discussions they plan their next step accordingly.

Programming Practices

• EA has company-wide programming standards per language.
• Most code is in C++.
• Some of the libraries they use are as old as 80s and 90s. For example, their exclusive EA STL that they still use today was originally built in the late 80s. This is mainly because they still work fine and there really isn’t any need to change them.
• Naming conventions: Lowercase ‘s’ in front of static variables, lowercase ‘m’ for member variables, classes are CamelCapped.
• Team coding standards: Teams usually set coding standards before they start working. These standards never contradict EA programming standards, they only supplement them. One example of a team standard would be deciding if everyone uses tabs or spaces for indents. This is important because for example, if one programmer formats a file in all tabs and then passes onto a programmer who reformats the file in all spaces, Perforce will say EVERY line in the file has been updated which will hide what was actually updated in the code.
• Unit testing: Engineers may build tests that won’t allow the code or game to run without passing it. While they are great, it’s best not to get too consumed in unit testing since most of the time you’re the only one who will test your feature. Unit tests are best for features where other people will extensively use and test the feature and is more common in the early portion of development or persistent design, and not so much for gameplay features.
• Language restrictions: EA rarely disables or outlaws any practices. They trust in their engineers and their peer reviews.
• Sometimes they strip down scripting. One example is taking out the DOM from Python to create a stackless Python because it was taking too much memory. In Sims 3 they stripped all of the networking from C# since all of the networking was coded in C++. They also took out file I/O since it leaves security vulnerabilities as the consumer will be able to write C# scripts to modify the game.
• Exception handling: They definitely use exception handling. One emphasis was actually how exceptions can actually be good things instead of just obstructive error messages. The topic was “Abort Callstack Without Fear of Yielding”, and Duke’s example of this was Sims 3′s reset exception. In a scenario where a Sim is stuck, by implementing a cheat code and shift clicking the Sim, a player can inject the reset exception and free the Sim from whatever the problem was. The reset exception specifically aborts the Sims call stack and repositions it in a safe location. Without it, Sims can essentially be stuck forever if they are unfortunate to ever come across a looping bug. Sure they don’t want the user to actually need to use the exception, but bugs do happen and this option is there if it ever occurs.
• Threading: Threading is used since PC, Xbox 360, and PS3 support it.

Cross Platform Development

When building across multiple platforms, EA engineers heavily rely on build automation where they develop mainly on one platform, which they call their lead SKU, and then use build automation to build the game on the other platforms. They have found that when they first used PC as the lead SKU, the development process was fine between PC and Xbox 360, but the PS3 version came up with a lot of problems. Now they use PS3 as their lead SKU, meaning that’s where they test that a feature is complete. They then waterfall back to the PC and Xbox 360. It doesn’t guarantee that there won’t be any problems with the other platforms, but it’s a lot easier since there’s usually less problems when PS3 is the lead SKU.

Originally I wrote out the word “skew” because that’s how Duke spelled out the word on his slideshow. I have since corrected the mistake as people have pointed out the correct spelling is actually “SKU”, meaning stock-keeping unit.

Engineering Roles

There are many different areas of engineering to specialize in:

• Gameplay Engineering: Implement the design of the game (rules of the game, NPCs, etc.) and are at the end of the pipeline and work with everything the other departments have created.
• Tools/Pipeline Engineering: Build and maintain the tools to support the development team.
• Network Engineering: Work with the client and server architecture for network communication.
• Database Engineering: Work with the databases.
• Automation Engineering: Build automated tests that are run on the game builds to make sure code and assets are running properly. Use PERL/Python scripts, can batch program, and know how to use build force triggers.
• Technical Artist: Similar to tools/pipeline engineering (more geared towards pipeline engineering), but the technical artist makes tools more geared for artists instead of engineers. Great for programming and artist hybrids.
• Engine Architecture (Breaks into many roles)
  • Graphics Engineering: Work with graphics and shaders.
  • Animation Engineering: Work with animation. Be excellent at 3D math.
  • Path Planning/Routing: Work with behavior. Lots of use of A* algorithm.
  • Resource Management: Work with resources and decides what should be kept in memory when and for how long. Knows what kind of caching systems should be used when.
  • Optimization: Specializes in optimizing the game.
  • Lighting/Shaders: Focuses mainly on lighting and shaders.

What are you lacking?

A computer science degree is a great basis, but it does not prepare you enough to make games. There are a number of skill sets that are required for game engineering that just aren’t found in most computer science curriculums.

Some things most people can work on are:

• Data structure knowledge for optimization: Most people can name data structures and give a general overview of them, but most don’t know when to use them, what the memory overhead for using them is, what’s actually bad about them, etc.
• Go beyond the classroom: Think about context how your code is going to be used, how often is it going to be used, what kind of inputs are they expecting, how many other people are going to use the code, etc. Everyone generally takes the same classes, so you need to distinguish yourself.
• Find your specialization: A great idea is find what you’re really good at or something you really enjoy and specialize in it, whether it be with artificial intelligence or graphics programming or whatever else you find yourself doing.
• C++ exposure for AAA: Most college curriculums don’t have C++ classes anymore, and even the ones that do usually don’t go low level enough. You need to have a good conscience about optimization because games need to run as smoothly as possible.
• Get a webpage!

Miscellaneous Topics

• Know the difference between a designer and engineer: Designers control the overall vision and make the decision of what’s right and wrong, while everyone else is usually focusing on creating a specific feature. As an engineer, especially a gameplay engineer, you greatly impact the design. Engineers try to understand what the high-level goals are and achieve them in efficient ways and communicate with designer and brainstorm to get “the best design for the right cost.” Duke specifically says, “As the engineering team it’s not our job to make the choice, it’s our job to make sure the designer and producers are making the most informed choice possible.”

  Duke feels that engineers have the most impact on games compared to the other jobs. Unlike designers, Duke brings up that point that if an engineer thinks an idea would be great in the game, he can actually stay after work and code it himself and show it to the designer, whereas non-engineers have to convince someone else that it’s a good idea and implement a prototype. The only thing is that since he is not the designer, he cannot decide if that feature actually gets implemented into the game or not, but having the capability to just pitch prototyped ideas is extremely powerful.

• Gameplay engineers are always the last to work since they deal with everyone else’s work.
• Engineers need to make sure they identify the areas that have the most chance of having problems after they make changes, to isolate areas for QA to test on. You can’t just tell them, “Test the game” and expect for them to just know what and where to test or to just test the whole freaking game. There’s just too much content.
• All projects are archived, so they can be returned to if they are ever needed. They are great for reference.
• Over 80% of the people they review are engineers. They are always looking for engineers. At the moment the positions that are in most demand are frontend engineers (for Origin) and backend server database engineering (since they are beginning to invest in building a backend platform that ties everything they make).

There’s a pretty big discussion about this post on reddit now, so if you’re interested you can read through the comments there as some of them provide confirmation to this post as well as other insightful details about the AAA game industry. You can visit the reddit discussion at: http://www.reddit.com/r/gamedev/comments/rmafw/what_its_like_being_an_ea_engineer/

Here’s just a list of websites/video series I think are good for game developers to follow.

From the Industry and Game Design/Development Perspective

#AltDevBlogADay: This blog just about covers everything from programming, to design, to even the business of games. The best thing about this site is that the content comes from a variety of people with different backgrounds. Some writers are actually from the industry, some are independent, some are educators, and some are even students so you’ll definitely get the perspectives from just about everyone. Also, not many sites go over the engineering aspect of games with as much depth as this one as you’ll find that notable programmers like John Carmack even write up some valuable programming tips you won’t find anywhere else. If you’re not a programmer don’t let that turn you away though. There’s definitely some very insightful articles on design and business that you won’t want to miss here too.

/r/gamedev: The gamedev subreddit on reddit is a great resource for game programming, art, audio, business, and more. It’s updated by fellow gamedev redditors constantly, so you’ll always find something new and interesting to read/learn every day.

Gamasutra: Gamasutra provides great information on the design and business side of games. Occasionally there’s stuff on programming, but usually when it comes to this specific topic they’re just re-posts from #AltDevBlogADay.

All Your History: In this video series by Machinima, you’ll learn about the history of games, game companies, and the game industry. It’s definitely valuable to see what the industry went through to get to where it is today. Don’t worry, it’s a lot more interesting than high school history class!

Extra Credits: A show run by Penny Arcade that takes a deeper look into games in various different topics ranging from game design to gamer culture.

Pach-Attack!: Pach-Attack!, a show by GameTrailers.com, is really interesting to watch since you get to hear insights about the game industry from a research analyst by the name of Michael Pachter. It’s good to see things from the business perspective and you’ll get some insight general statistics behind the money driving the games industry.

From the Gamer and Media Perspective

Don’t forget the gamer and media perspective! I don’t check these as often as the websites listed above, but I make sure to check over them at least once a week just so I can keep up with gamer/media opinions and such.

The Penny Arcade Report: The Penny Arcade Report (or PA Report for short) is one of the newer gaming-related publications. The depth and quality of the articles found here are great, and you can find very insightful posts on interviews, industry news, and more.

GameTrailers.com: Very in-depth video game reviews and has plenty of other shows about the gamer news and culture.

GameSpot: Another great source for game reviews and news.

Kotaku: Mostly has well-written articles about gamer news and culture. There’s some nice laughs to be found here.

GameInformer: Don’t go here for their news feed thing. You can find all of that stuff pretty much everywhere else. The good stuff is the exclusive content they reel out which includes very insightful game info and interviews. Just note that it doesn’t come out very often, so I wouldn’t really check this site every day. Don’t forget about it though because when it actually updates with real stuff, most of the time you’re in for an interesting read.

So this brings me to a New Years resolution. I’m usually not one who does this sort of thing, but I feel like 2012 is a new opportunity for me to fix all of these problems that have been on my shoulders for way too long. The resolution is this: by the time I hit my 20th birthday (which is late in the year), I hope to meet the expectations of the people around me and, more importantly, my own.

To do this, the plan is to pretty much become a lame ass loner for the next couple of months to just focus on myself to fix as many of my flaws as possible. That means finally setting a work ethic for myself. Strict sleeping schedules. Eating and cooking nutritious food. Working out regularly. Spreading classwork and office work evenly instead of cramming everything the night before due dates. No games. No parties. And, most importantly, starting to actually build a real game for my portfolio. The list goes on and on, but the point is by doing all of this stuff I really should be able to address all the problems and maybe I can finally stop being a depressed ass pussy.

No more emo posts. No more posts about plans I never follow. Time to actually do something.

On a side note, the Gaming category will now be more about my gaming experiences and less about actual game development. I’ve moved my Microsoft Game Studios UCSC Presentation and Electronic Arts UCSC Presentation posts away from it, and I’ve finally opened up comments on them to feel free to type away!

Even though before college I was miserable and was kind of just mindlessly drifting wherever life would take me, I guess I kind of miss it. Being a kid, not worrying about responsibilities or anything, it felt great. This quarter has really shown me how unforgiving the world can be, and it’s just depressing. What happened to the times where my life had no worries at all? All of the sudden I’m racking up debt in loans for school. I have no financial or even moral support from my family. I’m struggling to work hours a week just to get some food. I don’t have a car, so it’s hard even getting food in the first place since I have to walk miles carrying groceries or I have to waste valuable hours at a bus stop which is miles away from the market anyway. My major’s department decides to start weeding people with ridiculously difficult classes. My social life is non-existant now. Everything sucks, and I’m really alone. It feels like the world is moving too fast, but I know that I’m really just too slow.

I don’t even really have anyone I can actually sit down and talk to seriously which is why I’m blogging like this in the first place I guess. Sure I have great friends, but honestly I can’t imagine talking to them about anything serious. They just don’t understand what I’m going through since they don’t really need to worry or care about what happens to them after college. They have family and friends to go back to and support them. For me, I don’t.

The scariest thing is that even if I do pass college, chances are I won’t get a job with just a degree. I need to make something big on my own time outside of the major curriculum, something that will wow employers or attract investors, otherwise it will be as if I’m applying for a job with a high school diploma anyway. As harsh as college is for me right now, I understand it’s still cradling me from the real world. If I can’t deal with college, how can I even survive in the real world? I need to take control of my life now, even if I have to sacrifice everything that makes me happy. If it means I can live a better life in the future, it will be worth it. Honestly, I don’t even know if it’s possible for me to meet my definition of success, but I would rather fail and understand I never had a chance instead of giving up and never even knowing if I had a chance at all.

Anyway, I’m going to try blogging a lot more often to track my thoughts and progress so maybe I can look back and review them to help figure out what I could improve on. This does mean that many posts will be a bit more personal, but to make up for it I’m going back to posting actual content you care about including tutorials and stuff. Hopefully they won’t end up as emo as these past two though… Haha.

So pretty much I’m starting over with everything and I’m throwing away all the extra weight I don’t need. This includes big projects like Modern Edge and the online community project. Sorry everyone… I guess you can consider them a Duke Nukem Forever, but I hope to one day return and actually finish them. Instead of going high-level with languages like PHP and C# and building big projects, I’ve decided to start at a lower-level with C and start small. Hopefully I will build up from there.

I’m going to stop thinking about how I’m failing and hopeless in school. I’m going to stop thinking about the opportunity I lost to be with my “dream girl.” I’m going to stop thinking about all of the friends and college moments I had to throw away. I’m going to stop thinking about everything I missed out on. It’s already behind me and there’s nothing I can do about it, so there’s no point thinking about what I could have done because it’s already past. Nothing can change what already happened. The fact is, no one is to blame for all of this except for myself. If I want to prevent things like these from happening again, I need to work on myself now.

On the other side of things, I’m going to stop thinking about all of the time and money I need to get through school. I’m going to stop thinking about how I need to make something big now or I’ll never become successful in my life. The fact is, I’m too weak, stupid, and poor to do those things now. It isn’t school that’s getting in the way, it’s my incompetence. To get what I want, instead of worrying about the future, I need to worry about what I need to accomplish now.

All of the problems of the past or the future aren’t relevant to the problems I need to confront now. Instead of looking a million steps behind or ahead of me, I need to start looking at the the one step right in front of me. This is what I need to do now, and if I conquer each obstacle in front of me one at a time, slowly but surely I’ll get to where I want.

But seriously, I’ll write up a new blog post on what I’ve been doing lately pretty soon (hopefully).

Let me highlight some cool features it has:

1. Ajax Page Load

   Each menu and page is loaded in via Ajax coded through jQuery. That’s why the page never actually refreshes and each section of the page loads in on one single, persistent page!

2. Cool Animations

   Animations coded in jQuery not only make the website look cool and fun to use, but they also give visual feedback as to when the page is changing.

3. Resizeable Window

   As you resize the window, some page features will adjust like the second column’s size and the shadow around the edge of the browser screen. Also, the site supports up to viewport widths of 1024px through media queries.

4. HTML5 Document and CSS3 Styling

   Uses HTML5 elements to structure the site and uses CSS3 styling to get “Photoshop-like” effects such as drop shadows, RGBA backgrounds, and @font-face kits.

Just note that this is the first prototype so there’s plenty of bugs. Also not all the content is in right now, but it will be pretty soon. School is starting soon and I don’t think I’ll be able to reach a 100% finish before then, but I hope to have a more optimized and less buggy second prototype out by then.

Feeling

So the first thing I thought about was the feeling. Since this was a theme that was going to be on my personal website, I wanted it to reflect about myself some how. Immediately I thought about colors. Being that blue is my favorite color, I decided to design around it. (It’s also why the current website is blue actually.) The next thing I started thinking about was space. Originally as a child I wanted to be an astronaut since space intrigued me, so to reflect that childhood dream I started thinking about space and techy things.

The Cool Idea That Just Didn’t Work

My first impulse was to make a dark layout because… well space is dark. To contrast with the darkness, there would be a lot of glowing blue. Now to make it feel techy, being a gamer I immediately thought of taking inspiration from the interfaces used in the Dead Space game franchise. What interested me wasn’t just the futuristic theme of the game. It was really its creative use of futuristic user interfaces. For example, in Dead Space 2, there is no HUD. The interface is actually integrated with the in-game environment. So when you go through a menu on Dead Space 2, you aren’t just scrolling through it with your joystick. You actually see your character interact with the interface in the world. This technique is a lot easier to pull off in futuristic games since the creative interfaces used in the game are very believable with a futuristic setting. Check out some gameplay footage of the game shown in the following video:

Warning: The following video may content some mature and disturbing content.
Dead Space 2

The next thing that came to mind was the movie Minority Report. The interfaces used are similar to those found in the Dead Space franchise. The main thing I noticed in the video clip though was the way Tom Cruise interacted with the interface. It reminded me of how we use many modern Apple devices today (which is interesting because the iPhone wasn’t released until 2007). Immediately I thought that perhaps I could code some interesting interactions as well as give a sleek feeling by using JavaScript/jQuery.

Warning: The following video may content some mature and disturbing content.
Minority Report

For more specific color choices and experiences, I started looking at many websites. These webpages in particular interested me:
Namaste

Bungie – About Us

Dead Space 2

So I began thinking about what technologies I wanted to use. While I could easily use Flash, I wanted to use JavaScript/jQuery/Ajax instead. That way the website would be more search engine friendly and it would be a bit more challenging to code. Also, seeing Flash-like affects simulated in jQuery is very rewarding since it’s cool to say, “That isn’t Flash! It’s generated without the use of 3rd party plugins!” even though jQuery has been around for ages. (Well when you think about it, jQuery’s only been around for 5 years. But in technology time that’s the equivalent to 5 centuries.)

With the colors, inspiration, and technologies ready, I whipped out my pencil and sketchbook and started drafting. This is the first draft I ended up with:

The basic idea was that the content area (the panels in the center) would change without refreshing the page as the user interacted with navigational elements. Each time a new page is loaded, the header (the top bar) and the footer (the bottom bar) would remain on the page while the content areas would fade and slide off the screen, only to be replaced with the newly requested content panels. Since the entire page doesn’t reload like most websites, the experience would feel more persistent. This technology combined with the overall feeling the website would make it feel like you’re going through a computer system instead of a series of webpages.

The more and more I thought about it though, the more I was thinking about really dark, techy interfaces that would appeal mainly to techy nerds. While the whole concept was cool, perhaps it was too bizarre for the average visitor. Remember, this site isn’t just for those techy people, but it’s also a way for potential clients to evaluate my work and contact me too so I need to make sure it’s accessible and appealing to them. Sure I want to give a techy-vibe, but at the same time I don’t want to deter my source of income. The last thing I want is to scare away a potential client just because he/she thinks the website is a computer game or something like that. Not only that, but I have to build this theme as soon as possible so I can submit it along with my resume to potential employers for this upcoming school year. Doing something as experimental as this idea would take a lot of research and iteration to get it right. The whole concept intrigues me though, so I’m considering to give it a go as a side-experiment when I have spare time (which probably won’t be for a long while).

A Total 180

After sadly scrapping that very cool idea, I decided to do a total 180 and create a light layout. To appeal to both techy and potential client visitors, I decided to go for a more modern and clean feel. The colors would center around blue, grey, and white, and I wanted the background to feel textured with grain/noise so it wouldn’t feel to bland. Here’s one example of a similar look I wanted for the background:
Yoast – The anatomy of a WordPress theme

Then I came across the portfolio of Nick Jones on his website called Narrow Design. What interested me the most was the way the visitors interacted with the website. I definitely liked the sleek feeling it gave. The way the elements slid into their places was interesting and even fun. While it didn’t have a futuristic theme, the interface reminded me of the sleekness shown in the interfaces in Dead Space 2 and Minority Report. Another thing that caught my eye was that the website was left-aligned. Most websites these days are centered on the screen. Off the top of my head, A List Apart was the only other left-aligned website I could think of. It would be cool to do something a bit more unique like left-alignment to make my website stand out.
Narrow Design

Immediately after seeing the website, I started the second draft.

As you can see, the inspiration was heavily taken from Narrow Design, however there are many design considerations I took that make it a lot different. For one, instead of using Flash, like the first idea I wanted to use JavaScript/jQuery/Ajax instead to simulate that cool, sleek feeling. Second, the design has to handle both a blog and a portfolio while integrating many of WordPress’s dynamic features like the search and categories instead of just a showcase for portfolio items.

Now to explain the draft’s intended functionality. So basically the website is split into 3 columns. Column 1 which is on the far left acts as as the “header” of the page and functions as the main navigation and search. The interactions on this column determines what appears in column 2. Column 2 is essentially a list that changes depending on what’s selected in column one. For example, if blog is selected in column 1, column 2 will list all the posts in the blog that you can read. If portfolio is selected in column 1, instead of a list of blog posts, a list of portfolio items will show up instead in column 2. Now if you select on a particular post/portfolio item in column 2, column 3, otherwise known as the content area, will show the actual content the user requests. Note that this is all done without a single page refresh to keep the experience persistent thanks to Ajax. To prevent the visitors from getting confused when screen space is replaced with new content, as each column changes the visitor will obtain visual feedback due to the jQuery animations clearly showing when a column’s content is swapped out for new content.

As I thought about it more and more, I realized that the color scheme/overall feel I was thinking of would be very fit for Project Katacom, a project that I’m planning to (hopefully) announce later this year. So then I decided to scrap the colors/feel for this project and once again I started looking at different color schemes. The good thing was that this time around I was sure about the functionality of the site as shown in the second draft, so at least a few things were staying.

Going Back to the Dark Side

So off I went to look for more inspiration and shortly I found Blitz. I really liked the color scheme they chose. While it was centered around blue and black, its tone was a bit lighter in feeling compared to the dark tecy black and blue I was thinking about with the first design. This really inspired me to return back to a dark layout again, except this time I would consider the accessibility and appeal more instead of being lost in the whole “doing something totally new and savvy” deal.
Blitz – Featured Work

Another website I particularly liked was Sidebar Creative. Their color choice was nice, but what caught my attention was their use of the grainy, textured background. While I planned to use a grainy/textured background for the light layout, this website made me consider to bring that idea over to the darker layout.
Sidebar Creative

So now that I had a general idea on what I wanted, it was time to get down and dirty. While planning can help prevent some problems, nothing beats actually confronting unexpected problems during the implementation process. Honestly, I would normally put more time into the planning process, but I want to finish this before September 6th when my school’s job board goes up, so I have a pretty tight deadline coming next week! The post about coding Modern Edge comes next!

Anyway, I did these changes a while ago, but I’d like to officially state these changes in a blog post:
I’ve decided to remove the “Class Reviews” category entirely along with the posts in it since only a very, very small audience will understand and actually use it. I will be also removing some of my past tweets as I will try and be more conscious in splitting my personal and professional personas. The personal stuff will stay on Facebook, and the professional stuff will be everywhere else that’s under public view. That doesn’t mean everything I write in public will sound like a lifeless robot, but I’m just doing it so I want to leave appropriate impressions on the right people. It wouldn’t be good if a client saw I just came back from a wild party before working on his/her website now would it…?

While we’re on the topic of this website, I’m getting quite bored of this WordPress theme (which is actually a great example of me never finishing things since I never completed styling the comments which is why comments are always disabled…). While Project Katacom won’t be open to the public by the end of this summer, what I can promise is that IsaacLean.com will have a revamp sometime before I head off to school again! Look forward to that since my PHP and jQuery skills have sharpened. This time let’s hope I actually finish the theme (along with styling the comments of course) so you guys can comment on these posts!