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've uploaded Hoverbattles to its own server on EC2, and it has been running fine with an uptime of over 96 hours so far, and this is great!

http://hoverbattles.com

I've wanted to share a few of the mistakes/lessons learned writing and deploying a multiplayer game built entirely with JavaScript on top of NodeJS and WebGL for a while and this represents an opportune moment to do so.

I've gone with a brain-dump of various related learnings, as well as a couple of periphery items - first off, we'll go with the reason I couldn't keep Hoverbattles up on the old server.

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.

Why would one coding team drive itself to the edge of exhaustion to create a fully fledged video game—one featuring badgers—in the course of a single weekend? Why would 20? We sent our man in Australia to a 48 hour "game jam" to find out, and he came back with an amazing 24,000 word answer. If reading this piece doesn't make you want to whip out a laptop and do something creative, you may be dead inside. Here, then, is part one of our three part epic, covering the game jam's first evening; parts two and three will follow over the next two days.

Whenever I visit a developer, I always ask for a tour. Games aren't wished into existence; real people who hang out in real places create the titles we play, and I like to see where that happens. Unfortunately, the office buildings all begin to blend together. They're often dark spaces, they're often covered with action figures and other pieces of geek ephemera, and you'll often see some sad sack developer sleeping under a desk.

But what if you're a tiny outfit who can't afford a fancy office tower—where do you create your next masterpiece? I contacted independent game studios that I respect and asked them to take a few minutes and a camera and show off their workspaces. Some were enthusiastic, others were hesitant, and many seemed almost ashamed; they all assumed that everyone else had better space in which to create games.

Game Developer Magazine

Holy god.. that trailer makes me relive so many horrible memories.. yet is just so awesome.

For those of you who dont know, Tommy and i were both documented by a tiny 2 person team called Blink Works on and off for about a year during the middle-end of development of Super Meat Boy. We met them at GDC the year we lost at the IGF.. they approached us after the loss and told us they were thinking about doing a short documentary about indie games. They had been talking to many indie devs and wanted to do something that could show the world the life of an indie game designer, we agreed and they followed us back to santa cruz. For the next 9+ months of development our lives were peppered with their cameras and almost sickeningly kind and gentle nature (they are Canadian).

And start calling them Design Tools. Docs get appended, while Tools are put aside as needs change. Design docs are necessary, but their definition is both antiquated and inadequate to the task they provide. In fact, their task–as tools–is threefold, and it worries me that none of this was explained to me.
A game designers job goes through three major periods: figuring out what the hell you are making, getting the team on board with the initial idea, and then managing the vision as the game is redesigned (like, a lot – a LOT a lot); similarly, your documentation, as the project goes through these stages, serves three purposes: extrapolation, communication, and collation.

Courtesy of former Origin programmer Bill Randolph, and thanks to the tireless efforts of Joe Garrity of the Origin Muesum, Ultima Aiera is pleased to present four documents — which have been broken out into over thirty images — which discuss some of the technical details of Ultima 6.
Specifically, the documents — all of which appear to be internal documents from Origin Systems — discuss the conversation syntax of the game and its technical implementation, the object design of the game, and the in-house map editor that Origin developers used to construct the Ultima 6 game world.

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.

If you still practice or encourage the outdated practice of writing long design documents, you are doing your team and your business a grave disfavor. Long design docs embody and promote an insidious world view: They make the false claim that the most effective way to make a game is to create a fixed engineering specification and then hand that off to developers to implement feature by bullet-pointed feature.

Pretty much ever since we finished Kivi's Underworld I have had two very different and opposing viewpoints of the game. On one hand I think Kivi is a really cool game and I'm glad that someone made the game. On the other hand I think that Soldak developing Kivi was a mistake. I'm going to talk about both viewpoints a little.

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.

Probably the single biggest thing that stands between the idea of making a great game and the reality of actually doing it is the cost.

Even with agile practices in place, games need a certain level of development before they start to show their potential. The game actions need to extend, the loops need to be in place, the dynamic needs to be coming together and the wins need to build toward something. It needs to develop an aesthetic voice and style, work on the user experience and finally have some level of testing. These things take time and money.

How much? It varies massively depending on what it is, but the bare minimum is $100,000. If you find yourself pitching well below that, it usually portends trouble

Despite a huge backlog of games trying to get my attention, I found myself playing a lot of Team Fortress 2 (TF2) lately. This is in part because of the loot system, which drops random items –mainly hats or weapons– for you to use in customizing your avatar.1 This system has been in TF2 for a while, and it used to be that the only way of getting the gear you wanted was by getting it from a drop or by crafting it from raw materials (which also essentially came from drops). Many players rejoiced and were very proud of their silly hats and weapons.

With exclusive access to Minecraft creators Mojang, I spent a day with Markus ‘Notch’ Persson and his team in their Stockholm offices, from the first meeting of the morning to the Friday afternoon’s booze and gaming relaxation. With kebab in between. Notch talks to us about how he came to be in the position he’s now in, his intentions for Minecraft and Scrolls, and the philosophy behind his game development. I also speak to his colleagues Jakob Porser and Carl Manneh, find out how the team deals with player feedback, their passion for transparency, and Notch’s plans for games after he’s completed Minecraft.

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.

1999, San Francisco, Triton Hotel: we meet in person for the first time. We had found each other via our medium, the networked computer and had a brief but passionate virtual love affair. We got to know each other doing what we loved doing most, making websites and interactive artworks online. We begin living and working together soon after. 2003: Leaving behind careers of net.art and web design, the two of us radically redirect all our creative attention towards the medium of videogames. February 2005: After 2 years of designing and prototyping, our first project 8 is rejected by games publishers, then the only source of funding. We are devastated but determined to continue and to keep our independence. Reboot. September 2005: Launch of The Endless Forest. October 2006: presentation of the Realtime Art Manifesto at the Mediaterra festival in Athens. January 2007: Drama Princess engine complete. March 2008: Launch of The Graveyard. March 2009, San Francisco, Triton Hotel: launch of The Path.

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.

The history of Flash-game website Armor Games, which both hosts and develops some of the biggest browser-based titles around. Browser games, sometimes referred to as 'Flash games,' are easy to access. There's no install required. They're widely available, with hundreds of websites stabling thousands of games. The price for accessing most of these titles? A highly attractive zero dollars." Our lives changed when the mainstream latched onto the Internet, and it changed again when broadband access replaced dial-up in the workplace. Suddenly, text and images loaded in a blink. Improved streaming technology even let us tinker with games in between waiting for the paperwork or phone call that would fire up their corner of the corporate machine once again.

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.

Matthew Wiggins of mobile developer Wonderland, creator of the chart-topping Godfinger, has claimed that charging any price for an iPhone game is a mistake.

Following the Canada-only release in March, Godfinger went to no 1 in the charts in 36 hours with no promotion. It also topped the charts come its worldwide release in June.