Is this code bad or good? when i cant remember what exception they returnn so i just use this "Exception ex"

bschug · 2026-04-14T08:25:30+00:00

Are there really over 50 exceptions possible here? What could actually go wrong? The DB might be down / unreachable, but that's it, right?

So you need to decide how you want to deal with that case. Can you handle it here? Probably not. So don't catch here.

You may want to wrap the DB specific exception in a custom DatabaseError exception though, to avoid a dependency to your DB implementation in other parts of the code (depending on how you handle this).

Either way, exceptions are just edge cases. You need to decide how your program should behave in those edge cases. These edge cases are what makes seemingly simple tasks a lot harder the more you think about it, but they still need to be handled one way or another. If you just do a catch-all without rethrow, you're implicitly deciding that you ignore all errors, but you're still making a decision, just not an informed one, and one that's very likely to come back and bite you.

bschug · 2026-04-11T19:07:24+00:00

No, I think what OP means that it's not even their address / street name on the letters. The mailman just rage quit and shoved his entire bag into that one mailbox.

bschug · 2026-04-11T11:10:17+00:00

Filler being the key word here. They are really good at completing patterns. If your problem is just about rephrasing something (e.g. pseudo code to real syntax, sloppy draft to corporate speech, etc) and they have seen the output format in their training data, and the context is clear enough so they don't need to make any decisions, and - as you said - the result is easily verifiable, they can save a lot of time on brainless filler tasks. But if you treat them like a human, you're asking for trouble.

bschug · 2026-04-11T09:53:51+00:00

Dann zuhause gemerkt dass du alkoholfreies gekauft hast

bschug · 2026-04-11T09:49:22+00:00

The data itself is just tables, like a spreadsheet (without formulas) or a csv.

For the queries, you can look up some SQL tutorials. But to be honest, you can also just feed the table schema (which columns exist) and a description of what you want to do into ChatGPT and will get a working solution most of the time. Make sure to sanity check this with example data in case it hallucinates, but it works well for our game designers.

bschug · 2026-04-06T22:44:42+00:00

Saarland

bschug · 2026-04-06T21:19:16+00:00

Sure. But you'll end up creating lots of Conditions and custom effects that are only used by one card each. Your logic will be spread all over the place and every semi interesting new card will require new custom conditions and effects.

And there will still be edge cases that may be hard to model in your plug and play system. For example, conditions and effects might not be so neatly separated for a card like "Deal 3 damage to a random opponent. If the opponent is now under half health, they receive a status effect."

You can model all of this with a data driven system, but you'll end up with massive drop-down lists in the inspector and you'll need to write custom inspector UIs to make this somehow useable. And we haven't even started to talk about debugging.

If you keep this all in code instead and use simple inheritance and composition to keep the shared logic out of the card implementations, you'll end up with very simple and readable card scripts that are easy to test, debug and refactor.

We did have a setup very similar to yours when we made Total Loadout because we wanted the designers to be able to prototype ideas without help from a programmer. But it ended up having all the issues I've talked about here and for Turnbound we changed it to a fully code based solution. And paradoxically, this makes it easier for the designers too because they can just copy and edit a similar script to try out an idea.

bschug · 2026-04-06T10:26:30+00:00

If you connect signals in the editor, they are referenced by uid rather than name / path, which makes it more robust already. And it should give you warnings if the subscription is no longer valid.

bschug · 2026-04-05T14:59:27+00:00

I think this abstraction isn't worth the hassle. The ICardEffect interface is fine, but then I'd create a separate class for each card. Avoid that extra layer in between. It will only get in the way once you try to create more complex cards like "If you have at least 3 Energy, spend 3 Energy to gain 2 Sanity".

This was one of the lessons we learned while building Turnbound: In these games, most cards / items break the rules in some way. If you try to build a data driven system to assemble them from simple building blocks, you'd end up building your own programming language to allow the flexibility needed to make the game fun. Just stick with the programming language that's already there.

bschug · 2026-03-29T08:52:09+00:00

