Retroemulation people have been preserving the classics since decades, even more with libre (FLOSS) implementations made with SDL/SDL2 making these games ultraportable and eternal.
Not my lovely NFT at all.
Imagine the retro game and emulation required to run it forever preserved in a standard format. That's what a concept like NFT SHOULD be addressing. I'm lamenting that it's not doing so.
jeez guys, please read before dumping on me :)
I'm saying ideally, NFTs SHOULD prevent obsolescence of digital assets
They don't.
But if you think about it, it ought to be one of the primary purposes of a concept like NFT, right?
That's all I'm saying.
Sorry to use the trigger word :P
Detective Dotson is a game and a show! It has pixel characters placed in a realistic 3D depiction of modern India. Would love your feedback on our trailer!
I was a college student in India in 2001 being discouraged by my professors from seeking a graphics elective because "there's no career in graphics". 20 years later I can happily reflect on a dream career in graphics (EA, Pixar and my own game studio). The second edition of this book and its "make pretty pictures with a computer" message started it all off!
Heh, I had a similar story but just a decade later. Was not allowed to take the graphics elective in University even though it was a part of the official syllabus. The reason being that it was difficult to get a good grade in this subject in the finals.
Indian society and the love for meaningless numbers on a sheet of paper, name a better duo.
I think this is just sign of active fads. When I wanted to pick a research area in 2007 multiple professors/students had told me to ignore databases. The understanding was RDBMSes of the day had solved all problems. There were minor rumblings of the NoSQL movement back then, but no one was sure if it would be impactful and/or last long. At any rate not many ppl expected the field would see so much activity :-)
Another example I can think of is speech recognition systems (ASRs). Around 2007-08 again, I was told by researchers in the area that they are not coming to personal devices anytime soon - esp for Indian accents. A few years later you could dictate messages to hangouts on an Android phone :-)
> A few years later you could dictate messages to hangouts on an Android phone :-)
... can you ? it's 2021 and on any top of the line phone I'm definitely unable to get speech recognition systems to understand sentences to an acceptable level. A few words work... kinda. Hell, even typing has become harder than a few years ago where it used to be a simple dictionary - now every other message the automatic correction is completely wrong, which is very frustrating.
> there's no career in graphics sounds ridiculous today.
I'd wager that for this kind of people, even today, "graphics" is not a career. A career in these people's mind is something where you look like a stock photo executive, you'd do code for a couple years and move on to management.
“ A career in these people's mind is something where you look like a stock photo executive, you'd do code for a couple years and move on to management."
I shudder when I think about this outcome, despite its inevitability.
Blogging and side projects helped me land a job at Pixar! Many years later I wrote about it in an article-
https://hackernoon.com/3-things-i-learned-from-5-jobs-in-12-...
Blogging about how blogging helped me get a job got me the job I have now as CTO at Tonk Tonk Games :)
It's pretty main stream in the CG industry. Houdini is a great example of a very interesting take on visual programming in a non-destructive procedural workflow.
Visual programming is a staple at Pixar and features heavily in all their internal tools for shading, animation, set dressing etc.
At Pixar they push it to its limits, expressing all manners of development patterns through these tools to artists who don't know any software development at all.
I often think of a modified version of your question which is "Why isn't visual programming a bigger thing for trained programmers?" What needs to improve for that to happen? It's already a big thing for visual artists in the CG industry.
Just adding a bit to how pervasive this is: Blender, Cinema 4D, Max/Pd, Reaktor, Foundry's Nuke, Quartz Composer/Origami and Logic's environment are all examples of creative software that use some form of visual programming language. In fact, I'd even go as far to say that, outside of software engineering, it's the default approach (scripting interfaces are more common but less used, e.g., I'd guesstimate that over 90% Blender users use the node editor, while less than 1% of Photoshop users use its scripting interface).
From my analysis, most of the evidence points to visual programming languages actually being better. But.... there's just one problem, it's not plain text. The advantages of plain text are so powerful, and so pervasive, that they're like oxygen: We're so accustomed to them that it's hard to imagine a world without it, where we'd all be walking around without helmets on. Why is plain text so important? Well for starters it powers version control and cut and pasting to share code, which are the basis of collaboration, and collaboration is how we're able to construct such complex systems. So why then don't any of the other apps use plain text if it's so useful? Well 100% of those apps have already given up the advantages of plain text for tangential reasons, e.g., turning knobs on a synth, building a model, or editing a photo are all terrible tasks for plain text.
Visual programming works great when it all ends up in a set scene, a stable form that you just want to use code to create.
Once the task is to loop over time and do a bunch of processing, all the visual tools break down. They are two separate categories, two separate functions that shouldn't really be treated by the same tool just because they both use 'code'.
For example the visual programming languages for music and multimedia Max/MSP and Pure Data.
While you could use them to create a stable form, they are in my opinion much more useful and interesting for rapid prototyping, live coding, create or connect interactive systems, etc.
Sure, they are a bit niche, but certainly don't break down as soon as you loop over time and do a bunch of processing.
I had a quick look at Max and PD. I see what you mean, you can constantly run those programs, produce new outputs and edit it on the fly.
My meaning is more narrow I guess. Desktop apps and video games are built to run themselves post delivery. Music/film/3d models/textures end up as arranged bytes that are used as content for the apps and games to display. I guess textual programming languages work best when building the hierarchies and branches of loops that runtime apps have to self-navigate. Visual programming languages work well at symbolically representing many many many different rabbit holes one can draw from to produce an arranged set of bytes.
The visual stuff breaks down when you have to bake in navigating hierarchy after the product is out of your hands. The text stuff sucks at building 3d models vert-by-vert or with pattern matching. I haven't thought it all the way through.
As a wrote in another comment, where visual programming shines in my opinion is as a way to interact with an underlying complex system. An alternative to scripting languages.
To take the Max example further. Ableton Live integrated it deeply into their digital audio workstation. Although Ableton itself, not even talking about all the third party plugins, provides enough tools to make music with for a life time, having Max integrated opened up a whole new world of exploration beyond what the UIs created by the host and plugin vendors offer and it allowed non technical people to create and share their own extensions to a software.
I think even for trained programmers there is maybe more potential for visual programming. Maybe not for the core software we are writing, but to at the same time interact with and visualize the software and the ecosystem. I sometimes feel we are a bit stuck to have to either use cli and textual tools or graphical tools with limited and vendor specific UI.
I don't know how this would look like, since I'm a person that almost always defaults to cli and textual tools, because I know I can get the job done with them. But having used visual programming quite a bit outside of work, I'm intrigued to give it more attention to.
Visual for-loops work just fine for iterating over geometry chunks, and can even be parallelized with "compile block begin" nodes in Houdini.
High-level iteration is less intuitive, eg. iterating over random seeds for a sim and rendering preview animations, but the process is still easier than switching the entire thing to text input. The toolkit for this is called PDG or TOP networks.
It's no surprising that visual artists feel at home with visual programming.
There are more examples. Some people have mentioned Matlab/Simulink. In fact, many procedures are defined using some kind of visual programming. For example, in CAD and modeling software (like SolidWorks), you have a tree of operations that is just a visual program. The way in which effects are handled in PowerPoint is visual programming too. Even it could be argued that, when playing a game, you are just doing visual programming.
Mandatory mention of Grasshopper for product design and architecture! Amazingly powerful, can easily compete with most C++ geometry processing libraries
> "Why isn't visual programming a bigger thing for trained programmers?" What needs to improve for that to happen?
Because it's inefficient as hell. That may be mostly a problem with existing tooling, but it is a problem.
For context, I'm currently doing a side project with Unreal Engine 4, which uses visual programming for scripting and defining shaders; I'm sticking strictly to these tools, because I can't be arsed to set up yet another C++ dev environment on yet another machine. Because of that, the pros and cons of visual programming are on the top of my mind right now. Here are some thoughts:
Visual programming is fun while you assemble high-level blocks together. But god forbid, you have to do any maths. You end up spending 10 minutes assembling an unreadable mess of additions, multiplications, LERPs, etc. taking half of your screen, to build an equivalent of three lines of code you would've typed in 30 seconds in your editor.
(This presents an opportunity for improvement: why not give a generic "math" node, where I could just type a math expression by hand, and have the free variables show up as input pins? There's really no point in assembling things like "lerp(A x B, C x D, alpha) * -beta" from half a dozen nodes.)
In general, all the dragging quickly becomes annoying. As a trained programmer, you can type faster than you can move your mouse around. You have an algorithm clear in your head, but by the time you've assembled it half-way on the screen, you already want to give up and go do something else.
Visual programming is fun while your program fits on the screen. Because of the graphical representation, you'll usually fit much less code this way than you would in text. This, plus the fact that anything nontrivial won't form a planar graph (i.e. edges will have to cross somewhere), makes you want to abstract your code hard, otherwise it gets impossible to read. And here is where Unreal Engine starts to fail you. Yes, you can make perfectly fine functions - which are their own little subgraphs. But that also means they're different "tabs"; it's hard to see the code using a function and the code of a function simultaneously on the screen, it's hard to dig in and back out, jump around the references.
As an improvement in that particular case, I'd love if I could expend individual blocks into their definitions "inline", as a popup semi-transparent overlay, or something that otherwise pushes other nodes out while still keeping them on the same sheet. But given the performance of the editor, that would just burn my CPU down.
I think visual programming works well for artists, because when building shaders, you mostly stay on a single level of abstraction - so a flowsheet you can zoom around makes sense. But when you start coding logic and have to start DRYing code, dividing it up into layers of abstraction, the ergonomics starts to wear you down. Then again, I hear good things about LabVIEW, so maybe it can be made to work.
It doesn't have the be 100% visual programming or not. Same as a program does not need to be entirely written in one programming language.
Where I think visual programming shines is, as a way to interact with an underlying complex system, like the artists you mention. As and intermediate step between a rigid and often limiting classical user interface (forms, knobs, buttons) that someone needs to define and implement and the "real" code.
And I think trained programmers as well can have use cases for this. For example ETL tasks, continuous integration, etc. For me the important part is, that there is an escape hatch, and I can drop down to writing code if the blocks get in the way.
>>Visual programming is fun while you assemble high-level blocks together. But god forbid, you have to do any maths
Meh, I've worked on two games made in Snowdrop, where pretty much most of the game logic is made directly in the editor, all of the shaders, all of the animations, all of the UI is made using a visual scripting language and it's been more than fine. It meant that we had people who didn't know much about programming "coding" entire logic for animations for instance.
>>You end up spending 10 minutes assembling an unreadable mess of additions, multiplications, LERPs, etc. taking half of your screen, to build an equivalent of three lines of code you would've typed in 30 seconds in your editor.
Yes, which I appreciate is frustrating if you actually know how to type those 3 lines of code, and where to type them and how to compile the project and run it from scratch(so on the projects I worked with yes, it would take you 30 seconds to type in the code, but then 10 minutes to build and another 10 to run the game, while making those changes in the editor-based visual script you'd see the changes instantly). Our UI artists for example never even had Visual Studio installed and in fact I don't think they even synced code since they never had to - visual scripting was such a powerful tool for them that there was no need.
> so on the projects I worked with yes, it would take you 30 seconds to type in the code, but then 10 minutes to build and another 10 to run the game, while making those changes in the editor-based visual script you'd see the changes instantly
That's orthogonal to visual programming, and just the symptom of most programming languages being edit-compile-run. Compare that with UE4 (as far as I know) not allowing you to modify blueprints in a running game. Contrast that with different programming languages. I do some hobby gamedev in Common Lisp from time to time, which is a proper REPL-driven language. There, I can change any piece of the code, and with a single keystroke in my editor, compile it and replace it on a living, running instance of my game.
Visual programming is fun while you assemble high-level blocks together. But god forbid, you have to do any maths
I don't know whether a spreadsheet counts as "visual programming", but they are a much more accessible way for non-programmers to manage mathematical concepts.
Indeed, spreadsheets can be thought of as a kind of visual functional programming.
We are game and film veterans, united by a passion for learning and problem-solving, in order to build truly novel experiences for our players. Our culture is built around empathy - for each other and our players. If you want to be empowered to push the envelope and create games that delight like no other, come join our team!
