Japan’s ’golden coder’ making games apps aged 82 [video]
bbc.com
bbc.com
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?
All the most well known 80 and 90 game hits already have mobile remakes, not all of them commercial successes.
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.
For example, one guy ported Canabalt to the Commodore64: 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.
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!
In this case, though, we're talking about programming games using assembly language for outdated hardware, and doing so for no real technical reason. There's little definitive in software development, but we can agree on this: avoid assembly language whenever it's not mandatory for performance/memory/platform reasons. Software written in assembly is harder to understand, harder to fix, and harder to change. This is one case where using relatively modern tools (i.e. higher level languages) is an unambiguous win.
I do agree old tech has an indisputable charm. That's not what I'm arguing against here. If you want to write retrogames using old-fashioned assembly just because you can, that's fine! It will just be harder.
If you're arguing specifically that using an assembly language is less productive than a higher level language, then I fully agree with you.
Somehow I doubt these die-hard ex Nintendo devs are insisting on using Emacs or Lisp. I'd say those are "modern" tools anyway, in the sense that they still hold revolutionary insights for modern software development -- and also probably were NOT used for Nintendo games.
You're focusing on specifics, whereas I had been focusing on the more general theme of the thread.
To me, the theme, as set by icebraining, was generally: "does modern game programming benefit from using tools of old?"
Here, "tools" is a very general word, not limited to just assembly languages. sdrothrock expanded a little by saying "languages/approaches/IDEs", and "approaches" and "IDEs" are also very general words.
Your post, to which I initially responded, was:
> But why? There's a reason we don't use the old tools anymore.
Because old tools typically do have niche communities of varying size using them, I take "we" to mean "the majority of programmers".
So I understand your argument to be (I hope I'm not mistaken): "There should be no reason to use old tools, because there must be a valid reason why the majority are not using them anymore."
It's this reasoning that I disagree with. The reason the majority are not using them is because the majority of them look to use what the majority are using. It's a positive feedback loop. The remaining users, the ones that decided to use a modern tool before it was popular, probably chose to use it mostly based on a very important decision that can be made for any tool: how easy is it to learn how to use?
Now, a typically inversely correlated feature to this is: how powerful/flexible is it?
As examples, think of the choice of Vim or Emacs vs Visual Studio or Eclipse, or the choice of CLI vs GUI. It's a choice between ease of use (the popular choice) vs power/flexibility. Most will chose ease of use, but we shouldn't underestimate the importance of the minorities that chose otherwise.
So to answer your question, "why?", in the post I had given, I was providing examples of tools that are considered "old" but still held benefits over modern tools. The point was to answer your question in the general context, rather than suggest for them to use something specifically.
Now, if we talk specifically about what an ex Nintendo dev can do with their old tools, I've have no idea. :P But if it's true that "a lot of them have refused to adapt", like sdrothrock said, while it might be simply due to learning inertia, I would also consider the possibility that there might be something that was lost to the majority that might be worth recovering, something that that niche would consider important enough to keep.
I don't know what kind of system you use, but if it involves use of a command line, consider that many think it old and useless. They'd ask, "But why? there is a reason we're not using CLIs anymore. After all, there's GUIs!". Here is a highly upvoted StackExchange question asking just that:
https://ux.stackexchange.com/questions/101990/why-are-termin...
There are plenty of young people like that too.
Another thing I am wondering, what makes a company not hiring programmer at old age when their brain are still functioning properly?
But in this case I see your point. Many of these young CEOs just don't want older people in their offices. They have youth as part of "their culture". They also generally assume that older workers will be slower to adapt and less welcoming of a more volatile work environment; both frequent traits of many tech companies.
I'm not sure that is true, if you can't get a job because you are old then your wage is zero.
But shouldn't it be "silver coder"?
Referring to old people with "silver" probably refers to the hair, "golden years" I guess is because of relaxing in retirement and the wisdom of old age.
Interesting how she seats, my legs would hurt.