My question is, how is a career programming in the game industry different from other programming jobs and careers a Computer Science major could get? Other than working on games of course.
Differences are minimal in some ways, major in other ways.
First, it is the same.
You will use exactly the same kinds of algorithms and data structures. You will use many of the same CS topics. In this regard all the programming is the same. Programming is programming. It doesn't matter if you are creating a spell checker, a javascript web page, a business server, or anything else. The theory is portable.
Languages and tools come and go, but the algorithms, data structures, and other computer theory will always be around.
Second, it is different than many others.
The mindset of games tends to be far more performance oriented and results driven. In business software if you can query a database and get a result in 200 milliseconds that's quite acceptable. In games performance is often measured in microseconds. In business software you might occasionally profile the code if things are absolutely horrible. In games a profiler is one of the early tools. This by far is the biggest difference in my experience. When I jump between the game industry and business software --- which I've done several times over my career --- the most jarring thing for several months is the timeline of what is acceptable; hearing that 150 milliseconds for results ti display is by far the most upsetting. The shift back into games is far more comforting, leaning on the profiler and figuring how to bring execution times back below microseconds and into nanoseconds.
Game code tends to be less permanent, and consequently there is far less done for automated testing. In a business environment where the code needs to continue working exactly the same way for the next 15 years, or even then next 5 years, automated tests make complete sense and you should write them for everything. In games the engines and core technologies are fixed and deserve unit tests, but gameplay code is highly experimental and volatile all the way through the ship date. It gets locked down somewhat as you go through finalizing the project, but most likely a few weeks before you send in for certification half the team will break off and begin making the sequel or followup game, throwing out huge swaths of code, rewriting most behavior, and completely changing the way things work; automated tends to not make business sense in that environment. That's the other big difference for me. In the business software world everything revolves around an enormous suite of automated tests. That's as it should be. In games, it often feels like we're just praying everything works okay and we don't accidentally break anything. Unfortunately that is the nature of the ever-changing code base.
Finally, and this one is lost on most people, computer games tend to take all kinds of knowledge far beyond other industries. Games rely on more math than most other software out there. Games tend to rely on more research papers than most other software. Some game developers never push their boundaries, but many of us need to actively follow emerging research topics, actively follow journals, and figure out how to apply emerging algorithms to emerging hardware. This is most evident in computer graphics, but can apply to everything. Great game developers tend to apply far more knowledge and learning to their day job than most people will ever know. Not just the more obvious math topics of linear algebra, statistics, and calculus, but also physics and spatial relations and hardware knowledge and such. You can talk with game developers about topics like high dynamic range imaging, physically-based rendering, constructive geometry, properties of physics like rolling resistance and torques, statistical curves, finding the location of an object based on orientation to a few points, rather complex spatial data structures and dynamic spatial restructuring. In the business world about the most varied conversations come around transaction idempotence and transaction boundaries -- you still get those in games, so you don't miss anything.