Is there an important difference between designing according to the limitations and eccentricities of old hardware (developing with modern APIs/tech), vs. developing to that hardware (or a matching emulator)?
In your DiGRA keynote, you referred to Jesper Juul's reflecting on the Pac-Man ROM, asking whether the source was what the game "really is". That post, to anyone who missed the link at the time, along with my reply (short version: I disagreed), is here:
http://www.jesperjuul.net/ludologist/?p=469
If we can speak of a videogame as not so much its particular implementation, but rather the resulting unit operations and presentation, it seems as though there's a tradeoff between a slow method and a fast method to potentially identical results.
Is it a matter of the system's constraints being too difficult to account for fully, when we're given the opportunity to cheat? (It looked to me like Mega Man 9 on Virtual Console did this in a few places, and certainly most "retro" flash games cheat liberally in this way.)
If it's possible to simulate or account for the constraints of old hardware, there seem to be advantages offered in development time (like rewriting the core of Bubble Bobble in 6 days - http://tinyurl.com/obubbob ), or expandability (like tacking time manipulation on, after finishing doubles mode from 2600 Super Breakout http://tinyurl.com/stellatime ).
Is the underlying idea that the complexities and quirks involved in designing for history's more limited platforms squeezes a different type of prioritization, creativity, and thus result, from creators? Does this at all parallel typesetting with a replica Gutenberg press, as opposed to using Illustrator while following conventions to simulate old press output, such that the real interest is in how the process complexities affect the outcome?
While most "NES-style" games not developed for the actual hardwares pales in comparison to real NES games ( HomestarRunner's Stinko Man gets credit for trying http://is.gd/5U1UL ), so do most homebrew NES games programmed for emulator (like one of the largest from scratch NES projects I'm aware of, Sack of Flour Heart of Gold http://is.gd/5U231). Between the two, I can't help but feel like much of the retro games made in Flash not only took less time to make, but they have a better shot at coming out closer to what a commercial team with resources might have accomplished in the hardware's hay day, enabling a small team to do in their free time what once required a considerable budget.
Chris: it is possible to simulate older systems to a point, but what is not possible is the ability to simulate creating works for those systems. Virtual Console and Game Room offer an opportunity to contextualize such games in a productive way, just as one might put sonnets in a book of poetry, rather than as a still in front of a Michael Bay picture.
I'd just like to clarify some points here with regards to Virtual Console (and WiiWare). I think this knowledge is present in the comments so far, but a cursory reading leaves it a little unclear.
Virtual Console is an emulator for the older systems, and the original ROMs (I believe) are ran through that. WiiWare development is not emulated, and runs regular Wii code, and takes full advantage of the memory, storage, and processors of the Wii.
MegaMan 9, which was mentioned, is not a Virtual Console game. I believe MM9 is in exactly the same boat as the retro-facade flash games. The difference between a C-lang and Flash at that point is very small when compared to the difference between the NES and a modern PC or Wii.
Clayton - thanks! I'm in the unfortunate habit of using WiiWare and Virtual Console semi-interchangeably, although that was certainly a context where the difference was important.
Ian - My impression of platform studies was that the process of development played an important role in how videogames have been (and continue to be) shaped - is this an intended message? What Chris Crawford once referred to as a need for game designers to "with with the grain" (drawing a metaphor to woodworking) seems to vary wildly by programming language, asset preparation/constraints, and their relationship to "hardware", whether simulated or real.
One curious affect of the ability for people to (potentially) commercially release new titles created by the process of making games for old hardware limitations is the change in historical context. I imagine A Slow Year would have been received very differently in the late 70's, as opposed to when it was made in a post-Flower gaming market. A bit like Johnny Be Good in Back to the Future. ;)
In perhaps too far of a tangent to treat properly here, I'm curious as to whether platform studies has either implications or at least parallels to aspects of the Sapir-Whorf Hypothesis. What games were made for the Atari were clearly in part a product of what games it made possible, and the building blocks or means of manipulation if afforded. While modern hardware enables a wider technical variety there's still certainly a difference between what current machines do efficiently and naturally vs simulating/tricking them into doing otherwise. Am I likely reading too much into things in this case?
