5 ms·

A surprising number of NES/SNES developers are still employed, if not at their original companies, at other game companies. I bet for every Shigeru Miyamoto you

A surprising number of NES/SNES developers are still employed, if not at their original companies, at other game companies. I bet for every Shigeru Miyamoto you hear about, there are hundreds of other 50-something programmers who are still plugging away at games... and from what I hear, a lot of them have refused to adapt to modern languages/approaches/IDEs, which would explain why those particular people are not doing so well.

icebraining 9y ago
a lot of them have refused to adapt to modern languages/approaches/IDEs, which would explain why those particular people are not doing so well. Seems a bit shortsighted from the management's part. Retro and casual gaming is pretty hot right now, especially on mobile. I would license a good emulator, and then gather a good old-school team and let them make a few games their own way. Has anything like this been tried?
- pjmlp 9y ago
  It is hot on the news, but as most Gamasutra and GDC postmortems show, not hot enough to make a living out of it. All the most well known 80 and 90 game hits already have mobile remakes, not all of them commercial successes.
  - icebraining 9y ago
    I'm not saying remaking old games, but doing new games with the same tools. Like VVVVVV or Super Crate Box, but actually done with old tools, not just in an old style.
- dandellion 9y ago
  I'm pretty sure that most modern retro games are not written in assembly, which is what they used in the 80s for consoles. Most modern games are written using modern tools, most old developers that are still making games successfully are those that have adapted to modern tools, the others struggle. I think parent is referring to that.
  - icebraining 9y ago
    I get that games nowadays, even retro, are made using modern tools. My question is whether that's absolutely required, or if you could make a modern game using old tools. For example, one guy ported Canabalt to the Commodore64: https://www.youtube.com/watch?v=yibnVB9iXfU https://www.youtube.com/watch?v=yibnVB9iXfU But instead of porting, the team would develop new games like Canabalt using old tools, and then sell the games integrated with an emulator.
    - the_af 9y ago
      But why? There's a reason we don't use the old tools anymore.
      - icebraining 9y ago
        To take advantage of the skills and experience of the programmers mentioned in sdrothrock's post.
        the_af 9y ago
        I understand that. I guess I'm saying that while it can be done, the drawbacks offset the advantages. Soon there won't be any games programmers that only want to program in assembly language anyway.
      - jolmg 9y ago
        Old is subjective (when it was created or last updated), and even when old in all respects, it's not universally bad. Many would consider linux/unix, command-line interfaces, vim, emacs, common lisp, haskell, lisp machines, etc. to be old/useless, because they lack pretty graphics, support for the newest hardware, or is simply not windows nor mac. But these old technologies have positive traits that are lost and sometimes recovered in the newer technologies. Examples of when older technology was recovered could be the introduction of lambdas and higher order functions into mainstream languages like c++ and python; that's something that "older" languages like lisp and haskell have had since their inception. I'm also to understand that Windows servers needed a graphical interface because not everything was doable from command line interface, and so setup had to be done manually instead of just making a script containing what you'd otherwise would've typed through a CLI. Now, they've improved the situation by making a CLI in the form of Powershell and making more of the system available through it. As for other advantages of older tech that are not mainstream in "newer" tools, there is for example the fact that lisp machines are completely coded in lisp. Mind you, I haven't used a lisp machine myself, but I'm to understand that they have the ability to modify any part of anything running on the computer at any time even while the program is running, with minimum "build" time. I've experienced this on emacs, but on a lisp machine it's everything. Right now, I'm experiencing a bug on Firefox where some checkboxes and radioboxes are not rendered; this happens even with all add-ons uninstalled. If I wanted investigate this further, I'd have to download the firefox source, and read it in whatever multiple languages it's written in (as opposed to just lisp). Let's imagine I find the bug and fix it. I'd have to build the whole of firefox, not just the pieces I've changed. mozilla.org tells me I'd need "2G RAM with lots of available swap space" and, I imagine, lots of time. On a lisp machine, I'd just need to rebuild the functions I've changed. Emacs also has support for live coding in multiple languages through addons like slime for common lisp, cider for clojure, skewer for javascript, etc. I'm not sure if things like that are available in "newer" IDEs. Sorry, I ended up ranting. I just love to research "old" technology, as I find that they have much to offer over modern "equivalents". EDIT: This post seems to stray a little from the context of this thread, but consider for example live coding. I'm not familiar with the workflow of the typical modern game developer, but if modern tools don't offer something similar to live coding, they might benefit from it. If a particular piece of code is only launched under very specific conditions in the game, something that would require a little time to setup, they might benefit from being able to change/add and load the new code while they're playing in that "deep context". I remember once seeing a video of someone developing an FPS in Common Lisp. They where shooting at a wall and checking how it impacted with it. They would switch windows to emacs, edit a bit inside a function, hit a keybinding, and have the shots altered immediately in the running game, without having to restart it or anything. They would develop the game while playing it!
