i_c_b

I like the general idea - I would like a game tool like this.

(and before I give my feedback, I should say, I spent a year or two working on a solo indie Zelda/Diablo mishmash focused on teaching guitar fretboards and music theory back in 2006-2009. A video of that incomplete game is here: https://www.youtube.com/watch?v=R6O32PFGZCE . It relied on players playing intervals and chords to cast spells, for both fighting and puzzle solving, in an ARPG real-time context. I had to pause development due to life, but I'm desperately hoping to find a way to finish and ship it.)

Anyway, I think that your game is... well, really, really hard. More specifically, it feels like it gives a lot of negative feedback right from the get go.

If it were me, I would probably add substantially more scaffolding early on - pull from a smaller section of the fretboard at first for the player to master and get more positive feedback, then expand from there in much more incremental steps. I also feel like the timer feels pretty harsh and negative at the beginning. I've played guitar for many years but have, myself, not really memorized all the higher notes on all the higher strings, so I'm actually receptive for what this tool is doing. But running out of time and then losing a life while I'm trying to count off notes feels frustrating, like it's actively interrupting me doing the learning activity I'm there to do.

Hope that helps! As I say, I like the general idea and would love to see a more fleshed out version.

Let me make the case that it's definitely not just nostalgia - or, at least, that Quake style movement didn't fade away because of any objective, rational process.

One of the exasperating consequences of the rise of game engines has been that you have games shipping that have more and more of their game design inherited from their game engines.

On some level this makes sense - games are just massively complicated, and so if you already have working, tested code, it's often quite tempting to just go with what already works (and not spend time really internalizing how working things work) and then focus on figuring out the particular things you are adding from that baseline.

As just such an example, when I was working on Activision's Soldier of Fortune, we largely inherited Quake 2's movement code, and most of it was left untouched by the time we shipped. At some point, midway through development, inspired by Thief, I stayed late one night with a co-worker, and I added in leaning around corners to the player controls. I don't remember the particulars of that process, but (obviously) I had to make tons of aesthetic choices while doing that, because I was writing it from scratch. But the base movement we could inherit.

If you go back and look at first person games from the late 90's, their aesthetic choices about basic player movement are all different in subtle ways. That makes sense, because most studios were writing their own bespoke engines at the time, and there was vastly less code sharing. So people were writing code because there was no particular alternative, and so they were making tons and tons of aesthetics choices whether they wanted to or not. Lots of those choices weren't always great, but they were often particular.

It's clear at this point that lots and lots of FPS games just inherit Unreal Engines movement. Not because it's great, but because it comes with Unreal and it's a default. To me, there's something very specific about the way friction works with player movement in Unreal that feels very ... sticky? ... compared to Quake Engine games. Players come to a stop when input is released in a way that feels like being in glue - again, at least to me. There's more subtle gliding around in Quake. As far as I can tell, the difference rarely effects game play in most games. But it does change how it feels aesthetically to play moment by moment.

Anyway, this topic feels intensely path dependent to me. Unreal's movement is the default because Unreal is the default engine (in a lot of contexts), but it didn't become the default because of anything specific about its player movement code. Those aesthetic decisions were just along for the ride, so to speak. Or at least, that's my sense.

Interestingly, I found a github project a while ago that tried to reverse engineer Quake / Source's movement and put it into Unreal Engine 4. No idea how successful the project is, but I suspect it might be an interesting resource for seeing what's different between the two: https://github.com/ProjectBorealis/PBCharacterMovement

I've long been fascinated by the intense role of path dependency in what technologies and art styles get really explored and mapped out in connection with computers, and I think Flash is a magnificent example of that in action.

Until Flash got really big, 2D vector art styles in games were really pretty underexplored. Not totally - there were games like Out of This World, say - but in general 2D games historically leaned very heavily on bitmapped art work. And that made sense, given the nature of the sprite hardware of arcades, home consoles, and some 8 and 16 bit home pcs (like the C64) in the 1980s and early 90s.

But that meant at the time that there never really developed a culture of 2D vector game art that was a magnet for super talented, competitive artists who really tried to push the space to its limits, see what was possible, drive a tool ecosystem, share techniques, etc. And of course you _did_ see all of those things happen around bitmaps and pixel art - the very best of 16 bit pixel art still does look really impressive.

Instead, most of the effort that went into 2d vector art at the time (at least this is my understanding) was more over in the land of business, where real time frame rates on cheap consumer hardware weren't a concern, and having crisp and clean graphic design and fonts that could scale up (especially when printed) were much more important.

And then GLQuake and 3dFX Tomb Raider and the Playstation 1 hit, and and something like vector art (in the form of polygon meshes) suddenly became ubiquitous in games - but all in the context of 3D rendering, 3D cameras, 3D worlds, and so on. And that did indeed become (and remains) a magnet for super talented artists to try to drive the state of the art forward, shared techniques, build tools, etc.

Along the way, the rise in graphics capabilities became more than enough to enable really interesting real time 2d vector art work in games, but there just wasn't a critical mass of interest in it (probably because the massive leaps in 3D rendering in the late 90s through the 2000s were sucking up all the attention, and 2D gameplay was at the time viewed as the past).

And all that remained true until the circumstances where Flash rose, which 1) ran on reasonably powerful PCs but 2) largely didn't use 3D hardware, and all this in 3) highly file size constrained environments (because of internet deployment), while 4) shipping a small runtime plug-in that evolved into a pretty good stripped down real-time combination of Illustrator and Photoshop, along with 5) an integrated authoring tool that was good for making 2d vector art - and all of this in the context of 6) really massive potential audience size because of web browser deployment.

