I’ve spent a lot of time weighing my different options for post-graduation plans. As I’m surely not the only one who’s had issues figuring out what to do after college, I’ll break down the different options I considered on the off-chance it’ll help someone else.

Full-time Work

Fairly obvious pros/cons. Stable pay, consistent hours, etc.

Grad School

The first option other I seriously considered was getting a master’s degree, for the following reasons:

• You’re only in school once, so why not take advantage of it while you can?
• It would give two years of working on cool projects and research
• It would allow staying closer to family for a bit (I went to college around an hour’s drive away from home)

As my primary incentives were just working on interesting projects and staying with friends, the structure of a graduate program wasn’t really necessary. If I were looking to work in academia or had some other explicit need for a master’s degree, it would be a solid choice, but in my case I don’t feel it would be the right call.

Freelance Work

Part of the beauty of programming is that all you need is a computer. With a stable internet connection, it’s easily possible to work remotely.

Pros:

• Flexible hours
• Regularly rotating work (can help prevent boredom/burnout)
• Some choice in what projects you take on
• Job security. You’re used to fluctuating pay schedules, and you don’t have to worry about being laid off suddenly.

Cons:

• You’ll rarely work in groups. Even though I enjoy working alone, group environments can help shore up your weaknesses, give you people to bounce ideas off of, etc.
• Less-stable pay schedule. Your pay will fluctuate from contract to contract, and payment can take several weeks after the contract is actually finished.
• You’ll get taxed as both a business and an individual
• No benefits (medical insurance, dental, paid vacation, etc)
• Unpaid while looking for work and while negotiating contracts

Due to those last three bullets, freelance wages seem higher than they really are. As an estimate, take what your yearly salary would be, and divide it by 1000. So, the equivalent of working for $80,000/yr would be working for $80/hr as a freelancer.

Start a business

Perhaps the most ambitious, but also most difficult option, this is what I finally decided on. I’ll write up more on this as it develops! But, for the practical reasons why I’m shooting for this now:

• I’m still used to living like a student, so lower income isn’t an issue
• I don’t have that many expenses:
  • I’m still under my parents’ medical insurance
  • I don’t own a car
  • I don’t have children or other dependents
• My student loans don’t enter repayment for 6 months after graduating
• I still have friends in college, so it won’t be hard to find roommates at a similar quality of living

I considered working full-time for a year or two and saving up/paying off my student loans before attempting a business, but the above points are great reasons to go for it now rather than later.

Plus, what’ve I got to lose?

For the second year in a row, I attended the Math for Games Programmers tutorial at GDC today. As expected, there was a fair amount of review, but I also learned some cool new things!

The earlier talks on splines, blending, matrices, etc. were basically review for me, but it was nice to have that refresher. That said, one tip came up that really stood out to me for matrix math. Matrices are multiplied in a sort of “reverse” order, for example:

Rotation * Translation = translate-then-rotate

Incidentally, this is actually the same order you’d write functions while programming:

rotate( translate( point ) ) = translate-then-rotate( point )

Nifty!

Jim van Verth’s talk on quaternions was absolutely fantastic. He spent the talk discussing how quaternions work rather than why we use them. Questions like “why four values?,” “why do we input theta over 2 instead of the entire angle?,” “how can we visualize 4D space?” and more are covered. As a bonus, the tutorial will actually make it to the GDC vault this year, so definitely check out the talk if you can! If you don’t have vault access, you should be able to pick up the slides at http://essentialmath.com/tutorial.htm once they’re posted.

Dual numbers sound useful, but I’m not sure how often I’ll use the content of the lecture. That said, “you can basically get the derivative for free” is a pretty awesome thing to keep in mind. They’re pretty interesting from a mathematical standpoint.

The talk on Orthogonal Matching Pursuit and K-SVD for Sparse Encoding went way over my head, but I still pulled a good deal of information from it. I think I have a rough idea of how compression works now. I have some research to do!

The talk on Computational Geometry was pretty interesting, though it seemed more or less the same as last year. Still, it was good to get the review – I had forgotten a lot of it. I also learned about higher order surfaces on the GPU (i.e. tesselation, etc.), which was new to me!

Finally, the talk on Interaction With 3D Geometry by Stan Melax was amazing. It was a super-fast-paced crash-course on a huge number of subjects that left me really inspired to start writing some tech demos to learn how all of the concepts work. I’ll definitely be watching it on the vault.

Tomorrow: Physics!

After hammering out a prototype for the CREATE game jam (partly to prove to myself I can make this game), I’ve been planning out the development cycle for my upcoming OUYA game, Project Onslaught. In terms of time frame, there are a few known dates:

