OsrsNeedsF2P

Hey friends! Ex-Unity dev here. Today I've finally launched a game - it's not a good one, I made it in a few weekends, but it's my first launched game with Godot.

Play Blob Jump Multiplayer!

My Situation

• Unity is anti-developer, toxic, and slowly dying. I do not want to continue investing time into learning this game engine.
• I no longer work in the game industry, so making games will be weekend projects from here on
• To maximize fun and minimize friction, I want to make multiplayer, browser based games only. I have no interest in making singleplayer games or games that require a download

Initial Concerns with Godot

• Godot is not as optimized as Unity. I was worried about this, but then I didn't code my game like a monkey, and the profiler is great. This turned out to be a non-issue in any prototype I created.

Godot Frustrations

• The biggest frustration point I experienced with Godot has been errors that have no GDScript stack trace. It is very annoying to be told some Node can't access some Null feature or whatever and have no stack trace
• I've hit quirky edge cases with Godot physics. These are mostly remediated with Godot 4.5-dev, so I am running Godot compiled from source rather than a released edition.

Fresh Air

• Every issue I've run into with Godot has some open source issue tracking it. In Unity, you would see ignored threads for years. In Godot, the maintainers are actively responding, people are giving workarounds, and in some cases, community members are fixing the issues themselves!
• Godot loads fast. Unity projects can take >1 minute to load; I did not expect how much more productive it would make me to have a fast editor that doesn't break my focus
• Godot 4's multiplayer system is fantastic. The way it handles multiplayer.is_server(), is_multiplayer_authority, MultiplayerSpawners, MultiplayerSynchronizers and RPCs is at least 2x better than Unity as far as code simplicity, debuggability, and learning time

Multiplayer and Web Issues

• I originally wrote my game with ENet. Turns out that's not supported in the browser, and I had to switch it all to Websockets. Thankfully this was easy
• I bought my server of Hetzner (shoutout cheap EU cloud provider). To save money, I went with IPv6 only, which Github doesn't support, and Godot releases their binaries on Github. This was annoying, and after a few other IPv6 issues, I ended up buying an IPv4 address
• While originally prototyping to process inputs on the server, I chose to process inputs on the client in this game for a better UX. This actually resulted in a worse UX, since now the client needs to calculate player physics, which causes all sorts of issues if the client lags.
• The game wasn't connecting to the server when I ran it on itch.io - But there were no errors! I reasoned out that Itch.io uses HTTPS, so I configured to Nginx to handle SSL encryption and it started working.

Godot Dev Tips

• Watch Youtube guides. They are amazing
• Type your variables. It's borderline impossible to do complex things without strong typing.
• Spend 30 minutes learning the debugger. That thing is golden.

Next Steps

I enjoy writing games in Godot more than I enjoy playing Runescape (but I'm horribly addicted to Runescape so I can't stop). I've only scratched the surface, and hope to keep making more games. Thanks a ton to all the devs and the great community who make it what it is :)

cross-posted from: https://lemmy.ml/post/33319577

1. Running Good 1:1 Meetings

"I don't know how to start", "This solution won't work" and "I'm going to do X" are all bad examples of how to talk to your manager (or anyone). When you're talking with other people, you are having the privilege of leveraging their experience to solve your issues.

Problem --> Solution --> "What do you think?"

First, clarify the problem. If you tell (i.e. your manager, but it can be anyone) a solution, they won't know if it's the best way to solve the problem.

Second, tell your manager what your current plan is. Having an existing plan makes the next step much easier for your manager, and makes you look somewhat competent.

Third, ask your manager what they think. Maybe they'll tell you, "Yep, makes sense". Maybe they'll tell you to tweak it. Maybe they'll give you a completely different direction. Maybe they'll ask you why you're even solving that problem, and to go do something else.

I used to hate 1:1s. I had no idea what to talk about. Now, I gather a few of these questions throughout the week, and add it to an agenda. My manager regularly thanks me for having a productive session.

2. Make a Good Plan (& Real Prioritization)

What is the problem you're solving? Why is this an important problem? How do you know when you will have solved it? How are you solving this?

Start every project with a doc explaining these 4 things in under 2-3 sentences. Until you communicate this, you do not have a plan, and you do not have a project.

It's an uphill battle if you cannot do this. I run the System Design Club at Meta. My skip told me it counts as E4 (not Senior level) at best - because it's not solving a real problem.

3. Review Work Better

Everything we talked about above is applicable to how you review other people's work too.

First understand the problem, then understand the solution. Ask questions that make it clear the solution addresses the problem.

When reviewing plans, ask how you know they will be done ("How do you know when you will have succeeded?"). Be sure it's clear how it will be done (no "draw the rest of the f**king owl" memes) - Ensure all the steps, if followed, will resolve the problem. Ask for timelines so you can hold them accountable.

When reviewing code, your goal is to make sure the new code solves the problem, and doesn't add new ones. Don't nit about style, instead call out a problem that arises from their style ("If someone changes ABC, they won't know this breaks"). Don't assume a bunch of logic you don't understand works; ask "How do you know this is going to work?".

4. Being supportive in your messaging goes a long way.

Any time someone asks a question, I preface by saying "Good question - [...]" (ofc I change up the style). This keeps them asking more questions. Whenever giving critical feedback, I start by calling out the good work that was accomplished. This keeps the other person motivated.

