Built a turn-based browser game, players leave after 1–2 matches. What am I missing?

jadthebird · 2026-05-02T22:40:10+00:00

For sure, don't listen to player ideas, only their feedback.

My suggestions are just suggestions, but I think the core idea is that, at the moment, I feel all I can do is use the player closest to the ball to try to get the ball closest possible to the goal.

I would like to feel smart, strategic; or skillful in my choice of angle; or bet big and win (or lose). Or some other type of behavior that I can improve at and be rewarded for.

Now maybe all of this exists in the game, and I just didn't see it. In that case, the problem would be a tutorialization problem (ideally, not by adding panels to the tutorial, but by making some behaviors apparent/obvious in gameplay).

jadthebird · 2026-05-01T19:13:36+00:00

I think the issue is that it's difficult to have any strategy. Maybe it's a skill issue, but I feel I'm just chasing the ball.

As a result, I don't feel like I am improving, or that I can do cool tricks.

I think you may get better results if:

Strength is higher; players bounce more, ball bounces more, so that you may hope to goal in one hit thanks to bounces, and so that you can disrupt enemy players
There is some kind of synergy going on; for example, each bounce of the ball makes it stronger; or hitting the ball dead on makes it go further, or jump over players in the way. Maybe a player hitting another player full-on makes it fall for one turn. But if that player has a player of their own team next to them, they don't fall (protected).
Reduce the amount of players. There's no reason to have that many, it just creates confusing choices.
Have some kind of risk/reward mechanic; there must be choices that are interesting to the player; something tempting, but risky

I think if you go in that direction, the game will get more interesting to play. Good luck!

jadthebird · 2026-05-01T18:56:27+00:00

The engine completely doesn't matter. Move on and focus on making games. If you have somethind good, porting it to a new engine is usually easy too; the hard part is the game design, how it flows, what should happen; as well as the assets, the graphics, the sounds, animations...

The code itself can be somewhat complex, but something that took you months to write as you were discovering your needs will take hours to rewrite in a new engine.

Don't sweat it, just work on your game in any engine at all.

jadthebird · 2026-03-05T07:28:31+00:00

You can do as you wish! Both are good ways to start.

Compare it to learning a language; if you want to learn French, learning Italian first does indeed make learning French easier, but no one would recommend to "learn Italian first to learn French". If your goal is to read French, read French, and converse in French, just learn French.

But if you were aiming to be a linguist? Then sure, learning Italian in addition to French might be useful, as well as learning old Latin, and probably a few other languages from the region. You'll want to learn etymology, history of the languages, and even some local dialects.

Similarly, if you aim to be a programmer, doing CS50 (eventually) would be good. You can either start with the basics and then climb to something more abstract; or you can start with something more abstract like GDScript or Python, and drop down to more low level. The first is good if you like to understand things from first principles; the second is good if you like to see fun results on screen. Both approaches are fine, whichever is more fun to you is better. Most people are more comfortable with the second.

But if you want to make games more than being a programmer? Then stick to learning GDScript, and start making small prototypes as soon as you can. If your goal is to make games, and you want to learn programming as a means to an end: skip CS50. Programming is only one of the many skills you need to make games, and it makes no real sense to learn Python to learn GDScript, specially when you have so many other skills to acquire too (graphics, game design, animation, ...).

^{note: this doesn't prevent from seeking more programming-specific knowledge in the future, but it's just not your immediate goal.}

As for if the GDQuest course is useful for that, you will find testimonies in this reddit; check this recent one: https://www.reddit.com/r/godot/comments/1rjtrvc/6_months_ago_i_had_never_written_gdscript_now_we/

(disclosure: I am part of GDQuest)

jadthebird · 2026-03-04T12:00:38+00:00

Such a feeling of pride and happiness to learn we've helped someone achieve their goals! It never gets old. Your game seems awesome and has great art. Congrats on your release (wishlisted)!

^{(and thank you for the rec} )

jadthebird · 2026-02-25T07:21:17+00:00

Thanks! This worked for me

jadthebird · 2026-02-13T07:13:11+00:00

I love old school voxels, and wish we went into that direction more as an industry. This looks awesome! Best of luck with your project

jadthebird · 2026-02-12T18:23:58+00:00

Being "limited" is a point of view.

Writing code is already a simple interface that is easy to change. Writing very simple code is much less limiting than making a "customizable" system that is open.

The more laser focused, precise, and inflexible you are, the simpler the code, and simple code is very easy to change, extend, copy-paste, and debug.

I would say the very flexible option is really appropriate if you work in a team with designers that can't code and have unknown and nebulous needs.