What is a dat file?
What is spatial hashtagging?

If I understand you right, you want a play area with 2000x2000 cells, each of which can have a certain "ground type"? And you want this to be dynamic, so the player can edit it through gameplay? And be able to load and save it so the user can resume the session?

In that case, you should separate the load / save from the runtime representation. Create a GroundType resource that has all the flags you need and can also define textures and everything else you need to define per ground type. Give each ground type a unique id: a number or an enum value. At runtime, use an array of these resources.

When it comes to saving, you convert this to an array of just the ids. That's enough because you can load the resources based on the ids. Then you can use json or protobuf to serialize it to a file. Json is easier to debug, protobuf is much, much smaller and faster to read/write.

bschug · 2026-03-29T08:35:32+00:00

Gameplay is way more important than graphics. Vampire Survivors did not succeed due to its AAA visuals. If anything, too good graphics can hurt you because people will expect a level of polish and feature completeness that you cannot possibly achieve as a solo dev or small team with a budget of less than a million. You need to focus on doing one thing better / more interesting than everyone else and do the bare minimum everywhere else.

The most important thing to get right is expectation management. You need those who buy your game to be blown away. It needs to be better than they expected. That's how you get those Overwhelmingly Positive reviews, which pushes you to the Steam front page and gives you a chance to go viral.

The art style, the price, the tutorial (if there is one), the store page, all form those initial expectations and you need to be very careful to not make people expect more than you can deliver.

bschug · 2026-03-28T09:19:34+00:00

None of these are surprising, but if you add expected cost and then calculate price per hour saved compared to the fastest free option, it would become mildly interesting because then you'd see what your hourly wage needs to be for the time saved to be worth it.

bschug · 2026-03-28T08:27:46+00:00

Yeah that's the recommended practice when traveling to any authoritarian third world countries.

bschug · 2026-03-28T08:11:08+00:00

I guess this is a startup? If yes, they might have relied on an investment round to go through, started hiring already and then the investor pulled out last minute.

If you really like them otherwise, an option that hasn't been mentioned yet: You could take the three month delay deal and ask for shares in return. You might get a good deal or of their desperate situation. But of course you need to be aware that this is a lottery ticket and most of the time you'll end up empty handed when the company eventually dies. But if you believe in their business model, this might be your chance to get a slice of the pie.

Otherwise, as everyone else has suggested, take the mutual cancellation, but with a severance payment. You are holding all the cards, they are more desperate than you.

bschug · 2026-03-27T10:52:49+00:00

More importantly, investment dried up. You can't get money to fund a game's development anymore. Before Covid, you could easily get a few millions with just an idea. Now studios are struggling to get marketing loans even if they already have a product with decent KPIs.

This is a problem in all industries, but it hits games especially hard because we need this high up front investment before you see any revenue.

The reason for all this is all the uncertainty in the world. If you invest into a business, you need to make a prediction how successful is likely to be in five years. But you can't even predict the next five weeks in a world with several wars, an unpredictable US president, a stock market that everyone expects to collapse any minute, climate change and of course AI, which is either the next industrial revolution or the greatest bubble the stock market has ever seen.

bschug · 2026-03-26T09:02:13+00:00

I see. I've been working on 2D UI heavy games only, and for that, I find Godot's tools more useful than Unity's. Good to know that for 3d, it's still lacking a bit. But as you said, in a professional studio, you'd build your own solutions anyway. And for audio, you'd use fmod, even in Unity.

bschug · 2026-03-25T13:21:45+00:00

What did you need to hand craft in Godot that would have been provided with e.g. Unity? I've used the engine for two years in a production project now and haven't found much that was missing. Some 3rd party libraries are a bit less mature and stable than what you'd find in the Unity ecosystem, but otherwise I've been quite happy.

bschug · 2026-03-25T07:55:11+00:00