I first learned this trick when developing in open source, but saw it pay dividends at Meta. I had one contributor who was writing 90% of the project code - I would continuously praise their PRs and talk about how great they were. When I stopped doing that for about a month, that contributor noticeably dropped off. For some people it's support, and for others it's ego. But it keeps them working hard.

5. The Reality of Looking Good - and Failure

If you are doing well, people will want you on their projects. If you're stuck or confused, they will assume you tried your best, and it's the problem that is hard.

A good engineer might fail a project from time to time, but they have clear and notable success stories too. If you have only failed projects, you are a bad engineer.

Not only do people enjoy helping good engineers - Bad engineers get the plug pulled.

Despite a supportive culture, I have been explicitly told to stop helping person X, because person X is not worth helping. Person X is later removed from the company.

The advice here is to start strong. If you start strong, you will get the support you need to thrive. If you are currently weak, you need to do everything in your power to get strong - Things will naturally feel easier when things are going well, since other people will be helping you.

This post is dense information. Do not expect to walk away remembering all of it. But pick one that applies to your weakness the most - Think deeply about how it can be applied. Then get better.

1. Running Good 1:1 Meetings

"I don't know how to start", "This solution won't work" and "I'm going to do X" are all bad examples of how to talk to your manager (or anyone). When you're talking with other people, you are having the privilege of leveraging their experience to solve your issues.

Problem --> Solution --> "What do you think?"

First, clarify the problem. If you tell (i.e. your manager, but it can be anyone) a solution, they won't know if it's the best way to solve the problem.

Second, tell your manager what your current plan is. Having an existing plan makes the next step much easier for your manager, and makes you look someone competent.

Third, ask your manager what they think. Maybe they'll tell you, "Yep, makes sense". Maybe they'll tell you to tweak it. Maybe they'll give you a completely different direction. Maybe they'll ask you why you're even solving that problem, and to go do something else.

I used to hate 1:1s. I had no idea what to talk about. Now, I gather a few of these questions throughout the week, and add it to an agenda. My manager regularly thanks me for having a productive session.

2. Make a Good Plan (& Real Prioritization)

What is the problem you're solving? Why is this an important problem? How do you know when you will have solved it? How are you solving this?

Start every project with a doc explaining these 4 things in under 2-3 sentences. Until you communicate this, you do not have a plan, and you do not have a project.

It's an uphill battle if you cannot do this. I run the System Design Club at Meta. My skip told me it counts as E4 (not Senior level) at best - because it's not solving a real problem.

3. Review Work Better

Everything we talked about is applicable to how you review other people's work.

First understand the problem, then understand the solution. Ask questions that make it clear the solution addresses the problem.

When reviewing plans, ask how you know they will be done ("How do you know when you will have succeeded?"). Be sure it's clear how it will be done (no "draw the rest of the f**king owl" memes) - Ensure all the steps, if followed, will resolve the problem. Ask for timelines so you can hold them accountable.

When reviewing code, your goal is to make sure the new code solves the problem, and doesn't add new ones. Don't nit about style, instead call out a problem that arises from their style ("If someone changes ABC, they won't know this breaks"). Don't assume a bunch of logic you don't understand works; ask "How do you know this is going to work?".

4. Being supportive in your messaging goes a long way.

Any time someone asks a question, I preface by saying "Good question - [...]" (ofc I change up the style). This keeps them asking more questions. Whenever giving critical feedback, I start by calling out the good work that was accomplished. This keeps the other person motivated.

I first learned this trick when developing in open source, but saw it pay dividends at Meta. I had one contributor who was writing 90% of the project code - I would continuously praise their PRs and talk about how great they were. When I stopped doing that for about a month, that contributor noticeably dropped off. For some people it's support, and for others it's ego. But it keeps them working hard.

5. The Reality of Looking Good - and Failure

If you are doing well, people will want you on their projects. If you're stuck or confused, they will assume you tried your best, and it's the problem that is hard.

A good engineer might fail a project from time to time, but they have clear and notable success stories too. If you have only failed projects, you are a bad engineer.

Not only do people enjoy helping good engineers - Bad engineers get the plug pulled.

Despite a supportive culture, I have been explicitly told to stop helping person X, because person X is not worth helping. Person X is later removed from the company.

The advice here is to start strong. If you start strong, you will get the support you need to thrive. If you are currently weak, you need to do everything in your power to get strong - Things will naturally feel easier when things are going well, since other people will be helping you.

This post is dense information. Do not expect to walk away remembering all of it. But pick one that applies to your weakness the most - Think deeply about how it can be applied. Then get better.

I've got some great Linux swag from Ubuntu Korea, but I've been looking to buy new clothes lately and would love to rock more FOSS.

I see a couple websites that sell FOSS branded clothing, but does anyone have good experience buying high quality hats/tshirts/sweaters/active wear from any of these online retailers? Bonus points if the retailers donate proceeds to development

Like 75% of the candidates are cheating, and it's so obvious. It's a shame because even if I know they're cheating, it raises my subconscious bar on quality I expect from candidates.

"Oh I see you used Kafka in this design, but it appears to be pushing to your workers. Can you talk to me in a bit more detail about how this works?"

(note: You're only getting this question if you used Kafka to solve my problem. The answer is the workers pull off Kafka and store their own offset, or Kafka stores it in the case of consumer groups)

proceeds to read off the encyclopedia for Kafka

"that's great.. but explicitly, how are your workers using Kafka..?"

Thank god it was easy to convert to Websockets :)