1. February 11th – CREATE finalists announced
2. February 18th – CREATE winners announced. At this point, I’ll know for sure what my budget is. Keeping my fingers crossed!
3. March 4th – Classes begin again for me, splitting my focus
4. March 8th – Chuck, fellow OUYA enthusiast, comes to visit for a while and help out, which will help offset classes starting up again
5. March 25-29 – GDC week
6. March 28 – OUYA Launch Party (but not necessarily console launch)

There’s no official launch date set yet, but as the “launch” party is during GDC week in March, the apparent best plan of action is to be done by GDC. That said, they could hypothetically launch the console any time in March based on the Kickstarter dates, but I highly doubt it’ll be in the beginning of the month. Ultimately, that gives me about 8 weeks to develop a 3D hack ‘n slash game.

I’ll also be starting “from scratch” in the sense that I won’t be using the prototype code. I went into the CREATE game jam with the rule that I won’t carry over the prototype code so I could make it as hacky as needed to meet the deadline, and I’ll be sticking to it. It wasn’t wasted time – it was a solid proof of concept, and it gave me a much better sense of how to structure everything.  Plus, looking back at it for reference is fine, I just won’t be copying it fully.

With the 8-week time frame in mind, I needed to figure out what the minimum viable product (MVP) is. The MVP, as its name implies, is the bare minimum that needs to get done by launch for a solid game release. Updates after launch are definitely planned, but when the game comes out, we’ll need:

• 4-player support, local multiplayer
• 4 hero types to choose from, so everyone can be something different if they want
• Arcade Mode – Basically, one or more game modes that are focused on high scores, replayability, etc. Arcade mode will be free content.
• Campaign Mode – At least the first “chapter” available. The first level or two will be free, with the full campaign available for purchase (potentially released on a chapter-by-chapter basis)
• Power-ups/consumables – think Gauntlet: Dark Legacy. These have the potential to add a lot of fun to gameplay, and should also help the player feel like a complete badass from time to time
• Basic character progression. At a minimum, XP and levels that give more HP. Preferably, a few basic stats that can be increased. Nothing more complex than that – it should be a game you can sit down and play without fiddling with complex stats/builds/etc

With all of that in mind, I’ve got a rough, tentative schedule written out. It’s super-duper subject to change, but for now:

• Week of Jan 27: Re-implement player controls and basic combat mechanics (i.e. attack stuff to kill it). Hopefully knock out multiple hero types in one shot.
• Week of Feb 3: Enemies. Lots of work on enemies, to give lots of options for building levels/scenarios. Also includes polishing combat mechanics.
• Week of Feb 10: Build Arcade mode. Pretty much a more robust variation of the existing combat prototype. Cross fingers and hope to win CREATE prize money to fund art assets
• Week of Feb 17: Start working on a framework to build levels for the campaign mode. Discover I won prize money and rejoice! Or, failing that, congratulate the winners on a job well done =]
• Week of Feb 24: Finish campaign-building framework, and anything else missing in core gameplay.
• Weeks of March 3, 10: Content! Build content! (Also a buffer for slips in earlier plans)
• Week of March 17: Feature freeze. Polish. Only finishing up campaign content along with polishing and bug fixes – anything that hasn’t made it in yet won’t be in at launch (but hopefully will be shortly afterward!)
• Week of March 24: GDC week! Potential launch week! Network, talk about the game, go to talks, etc.
• Following weeks: Game maintenance, work on new content, etc.

I will, of course, be posting blog updates along the way as things progress. I wholeheartedly expect the schedule to change drastically before I’m done, but I’ve got a rough outline hammered out for now at least until more details develop. Part of the reason all of March is content is that I’ll also be busy with schoolwork, so I’d prefer content development and polishing to hardcore coding binges. That, and it gives a bit of flexibility if the console launch is announced earlier than expected.

It’s going to be an intense two months, but if it’s anything like the game jam was: this is going to be damn fun!

Prototype Features:

• Supports up to 4 players!
• Each player controls a warrior character
• Enemy skeletons will spawn in an arena as the party fights to survive!
• Game stats are displayed once the entire party is defeated. Try and beat your friends!

Development photos: Imgur album

Downloads: Android APK

Cross-post on OUYAForum.com here!

Official OUYA forum post here!

Here’s a teaser photo of the prototype running on the OUYA:

And as a bonus, here’s how the scene actually looks in Unity:

The interface elements are on a different layer from the rest of the game, which means the main camera can’t see the UI, and the UI camera can’t see the rest of the game. However, the interface elements are still off to the side for the sake of simplicity/cleanliness. Implementing it was surprisingly painless with a combination of the NGUI tutorial videos and these nice videos by BurgZergArcade. My code ended up a bit different from the BZA tutorials, though. Here’s a code snippet from the health bars:

using UnityEngine;
using System.Collections;