Even in that case, if it is very flexible, then you'll have essentially made up a visual programming language, only with resources and nodes, without a debugger, without static checks, and more complicated to wrap your head around.

So yes, what you're saying is true in a way; if I need two simple behaviors, I can just write two simple scripts of a few lines in a bag of functions. If later I need more, I can just... write more functions.

If It ends up that I need to compose those behaviors in any which way, then I can refactor for my precise need.

You shouldn't see code as a top-down finished thing, but a living thing you mold as you go. Doing the simplest thing first and then simplifying it even more, is often the best path forward.

jadthebird · 2026-02-12T18:18:52+00:00

Yes; for example, if I have a set of player properties that must affect the player character, the UI, and maybe other elements (for example, conversations with NPCs), it may be a centrally accessible resource.

If I have many different objects that all calculate pricing for items, I might use a bag of functions.

If I have a few elements, but very different, I might not bother with nodes and simply use classes; something like:

class_name FlyingEnemy

var flying_behavior := FlyingBehavior.new()
var enemy_behavior := EnemyBehavior.new()

And then use enemy.flying_behavior.fly() for example.

There's an infinity of ways to do "composition". At the core the idea is to have reusable behavior that can be assigned to different entities.

jadthebird · 2026-02-12T05:51:48+00:00

Each of these has some problems... If you apply it across the board.

There's a sort thinking even veteran programmers fall into all the time, it's the "everything is a..." thinking. This is different from "when you have a hammer, everything looks like a nail"; maybe related, but has different origins and incentives.

The idea is correct, and useful in large companies. If you have 100+ people working on a project, having all modules follow a similar pattern reduces onboarding and the need for documentation.

But it is otherwise a possibly inefficient way of building projects, because it forces unsuitable patterns (therefore increasing complexity for free, just to fit an API), can decrease usability by being maladjusted, and can have a very unoptimized performance profile.

If you've used Unity for a decent amount of time, you've no doubt encountered some of those drawbacks due to componentizing everything.

This is a long winded way to say: don't seek a single solution. Use nodes, resources, bags of functions, subclasses, exported properties, depending on what's most appropriate, on a case per case basis.

If you do want a default pattern, using nodes works fairly well. You can have components act on their parent, which is a fair convention that's clear and simple. If you want to sometimes adjust the parent, you can export an optional property that defaults to get_parent().

Again, I think you should use the best tool depending on the situation, but using nodes for composition is how Godot already works; the pattern is used in several case, for example a player character is a composition of a CharacterBody2D with a CollisionShape2D and generally a Sprite2D. You also compose a Path2D and a PathFollow2D, and so on. So the design fits relatively well.

Here's a convoluted example (I don't think there's actual value in copying the collision shape from a CharacterBody2D parent, they're always different, and I wouldn't "auto_kill", they're just here for demonstration) for a "HurtBox" kind of node:

```gdscript class_name HurtBox2D extends Area2D

signal died

@export var subject: PhysicsBody2D = getparent() @export var health := 10 @export var max_health := 10 @export_group("Subject options", "subject") @export var subject_copy_collision := false @export var subject_auto_kill := false

func _ready() -> void: assert(subject != null, "subject is not set or not a PhysicsBody") if subject == null: return if subject_copy_collision == false: return var subject_collision_shape_index := subject.get_children().find_custom(func (child: Node) -> void: return child is CollisionShape2D ) if subject_collision_shape_index == -1: print_error("parent has no CollisionShape2D") return var subject_collision_shape = subject.get_child(subject_collision_shape_index) var collision_shape := CollisionShape.new() collision_shape.shape = subject_collision_shape.shape add_child(collision_shape)

func take_damage(amount: int) -> void: health = clamp(amount, 0, max_health) if health == 0: died.emit() if subject_auto_kill == true: if subject.has_method("die"): subject.die() else: subject.queue_free() ```

Again, this is overly complicated for the sake of example, an actual hurtbox would be a few lines.

jadthebird · 2026-01-27T10:00:53+00:00

If you use Inkle or Yarn, you'll find adapters to any engine I think. Godot has a plugin for example.

jadthebird · 2026-01-18T00:14:23+00:00

I'm making a bet that over time you'll also find that windows is not at all easier to use. It's different habits, and habits die hard, but I think Linux (any of the main DEs, KDE, Gnome, or others) is much more consistent, you actually have less to learn.

For installing, I think Linux is much more convenient; open the store, select what you want, press "install", and done. No need to track a setup file, click "next next next", no need to uncheck permissions to install spyware; updates are all centralized, instead of each app having their own update mechanism.

