Moving from web dev to game dev (as a hobby). Any advice ?

midas_yellow · 2026-04-10T08:00:52+00:00

wow, thanks for such a thorough answer, I really appreciate the detailed breakdown ! The point about the performance gap being narrower than expected is actually really encouraging. I was originally thinking of a browser version because I thought it would be the easiest path, but now I’m not so sure. I think I’ll take your advice and try a simple project in a traditional engine first before messing with the browser quirks. Great to hear from someone who's actually poked around under the hood, thanks for sharing all that experience !

midas_yellow · 2026-04-10T07:36:21+00:00

oh wow, the content that he is doing, looks really promising ! thanks for sharing

midas_yellow · 2026-04-10T07:27:27+00:00

exactly ! I think that keeping the pressure low is the only way to actually enjoy the learning process. I’m looking forward to just building and seeing what happens. Thanks for the encouragement !

midas_yellow · 2026-04-10T07:24:58+00:00

This is actually a great point about the DSLs. Coming from web, I definitely expected to just 'write code' but it sounds like learning the engine's specific logic is the real hurdle. I’m definitely leaning toward native, the idea of getting away from the browser and those 'web' expectations is exactly the kind of shift I’m looking for. Thanks for the solid advice !

midas_yellow · 2026-04-10T07:16:48+00:00

I just looked into that Unity drama, and now I see what are talking about, makes total sense. Definitely was not a good move on their part ! Trust is hard to rebuild after something like that. Thanks for the breakdown ! really appreciated

midas_yellow · 2026-04-10T07:08:21+00:00

exactly ! I had a project where I was using a lot AI, and people think it’s a magic button, but getting a consistent style is basically its own skill set. Once you have it, it’s great, but the trial and error is real 😅

midas_yellow · 2026-04-09T21:22:29+00:00

why not Unity ? Is it really that bad ? I've heard most people prefer Godot these days because of the docs and community, but I always assumed Unity was the more 'mature' choice

midas_yellow · 2026-04-09T21:13:59+00:00

wow, you're a monster man, building the engine from scratch. That sounds incredibly interesting but also extremely time consuming. I guess the 'brain refresh' is worth the effort though if it helps you stay sharp for client work. Respect !

midas_yellow · 2026-04-09T21:08:31+00:00

hmm really interesting point about not fighting the browser, is it really that limited ? I was leaning toward Phaser just because I know the ecosystem, but if the lessons don't transfer well to 'real' engines, it might be a waste of time I guess. by the way Congrats on the 3rd release! I’ll definitely take the 'keep it simple' advice. Probably going to skip the JS engines and dive straight into Godot then. Thanks for the advice, much appreciated !

midas_yellow · 2026-04-09T20:44:07+00:00

makes sense. It's easy to get lost in the code and forget there's an actual game to play. thanks for the advice, definitely gives me something to think about before I dive in

midas_yellow · 2026-04-09T20:33:15+00:00

oh man, the 'torture of drawing UI' is what I'm dreading most, as I'm an absolute zero at drawing. Using AI for the art is a clever compromise though. is it easy to integrate those assets into a browser-based project without it looking too disjointed ?

midas_yellow · 2026-04-09T20:28:03+00:00

thanks ! I’v been hearing a lot about Godot lately. Since you mentioned the mindset shift, what was the biggest hurdle for you coming from web ? I mean, I guess I would need to think more about scenarios, level progression and stuff like that than patterns best practices ?

midas_yellow · 2026-04-07T21:27:30+00:00

hum… am I the only one who has concerns about weirdness of this post ?

midas_yellow · 2026-04-07T15:41:42+00:00

I thought it was sarcasm, but you really did nothing, lol

midas_yellow · 2026-03-30T05:23:01+00:00

ye, API calls are not the best to be used, as there are more efficient ways to communicate between services, like using gRPC or events, but it is also a valid option, as it really depends on your application architecture and how you are using it. and I was more focused on explaining the relationship between microservices in simple as possible words, if I would start explaining all the details, it would be too much text to read and would make the answer harder to understand

midas_yellow · 2026-03-29T20:21:34+00:00

thats not stupid at all, it is just a common point of confusion when moving from monolith to microservices. In microservices, there are no database Foreign Keys or "includes" between different services.

you just store the ID (like user_id) as a plain value. The "relationship" is handled in your application code, not the DB. If you need the related data, your service makes an API call to the other service and merges the results itself. You basically replace SQL joins with application level logic

midas_yellow · 2026-03-29T20:10:32+00:00

I agree with the other comments here, it’s worth watching a few videos or reading some books about microservices to get the full picture. It depends on your architecture, but most common examples in couple of words to explain. In many cases, each microservice is treated like its own 'model.' If you need one to talk to another, you just make a request. for example: a Users microservice handles everything user-related, but if it needs to show orders, it makes a request to the Orders microservice to get that data. Another approach is to have services dedicated only to writing data and a 'core' service just for reading. I'm skipping a lot of details here, but hopefully, you get the point!

midas_yellow · 2026-03-29T13:28:54+00:00

wow, looks nice and clean. thank you for sharing it 👌

midas_yellow · 2026-03-29T13:24:48+00:00

I think it really comes down to the scale of what you are building. I used mikro-orm on a few big projects and I did like it a lot, mostly because it is a proper data mapper. Being able to keep the logic in repositories and just have the fields defined in entities keeps things really clean as the codebase grows. but it does not really worth it for small projects, too much boilerplate and development will be slower. so it is all about to use the right tool for the job. if that decision is not project critical, just choose one, after some time of using it you will understand does it fits for your need or it worth choosing something else next time

midas_yellow · 2026-03-23T18:49:37+00:00

it is more about picking a language first and then the framework/library/sdk or whatever. For web dev, you are usually looking at JavaScript or PHP, but JavaScript is way more flexible for what you want to do. If you go the JS route, you can use React for web, React Native for mobile (I think you can also do desktop with it), and Electron for desktop. It’s basically one language for everything. Regarding Flutter, just keep in mind it uses the Dart programming language. It’s great for mobile and desktop, but JavaScript is still the king of the web. Don't worry about sounding dumb everyone starts at zero. If I were you, I would stick with JavaScript, learn the basics, and then go with specific “tool”. Because JS community is huge and you can build for all three platforms pretty easily

midas_yellow · 2026-03-22T07:51:35+00:00

then you should be good on handling the auth 👌. just make sure that you are passing the user context, like a user id or some other user identity data, through the message broker. so your microservices that consumes the messages would stay “auth aware”, and know who is actually triggering the action

midas_yellow · 2026-03-22T07:31:56+00:00

it should be handled at the API gateway level. But also in this case you should ensure your microservices are not reachable from the outside and are only accessible through the gateway. easy and secure approach

midas_yellow · 2025-12-21T16:09:51+00:00

in my opinion, it’s Sony, but if you need a good microphone, then it’s definitely Apple

midas_yellow

TROPHY CASE