public class HealthBar : MonoBehaviour
{
    private UISlider slider;

    void Awake()
    {
        slider = GetComponent<UISlider>();
    }

    public void UpdateDisplay(float percentHealth)
    {
        slider.sliderValue = percentHealth;
    }
}

Then, when the player takes damage, their script just calls healthBar.UpdateDisplay((float)playerHP / maxHP); to update the health bar. Easy!

Progress is looking good for CREATE!

The long-term game idea is a hack ‘n slash similar to the Gauntlet series. I have a lot of fond memories playing games like Gauntlet: Dark Legacy with my friends and with my dad, so it was the natural choice for a fun console game to make! Given the CREATE game jam is only 10 days long, though, we came up with a few constraints/goals to keep things in check:

• Shoot for 2-5mins of polished gameplay. Quality over quantity.
• Fight in an arena rather than along a level, as we likely won’t have time to make a good level for content.
• End either when the player(s) die (high score?), or after a boss fight that goes into a teaser screen
• Focus on making gameplay fun over making new features. This mostly means focusing on combat mechanics.
• Plan to throw the code away afterward and re-write it. Let the prototype be exactly that: a prototype, not the final product. This will let us throw in hacks and work-arounds as needed without spending too much time on code cleanliness, which will help a lot with the short deadline.

Overall, our progress has been pretty awesome! I only had limited experience with Unity3D before now, but I’ve been amazed at how easy it is to use. Even as a newbie, you can pretty much blunder your way through the interface and API and still be incredibly productive.

We’ve got three days left in the game jam: time to make the most of it!

A lot of people have asked me to compare working at Wooga versus working at Zynga. In terms of the work itself, though both companies use agile software development techniques (morning stand-ups, short sprints, etc.), Wooga usually has small teams whereas Zynga usually has large teams. As a consequence of this, Wooga has a focus on minimizing overhead and keeping teams small and focused (woo!), albeit at the cost of a structure lacking where you sometimes might want one. Zynga, on the other hand, has a more structured work environment as a consequence of larger teams needing more organization and having larger code bases. Zynga’s structure and organization were overall a good thing; it never felt overbearing or frustrating when I worked on ChefVille. I never personally experienced issues with crunch at either company.

Culturally, there are a few differences. When it comes to Wooga, I feel like there’s a specific type of personality that really fits in well. At Zynga, there is a lot of variety from team to team, so whether you’re the quiet-and-focused type or the open-and-relaxed sort of individual, there’s probably a team you’d fit well on. Wooga is also a much smaller company – a couple hundred employees compared to the few thousand at Zynga. Wooga also hires a lot of employees internationally; roughly half of the company’s employees are from outside of Germany. As a consequence of half the employees moving to another country to work there, almost everyone at Wooga was pretty open to meeting people, going out for food or a few drinks, playing at board game nights, etc. Ultimately, I felt a lot closer to my coworkers at Wooga. Don’t get me wrong, my coworkers were pretty awesome at Zynga as well, but it was the difference between “people I get along well with” and “people I hang out with on a regular basis”.

I felt as though I personally fit in better at Wooga, but overall, both companies were pretty awesome to work for.

#include <stdio.h>   // For input and output
#include <string.h>  // For string-related functions

// Main method
int main(int argc, char* argv[])
{
    int numChars = 0; // create integer variable numCharacters and set it to 0
    for (int i = 0; i < argc; ++i) // loop once for each argument
    {
        numChars += strlen(argv[i]); // add the length of string argv[i] to numChars
    }
    printf("Number of characters in arguments: %d\n", numChars); // Output the calculated number of characters
    return 0; // no errors while running
} // end main

The excess of comments clutters the code and makes it less readable, the exact opposite of your goal. Even worse, some graders will take points off if you don’t comment this heavily. Ugh.

For your coursework, just go along with whatever the instructor asks for; commenting style is not worth sacrificing your grades over. In the meantime, start un-learning some bad habits by considering the advice below.

Don’t point out the obvious.

Let your code speak for itself. Any programmer who looks at your code will know that “++i;” means that i is being incremented; you don’t need to repeat that information. The same goes for common programming idioms; for example, it’s pretty easy to recognize “for (i = 0; i < value; ++i)” as looping through something value times.

Save comments for when you’re doing something subtle or unintuitive. Of course, if you end up in that situation, remember this next guideline:

Bad code requires many comments. Good code needs few.

If you’re anything like me, your first impulse when you realize your code is hard to follow is to write a comment explaining it. However, “just comment it” shouldn’t be the first solution. If possible, try to re-write the code so it’s clearer.

Comment bug fixes.

