Bret Victor - Inventing on Principle
more on vimeo.com
How simple ideas – applied – have breathtaking consequences.
Filed under
game development
See all posts on posterous with this tag »Mar 4, 2012 / 10:50pm
The Reality of HTML5 Game Development and making money from it
I’m not one to believe there is any such thing as a true “cross-platform” technology when it comes to games.
more on photonstorm.com
A very sober, albeit technical, look at the HTML5 as a game development platform.
Dec 20, 2011 / 5:29pm
The John Carmack Archive - plan archive
I settled on combining all forms of input into a single system event queue, similar to the windows message queue. My original intention was to just rigorously define where certain functions were called and cut down the number of required system entry points, but it turned out to have much stronger benefits.
With all events coming through one point (The return values from system calls, including the filesystem contents, are "hidden" inputs that I make no attempt at capturing, ), it was easy to set up a journalling system that recorded everything the game received. This is very different than demo recording, which just simulates a network level connection and lets time move at its own rate. Realtime applications have a number of unique development difficulties because of the interaction of time with inputs and outputs.
Transient flaw debugging. If a bug can be reproduced, it can be fixed. The nasty bugs are the ones that only happen every once in a while after playing randomly, like occasionally getting stuck on a corner. Often when you break in and investigate it, you find that something important happened the frame before the event, and you have no way of backing up. Even worse are realtime smoothness issues - was that jerk of his arm a bad animation frame, a network interpolation error, or my imagination?
more on team5150.com
Reading the archive of John Carmack's aaaa.plan files files a bit like archeology of programming and game design. I still remember playing the games he was writing at the time.
Frequent insights about programming are intertwined with boring parts concerning tuning and racing with his Ferrari cars.
Aug 16, 2011 / 12:46am
Toward Programmer Interactivity: Writing Games In Modern Programming Languages
The Crash Bandicoot graphics engine was coded in C, of course, but the Lispish GOOL was used for the sequencing and data handling that defines the playable aspects of the game. C is brilliant for operating on rigidly structured values in an efficient manner, but isn't nearly as nice when it comes to slinging around data in the loose manner needed for gluing together bits of rendering into something fun. The scripting in Crash is about as complex and slick as ever attempted: Crash can run, fly a plane (and shoot down other planes), drive a boat, use a jetpack, swim underwater, and perform endless specialized actions. Oh, and the series has sold over ten million copies. Chalk one up for Lisp.
more on gamasutra.com
A 12 year old article from the times when dynamic languages were just making it into game development. By the way, do people write books on the history of programming? They could be fascinating.
Jul 21, 2011 / 12:15am
Synchronous RTS Engines and a Tale of Desyncs
With a fully synchronous lockstep architecture! In a synchronous engine every client executes the exact same code at the exact same frame rate. Let that sink in for a moment. In an 8 player game of SupCom every player has an identical copy of the game state and follows an identical code path. Instead of transferring over per unit state information (position, health, etc) over the network only player input needs to be sent across the networks2. If all players have an identical game state and process the same input then their output state should also be identical.
more on altdevblogaday.com
How games like Starcraft 2 or Supreme Commander keep up with thousands of units simultaneously in multiplayer matches.
