Jump to content

  • Log In with Google      Sign In   
  • Create Account

The Bag of Holding

Which [X] Should I Use?

Posted by , 23 July 2012 - - - - - - · 5,890 views
What {programming language | API | toolkit | operating system | etc. } should I use?
A fairly frequent source of discussion in the General Programming forum is the infamous "X vs. Y" thread. Put simply, this type of thread is basically asking which option the poster should choose out of a list of options. Sometimes it's more like "X vs. Y vs. Z vs. Q vs. ..." but the general format is almost always the same.

The Good News
On the positive side, you're likely to get a very large number of responses, all with varying opinions and perspectives. So if you're looking for more information to digest, this will work out nicely!

The Bad News
On the negative side, you're likely to get a very large number of responses, all with varying opinions and perspectives. So if you're looking for someone else to make a decision for you, this is probably not going to end so well.

Answer #1: It Depends
There is a common pattern in the "X vs. Y" threads: those with the most experience and perspective to offer tend to answer with "it depends." It depends on your desires, your own previous experiences, your current skill level, your ultimate goals, your resources, your motivations, and so on. Note that all these "dependencies" focus on you. This means that the person who is most informed to make the decision is yourself! Whether you feel like it or not, you know your own situation better than anyone else in the thread, so it ultimately comes down to you settling on something. The best anyone can offer you is some generalized guidance based on the context you provide.

Because of this, if you absolutely must ask an "X vs. Y" question, please provide the following:
  • What research you have done on your own (doing some of your own footwork is mandatory)
  • How much experience you have in the subject matter
  • Any relevant skills/experience you have in related options
  • What you are trying to accomplish
  • How much time/money/effort you are willing to invest

Answer #2: It Doesn't Matter
This is typically the correct answer for "what language should I learn" or "what should I do next" type posts. In reality, there are innumerable options open to you, and the magic of programming is that you can choose any of them that you like. Nothing is stopping you or holding you back, so go with your gut: do what seems most appealing and interesting and rewarding. If it stops being appealing, interesting, or rewarding, feel free to switch gears.

At the end of the day, what matters is that you're doing something you enjoy and find fulfilling. If you're miserable, you chose wrong, no matter how many "internet experts" told you to do whatever it is you're doing. So aim to have fun. Use your imagination, chase something that looks exciting, and stretch yourself as much as you comfortably can without getting in over your head.

Keep things balanced and keep enjoying yourself, and everything will work out fine in the end.

Oh Noes, My Code Is Teh Crash!

Posted by , 23 July 2012 - - - - - - · 3,788 views
My Code is Crashing. Help!
A common request for assistance in the General Programming forum involves code which is crashing, often for mysterious reasons. When posting a thread discussing a crash, there are a few important things you should do.

1. Understand what the crash really means
That scary-looking message with all the strange numbers is actually remarkably useful in figuring out what has gone wrong. You should read this article to understand what the numbers mean and why the error message is significant and not just arbitrary or random. In fact, that article has great tips on solving some of the most common crashes, so take a look at it before posting - it may solve your problem for you!

2. Catch the crash in your debugger of choice
Knowing what code crashed is just as important as knowing how it crashed, and both will lead you to the why. If you are not familiar with using a debugger, it is strongly recommended that you brush up on that skill before posting. This will almost certainly be the first thing someone asks you, so be sure the answer is, "Yes, I've caught the crash in a debugger." Answering "yes" to this question will enable you to successfully complete the rest of the recommendations in this FAQ.

3. Include a complete copy of the crash error message
In case the article linked under Point 1 above didn't make it clear, the error message is very important. Include a complete copy of the error in your post: all the numbers, codes, scary-looking gibberish, everything. This information will go a long way towards helping an experienced programmer spot the problem.

4. Provide a call stack and the code of the crash site
Obtaining a call stack for a crash is Debugger Usage 101. You should be prepared to provide this in your thread; in fact, if you can provide it up-front in the initial post, so much the better! Call stacks give important context as to how the program got to where it's at, and what has potentially gone wrong.

Call stacks are mandatory if you are posting about a crash that doesn't appear to be directly in your code.

Even better, provide the line of code (and possibly the lines leading up to it) that actually triggered the crash. If the crash is in your code, provide any context about what you're doing that you think might be useful. More information is always better than less information. If the crash is in someone else's code (e.g. inside a library or API call), provide the code of the crash itself and the code of the first place in the call stack where your own code is running.

For example, if you have a function MyCode() in which you call FooAPI() and it crashes, provide the line of code (if available) from the Foo code that crashed, and the code in MyCode() where you originally started out. This gives important context and might illuminate ways in which you have accidentally misused the API.

5. Always detail what you have already tried and what didn't work
Before posting, it is good etiquette to try and solve a problem yourself. When doing so, please provide a rundown of all the things you tried to do to diagnose and fix your problem. This will help others zero in on the real source of the issue as well as avoid offering you options that you already know won't work. Everyone wins!

Happy Bug Hunting!

Random mind dump

