This is one of those things that newbie game programmers seem to underestimate, frequently.
And when I say “newbie” I include “experienced, skilled programmers with 10+ years of coding experience – but who haven’t yet shipped a game of their *own*”.
(e.g. I’ve seen a couple of studios that started as Digital Agencies, or as Animation Studios, etc – that then transitioned to writing their own games. This is the kind of thing that they often struggle with. Not for lack of skill or general programming experience, but for lack of the domain-specific experience of game coding)

I’ll preface this by saying that yes, I’m running Google Chrome Beta as my main browser, and yes, some bugs are to be expected from running a beta browser. That’s besides the point. So what am I complaining about?

Any small bug on any browser can instantly kill a product you’ve worked months or years on.

The WebSocket protocol has applications beyond plain vanilla web development.  I will explain how the protocol works, how to implement your own server and share some insights I had along the way. Before we get down and dirty, I will explain what I’ve been doing with it.

ROM Hacks make the process of developing a functional Sonic game with unique art, enemies, and modifications much easier, since the game engine and basic mechanics are already functional. However, if the game requires a different game engine, modifying existing low-level assembly may be inappropriate, and some game designers might choose to program their own unique game engine. The physics of a game engine are rules that describe how to transform the player's input (either in the form of buttons, keyboard, or even a mouse if the designer feels inclined) into appropriate changes in the position of the sprites in the game (such as the Sonic sprite, or alternatively, how enemy sprites will respond). These physics guides will hopefully make the process of simulating the rules used in Sonic games easier.

Since the rules themselves are independent of how they are implemented, many people choose programming languages such as Java, C, C++, Python, or a Lisp dialect to implement game physics. In addition, people can choose to use more specialized applications like Flash, Game Maker, or a Clickteam program like Multimedia Fusion 2.

Hopefully, these guides will provide adequate information to facilitate implementation.

The web is evolving. After a few years of iteration the WebSockets spec is finally here (RFC 6455), and as of late 2011 both Chrome and Firefox are SPDY capable. These additions are much more than just "enhancing AJAX", as we now have true real-time communication in the browser: stream multiplexing, flow control, framing, and significant latency and performance improvements. Now, we just need to drag our "back office" - our web frontends, app servers, and everything in between into this century to enable us to take advantage of these new capabilities

Game Developer Magazine

In June 2010, as the world waited for news on the release of Portal2, Valve announced that making games is hard.  Everyone inside the industry knows this, but to gamers and journalists alike this seemed to come as a surprise. Partly because of disappointment that a game they were looking forward to wasn’t coming out for a bit longer, and partly because Valve is an industry leader. For them to put their hands up and say “hey, this ain’t so easy” made people think: “if they find it hard, what about everybody else?”.

Well, yup, everybody else finds it hard as well. But why? Surely we just take the last game we made and stick some new levels and graphics in it? Or just sit around all day playing the game until one day we decide to release it?

Unfortunately, it’s not like that at all. But why not?

I’m starting to realize that most of my blog posts begin with me making excuses about something as well as linking to somebody else’s post or article. Spoiler alert, today will be no different. The excuse is that this post is not my follow-up to my last one about my initial adventures with off-screen particles, due to a lack of time to work on it while moving into a new place and also some disappointing results with mixed resolution rendering. So what I’m talking about instead is my experiences with interviewing for programming intern positions throughout this past Spring. A while back, Jaymin did a great post about programming tests and demos, but I feel like I might have some insights for aspiring entry-level game developers.

Since it’s quite a long time after GDC 2011 and I never found the time to do a proper conference report, I thought I’d at least do a link roundup.

Eve Online's players are a notoriously dedicated, and vociferous, bunch. Self-governing, focused and regularly taking part in huge interstellar fleet battles, meeting their expectations presents a daunting challenge to any AI programmer. We sat down with CCP Games senior programmer, Joel McGinnis, to discuss the difference between real and observed artificial intelligence, why MMOG developer's tend to push AI to the bottom of the to-do list and what we can expect from game AI in the future.

This is a free, community driven Q&A for professional and independent game developers. It is a part of the Stack Exchange network of Q&A websites, and it was created through the open democratic process defined at Stack Exchange Area 51.

I was trying to communicate to management that server developers have different priorities than game developers. As a means to show the importance of laying in administrative infrastructure, and other software engineering "overhead", I put this list together. Hope it helps you to think about making the right investment in making the system sustainable, and make those points to the powers that be.

I'm primarily a server programmer, but I still end up doing UI work every once in a while, and that's been true for the majority of the last three weeks. Not being an experienced old hand at UI design, I find myself falling back on first principles and decade-old books. I'm mostly happy with the results, but the code that results in implementing the interface... well, it's not the kind of code that I like to write.

Within the MMOG industry there are two primary server structures employed to house the player base: Separated shards of some sort (typically referred to as 'servers' though this is misleading from a hardware standpoint) and a more unified, single-world structure. Primary examples of each are World of Warcraft, which employs a shard-based structure that breaks its considerable population into separate worlds, and EVE Online which houses its entire player base in a single universe.

As I work towards completing my own game, I’ve been thinking a lot about finishing projects in general. I’ve noticed that there are a lot of really talented developers out there that have trouble finishing games. Truthfully, I’ve left a long trail of unfinished games in my wake… I think everyone has. Not every project is going to pan out, for whatever reason. But if you find yourself consistently backing out of game projects that have a lot of potential, it could be worth taking a step back and examining why this happens.