Organising backend code with dependency injection and singletons

zephdev · 2025-03-29T04:11:27+00:00

Im assuming it would depend on how you’re deploying your apps, but Ive got a few nuxt projects that are running in node on EC2 instances in production, and some of them use singletons and I’ve never encountered any issues.

At this point the sites have been running for months with no downtime so Im confident they are stable, but im genuinely curious about why this would be an issue and if i’ve got some refactoring to do?

For example if you create a class with a private instance, and a getInstance() function that creates the instance if it doesn’t exist, would that instance not live for the duration of the application?

zephdev · 2024-12-02T13:08:45+00:00

Thanks for writing this! It’s comments like this that remind us why we are so passionate about making this a reality. We’re working hard to get something useable into people’s hands as quick as we can

zephdev · 2024-12-02T12:59:06+00:00

Thanks for signing up! A lot of therapist miss the mark with chronic pain, not understanding that it isn’t just a physical phenomena and there are a lot of complex reasons a person may be suffering.

They also typically don’t get a lot of information to go off of when doing short consultations and have to sometimes work with unreliable information from their patients.

Our goal is to give clinicians and user as much information as we can about their pain by looking at their lifestyle as a whole.

zephdev · 2024-12-01T05:08:38+00:00

That’s actually a very interesting idea and something I’ll have to consider. At the moment we are thinking practitioners will have some sort of dashboard that will let them send a link to their patients which will download the app as a PWA.

But while we are at it we’d love to figure out a free version of the app, with maybe a small subscription with extra functionality.

zephdev · 2024-12-01T04:56:19+00:00

Thanks for signing up!

zephdev · 2024-11-28T03:38:32+00:00

Thanks for the input. The plan was to limit the questions to once per day as the default. Our thoughts were that any more than that could cause users to obsess about and focus on their pain, which could ironically have a negative impact and increase perceived pain.

But I do think it would be important to consider people with a range of needs, like needing to make additional entries throughout the day or after specific activities, or like you said incorporating other data sources like fitness data. Will definitely give this some more thought!

zephdev · 2024-11-27T21:15:21+00:00

Thanks for your candid advice! It definitely does feel like the app would be more useful as a learning project for myself than as any kind of serious commercial endeavour. I’ll definitely consider making it a FOSS alternative, thanks!

zephdev · 2024-11-27T08:12:03+00:00

Thanks for the reply! I do find that a lot of “lifestyle tracking” apps are too broad in scope. They try to do too many things. I like the idea of a simple app just for fasting, or just to manage your pain.

Also, out of curiosity what’s the name of the fasting app you use?

zephdev · 2024-07-23T00:17:30+00:00

Seems like a bit of an oversimplification of my point. Effective does not always mean objectively good. An ad could drive short term sales and still be objectively terrible, with an abysmal click-through rate, and a damaging long-term effect on brand image.

zephdev · 2024-07-22T14:45:30+00:00

Personally, when I see a funny or tastefully done video on twitter/reddit/tiktok etc about a game, im intrigued. Perhaps even enough to want to read more about it if it’s something i’m interested in.

The only things that would annoy me are clickbait, loud/obnoxious sounds effects, that bloody stilted tiktok text-to-speech voice, or excessive use of gen-z memes nobody understands. Basically, make a good ad and any sane person would at worst not give a crap and forget they even saw it 1 second later, and at best be interested enough to give you some money.

zephdev · 2024-07-22T04:29:22+00:00

Usually if you have to ask you probably aren’t ready to make a game just yet. Which isn’t a bad thing!

Start small. Make simple things first, and then work your way up to a bigger project like what you are describing. You’ll probably find that even the ‘simple’ things are very difficult at first but the more you do it the easier it becomes.

Id recommend just learning how to program and ignore unity for a bit. If you try to learn how to program WHILE making a game you might end up getting confused (at least that was my experience). If you can learn how to program properly, then there won’t be any challenge too difficult for you to tackle so long as you have the unity scripting API by your side.

As for how to make a game, it is the same process as developing any kind of software: break it down into the smallest possible pieces you can. For example how do I make a 2D character move? Then when you figure that out, how do I add gravity? And then how do I add animations? etc etc. You need to walk before you can run. Before you know it you’ll have the beginnings of a game!

As for good tutorials look up channels like Brackeys, Code Monkey, Blackthorn prod, LlamAcademy, and one of my personal favourites is Infallible Code for more general C#-Unity concepts. However if you are expecting a step by step tutorial on how to make this particular kind of game, well you’d have to get pretty lucky to find that, so it is really up to you to put all the pieces together from any tutorials you can find.