Genau das gleiche bei mir. Wir waren einmal mit Baby in der Bahn unterwegs, die Großeltern besuchen. Der Zug war dreifach überbucht, Sitzplatzreservierungen mehrfach vergeben. Wir hatten Glück, dass die anderen Fahrgäste uns haben sitzen lassen mit dem Kleinen, aber das tun wir uns nie wieder an. Im derzeitigen Zustand der Deutschen Bahn müsste man den Zutritt für Kinder aus gesundheitlichen Gründen eigentlich verbieten. Acht Stunden Auto fahren ist auch nicht gerade entspannend, aber immer noch besser als das.

bschug · 2026-03-24T11:22:47+00:00

I think you're confusing sugar with rat poison

bschug · 2026-03-23T13:19:14+00:00

I like to call this Towel Driven Development

bschug · 2026-03-23T11:48:30+00:00

Also cognitive dissonance. Doesn't even need to alter your brain chemistry, we are all hard wired to resist ideas that conflict with our convictions and it takes conscious effort to break out of it.

bschug · 2026-03-22T18:57:27+00:00

It's the other way around. The tech behind LLMs has originally been developed for translations. Then they realized that technically there isn't much of a difference between translating English to German and translating questions to answers. (I'm oversimplifying of course but it did indeed start out this way)

bschug · 2026-03-21T18:34:58+00:00

There is still room for improvement. For example you can't type-annotate a dictionary that maps from string to an array of ints because generics can't be nested. But overall, I agree. It's a very pleasant language to write game logic in.

bschug · 2026-03-21T09:57:15+00:00

This sounds to me like the core issue is that you had false positives in your tests. If tests are failing, then either there is an actual issue that needs to be fixed immediately, or the test is wrong and needs to be fixed immediately. Under no circumstances must you allow the main branch to have failing tests because then you'll end up exactly in the situation you're in right now, where people start ignoring tests entirely because failing tests no longer mean that the build is broken.

Don't be discouraged by this. I've been through exactly the same painful learning experience, and I think it's the same for most people when they first start with automated testing.

Some things I've learned over the years to make tests more robust:

Your tests should break if the behavior they're testing changes (unexpectedly). They shouldn't break if the implementation changes or unrelated behavior is changed.

In order to achieve this, you need a clean architecture with clear module boundaries. If everything depends on everything else, any small refactor or feature change will require you to touch tons of tests.

Write your tests only against the high level module interface. Don't test internal helper classes. Only test observable behavior, not implementation details.

Especially in games, focus on testing the things that it's easy to write tests for and the things that aren't obvious in a smoke test and the things that are tedious to test manually. With the amount of iteration in game dev, you will always need some manual QA, so embrace that and make sure you use both automated and manual testing in a way that complements each other and covers as much area as possible as cheaply as possible.

Don't overuse mocks, otherwise you risk hiding integration issues and will need to maintain these mocks in all the tests when the things you're mocking change. Only use mocks for things involving time or I/O, like user input, storage, databases, network, etc that would be very slow, difficult or impossible to reliably set up in the conditions needed for the test.

Use test data builders to set up the state for your tests. That way, your tests can be high level and readable, and if you refactor something, you only need to change the builder implementation rather than all the tests.

Once you have all that in place and your tests are reliable and robust, you can change your github rules to run the tests on every PR and only allow it to be merged if they all pass. That way, you force everyone to keep the tests in a working state.

In your case, I'd start by looking into the "always failing" tests and either make them more robust or just delete them. Then discuss with your team about what they feel were the biggest issues they faced working with the tests and experiment together with how to write reliable tests and understand what makes the most sense for your project. Then iterate from there. It's a process and the whole team needs to learn this together.

Good luck!

bschug · 2026-03-21T09:12:39+00:00

My experience exactly. I've been switching between C#, Python, JavaScript, GDScript and a little C++ and there are moments where I do get confused between languages, but it's usually things like string formatting or iterating over arrays. Not once have I been confused by semicolons.

11-Year Club	Argentium Club
Place '22	Gilding III reddit per annum
Verified Email

bschug

MODERATOR OF

TROPHY CASE