seems like no experience explains the earlier 2

If you have little experience programming, JS/TS is arguably one of the best choices for making a game. You have a built-in rendering engine in the form of the browser and it's universally accessible by nearly any device. There's no permission needed for distribution: just create a web page with a live demo and share the link. It's a great way to learn about game loops, pathfinding algos, state management, physics and world building and there's tons of free tools. A couple of my undergrad projects were JS games and they were very fun to work on. Clearly not the right choice for AAA game dev or a full length indie game, but definitely solid choice for learning.

The Broughlike tutorial is pretty decent. It targets a very specific genre, but it does explain every step and you have a serviceable game at the end.

https://nluqo.github.io/broughlike-tutorial/

Because most game tutorials are about moving things around, maybe sounds, maybe collision detection.

And the actual mechanics of, notably, a 2D engine, are reasonably straightforward. But going from moving stuff around to “game” is a lot of work. A lot of polish, testing, feel, balance, etc.

Now, to be fair, a full tutorial of something like Breakout or Space Invaders doesn’t seem like too much to ask, since they’re so simple. But then it depends on what kind of games folks want to write.

Something like a simple RPG or platformer can be complete black holes.

The video that inspired that one

https://www.youtube.com/watch?v=Fy0aCDmgnxg

Game like a short hike use rendering pipelines instead of accuracy in the models for example

better tooling around 3D in my opinion

2D games can require a lot of assets. And most programmers are not artists.

After bouncing off of Unity the first few times, I finally decided to commit to it after trying out some of the JS game frameworks (like Phaser)

Absolutely worth it, have made lots of games in Unity just for myself that feel pretty polished, there are just so many systems to make a game work.

The advice around game engines kind of seems like "to learn how to write programs first create the compiler.

Not to say all games should be made in engines but it certainly helps.

Arguably the reason is making a game engine is easier than making a game. Obviously creating all of Unity/Unreal is a ton of work. But, to make a game engoine you have a checklist of features (gameloop, rendering, audio, input, ...) each of which you can break into smaller features. It gives you a free todo list, each item on the list has generally known solution, and makes it feel like you're making lots of progress as you check things off and see systems come up. That progress feels great. And you are making progress but you're making progress making a game engine, not a game.

A game on the other hand is a blank sheet. There is no checklist. It's way harder to make progress on a game.

Oh yeah my bad LOL. Yup that's the one.

> Defold is definitely not ultra-light

Defold ships as a ~2MB executable, is designed for lightweight performance on non-cutting-edge mobile devices, and focuses on portability with a commitment to never require any build tooling. Professional game developers and hobbyists alike very much consider it a lightweight platform, but you're welcome to disagree with them.

> I'd 100% pick a "fantasy console" like Pico-8

Ok?

> Phaser[3] actually IS regular javascript ... I don't know how much more standard JS you can get than that.

Your linked example starts with `class Example extends Phaser.Scene` as the base for everything, then fills it with gems like `this.physics.add.image(400, 100, 'logo')` ... For your colleagues' sake, I truly hope that's not the sort of "regular javascript" you use at work.

This looks great! I hope you will be able to get back to it