All of those constraints and capabilities together were a really fertile space for 2d vector art in games to become a magnet for attention and talent and evolution, making it one of the major art styles in games today. Maybe that would have happened anyway, but Flash certainly played a major role in the world we actually live in.

**

Flash really left its mark as a stripped down, real time Adobe Illustrator, but its runtime (less so its authoring tools) was actually equally powerful as a stripped down real time Photoshop - something like what the Super Nintendo or Amiga could have conceivably evolved into had 3D acceleration never shown up, and if massive amounts of RAM and level-loading-time rendering and caching became a central rendering paradigm.

I was doing, I think, pretty striking indie work from that angle between 2010 and 2013, but I never quite found a way to turn it into anything and wasn't as good at shipping and networking as I needed to be (be honest with yourself when you need a business person or a producer, folks) ... so I'll dump some videos here instead, because why not.

So, the first approach I did was something like a Flash evolution of the parallax techniques used in Shadow of the Beast (and other 16 bit games):

Sideview Rendering Demo: https://www.youtube.com/watch?v=ybHJx-S3LWk

Incomplete Platformer: https://www.youtube.com/watch?v=MRUDYdfwvCI

And second approach was something like a Flash evolution of the techniques used in Sega's After Burner 2, Sega's arcade Rail Chase, Sega's Power Drift, or Sega's Galaxy Force 2:

Incomplete Racing Game: https://www.youtube.com/watch?v=mrL33EF-v0I

Cartoony Minecraft Demo: https://www.youtube.com/watch?v=5h1zzLOCAaQ

Unfinished FPS Wolf Horror Game: https://www.youtube.com/watch?v=k2WgC7OL8Aw

81k First Person Grass Demo: https://www.youtube.com/watch?v=rRsc0salnEs

All in file sizes < 2 Megs. All were using, essentially, lots of clever caching and image-based rendering techniques.

I've updated some of these techniques to work with Canvas more recently. The parallax scrolling techniques in particular work quite well on phones and tablets with javascript and Canvas.

Glad to see this article making the rounds again.

Here's a little background to the article that might be interesting to some of you, concerning the evolution of shooters.

I'm the Nathan McKenzie the blog author thanks at the end of the article. I worked at Raven Software, off and on, from the spring of 1997 through the summer of 2004. I think JP, who wrote the blog, worked at Human Head in Madison, WI for a time. So we were both kind of in the id / fps diaspora, to some degree. I think this conversation took place on JP's old anti-factory blog, way back in the day.