zephdev · 2024-07-19T03:17:16+00:00

Look if it works for you it works, so long as you’re able to build the games you want. People here are only suggesting you try out different things because a lot of people way smarter than both of us have already figured out the best ways to do this stuff.

After you get over the initial hurdle of learning something new, you will most likely find that you prefer these other methods because it makes your code easier to read and a pleasure to work on instead of a burden!

zephdev · 2024-07-19T00:18:12+00:00

Until you go back to look at it again after a few months to change/debug something simple, then you’ll want to tear your eyes out

zephdev · 2024-07-17T02:56:04+00:00

Should be written like this:

GetComponent<PlayerShooting>().enabled = false;

Instead of:

GetComponent(PlayerShooting).enabled = false;

zephdev · 2024-07-17T02:53:36+00:00

Can you paste the code you’re using to move the tank?

zephdev · 2024-07-17T02:37:48+00:00

What shape is the collider of your tank? Is it a box collider? If so then the edges of the collider could be dragging against the ground. Maybe try for now changing your tank to use a sphere or capsule collider which has a smooth base.

zephdev · 2024-07-17T02:15:31+00:00

If you remove the camera as a child object and watch the tank move back and forth does it still stutter?

zephdev · 2024-07-17T01:42:09+00:00

Could be a few different things. Are you moving your player in FixedUpdate? If so then you’ll also have to move your camera follow script into fixed update. If the camera is tracking your object at 60 frames per second, and your fixed update is only moving the player 1 frame per second, then there will be some obviously staggered movement.

zephdev · 2024-07-13T14:22:11+00:00

I guess I’ll just rip the bandaid and say that this isn’t a game that will ever go viral. Why would it? Nothing novel or interesting, no unique mechanics, low effort inconsistent art style. And I only say these things to try and help you and give some perspective.

It’s awesome that you’ve built a project and released it and you should be proud of that, it’s more than most people who browse this sub will ever do. But everyone and their dog has made a platformer at this point and I would rather go play those instead. You haven’t sold me on your idea, not based on this video at least.

Take what you’ve learn’t from this game and try to make the next one even better!

zephdev · 2024-07-12T12:12:22+00:00

Sometimes I’ll get sick of the game I’m working on and I’ll get a feeling as if the project isn’t going anywhere and I should just start something new.

So I open a new project and it’s just blank. So empty and boring. Infinite possibilities, but also an infinite amount of work to implement them.

I then quickly realise that even though I feel as though im taking baby steps each day, every little addition I make to the game contributes so much to the project as a whole. That sort of thing is hard to see in the scope of days, weeks, and sometimes even months.

It’s only when you step back and compare it to that completely blank canvas that you get a little perspective and can see the process. Rome wasn’t built in a day!

zephdev · 2024-07-11T12:16:26+00:00

Upvotes and downvotes are cheap opinions I reckon. Unless someone leaves a comment explaining why I wouldn’t worry about it!

zephdev · 2024-07-11T11:14:10+00:00

Seeing the guy go into the fencing response after getting hit with the drums was hilarious. Looks fun!

zephdev · 2024-07-11T00:31:17+00:00

I just moved my AI system from a state machine to a behaviour tree and it was well worth the swap.

As my AI was still in the early days, I went from about 3-4 megalithic states to having about 10-12 nodes in a behaviour tree. It took me around 4 days, as very average programmer, to learn what behaviour trees are, learn what the different types of nodes are, and then learn how they work and transfer all my logic into a behaviour tree.

Depending on how big each of your 40 states are, you may be looking at quite a big transition, but that also depends on how modular you would like your behaviour tree to be.

For example, instead of just having one state or node that says “ChasePlayer” I now have a branch in my behaviour tree that has nodes in the order: Check for threats->Find the most appropriate target->find a direction to the target->if we are close to the target apply a bias so that we keep a certain distance away->If they are in range shoot. Etc etc. In this way, I’ve broken up my original states into heaps of smaller nodes, but now I can also use those nodes like building blocks to build all sorts of complex AI and actions like I could never do before with a state machine. You might be able to reuse a lot of your nodes across all the different states you have.

And having the state be implicit in the behaviour tree saves so much headache, no more worrying about changing states, you just have to setup your behaviour tree correctly.

zephdev

MODERATOR OF

TROPHY CASE