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.

Think Big.

It needs to start with an incredible idea. Not just good, or different, but incredible. This will not only set you apart from the rest, but drives the momentum of the team to a common goal during hard times.

Timing must be right: you are not working for another game company, finished with prior projects & obligations to your colleagues, have enough money to last through early development / prototyping etc…

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.

As I've said before, good UI and readable, maintainable code don't mix. But lately I've been inspired to revisit this topic, because it's an idea that has been popping up in other venues as well

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.

What’s on this page? I’m interested in producing complexity out of simple parts. This page contains bookmarks that I collected while working on games; I did not write most of the content linked from here. As a result the set of links here reflects the types of things I needed to know: only a few specific topics (not everything related to game programming), general ideas instead of platform-specific information (graphics, sound, compilers), and ideas and designs instead of source code (I find it easier to go from an idea to code than from code to an idea). Other sites, like Gamedev and Gamasutra, cover lots more topics than mine does. These are the topics I cover:

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.

Sadness. According to a post on MineCraft developer Notch’s blog, PayPal have limited access to his PayPal account due to “a suspicious withdrawal or deposit”. That’d be the same PayPal account people drop money into when they buy MineCraft. In the post, Notch says that there’s more than €600,000 in there, and if PayPal decide something untoward is going on they’re going to keep that money.

Auriea Harvey & Michaël Samyn, zwei meiner persönlichen Indiegame Superheroes die beiden Menschen hinter Tale of Tales, hielten im diesjährigen Februar einen interessanten Vortrag am Art History of Games Symposium in Atlanta (Georgia, USA) über das was sie tun, und warum sie es tun. Spiele entwickeln nämlich

We have a new video that we wanted to share. Back in May we sat down with Adam Saltsman (aka ‘Adam Atomic’ of Semi Secret Software) while he was grinding away at PegJam. We started the interview with the purpose of fleshing out game jams for a short piece on the event (see here), but we quickly segued into talking about Canabalt and larger gameplay topics.

This is a time-lapse look at Markus “Minecraft” Persson’s Ludum Dare 18 entry – a “game in a weekend” competition. As with many of the competitors, it’s dang impressive what was accomplished in only 48 hours of development time.

Making games run faster is a pet topic of mine. Code samples are too specific to help many people, so here are some general principles I’ve learned.

You’re not alone, I was also doing prototyping wrong until a few years ago. There are probably many different ways of prototyping games correctly, and maybe your way works great for you. In that case, a more accurate title for this post could have been “Prototyping: I Was Doing It Wrong”.

A good game prototype is something fast/cheap that allows you to answer a specific question about your game. The key points there are fast/cheap and specific question. It’s not a level of a game, it’s not a “vertical slice”, and it’s certainly not an engine for the game.

Chris Hecker and Chaim Gingold gave one of the best presentations on the subject of rapid prototyping. It was hugely influential for me, and it made me re-think the way I do prototypes. If you get a chance, find the audio for the presentation, it’s definitely worth it.

[In this much-referenced technical piece originally published in Game Developer magazine late last year, the team behind idiosyncratic MMO success EVE Online discusses precisely why sharing a single world between all of its players makes sense.]

“It looks like around 92% of the people playing the full version of [the pictured] Ricochet Infinity pirated it.” It’s moments like those that make people in the industry stop dead in their tracks. 92% is a huge number and though we were only measuring people who had gotten the game from Reflexive and gone online with it, it seemed improbable that those who acquired the game elsewhere or didn’t go online were any more likely to have purchased it. As we sat and pondered the financial implications of such piracy, it was hard to get past the magnitude of the number itself: 92%.

Why start this site?

Well, I believe that game developers are interesting, and have a lot to say. I also know that a lot of them keep blogs. But I don't think they promote them, and I don't think they are too easy to find. The reason that I think this is because I have too often seen people ask the question "does anyone know any decent developer blogs?"

5 Things Big Publishers Don’t Understand About Small Games
Sean Murray, Hello Games

I’m Sean Murray, one quarter of Hello Games. We’re a tiny studio. Four friends. A young startup, we’ve just released a game called Joe Danger on PSN. We’re bedroom developers and bedroom publishers. We published our game as well as developed it.

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.

This paper explains the design architecture, implementation, and some of the lessons learned creating the multiplayer (networking) code for the Age of Empires 1 & 2 games; and discusses the current and future networking approaches used by Ensemble Studios in its game engines.

daniel 'sirleto' renkel
independent game developer
technical artist
programmer
designer

bachelor of computer science
living in darmstadt, germany
born 1980 as a leo

You’re a programmer. Have you ever wondered how multiplayer games work? From the outside it seems magical: two or more players sharing a consistent experience across the network like they actually exist together in the same virtual world. But as programmers we know the truth of what is actually going on underneath is quite different from what you see. It turns out that it’s all an illusion. A massive sleight-of-hand. What you perceive as a shared reality is only an approximation unique to your own point of view and place in time.

Last week a great blog post, followed by a seemingly innocuous tweet from @mysterycoconut, escalated into what is now known as iDevBlogADay. The concept is fairly straightforward; Every day a developer (or two) will post on their blog. We all have an allotted day so that there is at least one blog post published every day of the week. @mysterycoconut has done a great job of organising it with the #idevblogaday hashtag, a twitter list for the participants, and even an aggregated RSS feed of all the blogs. There’s a wide variety of developers joining in – Scroll to the bottom of this page to see the roster.

3DRT.com is a world leading developer of real-time CG content. We specialize in high-quality 3D models for video games and the web

Forum about indie game development

Next-Gen has compiled a list of the 50 books from which everyone in the game industry could learn something. Our list covers game design theory to histories of games companies to sociological texts to novels. Compiled by game designer and author Ernest Adams...

The world is full of games companies that blow stupid amounts of money on making online games (typically “massively multiplayer online games” (MMO)). It’s time to put a stop to this madness; honestly, I thought everyone learnt their lesson about 5 years ago when we had the last wave of “everyone’s making an MMO … oh god, these things are TEN TIMES as expensive and ONE HUNDRED TIMES as difficult as we thought … Run away!”. Apparently not.

Damion Schubert, lead combat designer for BioWare Austin, argues that your endgame – what happens when MMO players have finished all the lower level quests and “made it” in the game universe – realizes the true potential of MMOs.

I surveyed MMORPG players for the first time in the Fall of 99. Since then, I've surveyed over 35,000 MMORPG players from most of the popular US MMORPGs. Over the past 5 years, I've presented these findings in a variety of formats. I settled on The Daedalus Project as a way to easily present findings, but the problem that emerged was that it became hard to illustrate themes and show the big picture using a blog format. The Daedalus Gateway is an attempt to provide a coherent gateway to all those findings.

Hi, I'm Jeff, Lead Architect and Co-Founder of Orbus Gameworks, a game middleware company located in Cambridge, MA focused on providing metrics gathering tools. Before that, I was an associate programmer at Bethesda Game Studios and before that I was a lead programmer at a small government contractor.

XNA, Managed DirectX and Game Programming

Graphics and Game Development, Homebrewing, and the Quest for the Holy Grail