Anyway, enough real-life background. The more interesting, possibly, background, is that I carried a lot of the responsibility for the single-player game balance and feel of Raven's and Activision's 2000 FPS, Soldier of Fortune. I basically was responsible for tuning player weapon damage, player input responses, enemy response times, enemy damage, high level enemy logic, enemy style differentiation, overall game progression curves, user settable difficulty levels, etc. I worked with other super talented people, of course, but at the end of the day, I was the main person in Raven's office at 2 am tweaking variables and subtle enemy aiming algorithms and properties to try to make the game match what appealed to me aesthetically. I really didn't work on SoF2 at all, so in so far as the games feel quite different, I would say that at least partially comes down to SoF being much closer to my own tastes.

I actually don't remember the conversation in great detail that JP and I had that led to this blog post, but I do know that a lot of what I was saying at the time about Doom was related to my experience of trying to do my part to balance Soldier of Fortune and make it fun and fair, and the challenges I faced in doing that.

SoF is a fine game, but I think it occupies an interesting point, historically, for shooters. I LOVED Doom. I just loved it. I played so much of it. It was hugely influential on me. If it had been up to me, I would have just been making more Doom-esque games.

But once you're making a realistic, bullet weapon based game with human enemies in relatively recognizable environments, much of what Doom got right kind of HAS to go out the window in the name of realism. Player movement speed. Enemies very strongly differentiated by attacks, properties, and novel behaviors. Enemies very cleanly parsable with strongly different silhouettes to signify that they are of different kinds. Enemies with radically different amounts of health or interesting weaknesses or weak points. Weird, interesting, abstract traps and interactive gadgets that can be combined with enemies to create novel situations. Game pacing controlled by the rate of introduction and variation of these things. Fairly abstracted environments that interconnect in weird ways, custom built to make for interesting combat experiences. Ratios of player size to monster size to projectile size to environment size that maximize player ability to move gracefully. Player interaction styles that maximize the aesthetic appeal of moving through a hostile environment that looks nothing like how real people interact with being shot at (specifically, using cover). There's an entire grammar that Doom and similar shooters from that era rely on that kind of has to be tossed (or at the least VERY dampened down) once you want some realistic verisimilitude.

And it just gets worse when you're trying to tell a linear story in the middle of the game and so require hyper linear level flow to make sure all the plot points are hit, and so you have to largely toss exploration as an aesthetic pleasure. And it gets worse still when you have dumb AI buddies that have to stay alive and get in the player's way in the middle of combat, and end up causing players to lose because the AI decided to do dumb things and die.

We were in the middle of all these broader genre transitions while working on SoF, and I don't think we entirely understood the consequences of how the individual changes were adding up, nor did the broader industry. It was like we had a recipe for a perfectly good dish, and then said, "Yeah, we're going to totally make that exact recipe again! Except we're not going to use salt, chicken or flour, and we will be adding some grapes and some rhubarb. And no use of an oven!" You might be able to hill climb your way back to a new recipe that works, but there's no guarantee, and once you do, it will be something totally different.

The biggest thing that plagued me while trying to balance SoF, and what caused me to look so much more closely at Doom later, was the issue of fairness and legitimacy of challenge. In Doom, because of a variety of very carefully considered factors (many of which JP talks about), when players take damage, it's nearly always because they did something dumb that was avoidable. When you get hit in Doom, it is punishment. Because of this, it's very difficult to get yourself into an unrecoverable state in Doom. No matter how low on health you get, you can almost always finish a level as long as you are sufficiently savvy. And because of this style of design, Doom levels can really ratchet the difficult up while still presenting a fair challenge. And, in turn, the distance between casual play and really skillful play can be pretty immense.

I really love and admire that quality in a game. But it really does take a lot of very precisely balanced, often game-y choices to make that possible.

I think JP's mention of the player-as-damage-mop versus player-as-one-who-dodges gets right at the heart of this. Obviously most shooters with regenerating health in the last decade or so are fair in some important sense of the word. If you play reasonably, you will probably win. But they're often just... sloppy. The connection between player input and resulting world states is often looser, more chaotic, more often collapsing into a kind of spectacle. Obviously you can ship a game someone can play through with those design choices. But I do think games have lost something in the transition. Given the success of the Dark Souls series, I think there's some contingent of gamers out there how agree.

In the end, I think SoF was pretty fun. I was certainly proud of my work on it. It's hard not to look back on it as a kind of intermediatary step, digging its heels in as a traditional run-and-gun shooter as the future of modern military shooters came barreling down. I know there are plenty of people who like the direction that more modern shooters have gone, but for my part, I always lament that I never got to work on a shooter more closely aligned with the original Doom's design philosophy.

