@@overthinkerapexx7845 Assuming the games were sold at the current prices he would have made 31500 dollars from neversong and 41235.75 dollars from pinstripe in revenue
@@quaker5712 Yeah, I only watched like 3 videos from this guy and he constantly keeps talking over guests. Guess this one was an exception because he's just clueless and doesn't know what to say about low level stuff, but basically the guy is a fraud.
Whoever this interviewer, it seems that either he does not get what jonathan is saying or he is not interested in what jon is saying but only want to get the views.
It's funny because you can feel the difference between the two, it's almost painful to watch in their body languages, while Johnatan is talking about the implication of consistent frame rendering Thomas almost seems to have difficulties to grasp and participating in the conversation (only muttering "right", "correct", ..etc), only for the tension to disappear by him stating " you're the opposite of me" which I found it to be a great statement to say. And yes nowadays there is lot more of Thomas than Johnathan because of freely available tools like Unity or Unreal, _which he stated by himself while I was thinking it the whole first part of the video_, how crazy. And I don't think it's either a good or bad things (while I admit I tend to feel more connected to the first crowd of "game devs as low level programmers"), it's just what is nowadays. Ô well.
Oh man that response. I'll just let my engine figure it out. Bruh, that's why so many people who care about this stuff are complaining about how awful UE5 is making games look and feel. I now understand this comment.
@@ferinzz i mean both are correct. for a generic game, something like Unreal Engine 4 or 5 will handle most of the optimization stuff because they have built in controller support that works for all controllers and saves a lot of time on that end just as an example, however it can happen that devs are inexperienced in using a engine and just not toggle an important setting or dismiss all form of optimization, like in the case of stalker 2. That game has no right to run like ass for what it delivers.
@@ferinzz yeah UE5 is a disaster, so much so that CDPR rewrote half of the engine. Stalker developers, obviously, rewrote less stuff, and now we see the result. After 6 years in development, it barely runs on rtx4090, has tons of bugs, stutters and looks like a 2015 Frostbite game. And it's a game with a completely static world, I cant imagine how bad would dynamic games with physics perform...
@@FireF1y644 yup. PoE's leaad engine dev said it best. We need to stop trying to solve lighting and these other complex heavy mathematic systems with more power. Because we're not going to be able to keep innovating in that direction. Nanite is cool. But it only works for a very small subset of games and if your levels are not dynamically altered you're not going to see as much benefit compared to other industry standards. It also fails heavily on trees and such, causing severe overdraw which means either completely changing how you create trees or your game runs like ass. I've also heard devs state that scenes that would show there is a ton of overdraw in ue4 is showing that no this is fine in ue5... As if Epic has shifted the goal posts on what is 'fine'. Sorry for the ramble. Did not mean to go so long.
Because guess what, huge IQ disbalance, because all major companies market these engines in a way that makes everyone convinced they can be a game developer. If you believe you can make professional games using blueprints, you are not cut out to be making games.
I went on a similar rabbit hole with fullscreen and aspect ratios. Sometimes you just need a fixed aspect ratio and many engines at the time were terrible at it, they would stretch or force the wrong one on you. Unity did pretty well out the door so it's mostly solved for me now. No multi-window though. Timekeeping was hard also, I had to guesstimate frame time using a rolling window for physics updates and just eat the occasional lag spike from interrupts and such. Multithreading and high resolution timers solved this one. The solution for physics updates and timing has already been done for decades and it's interpolation. You run your physics at a low fixed rate (used to be as low as 15fps but it's a choice) and rendering interpolates between physics frames, so it LOOKS better in faster machines, but the experience is mathematically the same. Been done since the Tomb Raider era. Major engines already have this.
Maybe the craziest thing is that the unsolvable problems are some of the first things you have to think about when you are writing a game engine. Picking between simple to work with programmer solutions and integral math solutions is a total head ache.
I'm currently struggling with similar problems and I found that I can run the internals of my game at a different tick rate compared to the graphics. So the game just runs the logic and graphics, animations etc interpolate between ... I guess this approach is not very smooth in lots of cases.
What annoys me and this has actually become worse is the unsteady movement of rotating objects. You have cube rotating with 120 fps and it looks like it's stuttering and jumping. You turn on VSync to 30 or better 60 frames and it looks steady or normal. This is a thing of modern monitors and it started after LCDs and it's the weirdest thing. And don't tell me "free sync" because free sync gets rid of tearing, but that's not what I'm talking about. I'm talking about the effect that the eyes pick up extremely well on frame rate inconsistencies and the fast traveling corners of rotating objects just reveals it.
Not sure if you noticed, but you have a bad habit of messing around with your microphone all the time, and it causes a lot of low-frequency noise when listening to this interview on headphones.
Thomas can't even pretend to listen. His eyes are constantly looking away, and he's fiddling with the mic he's not even speaking through. Bro, stop cutting to your face if your face is disrespectful. 🙄 Why do interviews when you do not like listening, Thomas? I'm also not convinced this isn't a real issue. I think this is a skill issue. I've seen better performance from some modern programs than ever before... Its just, the skill needed isn't avidly taught anymore. Colleges are mass producing basic coders, but not actual experts with knowledge necessary to use all the tools fully. Only, in the most shallow "get it up" means possible. And, thats still a skill issue. Not an issue of inherently higher complexity, more so inherently lower knowledge to meet it.
nobody buys a 240hz monitor with the expectation that every game they play will be 240 fps. most people who buy high refresh monitors are doing it for very specific games (usually competitive shooters.) it's not even an issue that 99% of developers need to concern themselves with.
Exactly. Thats the point. I'm making a good game, and I smash into a wall. I should solve the problem, but do I really need to? This eroeds quality, and in a stack, or using an engine rife with these small erosions, single handedly being the inverse of said process is nearly impossible.
I guess I'm not understanding this. I always understood that most games these days simulate at 60hrz while the frame rate can go higher giving you a very smooth experience. As for vsync, most people turn that off because of the latency it produces. I always turn that off in any game I play. I don't get screen tearing and games run smooth. I've been playing like this for years now. And for physics being reliant on frame rate, I thought that problem was solved with delta time? For example Half-Life 2 I've played on multiple different computers, I have never noticed any significant changes in the physics on each of those systems. Maybe someone could explain it to me better?
Well that’s interesting, maybe free/g-sync is preventing the tearing, but variable step will never line up with monitor vsync. If there is input latency WITH vsync, it’s probably because the game expects it to be turned off because the vsync is blocking and stalling it. -I design around vsync being present btw.
This is also my understanding. The simulation happens at fixed intervals (usually 60 times per second) using the delta time, while rendering happens at variable rates with techniques optionally employed to smooth things out.
@@hifumibestgirl Yeah games like Half-Life 2 have pretty good physic in them and I've played that game on a few different machines and noticed no change in how the physics handled. I mean there could be slight changes but it's hardly noticeable.
@ ha yes I was “joking”. In theory NES program should be easier because the hardware is fixed but obviously archaic. I assume there are ways to program in C for NES at this point, but I was also trying to intimate that programming in assembly language would be specifically for the NES (or 6502 + proprietary hardware) and that one of the advantages of contemporary programming is that you can program for a range of hardware (different CPUs, operating systems, mobile, web, etc) with high level languages but whatever is going on under the hood causes the issues he is talking about.
Man this is just a man getting old and thinking incorrectly that stuff used to be better in the past. Spoiler it's never been better, for game devs just like for everything else
The quality bar of AAA is high but its not worth it trying to reach it as solo or indie. And i doubt any AAA devs watch these videos. Just try to do what you need for the game and dont chase the stupid gimicks or micro optimisatoons that only big studios can support.
Jon is both correct, and probably unhealthily engaged with how to address the problem.The reason he's engaged with the software stack in that much detail is because he makes games with high-end graphics; you can decide "the game targets 60hz and nothing else", like a Game Maker user, and immediately reduce a lot of the surface area of the issue. We're in a market today where the majority of game buyers have drifted away from the tech cycle - they might play AAA stuff, but they drop settings instead of upgrading. In that sense, saying "it's always 60hz" can be like "ah, good, no tech FOMO". Because Jon defines this as a quality issue - the game *could* use more of the hardware and give a higher-fidelity experience in this dimension - he ends up seeing the problems. The path he's on makes him cooperative with an array of Fortune 500 companies that see the chip features and drivers and operating system and engine support as marketing expenses - something you spend on to get chips and licenses sold, with no promise of it ever leading towards a robust software ecosystem. The bulk of the complexity is simply the business model of the computing industry, where everything has to be "supported" by everything else with a SLA. By making a high-end game, he is actually doing marketing for these companies since it now has to acknowledge and address their devices and features to get the most out of them: every game that has "RTX enabled" is an advertisement for Nvidia RTX. Every game that has "240hz support" sells 240hz monitors. As an artist, it's worth disengaging with that and having the confidence in yourself to say, "it doesn't matter how efficiently I'm lighting up the transistors, I can make good, interesting graphics regardless."
This has less to do with the graphics quality, and more to do with the game's genre. It's surprisingly hard to make even visually simple games to run at reliable 240hz, on any hardware. Even many games from early 2000s struggle to hit 60 on modern hardware. So just lowering the target fidelity is not actually that good of a solution. It mostly reduces your production costs (modeling, visual design, sound design, what have you), but not necessarily directly improves performance. E. g. Factorio looks like it could be from the late 90s for all you know. It took 20 year of engineering to actually make it work. In fact it barely matters at all what kind of graphics Factorio would have compared to the inherent challenge of optimizing a game with that many active objects in it. Factorio did sort of go the "fixed 60" route though, although I don't think it had much to do with hitting a stable framerate.
@@todorsamardzhiev144 what does any of this have to do with fidelity or realism? Gameplay itself can enforce pretty significant performance requirements.
@@antonuramer As someone who was gaming during the late 90s, Factorio's graphics would have absolutely blown us away and it would have been leagues better than anything at the time. Don't forget Playstation 2 came out in the year 2000.
@@MadsterV in terms of rendering resolution - sure. But the overall visual style and aesthetic is not too unlike something like Fallout 1 or even Vangers.
For physics framerate indepdence, best we came up with is the physics framerate limit, it's in several engines including Godot (like if its too low the clock slows down, is also in Holocure on GameMaker), and with 4.3 they also brought back physics interpolation, well that means you could run all the processes in physics process and it will interpolate to higher framerates. I dont think many devs target more than 60 hz and for that even older godot versions work well. I dont recommend using framerate dependent physics calculations and I hardly can find anyone who prefers it. Also many times in history of Warframe they found out the hard way to change from framerate to physics rate for fairness with many abilities and some weapons.
@smallbluemachine except everytime someone tries that and it worked on console, it immediately breaks once you have to support ports on worse and better hardware. Some NFS game had have like 30hz fixed render and physics rate and everyone complained on PC. From a coding perspective it's fine but then everyone's preferences and also the requirements are fucked.
PC is indeed a mess. I can hint to the driver what I want, but driver global settings overrides it 🤷♂️ it’s very difficult to control presentation. ☹️
I think we have a division between game and optimization. Game is story, art style, dialogue and voice acting, sounds and music, level design, mechanics...etc. While optimization is how good games run. So many complaints against big games are down to game not running well, then we draw the bigger conclusion of: Game not running well = game bad. Obviously people deserve to have a functional game, they paid for a reasonably working product. But I think if we bring more understanding of this, we can have better discussions about games.
@todorsamardzhiev144 Depth vs width. You can make a truly incredible experience, but if only a couple hundred folks can get that experience, is it worth it?
NO MAKING GAMeS ARE HARD 4 those who dont understand what they want to do. i love figuting games and action games for me ist insane simple to create new combat systems, but also im good at math. and ok in making art.
Games were simpler to make before because developers were developing for simple hardware like gameboy or snes. Sure engines do alot for you but the second you want to do it from scratch its a nightmare compared to 80s and 90s
Better name would be - "Game engine developer tries to reason with Unity dev"
8:24
Blow: "What bothers me the most is that people don't seem to care about this"
Host: \*nervous laughter from a guy who clearly doesn't care\*
@@overthinkerapexx7845 Assuming the games were sold at the current prices he would have made 31500 dollars from neversong and 41235.75 dollars from pinstripe in revenue
He has released a couple of games plus a newgrounds game back in the day. I'm fairly sure he has made 6 figures with just games @@overthinkerapexx7845
@@overthinkerapexx7845 You should do some research about him before spitting nonsense :)
@@zdeneksotolar2852 oh sorry i should
Yep, though the games he makes don't have the same issues with unreal bloat and defaults and stuff
Thomas Brush seems so disinterested, really bad interview style.
Thomas Brush is only interested in Thomas Brush.
he said he's been looking forward to this interview for 2 years just to not even know about the game john is currently working on 😭
Not only disinterested, but also clueless. He clearly has no clue what Jonathan Blow is talking about. Very painful to watch.
@@quaker5712 Yeah, I only watched like 3 videos from this guy and he constantly keeps talking over guests. Guess this one was an exception because he's just clueless and doesn't know what to say about low level stuff, but basically the guy is a fraud.
johnathan literally said he blew off the interview and then thomas is disinterested because the only reason jb is here is to talk shit... ok..
Whoever this interviewer, it seems that either he does not get what jonathan is saying or he is not interested in what jon is saying but only want to get the views.
seems like the interviewer can't wait for jonathan to stop speaking lmao
It's funny because you can feel the difference between the two, it's almost painful to watch in their body languages, while Johnatan is talking about the implication of consistent frame rendering Thomas almost seems to have difficulties to grasp and participating in the conversation (only muttering "right", "correct", ..etc), only for the tension to disappear by him stating " you're the opposite of me" which I found it to be a great statement to say. And yes nowadays there is lot more of Thomas than Johnathan because of freely available tools like Unity or Unreal, _which he stated by himself while I was thinking it the whole first part of the video_, how crazy.
And I don't think it's either a good or bad things (while I admit I tend to feel more connected to the first crowd of "game devs as low level programmers"), it's just what is nowadays.
Ô well.
Oh man that response. I'll just let my engine figure it out.
Bruh, that's why so many people who care about this stuff are complaining about how awful UE5 is making games look and feel.
I now understand this comment.
@@ferinzz i mean both are correct. for a generic game, something like Unreal Engine 4 or 5 will handle most of the optimization stuff because they have built in controller support that works for all controllers and saves a lot of time on that end just as an example, however it can happen that devs are inexperienced in using a engine and just not toggle an important setting or dismiss all form of optimization, like in the case of stalker 2. That game has no right to run like ass for what it delivers.
@@ferinzz yeah UE5 is a disaster, so much so that CDPR rewrote half of the engine. Stalker developers, obviously, rewrote less stuff, and now we see the result. After 6 years in development, it barely runs on rtx4090, has tons of bugs, stutters and looks like a 2015 Frostbite game. And it's a game with a completely static world, I cant imagine how bad would dynamic games with physics perform...
@@FireF1y644 yup. PoE's leaad engine dev said it best. We need to stop trying to solve lighting and these other complex heavy mathematic systems with more power.
Because we're not going to be able to keep innovating in that direction.
Nanite is cool. But it only works for a very small subset of games and if your levels are not dynamically altered you're not going to see as much benefit compared to other industry standards. It also fails heavily on trees and such, causing severe overdraw which means either completely changing how you create trees or your game runs like ass.
I've also heard devs state that scenes that would show there is a ton of overdraw in ue4 is showing that no this is fine in ue5... As if Epic has shifted the goal posts on what is 'fine'.
Sorry for the ramble. Did not mean to go so long.
Because guess what, huge IQ disbalance, because all major companies market these engines in a way that makes everyone convinced they can be a game developer.
If you believe you can make professional games using blueprints, you are not cut out to be making games.
Serious Sam mentioned, absolutely based. It was revolutionary for the time.
Have not played Serious Sam but the Talos Principle was iconic for me
This is the talk on frame pacing by Alen Ladavac, that Jonathan mentioned:
ua-cam.com/video/n0zT8YSSFzw/v-deo.html
Thanks!
Thank you
This man says it how it is! Software is becoming harder and harder to do well yet people care less and less about it in the industry
I went on a similar rabbit hole with fullscreen and aspect ratios. Sometimes you just need a fixed aspect ratio and many engines at the time were terrible at it, they would stretch or force the wrong one on you. Unity did pretty well out the door so it's mostly solved for me now. No multi-window though.
Timekeeping was hard also, I had to guesstimate frame time using a rolling window for physics updates and just eat the occasional lag spike from interrupts and such. Multithreading and high resolution timers solved this one.
The solution for physics updates and timing has already been done for decades and it's interpolation. You run your physics at a low fixed rate (used to be as low as 15fps but it's a choice) and rendering interpolates between physics frames, so it LOOKS better in faster machines, but the experience is mathematically the same. Been done since the Tomb Raider era. Major engines already have this.
literally what Terry Davis was saying all those years
Based.
Maybe the craziest thing is that the unsolvable problems are some of the first things you have to think about when you are writing a game engine. Picking between simple to work with programmer solutions and integral math solutions is a total head ache.
10:09 The host didn't like that Jon didn't let him finish his sentence.
I'm currently struggling with similar problems and I found that I can run the internals of my game at a different tick rate compared to the graphics. So the game just runs the logic and graphics, animations etc interpolate between ... I guess this approach is not very smooth in lots of cases.
What annoys me and this has actually become worse is the unsteady movement of rotating objects. You have cube rotating with 120 fps and it looks like it's stuttering and jumping. You turn on VSync to 30 or better 60 frames and it looks steady or normal. This is a thing of modern monitors and it started after LCDs and it's the weirdest thing. And don't tell me "free sync" because free sync gets rid of tearing, but that's not what I'm talking about. I'm talking about the effect that the eyes pick up extremely well on frame rate inconsistencies and the fast traveling corners of rotating objects just reveals it.
Not sure if you noticed, but you have a bad habit of messing around with your microphone all the time, and it causes a lot of low-frequency noise when listening to this interview on headphones.
2:50, so whenever I lock FPS I'm helping the game, huh?
Thomas can't even pretend to listen. His eyes are constantly looking away, and he's fiddling with the mic he's not even speaking through. Bro, stop cutting to your face if your face is disrespectful. 🙄
Why do interviews when you do not like listening, Thomas?
I'm also not convinced this isn't a real issue. I think this is a skill issue. I've seen better performance from some modern programs than ever before... Its just, the skill needed isn't avidly taught anymore. Colleges are mass producing basic coders, but not actual experts with knowledge necessary to use all the tools fully. Only, in the most shallow "get it up" means possible. And, thats still a skill issue. Not an issue of inherently higher complexity, more so inherently lower knowledge to meet it.
nobody buys a 240hz monitor with the expectation that every game they play will be 240 fps. most people who buy high refresh monitors are doing it for very specific games (usually competitive shooters.) it's not even an issue that 99% of developers need to concern themselves with.
Exactly. Thats the point. I'm making a good game, and I smash into a wall. I should solve the problem, but do I really need to? This eroeds quality, and in a stack, or using an engine rife with these small erosions, single handedly being the inverse of said process is nearly impossible.
@@jonathanhoward1499 it's quite literally not his point lmao. you don't smash into a wall because the wall doesn't exist.
I guess I'm not understanding this. I always understood that most games these days simulate at 60hrz while the frame rate can go higher giving you a very smooth experience. As for vsync, most people turn that off because of the latency it produces. I always turn that off in any game I play. I don't get screen tearing and games run smooth. I've been playing like this for years now. And for physics being reliant on frame rate, I thought that problem was solved with delta time? For example Half-Life 2 I've played on multiple different computers, I have never noticed any significant changes in the physics on each of those systems. Maybe someone could explain it to me better?
Well that’s interesting, maybe free/g-sync is preventing the tearing, but variable step will never line up with monitor vsync. If there is input latency WITH vsync, it’s probably because the game expects it to be turned off because the vsync is blocking and stalling it. -I design around vsync being present btw.
This is also my understanding. The simulation happens at fixed intervals (usually 60 times per second) using the delta time, while rendering happens at variable rates with techniques optionally employed to smooth things out.
@@hifumibestgirl Yeah games like Half-Life 2 have pretty good physic in them and I've played that game on a few different machines and noticed no change in how the physics handled. I mean there could be slight changes but it's hardly noticeable.
Damn, I even forgot I've ever subbed to this channel, cheers
So you’re saying we should all just program for the NES?
Are you responding to the right video?
@ ha yes I was “joking”. In theory NES program should be easier because the hardware is fixed but obviously archaic.
I assume there are ways to program in C for NES at this point, but I was also trying to intimate that programming in assembly language would be specifically for the NES (or 6502 + proprietary hardware) and that one of the advantages of contemporary programming is that you can program for a range of hardware (different CPUs, operating systems, mobile, web, etc) with high level languages but whatever is going on under the hood causes the issues he is talking about.
Man this is just a man getting old and thinking incorrectly that stuff used to be better in the past. Spoiler it's never been better, for game devs just like for everything else
The quality bar of AAA is high but its not worth it trying to reach it as solo or indie. And i doubt any AAA devs watch these videos. Just try to do what you need for the game and dont chase the stupid gimicks or micro optimisatoons that only big studios can support.
Jon is both correct, and probably unhealthily engaged with how to address the problem.The reason he's engaged with the software stack in that much detail is because he makes games with high-end graphics; you can decide "the game targets 60hz and nothing else", like a Game Maker user, and immediately reduce a lot of the surface area of the issue. We're in a market today where the majority of game buyers have drifted away from the tech cycle - they might play AAA stuff, but they drop settings instead of upgrading. In that sense, saying "it's always 60hz" can be like "ah, good, no tech FOMO".
Because Jon defines this as a quality issue - the game *could* use more of the hardware and give a higher-fidelity experience in this dimension - he ends up seeing the problems. The path he's on makes him cooperative with an array of Fortune 500 companies that see the chip features and drivers and operating system and engine support as marketing expenses - something you spend on to get chips and licenses sold, with no promise of it ever leading towards a robust software ecosystem. The bulk of the complexity is simply the business model of the computing industry, where everything has to be "supported" by everything else with a SLA. By making a high-end game, he is actually doing marketing for these companies since it now has to acknowledge and address their devices and features to get the most out of them: every game that has "RTX enabled" is an advertisement for Nvidia RTX. Every game that has "240hz support" sells 240hz monitors.
As an artist, it's worth disengaging with that and having the confidence in yourself to say, "it doesn't matter how efficiently I'm lighting up the transistors, I can make good, interesting graphics regardless."
This has less to do with the graphics quality, and more to do with the game's genre. It's surprisingly hard to make even visually simple games to run at reliable 240hz, on any hardware. Even many games from early 2000s struggle to hit 60 on modern hardware. So just lowering the target fidelity is not actually that good of a solution. It mostly reduces your production costs (modeling, visual design, sound design, what have you), but not necessarily directly improves performance.
E. g. Factorio looks like it could be from the late 90s for all you know. It took 20 year of engineering to actually make it work. In fact it barely matters at all what kind of graphics Factorio would have compared to the inherent challenge of optimizing a game with that many active objects in it. Factorio did sort of go the "fixed 60" route though, although I don't think it had much to do with hitting a stable framerate.
It's about style rather than fidelty and realism. Check out his comments on the new version of Riven, for example.
@@todorsamardzhiev144 what does any of this have to do with fidelity or realism? Gameplay itself can enforce pretty significant performance requirements.
@@antonuramer As someone who was gaming during the late 90s, Factorio's graphics would have absolutely blown us away and it would have been leagues better than anything at the time. Don't forget Playstation 2 came out in the year 2000.
@@MadsterV in terms of rendering resolution - sure. But the overall visual style and aesthetic is not too unlike something like Fallout 1 or even Vangers.
For physics framerate indepdence, best we came up with is the physics framerate limit, it's in several engines including Godot (like if its too low the clock slows down, is also in Holocure on GameMaker), and with 4.3 they also brought back physics interpolation, well that means you could run all the processes in physics process and it will interpolate to higher framerates.
I dont think many devs target more than 60 hz and for that even older godot versions work well. I dont recommend using framerate dependent physics calculations and I hardly can find anyone who prefers it.
Also many times in history of Warframe they found out the hard way to change from framerate to physics rate for fairness with many abilities and some weapons.
I target 60hz rendering and physics with a 60hz fixed time step. Everything fits. Consequently i can target PCI bandwidth exactly. Buttery smooth.
@smallbluemachine except everytime someone tries that and it worked on console, it immediately breaks once you have to support ports on worse and better hardware. Some NFS game had have like 30hz fixed render and physics rate and everyone complained on PC. From a coding perspective it's fine but then everyone's preferences and also the requirements are fucked.
PC is indeed a mess. I can hint to the driver what I want, but driver global settings overrides it 🤷♂️ it’s very difficult to control presentation. ☹️
Unity has Update and FixedUpdate as well.
3:16
I shit my pants
I think we have a division between game and optimization.
Game is story, art style, dialogue and voice acting, sounds and music, level design, mechanics...etc.
While optimization is how good games run.
So many complaints against big games are down to game not running well, then we draw the bigger conclusion of: Game not running well = game bad.
Obviously people deserve to have a functional game, they paid for a reasonably working product.
But I think if we bring more understanding of this, we can have better discussions about games.
I respectfully disagree. There are sooo many possibilities to be explored with the amount of performance that is being left on the table.
@todorsamardzhiev144
Depth vs width. You can make a truly incredible experience, but if only a couple hundred folks can get that experience, is it worth it?
@@romankhamov6229 I'm guessing they were talking about improving efficiency, not raising the minimum hardware requirements.
NO! Lets slap 24 new Metroid clones and 49 Mario clones!
Are you responding to the wrong video?
It's a house of cards.
The solution, as always, is to throw more hardware at it.
I'm so tired of both of them.
Jon has pedigree. Thomas.. well, he’s got a great camera setup and production value.
Then why are you here watching this?
Oh no, the browser isn't letting this person switch pages!! HELP HIM!!!
@RealBrianRussell you didn't have to comment. Follow your own logic.
@@ciscornBIG Oh no, I can help you! Please browser, don't force him on any Brush or Blow videos! PLEASE SPARE HIM
Bro just talked shit about my MSI FreeSync monitor 32 inch 4k 160hz (Idk what the model name so I just refer to it like that) 😅 😢
NO MAKING GAMeS ARE HARD 4 those who dont understand what they want to do. i love figuting games and action games for me ist insane simple to create new combat systems, but also im good at math. and ok in making art.
Games were simpler to make before because developers were developing for simple hardware like gameboy or snes.
Sure engines do alot for you but the second you want to do it from scratch its a nightmare compared to 80s and 90s