tonyedgecombe 9y ago
>>a lot of them have refused to adapt to modern languages/approaches/IDEs There are plenty of young people like that too.

icebraining 9y ago

a lot of them have refused to adapt to modern languages/approaches/IDEs, which would explain why those particular people are not doing so well. Seems a bit shortsighted from the management's part. Retro and casual gaming is pretty hot right now, especially on mobile. I would license a good emulator, and then gather a good old-school team and let them make a few games their own way. Has anything like this been tried?

pjmlp 9y ago
It is hot on the news, but as most Gamasutra and GDC postmortems show, not hot enough to make a living out of it. All the most well known 80 and 90 game hits already have mobile remakes, not all of them commercial successes.
- icebraining 9y ago
  I'm not saying remaking old games, but doing new games with the same tools. Like VVVVVV or Super Crate Box, but actually done with old tools, not just in an old style.
dandellion 9y ago
I'm pretty sure that most modern retro games are not written in assembly, which is what they used in the 80s for consoles. Most modern games are written using modern tools, most old developers that are still making games successfully are those that have adapted to modern tools, the others struggle. I think parent is referring to that.
- icebraining 9y ago
  I get that games nowadays, even retro, are made using modern tools. My question is whether that's absolutely required, or if you could make a modern game using old tools. For example, one guy ported Canabalt to the Commodore64: https://www.youtube.com/watch?v=yibnVB9iXfU https://www.youtube.com/watch?v=yibnVB9iXfU But instead of porting, the team would develop new games like Canabalt using old tools, and then sell the games integrated with an emulator.
  - the_af 9y ago
    But why? There's a reason we don't use the old tools anymore.
    - icebraining 9y ago
      To take advantage of the skills and experience of the programmers mentioned in sdrothrock's post.
      - the_af 9y ago
        I understand that. I guess I'm saying that while it can be done, the drawbacks offset the advantages. Soon there won't be any games programmers that only want to program in assembly language anyway.
    - jolmg 9y ago
      Old is subjective (when it was created or last updated), and even when old in all respects, it's not universally bad. Many would consider linux/unix, command-line interfaces, vim, emacs, common lisp, haskell, lisp machines, etc. to be old/useless, because they lack pretty graphics, support for the newest hardware, or is simply not windows nor mac. But these old technologies have positive traits that are lost and sometimes recovered in the newer technologies. Examples of when older technology was recovered could be the introduction of lambdas and higher order functions into mainstream languages like c++ and python; that's something that "older" languages like lisp and haskell have had since their inception. I'm also to understand that Windows servers needed a graphical interface because not everything was doable from command line interface, and so setup had to be done manually instead of just making a script containing what you'd otherwise would've typed through a CLI. Now, they've improved the situation by making a CLI in the form of Powershell and making more of the system available through it. As for other advantages of older tech that are not mainstream in "newer" tools, there is for example the fact that lisp machines are completely coded in lisp. Mind you, I haven't used a lisp machine myself, but I'm to understand that they have the ability to modify any part of anything running on the computer at any time even while the program is running, with minimum "build" time. I've experienced this on emacs, but on a lisp machine it's everything. Right now, I'm experiencing a bug on Firefox where some checkboxes and radioboxes are not rendered; this happens even with all add-ons uninstalled. If I wanted investigate this further, I'd have to download the firefox source, and read it in whatever multiple languages it's written in (as opposed to just lisp). Let's imagine I find the bug and fix it. I'd have to build the whole of firefox, not just the pieces I've changed. mozilla.org tells me I'd need "2G RAM with lots of available swap space" and, I imagine, lots of time. On a lisp machine, I'd just need to rebuild the functions I've changed. Emacs also has support for live coding in multiple languages through addons like slime for common lisp, cider for clojure, skewer for javascript, etc. I'm not sure if things like that are available in "newer" IDEs. Sorry, I ended up ranting. I just love to research "old" technology, as I find that they have much to offer over modern "equivalents". EDIT: This post seems to stray a little from the context of this thread, but consider for example live coding. I'm not familiar with the workflow of the typical modern game developer, but if modern tools don't offer something similar to live coding, they might benefit from it. If a particular piece of code is only launched under very specific conditions in the game, something that would require a little time to setup, they might benefit from being able to change/add and load the new code while they're playing in that "deep context". I remember once seeing a video of someone developing an FPS in Common Lisp. They where shooting at a wall and checking how it impacted with it. They would switch windows to emacs, edit a bit inside a function, hit a keybinding, and have the shots altered immediately in the running game, without having to restart it or anything. They would develop the game while playing it!

tonyedgecombe 9y ago

>>a lot of them have refused to adapt to modern languages/approaches/IDEs There are plenty of young people like that too.