Depending on how you fix a bug, it might be worth putting a comment there explaining the bug you just fixed. It prevents the problem of someone coming along later (possibly even yourself!) and saying, “This is over-complicated. I’ll just re-write it to be simpler…” and re-introducing a bug you already fixed. That being said, if you’re using unit tests, you’re probably safe if you just write a regression test for that bug and call it a day.

// Good example: explains a possibly unintuitive piece of code
void updatePlayer(Player& player)
{
   ...
   if (player.x > CAMERA_BOUNDS)
      doSomething();   // BUGFIX: Prevents the edge case where [...]
   ...
}

// Bad example: points out the obvious
void someFunction()
{
   int x = 0;
   while(x < 10)
   {
      ...
      ++x; // BUGFIX: loop didn't end
   }
}

Comment function headers.

You can probably guess what this function does if you find it in a header file:

float max(float x, float y);

However, you don’t want to code based on “this function probably does what I want it to.” You’ll probably go through the code and double-check what it does – no big deal, the function is only two lines anyway, right? And then so will everyone else who uses this function. Every. Single. Time.

You don’t necessarily need a super-verbose JavaDoc-style comment at the top of every function, but you should at least write a quick comment saying what the function does:

// Returns the greater of two floats
float max(float x, float y);

Furthermore, if someone else forgot to add in that comment, write it yourself after you figure out the function and save everyone some time. Make sure you’re correct, though! Incorrect comments are worse than no comments in most cases.

Stick to established commenting styles

Even if there’s no official, formal commenting policy for a project, please keep your new code consistent with the old. Remember just above where I said “You don’t necessarily need a super-verbose JavaDoc-style comment…”? That doesn’t apply if every other function in your project has one. Consistency trumps personal preference here.

Follow these guidelines judiciously.

No rules are set in stone. Let’s say you’re using a super-fast but super-complex algorithm because you’ve optimized that part of your code heavily. Of course it’s going to require a lot of comments. Just make sure to keep that complexity encapsulated behind a nice interface.

With that, I’ll leave you with how I would personally write the program at the top of this post:

// Arglength - Prints the total number of characters passed in as arguments, including the program name
// Author: Zachary Hoefler

#include <stdio.h>
#include <string.h>

// Entry point
int main(int argc, char* argv[])
{
    int numChars = 0;
    for (int i = 0; i < argc; ++i)
    {
        numChars += strlen(argv[i]);
    }
    printf("Number of characters in arguments: %d\n", numChars);

    return 0;
}

Yep, that’s an arcade cabinet we built and a Wooga-themed fighting game to play on it. Enjoy!

First, try to relax. (Click image for source)

If you’re submitting a lot of applications and not hearing back…

• Refine and polish your resume. The one goal of your resume is to get you to an interview.
• If your skills are too weak to have a solid resume, spend time working to improve them. Whether that means working on side projects, reading books, or anything else you can think of, don’t just sit around and expect things to improve.
• How are your cover letters? Do you have others review them with the same scrutiny as your resume? If not, why not?
• Are you persistent with your applications, or do you just send an email and forget about it unless you get a reply?
• Are you being realistic about the companies you apply to? Finding a co-op is very much like a college search: by all means, apply for a “reach” (e.g. Blizzard, LucasArts, EA, etc.), but don’t count on it. Even if you’re a rockstar student, getting a highly-competed-for internship at a AAA studio is a crapshoot.
• How many applications are you submitting? If you’ve only applied to 5-10 places, you’re not trying very hard yet.

If you’re getting to the interviews and not getting a position…

• Have you practiced your interviewing skills? Do mock interviews, read books (e.g. Cracking the Coding Interview for programmers), and get all the advice you can.
• What sorts of questions give you trouble? Have you worked on improving your abilities there?
• Do you appropriately research the company beforehand, or jump in blind?
• Are you enthusiastic, or do you not sound interested? Are you modest, or do you come off as cocky?
• As a student: do you show potential? Nobody will expect you to be a programming guru while in school; however, interviewers are looking for someone who’s able to learn and improve.
• Do you ask questions at the end of the interview? A pretty easy (and useful!) one is, “why did you decide to work at [company]?” Remember, it’s not just a chance for them to get to know you, it’s a chance for you to see if you want to work there.

After the interview, when you’ve been rejected…

• Follow up briefly and thank them for their time. Ask when a good time to apply again would be (generally a year). Even if you didn’t get the job now, that doesn’t mean you can’t get a job there – it just didn’t pan out this time.
• If you’re truly at a loss as to why nobody’s accepting you, you can try asking for feedback. Don’t get your hopes up, though; HR departments are incredibly busy at most companies. Don’t take it personally if they don’t get back to you. If you’re lucky, though, you’ll get a reply that might help you in the future!
• Reflect on why you think you might not have gotten the position. Try and shore up any weaknesses that come to mind.
• Keep at it! You’ll find work eventually, but you have to work for it!