Do you prefer the C library interface for working on strings to the way that Java handles them, then?

After all, Java allows statements like "string3 = string1 + string2;", which is much more ambiguous than C's "strcpy( string3, string1 ); strcat( string3, string2 );" (or a modern equivalent where those functions are namespaced in a string class).

I work on 3D games. Sometimes I work in languages (c++, c#, shader languages) that allow me to use operator overloading (and thus infix notation) for 3D vectors and matrices. And sometimes I work in languages (actionscript, java, javascript) that don't allow me to use operator overloading and infix notation for vector and matrix math.

The code in the latter set of languages is much, much, much less readable by nearly any reasonable measure.

My favorite "1 not behaving as a prime" example.

Here are two simple javascript functions:

function f(n,k){ var t = 0; for( var j = 2; j <= n; j++ )t += 1/k - f(n/j, k+1); return t;} function p(n){ return f(n,1)-f(n-1,1); }

If you call p(n) when n is prime, it will return 1. If you call p(n) when n is a prime power (so, say, 4 or 9 or 16), it will return 1/power (so p(4) is .5, p(8) is .3333..., etc). If you call p(n) with a number with multiple prime bases (so 6 or 14 or 30 or...), it will return 0.

And if you call p(1), it will return 0, NOT 1.

In fact, f(n,1) here is a compact (and slow) way of computing the Riemann Prime Counting function: http://mathworld.wolfram.com/RiemannPrimeCountingFunction.ht...

Another way to compute this exact same function (given as (8) on that link) uses the famous Riemann Zeta function zeroes, although that is much harder to follow.

Now, the behavior of the Riemann Prime Counting function doesn't PROVE that 1 isn't a prime, which, as noted, is a question about definition. But what it does do is show that, in an extremely important context, a context that seems to be, mathematically, solely about identifying primes, 1 isn't behaving like the primes at all.

When I was working at a game dev studio on a game that partially took place in a city, we had an artist, looking for photo reference, type in "man hole" in the google image search.

The resulting photo reference, in addition to being rather NSFW, was not useful for the particularly game we were making.

One nasty aspect of the advice "Don't reinvent solutions to common problems" is it doesn't really provide a way to tell when your problem is really, truly a common problem, which can be a lot more subtle than you might think.

Sometimes the simplest single requirement change - say, works in low memory environment, or handles high latency, or utilizes a GPU, or has a good public API, or has low battery usage, or can save its entire state to disk, or is skinnable, or supports other random feature X - can instantly take all common solutions to a problem and invalidate them. But just as often, it doesn't. Or, just as often, you have to just give up on those requirements for pragmatic reasons.

Given what you've written, I have my own doubts about your understanding too.

Unfortunately, that and your proactive psychoanalysis of me are not interesting conversation topics.

BUT clearly there is a world of difference between saying "it would be nice to have char* + char* as a short hand for string concatenation somehow" - which is roughly what I was saying - versus saying "all operators in a language should be arbitrarily overloadedable", which is roughly how you responded.

Now, I'm not saying there is an obvious way to handle "char* + char" meaningfully or safely in C. But on the other hand,

char stackString = "some literal";

is generally handled in an entirely different fashion from

int myVar = 7;

if both are declared as local stack variables - and C programmers generally have no problem learning that "=" is going to mean something quite special when declaring string literals this way, compared to other data types. Because as you say, it's just one more language rule.

The only real places where I miss operator overloading in C are when dealing with strings in performance non-critical places, any time I'm using 3D vectors, and any time I'm writing matrix math. If those were handled as primitives in the language (and as the string literal example shows, C already does go partway down that road), I'd very happily part with arbitrary operator overloading.

C is willing to hide a lot of numeric type casting details about doubles vs floats vs unsigned ints vs chars behind the magic of the "+" character, so maybe you're willing to endure a lot more type-dependent compiler magic than you're letting on here, despite so graciously speaking for many other C programmers. In fact, "p+1" might very well mean "p+4" if p is an int. Or maybe it means "p+32" if p is a FILE (on my compiler). Or maybe it means... Wow! Wait a second! That seems pretty type dependent to me, come to think of it! But that's just my opinion.

Well, to be fair, strings are much nicer to work with when you have a suitable overload for '+', and that very much is a problem with C the language. Same goes for 3d vectors in C as well.

I assume when he says "no simple excuse", it's more pointing to the massive problems that the mere existence of the macro pre-processor introduces for reasoning about the text of any C or C++ program, for programmers, tools, and compilers.

I've worked in a code base where, tucked away in a shared header file somewhere up the include chain, a programmer had added the line

#define private public

(because he wanted to do a bunch of reflection techniques on some C++ code, IIRC, and the private keyword was getting in his way)

Now regardless of whether that's a good idea, if you are reading C or C++ code, you always have to be aware, for any line of code you read, of the possibility that someone has done such a thing. Hopefully not, but unless you have scanned every line of every include file included in your current context recently, as well as every line of code preceding the current one in the file you're reading, you just can't know. Clearly this makes giant headaches for compliation and tools, as well.

So yeah, of course every mid to large C / C++ program uses the macro pre-processor extensively. You can do useful things with it, and there's no way to turn it off and not use it, anyway, given the way includes work in C / C++, so you might as well take advantage of it.

But it's not an accident that more recent languages have dropped that particular feature.

I've observed something kind of similar, although in my view, the axis is, if you rely on abstracted rules and disembodied systems and institutions, you tend to be liberal, whereas if you rely on much more on tightly shared unstated norms and cultural expectations, you tend to be conservative.

If you live in a dense, cosmopolitan city, you need local government to make sure that all those diverse transient strangers around you are coordinating their lives properly through the shared explicit protocol of secular government.

If you live in a distant suburb, on the other hand, it's not the cops that make you feel safe, its the fact that most people around you look and dress like you do, water their lawns, go to church, and generally display themselves publicly exhibiting the norms of your community. But of course, you better be exhibiting those norms too.

I wish more comments engaged his actual argument. Here, there's a lot of "Torvalds is a jerk and unprofessional" versus "Blunt is good, and screw the PC police talk!" That's not his argument.

Torvalds is saying, "Some people think there SHOULD BE a universal 'professionalism' that 'we' can haggle over in the public sphere and then enforce on bystanders in local contexts" and "Other people think there are just local relationships in groups to be negotiated ad hoc in those local contexts." And he works as though the second statement is more credible.

Saying "we" should be "professional" is actually assuming a bunch of very contestable propositions from the first word. There absolutely ends up being a bullying component when you invent a broad "we", declare other people to be members of it, and then try to enforce norms on that imagined "we".

And I say all this with the caveat that Torvalds is probably too blunt for me. But that doesn't make him wrong.

Huh. It's like he's saying (because of libraries in the web browser) that we should be benchmarking HTML5 the way that we would a C64 or an Amiga 500... not as a general purpose machine that can implement arbitrary algorithms, but as a crummy machine where all the magic is done in hardware (or, here, libraries).

Part of me wants to resist that frame. The whole point of browsers running (sandbox safe) arbitrary code is getting the benefits of arbitrary code, right? Who wants to distort their problem solving to conform to the ad hoc details of the current state of browser vendor libraries? Isn't that what we're trying to get away from?

But then a part of me thinks... we do that with GPUs too, right? If you benchmarked a modern game that didn't use the GPU (and didn't distort what work was done to accommodate the particularities of the how the GPU expects computation to happen), its performance would be relatively speaking even more dreadful. Just like a web app that doesn't lean heavily on the browsers' libraries.

