Starting game development in JavaScript with no experience
jslegenddev.substack.com
jslegenddev.substack.com
If you wanted to learn JavaScript by building games, then you should definitely not use Kaplay or Phaser, etc, since they're so far removed from JavaScript you wouldn't learn anything (other than how to build things in their particular environments). Web standard JS is more than capable of building simple games with no abstractions separating you from what you're trying to learn.
Second, Phaser[3] actually IS regular javascript. It's the opposite of Defold that is a whole node based editor thing. Phaser is just a an API you use in a script file, that you just splonk into your html page. I don't know how much more standard JS you can get than that.
[1]: https://www.lexaloffle.com/pico-8.php
[2]: https://github.com/paladin-t/fantasy
[3]: https://docs.phaser.io/phaser/getting-started/set-up-dev-env... (linked to the hello world example)
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.
If your goal is to make a game, these are exactly the things you should be learning, not reinventing your own architecture. If you just want to learn about engine internals, then sure go for it. But games (even very simple ones) are an incredible amount of effort that has nothing to do with programming. If you actually want to make one you should be working at the absolute highest level of abstraction possible so that you can start doing the real work; building the mechanics, creating the art, designing levels, writing the story, music, sound effects, etc. etc. Many of the succesful indie games these days are made almost completely via "no-code" visual tooling. It's basically a meme at this point for programmers to want to make a game and just end up wasting their time writing a naive engine.
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.
A game on the other hand is a blank sheet. There is no checklist. It's way harder to make progress on a game.
https://breaka.club/blog/godots-most-powerful-scripting-lang...
I've got a HEAP of stuff I still need to upstream
https://github.com/godotjs/GodotJS/compare/main...Benjamin-D...
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.
I think most people with reasonable know-how can make a basic game, whether it's asteroids, flappy bird, breakout, etc. For me, I never understood how to get past the "finished the tutorial" to "looks like an actual game". Screenshake, aka game feel/polish/production effects, was what made it gel.
As it matches the name and has a discord channel with about 2000 members.
This isn't necessarily the case if you are looking at total cost of ownership.
3D provides things like perspective projection, which enables intuitive experiences and notions of "world space" that are fundamentally meaningful and map well with our physical reality. You can do a lot of damage with 3d primitives, an FPS camera, a skybox and some clever lighting.
That's just as true, if not moreso, with "3" in place "2".
Conversely, 2D games can also require very little in assets. It's just a matter of what game you are making.
Building an engine from scratch? 3d is definitely more complicated.
Using an existing engine? Tbh shoehorning 2d sprite based games into engines like unreal or unity is often harder than 3d because it gets less development effort on the engine side put into it.
Asset creation? Depends - the great thing about 3d assets is you only need to model each thing once, whereas with 2d unless you're doing skeletal animation you have to draw every frame, facing direction etc.
But on the flipside creating one 3d model could take just as much time as a pixel art walk animation in 4 directions.
There's also art styles for both 2d and 3d that can significantly cut down on effort (low poly, drawing everything from absolute top down perspective, using ascii characters roguelike style, using simple 3d primitives only, first person perspective etc etc etc).
Ironically web support is not in yet.