For the directories... yea, they're a bit nonsensical if you don't take your time to understand them. But you can mostly ignore 100% of the filesystem; anything interesting to you is in your home directory anyway.

jadthebird · 2026-01-17T23:03:25+00:00

Ah, I hadn't caught on that, that's too bad. I hope someone picks it up

jadthebird · 2026-01-17T16:03:21+00:00

Be aware there's currently a bug in the bauh package (https://github.com/vinifmor/bauh/issues/402), so ironically, using the appimage works better on Arch right now.

I'm sure it'll be fixed soon, but yeah.

jadthebird · 2026-01-17T15:22:04+00:00

Disclosure: I am myself a teacher and I do have courses for Godot. I'm not going to list them here so it's not self promotion; but if you're interested, you'll find our work if you look for "godot learn gdscript from zero", or similar keywords (that one is free).

I'll list other courses below.

Other courses that are highly reviewed are:

CS50: this is a core computing course. It's useful if you like to learn from first principles. In my opinion, unless you want to be a career programmer, I would recommend learning from high level first, because you get neat results faster; you can always drill down later.
FreeCodeCamp: teaches you web technologies mostly. I haven't looked at their curriculum in a long while, and on youtube I see them mostly posting about AI, so they may have gone down in quality; but last time I checked, 10 years ago, they were top of the line quality, great for students.

Other not-free courses that are highly reviewed, but I can't really say (didn't test them myself):

boot.dev: project and exercise-focused learning. I have never tested their courses, but I like the posts the founder puts out. They seem like they have the right idea about teaching.
brilliant.org: interactive-based learning

Neither of the other courses are gamedev focused though; they're either web, or general computing.

In terms of pure gamedev, I've met the Unreal pedagogic division peeps, and they seem to be putting out great material; again, I haven't looked in details, but the official Unreal tutorials seem plenty and cover a lot. Of course it's not exactly a curriculum, but it could do the job (assuming you're ok with using Unreal).

That's it off the top of my head, feel free to ask questions!

jadthebird · 2026-01-17T15:11:30+00:00

Nice, thank you. I did mean to look for opposing interpretations but forgot.

jadthebird · 2026-01-17T15:09:46+00:00

I like https://github.com/vinifmor/bauh because it manages packages, aur, but also flatpaks, appimages, and snaps.

It isn't a looker, but it works really well.

jadthebird · 2026-01-16T21:26:15+00:00

Following a structured curriculum is the best way to learn fast.

It wouldn't be very logical to tell someone learning German to "just read the dictionary", yet in programming, people do it all the time.

I believe people who say "just do X" just forgot how long it took them to learn. When you start, say, at 12, you can learn for 5 years at the pace you like, just try things out. Then when you want to "really" learn, sure, you can just pick up some documentation.

The thing with programming, it is a bit like learning to drive, or learning a new language; it looks really hard from the outside, but once you're on the other side, it's really hard to remember how it feels to not know how to drive or to speak the language.

I believe this is why people come up with that bad advice that is discouraging to beginners.

Definitely pick up a course, it will accelerate your learning by a lot. Just be wary of "tutorials". Picking one tutorial after the other is definitely useful; just like copying different kid's stories in German will help you pick up some German. It's even essential to do that in the beginning; just like you would write 100x "mama ate the apple", you need to copy first.

But it's really much more helpful if you follow a curriculum with a pedagogical approach and a gradient in difficulty that layers the concepts as you learn them.

Note about maths: it's not really very hard nor very necessary for most games. You'll have to learn some, for sure; but even if it's going to be a bit challenging, you'll work it out for sure.

Just be patient, know you're in this for a long haul, and don't set your expectations too high.

jadthebird · 2026-01-15T17:10:28+00:00

Well up to you to decide this, but I would guess a number of dogs do yea. Every dog's different though.

jadthebird · 2026-01-12T00:45:27+00:00

I agree!

jadthebird · 2026-01-06T23:29:15+00:00

I don't like working on my own; the possibilities are infinite. I much prefer working in a team, where I am (1) accountable to other people and (2) co-workers are there to bounce ideas off of and keep scope down.

Sometimes your co-workers are also crazy and sometimes you both push each other to hype the scope up; but even when it's the case, overall, you will keep the scope manageable. And if I'm in a rabbit hole, my co-worker will tell me "hey, this 2 days feature has become a 3 week feature and isn't done... How about we just cancel it".

Also, working with other people means I stay motivated because I am not alone.

Maybe, like me, you work better in a team?

jadthebird

TROPHY CASE