Obviously there is a difference in that browser constraints are mostly social (and thus kind of arbitrary), and GPU constraints (and those of the C64, for that matter) seem to be responses to certain physical realities.

I guess in the short run, he has the right attitude if you want to make code that actually performs well today, but wrong if you think that putting political pressure on standards bodies and browser vendors by offering up critiques like the original article is likely to improve things.

There are lots of ways to approach this topic, but here's my favorite, because it doesn't rely on definitions, just arithmetic...

Javascript: function q(n,k){ var t = 0; for( var j = 2; j <= n; j++ )t += 1/k - q(Math.floor(n/j),k+1); return t; } function p(n){ return q(n,1) - q(n-1,1);}

If you check out values of p(n) for n = 1...16, you'll see you get 0,1,1,.5,1,0,1,.3333333,.5,0,1,0,1,0,0,.25

So notice what p returns here - if n is prime, p(n) is 1. If n is a prime power p^a, its 1/a (hence 16 = 2^4 -> 1/4).

And if n is 1? Then p(n) is 0.

In fact, q(n,1) is a tidy (but slow to compute) expression of the Riemann Prime Counting Function: http://mathworld.wolfram.com/RiemannPrimeCountingFunction.ht....

This doesn't prove anything about the "definition of prime numbers", of course - definitions are social things. But 1 does behave differently from the primes in this function that seems to do nothing at all but explicitly identify primes.