Posted by , 12 July 2012 - - - - - - · 1,222 views

Just offloading some interesting tidbits; I might get around to formatting this into a more interesting post later.

  • Floating point determinism is bloody hard, but not impossible, to achieve
  • Syncing between x86 and x64 code is a nightmare
  • SSE2 is pretty much everywhere, so configure your compiler to use it
  • If you have to interact with the FPU, use /fp:precise (in Visual C++) and set the floating-point control bits to force 24-bit mantissas (i.e. IEEE single precision)
  • Starting with non-deterministic code is a recipe for immense frustration. Before screwing with floating-point determinism issues, start with all your code running on the same machine with the same instruction set and make sure it's deterministic at the algorithm level before diving into the ugly parts
  • Divide-and-conquer is essential. Narrow down on one area that's full of synchronization problems and fix it, then move on to other areas
  • In the same vein, having a way to feed the same exact input into multiple runs of the code (across machines etc.) is so useful you don't want to live without it
  • Beware compiler optimizations; you may spend a lot of time rooting around in icky FPU or SSE2 code figuring out why exactly things differ across builds, for instance. Know how to suppress (or encourage!) your compiler's optimizations selectively so you can get better consistency
  • Work from the bottom layers upwards. Get consistent simulation results for, say, your physics before worrying about higher-level logic bugs, especially latency-related issues. Nothing sucks like banging your head on what seems to be a logic bug when it's just your physics being snarky

Might update with more as time goes by, or again as above, I might bother to actually write up the reasoning behind all this. For now I'll just dump it here and see if anyone finds it interesting :-)

Behind the Scenes

Posted by , 01 July 2012 - - - - - - · 1,299 views

I've known since I was very young that someday I wanted to be a video game developer. It didn't take too long to narrow that down to video game programmer. And now, many years down the road, I've wound up precisely where I wanted to be.

It's an interesting quandary, in a way. I work with a phenomenal team on a game that I truly love being a part of, but there's only so much I can discuss about it publicly. For (hopefully) obvious reasons, such a high-profile team exercises strict control over what the members can talk about openly. This is one side of the coin; but even if I had complete liberty to talk about things like project schedules, deadlines, release dates, cut features, and whatever else, I could only go into so much detail about the project I'm working on at the moment.

What I can say is that I work with the server and back-end technology team. We're responsible for the core systems that power the game - from the frameworks and platforms on which the game is developed down to the actual management of individual hardware servers and whatnot. It's a fascinating role, and deeply interesting to me on a number of fronts. It touches on a number of areas of technology that stretch my limits and force me to stay on the peak of my game. We work with scaling issues, performance issues, resource allocation issues, uptime and reliability challenges - on everything from networking code to multithreading solutions and low-level ground work upon which a world-class MMO can be built.

Ironically, for being so central to the survival of the project, most of us are pretty low-profile folks. Outside the server team itself, I don't know how much of the company could even identify us or our areas of responsibility just by looking at the team photo directory. As we often quip amongst ourselves, people only remember that we exist when we've really fucked something up.

For the most part, I'm happy with this. Another one of my childhood dreams - before I latched onto programming - was to be part of the space program. I didn't aspire to be an astronaut or test pilot or control room operator, though; instead, I wanted to be the guy who operated the refueling systems for the space shuttle (which was, at the time, still running numerous missions every year).

I'm not entirely sure what to call it, but there's always been a part of me that's content to just sit in the shadows and do some critical but unsung part of a larger operation. It's not that I'm averse to spending some time in the spotlight; far from it. I've spoken at events like GDC in the past and enjoyed the experience immensely. To me, it's a tremendous privilege to be able to share details about the things I'm passionate about, and having a large audience of similarly interested people just makes it that much sweeter.

But at the same time, there's a sort of cloak-and-dagger mystique to just sitting back and quietly doing something heroic, even if nobody will ever know about it. I never really had any political allegiances strong enough to seriously consider entering the spy trade, but it holds a similar appeal for the potential to offer opportunities for changing the world without being at the forefront of anyone's attention. As cool as it is to be center stage, there's something alluring about accomplishing amazing things that nobody will ever know about directly.

It's a lonely road, though. What I'm working on now is incredibly fun - it touches on virtually every piece of technology that the company uses and operates, and will deeply and profoundly impact the end-user experience of the game in very fundamental ways. But that's about all I can really go into about it, at lest for now.

Maybe someday, many years from now, we'll be able to "declassify" the project and talk openly about what went into it. For now, though, I'll have to be content with putting in my hours and quietly knowing that the overall experience is benefiting from my work, even though there's nothing shiny to point at and say, "Yeah, I made that."

The silver lining is there, though. Even though (hopefully) nobody will consciously notice all the intricacies that go into the server systems, and my bits of work in particular, I do get one piece of gratification.

On August 28th 2012, we will launch Guild Wars 2. And every time someone logs in and runs around the vast expanses of Tyria causing mayhem and generally being heroic, I'll be able to look on and know, quietly and privately,

"Yeah. I made that."

July 2012 »