Starting game development in JavaScript with no experience(jslegenddev.substack.com)
jslegenddev.substack.com
Starting game development in JavaScript with no experience
https://jslegenddev.substack.com/p/how-to-start-making-games-in-javascript
47 comments
I'm confused by your advice, honestly. Defold is definitely not ultra-light, it's a whole ide/studio engine. If I was recommending for ease of entry, I'd 100% pick a "fantasy console" like Pico-8[1] or one of the many alternatives[2] that are free and use a different language if Lua isn't the person's thing.
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)
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 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.
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.
>However, as opposed to using an engine like Unity, Godot, Unreal, using a frameworks still allows to you architect your codebase with a greater degree of freedom and prevents you from spending too much time learning how specific game engine workflows and UIs 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.
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.
Exactly right. That’s why the joke “There are 100 game engines written in Rust… and 5 games” is so funny. Programming nerds love the engine stuff more than the art stuff. I know I fall in to this category.
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.
A game on the other hand is a blank sheet. There is no checklist. It's way harder to make progress on a game.
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.
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.
[deleted]
[deleted]
This is like those learn how to draw tutorials with the owl…
For me, the "owl" was all the polish and game feel. "The art of screenshake" by Jan Nijman of Vlambeer [0] was what helped fill in the steps to "making the owl".
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.
[0] https://www.youtube.com/watch?v=AJdEqssNZ-U
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.
[0] https://www.youtube.com/watch?v=AJdEqssNZ-U
The video that inspired that one
https://www.youtube.com/watch?v=Fy0aCDmgnxg
https://www.youtube.com/watch?v=Fy0aCDmgnxg
I've seen it. For some reason, the Vlambeer one really hit home for me, whereas that one fell flat. It's not that they're saying fundamentally different things, it's that the Vlambeer one shows it better.
There are very few game development tutorials which aren't how-to-draw-an-owl and I'm not fully sure why.
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.
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 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/
https://nluqo.github.io/broughlike-tutorial/
"Game development", "javascript", and "no experience" is quite the combination.
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.
For the record, Godot has a pretty permissive license and can export to the web. It also has JS/TS bindings iirc. Definitely worth a look if you're interested in getting deeper.
I've been working on improving Godot's TypeScript development experience:
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...
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...
I'd say any beginner should start with P5.js first before going into larger game dev frameworks. You can make simple games and the API is very approachable.
Fyi if you're interested in making games on the web / with web tooling join the Web Game Dev Discord (we're over 2k devs in there).
You didn’t include a link but I assume it’s this one.
https://www.webgamedev.com/
As it matches the name and has a discord channel with about 2000 members.
https://www.webgamedev.com/
As it matches the name and has a discord channel with about 2000 members.
Oh yeah my bad LOL. Yup that's the one.
> Stick to 2D, Since 3D is More Complicated
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.
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.
I think that statement can only be said with the right context.
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).
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).
And how did this illustrate that 3-D is not “More Complicated”?
2D games can require a lot of assets. And most programmers are not artists.
Also, 2D assets are much more difficult to change later if you decide you need to change the aspect ratio or scaling later on. While a tile map is comparatively technically simple, the initial choice of tile size carries a rather critical importance to how the game development process unfolds. If you want or need to change it later it is likely going to be a fair amount of work, and that friction can hinder a lot of experimentation. Compare this to a 3d camera, that affords you the ability to completely change perspective with a few lines of code, it’s evident that a 2d game is not necessarily simpler to develop in practice.
It is the exact reason why I choose to make my game in 3D.
I am making a game similar to advance wars/apes warfare in threejs.
My drawing skills are close to zero but thanks to the engineering background my CAD and 3D modeling are somewhat usable.
So I am currently learning blender to improve on top of that and I cannot fathom how much more time it would have taken me to make assets if those were to be in 2D.
Everyone is an artist. We're just not all equally skilled.
> 2D games can require a lot of assets. And most programmers are not artists.
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.
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.
Game like a short hike use rendering pipelines instead of accuracy in the models for example
[deleted]
better tooling around 3D in my opinion
That's really cool! Sounds complicated though.
I don’t want to use JavaScript /TS but I want to make games for the web. Are there any nice framework which lets me write in Rust, it compiles to WASM for web?
I’m working on something for this. It’s sort of on the back burner right now but perhaps I’ll put more time into it… https://rune.sh
Ironically web support is not in yet.
Ironically web support is not in yet.
This looks great! I hope you will be able to get back to it
I wish the software/libraries mentioned had links to them, but the only links are to more videos from the author.
Just use AI
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.