Nothing rigorous here, of course, but I think it's a fun, quick-to-code-and-play-with example.

The question is in honest, good faith.

The progressive era followed the era of robber barons. There was even more wealth asymmetry in America then than now. Something happened to make that transition take place, something cultural, something that the abstraction called dollars couldn't sufficiently buy and sway. Concentrated money can't be the only determining factor in how change happens, or at least not in a sustained fashion. It's just one more leaky abstraction about legitimacy that breaks down from time to time when abused too far.

Occupy Wallstreet (and the we are the 99 percent tumbler) has been responded to as a wildly outsized threat in the political discourse of establishment pundits that I follow, almost an existential threat. I guess I'm writing through all this to try to understand why they're so shaken by it - clearly, it's not like those dirty hippies and their bongos have giant war chests, either.

The thing that makes the concentrated wealth in America so damn powerful, I'm increasingly convinced, far more than the pragmatic reach of the money, is the confidence of its holders in the moral rightness of the general order, their outsized belief in the narratives they tell themselves - and the complacency of the rest of us in going along with those stories.

Money matters, in some eras much more than others. (Again, this is why I find the idea of Wikipedia going, essentially, on strike, so massively fascinating. How much money does Wikipedia have, and how much profit? And yet how much cultural and moral influence does it have?) Maybe the frustration and sense of helplessness that you're writing here, that so many of us write here, is exactly the thing that eventually whittles away the confidence up above, the thing that makes attacking the corruption possible?

Or maybe not. But I'm toying with the idea of trying on just a bit of hope for tactical reasons after stewing in an awful lot of cynicism for quite a while.

I don't have answers about any of this; really, I just having growing questions.

I don't disagree with you. Particularly with 2-income professional families (or ambitious younger people in challenging jobs like startups), there clearly is very little emotional and mental energy to spare for this level on non-voting, day-in/day-out political engagement.

But with that said, I have in my own extended family seen the extent to which conservative churches often play aggressively political roles in organizing and putting lots of political pressure on politicians. As busy as we all feel, somehow they still often manage to find the boots on the ground for this kind of stuff.

I hate to get all Oprah / the Secret on this topic, but I'm inching towards thinking that this entire topic is about confidence, primarily. Most us of in internet land seem to have a certain exasperated resignation that things can't get better, only worse. It seems like a deep seated belief. It's hard to find the energy to fight when you assume you're fighting a lost cause, regardless of how worthwhile. I'm not sure how much of that is self-fulfilling - maybe no one can.

By my understanding of things, in the 50's, the civil rights movement was extremely tactical about where they choose to have boycotts and protests, actively targeting certain Southern communities and leaders that they knew would be particularly aggressive and, thus, particularly effective at mobilizing public moral sentiment to the movement's cause.

I'm not going to claim that what we're discussing here is on par with that, but was it sad that they had to game the system to effect change? Were they gaming the system? Or were they just confronting the reality of our politics and using that reality as a force for moral good in the world? Is that gaming, or is that grabbing reality firmly with both hands? I'm not being rhetorical here; I'm actually kind of wrestling with this myself.

