Totally fine to paint in broad strokes, and I would probably lean towards that perspective myself. However there are some games that show off the programming more than others, at least in motion. Movement based games, like technical platformers or similar, have a lot of expression through the systems that govern them. Whether or not a game feels good is fairly easy to figure out after spending some time with it, but understanding what would make it feel better and how to achieve it is a much harder skillset to develop. Obviously non-programmers can work out in high level terms what might improve game feel, but I think you can get much better results when you have deep understanding of how things work, what's possible, and what side effects may fall out of a given change.
That said, some of the most fun mechanics are born out of happy accidents involving interactions that weren't fully considered so it's definitely not a constant
I am being broad but to be more specific, if we classify games across two dimensions, one being tall (aka systems) versus wide (aka content), then I can't think of a single game that is more tall than wide. At best you get games which are squares, like tetris and pacman where a small amount of systems and a small amount of content go together.
For the vast majority of games they are very wide. Including technical platformers, which will have very finetuned movement systems, but they must be accompanied by a lot of equally finetuned levels. Another way of seeing it is that content is the "space" which your systems are expressed in, and more expressive systems require more space. A complex combat system will demand more enemy characters for its complexity to be relevant.
But I was only speaking in terms of programmers' understanding the nature of game production, rather than their actual contribution to the game. Of course there are very programming forward games, and entire genres driven first and foremost by innovative gameplay code. But even in those games and genres the programmer must understand that on top of the unique features that are being programmed, most of the important work will still be content creation. It's the nature of the beast. I'm a programmer who had to learn this the hard way. It's nothing like a software startup. It's more like a movie production with a software project inside.
I would've focused on game engine development and gone into the game industry instead of chasing the money in web/web-adjacent tech. It's almost impossible to make that kind of change now without taking a massive pay cut and it genuinely makes me sad almost daily
I've made several half-attempts at this over the years, but it always ends up falling to the wayside when life gets hectic. Maybe one of these days I'll finally push through though!
Could you work on an open-source game engine in your spare time, then use that to pivot across? And/or get a web-dev job in a games company and then try to get an internal transfer?
My wife has suggested the latter a few times and it definitely seems like the most realistic approach. I have a small game engine I've worked on off and on again over the last few years, but it never feels like I have enough time to make real progress
If you're into game engine development and C++, Godot is very accessible for new contributors. It's a great place to explore that stuff while also making (small or large) contributions which will actually get used and appreciated by a growing number of serious game developers.
I stopped at 1144 and 114. This could really use more of a difficulty ramp. After level 20 or so I really didn't notice it getting any harder and it sort of got boring. There was _one_ level fairly early on where it dumped a ton of letters on me all at once for some reason and I actually started to fall behind, but then it never happened again
Good tests only render SST superfluous insofar as the person writing the tests is capable of never making a mistake. The thing about good static type systems is they don't typically make mistakes in the domain they work in. The fact that you don't have to muddy your test with a bunch of type checking logic and instead focus on the thing actually being tested is just the cherry on top.
This feels a lot like a self-fulfilling prophecy that Javascript just happened to be chosen for.
- Javascript is "easy" and the only option for browsers, so lets teach it to beginners.
- We have all of these beginner programmers who can't work on the backend without learning a new language, so lets put javascript on servers.
- CPU, memory, and bandwidth have continued to become cheaper, so lets just run everything in javascript because "we can"
- Let's hire javascript developers because we've made them the easiest to hire for
- It's too expensive to use a different technology because our entire engineering team is javascript developers
I honestly can't fathom the reasons why we've encouraged Javascript to eat the world, but I don't think there's any arguing that it has. Is this good or bad for business in the long term? My personal take is that it isn't, but there are enough variables to make this really difficult to say with any kind of certainty. It feels more like we've just:
- Lowered the bar for acceptable quality over time
- Convinced ourselves that the Javascript ecosystem is a one-size-fits all optimization for time-to-product
> I honestly can't fathom the reasons why we've encouraged JavaScript to eat the world
Who is "we"? The scenario isn't some God-like figure who made the decisions and handed them down to mortals to live with. The reality is more like evolution (one you actually described very well), where many different, independent players are each working in their own interest.
> Lowered the bar for acceptable quality
Define "quality". Especially given the evolution prism, I'd argue that quality is not a rubric like "best technical performance" but rather one like "permits as many people as possible to engage with as many parts of the stack as possible." With that definition of quality, the JS ecosystem is by far and indisputably the king of the mountain. Graveyards are littered with many "best technical quality" options (Betamax, Itanium...).
> time-to-product
Nitpick, the term is time-to-market. What matters is not just building and shipping your MVP (which can be done by one person, who can choose whichever technology stack) but continually shipping at high velocity over time as the company grows, the original engineers leave, etc.
"we" is everyone in the industry. I recognize it's more of an evolutionary thing, it's just my stance that the current environment is pushing us towards an evolutionary dead end.
> Define "quality"
I also agree that software quality is fairly subjective depending on your lense, unfortunately. For example, I wouldn't view quality as permitting as many people as possible to work at every level. Diversity of ideas is great, but I want those ideas to come from folks who have the skillset. If someone who roofs houses decides to pour foundations without gaining the proper skillset or picking up different tools I would view that as a loss of quality, not a gain.
> the term is time-to-market
I chose time-to-product fairly intentionally, because I think the benefits of something like Javascript start to rapidly decay once you start approaching any sort of product maturity. The problem is teams rarely optimize towards stability and quality until they have literally no other option
> I want those ideas to come from folks who have the skillset
When the industry/society comes around and finally can get behind the idea of requiring licensing for software engineers to practice, get back to me :) . Until such a level playing field is imposed on all players, such practices impose a cost that your competitors are not paying, and they will out-manuever you and out-ship you.
> start to rapidly decay once you start approaching any sort of product maturity
Perhaps time-to-maturity then? Because it's besides the point that maturity is a characteristic necessarily of successful products. You find success by iteratively shipping.
> teams rarely optimize towards stability and quality until they have literally no other option
First make it run, then make it stable, then make it optimized. Pre-mature optimization is the root of all evil. This additionally lends focus to why the business can get behind such efforts: you need product flexibility to grow from $0 to $Xmillion/year, then you need to protect the $Xmillion/year so that it's not at risk from incompetence, hackers, etc., then after your user count stops growing, you continue to grow profits by cutting costs (e.g. by using more efficient languages like Rust that let you serve the same customers on less hardware).
This line of thinking is precisely why node and TypeScript are so pervasive. It has nothing to do with them being the right tool for the right job and everything to do with perceived lower barrier to entry and resistance to learning better tools. I would never try and use a hammer to saw a board in half, and yet that's exactly what people try and do with node/TS
I mean, they're also just kind of fun. Suppose you are building a CLI tool just for yourself, Deno is way more fun than Bash, say. Especially if your usecase starts to get into like tree traversals and stuff.
I'm not saying that you should use TS & Node for everything, not sure how you got that wrong. I'm saying: use the tools your developers know. If you have Java developers, use Java. If you have Rust developers, use Rust. If you have Typescript developers, use Typescript. Don't give a metaphorical person without arms a saw to split a board in half, even if it's supposedly the right tool.
I didn't really think you were saying they should be used for everything, but I do think discouraging branching out into better suited tools perpetuates using the lowest common denominator. If devs are never pushed out of their comfort zones, it's really hard for them to grow arms in order to use the saw.
I do acknowledge I have a lot of bias, though, because I work at a TS shop where the primary reason we continue to use it is because we always have. The longer I have to put up with it, the more I feel like this is a broken foundation to stand on
You shouldn't let developers branch out by trying to write their first real application in a completely new language as a productive thing for your company or your customers. They should learn by implementing real projects that will not be important or improved and maintained long-term.
Modern JS is a passable language only after a tremendous amount of time and effort was invested to retrofit it as such. For all of the purported isomorphic benefits, I still don't know why anyone would choose to use it outside of being forced to in browsers
It works great for you because you haven't seen better. Which other languages do you have more than 1 year of professional experience with? May I answer that for you? None. Just because you've just discovered a knife, doesn't mean it's the best tool to eat the soup with.
Javascript, like python, was "simple yet flexible". Thats what made them successful.
When a language is successful, people start to bolt on extra bits of syntax and features (async, prototypes/classes, lambdas, etc). Eventually it is no longer simple, and the learning curve gets steeper for new users.
Someone comes up with a new simple yet flexible language, all the new users start with that instead, and the cycle repeats.
BASIC/visual basic/VB.net went through that cycle in the 90's. C then C++ went through that in the 2010's. Python/Javascript is going through that now. Go is about to go through the same.
All the "good" languages have tremendous effort - it's how they get good. Nothing starts great...it's a journey. We've been watching the sausage being made.
Just because "it's a journey" and we invested tremendous effort, doesn't mean it's suddenly great. It's a terrible language with many illnesses, even today's modern version, because it's kept its diseases from the past. It surely is lightyears better than what it used to be, but it's still a pile of turd IMO (I work with JS every day).
That’s why git and JS don’t really belong on this list without a massive asterisk. It’s not like JS you use today is the same as the one that took “10 days”. Same goes for git.
My team helps run and deploy a python service that is entirely CPU bound. It accepts an input, performs some computation, and returns a result without any sort of I/O outside of the initiating HTTP request. In the past week it's averaged around 144 req/s with a p95 latency of ~1s.
We average ~80 "instances" to maintain this level of performance. I have very little doubt that, if given the opportunity to rewrite this in rust, we could smash 10x perf improvements. Could we also get more perf out of tuning our python code better? Definitely. Do I think there's 10-20x improvement waiting to be uncovered? No.
Unfortunately (fortunately?) we're at a stage that it makes more sense to throw ludicrous sums of money at it than it does to ground up rewrite.
Most of my bitching that JavaScript is slow comes from node, which is quite far removed from the DOM. Fast and slow are relative terms, of course, but JavaScript's language features necessitate that it will always be slower than most static, compiled languages. Regardless of runtime. What blows me away is how unsafe the language is on top of being slow, and yet it's basically eaten the world
That said, some of the most fun mechanics are born out of happy accidents involving interactions that weren't fully considered so it's definitely not a constant