I HATE politics. I have no stomach for it. But it does seem to me that it can't be escaped, that it is ultimately all there is, and that good peoples' resistant idealism often lets some pretty lousy people do whatever they want with, short term, nearly no consequences (and probably long term with a lot of massively destabilizing consequences that aren't really good for anyone).

Is it sad?

If someone bought a car and then complained that it wasn't taking care of all their transportation needs, but they never learned how to drive and didn't expect that they would have to do the work of driving, we would (rightly) say that they misunderstand what the car does; it's a tool and a force amplifier, but it still requires a lot of effort and attention.

Say what you will about the religious right and the tea party (and various mega-corporations), but they all understand that you have to drive the car that is our politicians. I feel like a whole lot of us aren't even showing up for our seat at the table - and there are a lot of us. (This is what I find so heartening about the threat of a Wikipedia black-out, too)

While I read about SOPA, and the way that the MPAA lobbies, the thing that keeps popping into my head is, why exactly are those of us who love a free internet on the defensive on these issues? Why do we always end up being reactive? Why are we vaguely relieved when some people start making a bill that's only 1/10th as bad as SOPA / Protect IP? Why aren't we (or wikipedia, or tumblr, or google, or the whole fuzzy mess of everyone who so identities) driving for more proactive legislation that makes the internet even more free and even better protected? Why are we voluntarily relinquishing initiative here? Why aren't we actively engaging in our own lobbying to neuter fundamentally anti-Enlightenment viruses like the MPAA more generally, to cut them off at the knees?

Thank god for the EFF, but there has to be some way to mobilize broader-based support for a lot of these values in a more sustained and pointed way.

I think Quake's code represents a design methodology you almost never see in the wild. Essentially, Quake's code operates on the same principles that Apple's physical interface designs do (or perhaps singular programming language designs like Scheme or C).

Carmack, as dictator of id code (and thus id design) had the ability to say "we are not adding the following feature to our game because I don't like the compromises it will force in our technology and, thus, in other features we want to add down the road." It's basically as simple as that.

In almost all other organizations, someone holding the pot of money will trump the programming overlord at that point and say, "I don't care, XML is the buzzword this second, and all objects in the game need to be serialized to XML as web services - that's what the market is clamoring for right now" (or whatever the buzzword du jour is). And over time those political technical decisions add up to so much cruft that adding any new thing becomes a technical, jenga-style nightmare.

Not so with id's engines. I actually worked on beta versions of both Quake 2 and Doom 3 code bases while those games were in development, and one striking thing about getting updates from Carmack was his ruthless willingness to eliminate working, finished features / code if he didn't think the complexity or dependencies they introduced were worth whatever feature they added in the overall technical context.

Quake is what you get when a genius programmer who has mastery of his knowledge domains leads. Institutionally, there aren't too many other circumstances where similarly talented and sure-footed and, well, fundamentally, _right_ programmers get to specify requirements like that. I think the comparison to the Linux kernal is apt.

I think by Doom3 id had reached a point where they needed a team of programmers, rather than Carmack + programmers orbiting Carmack. And so Doom3 represents their transition to dealing with all the software engineering / communication issues all of us on teams always have to deal with.

I don't have any knowledge of idTech5, although I would guess it goes further down the lineage of Doom3. id still has to find solutions to the problem of programmers working on teams, after all - no amount of Carmack genius is going to magically fix that all too banal (and inevitable) organizational challenge.

I had my fill of the industry by the mid-2000s and have been working on indie/experimental/violent educational games since, so that's roughly where my big iron engine knowledge fades...

I worked on Quake4 as a programmer for a bit over a year, though little of my work ended up in the final game.

The Doom3 engine is mostly C++. If I recall correctly, the renderer still looked more like a blend of C with some C++ slowly drifting in (which makes sense, given how good of a C programmer Carmack is), but the rest of the game code is very heavily C++, for some definition of C++, along with a scripting layer.

Having worked extensively with the Quake 2 engine previously, I really didn't like the Doom 3 engine, myself. It was radically less... pragmatic. Earlier id engines, to me, were masterpieces of concision. They weren't amazing feats of black box abstraction by any measure, and they implicitly assumed you needed a lot of domain knowledge to understand what they were doing, but they did exactly what they needed to do with a minimum of fuss. Features were included because they were used, generally with the smallest and simplest code and tool footprint possible.

Not so with Doom 3. Huge amount of code appears to have been written because someone prolific thought it would be lots of fun to write it, many features end up going unused or are in the way, and ultimately (because it's more typically software engineered in style), every feature requires about 30 times as much code to be written properly and has several extra unused layers of abstractions crufting things up. The game code (in C++) in particular bears an unfortunate resemblance to Windows MFC-style C++, with a giant 12 layer deep inheritance graph with everything inheriting from a few enormous base objects.

All of that to my eyes, anyway. But then, I really cut my teeth on Quake 1 and 2, and found that their concision and brevity really helped them stay out of the way when adding new, innovative features.

The funny thing about the code for Doom 3 is that, looking through it all, you'd get the impression that Doom 3 was a radically more complicated game that what you ultimately experience when you play the game.

The best way I could put it is this: Quake 1 and 2 and 3 were well made games that ended up being enormously fruitful for white box reuse. You couldn't do much with them without understanding fair bits of their internals, but they didn't actively resist being understood. Doom3 was built to be used in a more black box fashion (like the Unreal Engine), with all that entails from an architecture perspective. I'm sure others might disagree with me from a code ideology perspective, but it is hard to ignore how fruitful the Quake engines were for licensing, and how much Doom 3 sank like a stone.

The code bases make really fascinating studies in contrast about the consequences of different software engineering values, at the very least.

TL; DR: Quake 1 - 3 remind me of linux code, Doom 3 reminds me of MFC.

I used to feel exactly the same way you do... but to be honest, over time, I'd say these kinds of conversations have actually gradually affected my viewpoint.

I agree that the conversations, _in the comments_, never seem to resolve, but never underestimate the impact on people who aren't typing. Knowledge, education, and maturity aren't equally distributed, but conversations like this, even if they are exasperating, are one way to change that. It's affected me, anyway.

My hunch is that they had to cartoon up the expenses a bit because a more realisitic version would have had cheaper prices but probably x10 the number of economic transactions, which would have bogged the game down. Same with the amount of bad luck situations. As an example, the player did have really bad luck - but no starting credit card debt, or rolling payday loan debt, or student loan debt from incomplete schooling...

As long as Adobe can find ways to help steer an awful lot of what is great about Flash into the HTML5 space (with tools and process to support it), then it's all to the good.

I get a bit exasperated reading all the HTML5 boosters who, for understandable political reasons, blithely dismiss flash at a technical and especially domain-specific level. Flash let's me do the following in a browser with relatively clean deployment, like, two years ago: http://www.icecreambreakfast.com/flash3d.html . I'll be ecstatic when I can reliably get the same possibilities from HTML5, but these are real, hard-and-fast features based on specific knowledge about a relatively complicated domain, and often times I get the sense that the domain knowledge issues and feature specificity are somehow beside the point with Flash bashers. At least for browser based games, Flash lets me do a lot of things I want to do right now.

It's hard to shake the feeling that a lot of the anti-flash feelings mirror the structure of GIMP versus Photoshop as discussed occasionally on slashdot. I love the idea of GIMP, politically, but taking away Photoshop from me would literally be like partially lobotomizing me.

Just have to chime in with one more "Quake changed my life", though perhaps even more so than most - loving Doom to death, I was _utterly_ obsessed with Quake modding and map making. Then I sensibly dropped out of college in 1997 and went to Raven Software to work as a programmer, where I got to work with the Quake engine while its paint was still wet, and even more so with Quake 2 while it was being developed. The amount of brilliant co-workers I had who came up through the mod community at that point is actually pretty astonishing, in hindsight.

Thanks id.

Look up blog posts by Mark Guzdial. He's a very thoughtful, reflective CS educator who has written quite a bit about students learning to program.

I can't remember where he wrote about it, but apparently, 1) students can use other people's objects just fine, if they are simple (and so from that perspective, OO is fulfilling its general promise), but 2) new students have a nightmarish time trying to both solve new problems AND decompose problems into objects at the same time.

Which is to say, there is absolutely a reason not to introduce this to beginners. It makes them fail and quit.

Incidentally, the same argument could be made for the concepts of abstraction involved with composing new functions - new students can call existing functions just fine, but the skills involved with abstracting a problem, and replacing a pile of copy/paste with a parameterized solution, is apparently a more taxing set of skills than you might think.

Everything in it's right place.

Why do you think D&D calls hobbits halflings, and ents treants? TSR has a vexed history with Tolkien's estate.