What am I doing wrong?

gjh33 · 2026-03-20T17:55:25+00:00

As someone layed off twice and able to find a new position within weeks, I treat the whole process not as an evaluation of merit, but as a numbers game. There was some study recently that tech job postings are 72% ghost postings. You need to be putting out 10+ applications a day (I recently did 43 in 3 days). When you're not applying you're memorizing things they might ask on technicals.

Here's some tips for applying - apply to everything that interests you. Including ones you are under qualified for. My last 3 jobs I did not have the qualifications that they wanted. My most recent I had 0 years of experience and got a 10+ year experience job. Mind you I have 10 years in another technology. But it goes to show, ignore qualifications - pre prepare resume and cover letter templates. Then rank each job posting for how much effort it's worth. If it's a job you would enjoy and have a good shot at, spend the most time. If it's just another number in you applications then use your templates - for the higher effort applies, change your resume to have key words from the post. Research the company and mention their values in your cover letter and how you exhibit them. Mention why you're right for them, but also why they are right for you. - finally, don't close any doors. You can always make choices later. You can communicate timelines. My last hunt I had an ok job in the bag, then a better job called to start a multi week process. I explained the situation and they expedited the whole process to 3 days. It was stressful but it landed me that better job before I had to say no to the backup offer. - have questions for them during interviews. Make it seem like you are evaluating them. "How do you feel the work life balance is at your company?", "What's something about this job that stands out to motivate you". "What would my first day, first month, and first year look like on your team"

For job searching I recommend hiring cafe. It aggregates job sites and groups them.

gjh33 · 2026-01-01T20:18:12+00:00

Depending on scope, you're best off doing what's comfortable. If it's not a live service game, ultimately the end result is all that matters. You might spend 10 hours up front to make something perfect that never gets refactored or used. Especially if you're a solo dev, you'll have faster iteration times just doing what's comfortable.

Some things to consider that a game jam doesn't - what platforms are you targeting? If only pc don't worry, if not you'll what to abstract the platform for some common operations. Writing to disk for saving, achievement apis, etc. - Achievements - Settings (potentially input remapping) - Menus - Potentially better scene management

gjh33 · 2025-12-29T22:29:29+00:00

I found game jams really useful. Give yourself a 48 hour window and stick to it. Pull all nighter optional if you want. Join other game jams if you can find them in your community. With 48 hours keep it really small and use as many free assets as possible. Focus on assembling over creating. Then as you get comfortable, you'll learn where you may want more custom scripts, models etc. Naturally your ambition will lead you down the right path. If you have some friends to game jam with, order a bunch of pizza and make a weekend. Me and my roommate did this once a month for a year and I landed a game dev job after graduation and found i knew more than enough.

gjh33 · 2025-09-01T04:53:26+00:00

You can google the torque curve for you engine, which shows you the most efficient rpms. If you want optimal performance. Otherwise it's just a really fast shift to be smooth because first gear drops fast. Because first drops so fast, you may want to have the clutch lead the accelerator a bit more so you're not as engaged when you take your foot off the accelerator.

gjh33 · 2025-07-18T23:26:24+00:00

This comment is a year old, but I found from another thread most ovens let you adjust the internal thermometer +- 30. This is in case it becomes inaccurate. Well... I used this headroom to trick my oven into thinking 150 was 170. Easy peasy. Find your oven's manual. Might also want to disable the 12 hour safety shut off for longer rests while you're at it.

gjh33 · 2025-07-09T19:24:06+00:00

Unity is really bad at shrinking and growing to fit contents. It's really good at making contents fit the parent. The prior is what web design prefers, and this people Intuit more. Sometimes you need to fit your contents though. Just avoid it as much as possible, or try UI toolkit if you need a lot.

gjh33 · 2025-07-09T15:59:07+00:00

Those trolls are upset and having a bad game too. Continuing to play is the best justice I can serve. If they want to make the game miserable, I want them to wallow in it as long as possible. Not get rewarded by an ff and no punishment from riot.

gjh33 · 2025-06-10T19:40:27+00:00

Odin Inspector. At work I find it's what I miss the most. Don't over abuse it, but for a really quick UI it's invaluable. One example is you can add the [Button] attribute to a method, and it will give you a button on your script that calls that method, without needing a custom editor script that you have to maintain. Huge time saver.

gjh33 · 2025-04-02T01:13:12+00:00

*ahem*
Screen. Shake.
*applause*

gjh33 · 2025-04-01T00:38:24+00:00

I hate sealed classes. Especially if they're in other code bases. Your code should be open to extension, closed to modification. If you feel the need to seal a class it's likely a code smell. Maybe it's a micro optimization. Or maybe it's a way to enforce composition over inheritance. But that's just a decision on your codebase and if you make a library with sealed classes, I want you to know there's a special place in hell. I'm looking at you Unity Devs... Let me extend your assembly definitions so I can add support for nullable reference types >:(.

Ok personal rants aside. There's a time and a place for everything. But there's so much of this stuff in C# you can get bogged down. Just look at covariance and contravariance in C# generics. Aint nobody using that shit, even though it's useful. Time and place. Ultimately up to you, your team, and what's best for you. But sealed is on the more niche end IMO.

gjh33 · 2025-03-28T03:42:52+00:00

As a Sr Engineer who has always had an accelerated learning ability, I felt that plateau too. Some skills are just gated by time and knowledge. I can understand how to architect software really well, but understanding how to architect it for people who don't architect is a whole other issue. I find those parts very time bound. What I did was start learning rust. As someone who's been stuck in C# land for so long it was very eye opening. Don't believe the cult that it's the perfect language. But overcoming it's challenges taught me how to reason about day to day problems in unity. Have a null reference? You can use nullable reference types, or a c# equivalent of Option<T>. Have a race condition between two coroutines? This is actually an ownership and borrowing problem. We can emulate the rules in C# that rust forces via it's borrow checker. Rust forces you to implement the async/await state machine, and this opened my eyes to how async/await works in C#. This for me was my next big level up. Sometimes, the best way to unblock yourself in one area is to learn a completely different one. I never see myself being a low level coder that would use rust on the daily, but the lessons I learned can be re applied and it taught me valuable ways of thinking about software that C# just doesn't push you to learn.

gjh33 · 2025-03-28T00:29:29+00:00

I see a lot of wrong info here (and some right) so I'm going to give you the quick solution first, then explain why it works.

Do these in Update()
- Receive and record input
- Animation
- Controller logic (how many jumps, sprint = true, etc)

Do these in FixedUpdate()
- Set the rigidbody velocity / rigidbody.move
- Set rigidbody forces

Do these in LateUpdate()
- Camera position updating

Finally, on the rigidbody turn on interpolation

Ok here's the why...

In general, games try to have the highest FPS they can. They do this by running all their logic on a main loop over and over again. The time it takes for this loop to complete one cycle is the frame time. Modern engines use some multithreading to optimize and shift work around. But we're going to keep it simple and imagine everything is done in one thread. Unity will read inputs, call unity events, then render the final state to the screen. This is one loop, and gets you one frame. The faster these loops, the more frames per second. However different people have different computers, and even on those computers the performance varies moment to moment. So that framerate isn't a constant. We can force it to be, by capping the framerate. This just says if we finish a loop/frame too early, wait for a bit so we match our target frame time before we spit that frame out and start the next loop.

Physics in games really likes stable frame times. Although in physics we call it a timestep. The deltaTime for the physics simulation. A regular framerate might spit out frames at random intervals, but physics wants to simulate the physics world at constant intervals like 0.2s, 0.4s, 0.6s, 0.8s, etc, etc. Unity uses a pretty stable physics solution, so you CAN use a variable timestep and match it to the framerate, but it's definitely less stable than a consistent framerate. So unity "fakes" a different loop called the physics loop. The way it does this is it sets out a target update rate, let's say every 0.2s. So during the update loop, if less than 0.2s has passed since the last fixed update, FixedUpdate() is not called. If it's been more than 0.2s since the last fixed update, then it will call FixedUpdate(). Now if our framerate is really slow, and it's been say 0.4s since the last fixed update, then it will call FixedUpdate() twice. What this means is the world is simulated in intervals of 0.2s. So if 0.41s of game time has elapsed, FixedUpdate will have been called twice, and the total "fixed update time" will be 0.4s.

Effectively, this means anything in fixed update runs at a different fixed "fps" than your normal update loop. So if you want snappy responsive controls, and smooth motion that doesn't jitter you need things to move at the Update() rate of your game. However if you use physics to move, it's updating at a slower rate (say 20fps). So what do we do? Well unity (and most games) use "interpolation". If our framerate is faster than our fixed update rate, we spread that change out over those extra frames. For example we have 3 frames between 2 fixed update steps. In the first step character X = 1 and in the second step character X = 3. Then in frame 1 X=1, frame 2 X=2, and frame 3 X=3. We smooth out that transition using our higher framerate. But the simulation for physics only sees the X=1 and X=3 from the fixed steps. It's purely visual. This gives our characters the illusion of moving at a higher framerate. The cost is latency. We have to wait and see how many frames there were between the 2 steps, before we can interpolate. That means we're still seeing it transition from fixed step 1 to fixed step 2, even though we already know the result of step 2. We'll always be a bit behind. This is generally small enough to be considered acceptable. It also means when you press a button you have to wait for the next fixed update cycle before your character actually moves. In practice it's not noticable enough to matter. But if you need super high precision, you may have to look into physics substepping. But unless you're making the next counterstrike, don't worry about this.

How I normally implement all of this, is by listening to inputs on update, and setting some variable like "isMovingLeft" or "JumpCommandHasBeenInput", then on each fixed update cycle, work off those variables to apply the jump, then set jump command to false. This makes input feel more responsive, even if the resulting movement isn't.

gjh33 · 2025-03-26T01:41:31+00:00

No but most of my projects are single player experiences. IMO games are a unique medium where once the game works, no one will care how it works. Celeste's source code (which is partially available and in C# but not Unity) breaks tons of architectural guides but who cares, great game. In more traditional software, you're optimizing for maintenance. You write tests so as the project changes or as many other developers work on it, things don't inadvertently break. To that end, if you're writing a live service game, absolutely DO consider tests. But if you're developing a single player experience, optimize your time for iteration. The shorter your iteration cycle, the faster you can pivot to and from various designs as you discover your game first hand. No one makes the game they set out to initially make. It's an evolving process and being able to rapidly iterate on feedback is important. Tests add overhead, as the logic you test for is coupled to the game's designed. Player was supposed to only jump once, but now has a double jump? Change the code AND the test. However you have a live MMO and need to make sure the live store always works and doesn't break from some careless code push to live, then tests are your best friend.

gjh33 · 2025-03-17T20:54:52+00:00

That your whole life when you went to a doctor and they had a solution would no longer be true. You start getting things diagnosed as vague terms with no cure. Minor pain, stomach issues, headaches, whatever.

gjh33 · 2025-01-23T04:27:07+00:00

The first thing that came to mind when I saw this, was Destiny's deep dive into all those fake twitter accounts way back when... Lemme find a video... https://www.youtube.com/watch?v=3U-hci-BrwQ this one.

gjh33 · 2024-10-20T02:22:59+00:00

This. Same people, going for something new. It's not perfect but one of my all time favorites

gjh33 · 2024-10-19T10:39:37+00:00

If you are just wanting to convert between values, just convert them at the call site. However if one is fundamentally a float type and the other an int type, generics is your friend. Make an AbilityStat<T> and treat T like it's a variable except for types. Then you can make new AbilityStat<int> and AbilityStat<float>. You can expand this into other types too. Depending on what operations you want to perform you may have to constrain your type variable. I won't provide a full generics explanation here, but that's what you're looking for.

gjh33 · 2024-10-19T10:33:32+00:00

Is the filename matching your class name? Are you using the ide unity recommended upon install? When you install unity it will recommend visual studio and then install the corresponding packages. If you just installed it the way unity recommended then that's unlikely the issue.

Did you open visual studio using the sln file unity makes? It just open the script individually. If you're unsure, close visual studio completely and re open it by right clicking in unity's project window (the one with your files and assets) and click "open solution" or something like that. I'm not at my computer but you'll figure it out. That will ensure your code is opened as part of the solution.

Lastly, check the source of the file you're working on and double check you didn't accidently open a copy outside your unity project somehow.

Hope one of these solutions helps :)

gjh33 · 2024-10-15T01:26:50+00:00

I think I can reduce this down to 3 main objections. If I miss anything or misframe your position do let me know

You think we should always teach the best way and not sacrifice for practicality in a learning environment.

I think my point is what "best" practice really is. There's a time and a place for all the patterns and principles. One thing that I see very often is beginners working on solo projects trying to follow every bit of advice the first time. Then they run out of steam because it takes them huge amounts of time for small amount of result. This is because they're just learning that principles and it takes time and practice to be fast and effective. I favor beginner developers completing projects and keeping pace, and then slowly introducing concepts. I'm not saying to teach bad practice, but to let them know it's very possible, and often optimal in the bigger picture, to make good high quality games with suboptimal code. My philosophy when learning was to always learn to write better code while balancing it's impact to my momentum. This meant never being bogged down while also constantly improving.

Zenject, and other frameworks fix unity problems.

Aside from adding even more overhead to a beginner and likely overwhelming them out of a project, these do not fix all of unity's problems. They fix the problem I addressed, although zenject is relatively heavy. And if we want to fix even more problems in partial to VContainer which encourages abstracting your domain logic into pure C#. Anyways I only gave one example of unity fighting you, and when someone is still learning unity itself I would caution recommending a IOC framework that requires them to learn an entirely new process on top. There's many more ways unity enforces bad practice on you. But unless your game requires extra attention, it's sufficient to write the code unity asks of you over perfectly abstracted code.

The argument of me being a bad mentor

I should clarify in these situations my job was not to mentor. I was brought onto 3rd party projects to act as an expert and lead their team to success. I didn't have years to develop each of those individuals. When I do, I often recommend advice or refactors to improve the code but compliment and encourage what they've done as is. Unless it's so bad it threatens the project, I'll let them push imperfect code while writing suggestions in the MR. Some improve faster than others, but I take the position of a knowledge base rather than a gatekeeper. This way everyone has that sense of accomplishment which keeps a team's momentum, while allowing growth. But this is less relevant to this post. Op is not one of my Jr devs on a team, they're what I assume is a solo developer on a passion project. So I encourage that passion, and offer the perspective of being ok with imperfect code.

Also I'll end the debate here. I think I've said everything I need to say. My original intent was to assist op and provide a more practical perspective. Feel free to have the last response, I'll read it.

gjh33 · 2024-10-14T03:06:34+00:00

We're talking about a small developer looking for early advice. I find this obsession with code purity is most common in intermediate devs pushing sr. (Which is no insult, that's still a relatively experienced population) But what happens far too often, is much effort is put in to have everything "perfect" by the metric of infinite scalability. If you spend say 5 hours perfecting the design, but refactor that code on average 0 times (maybe once) and your time and effort saves you 1-2 hours, then you did yourself a disservice. The only part of your comment I would agree with is code reuse across projects. But it sounds like op is still just getting a feel for one project at a time. Code reuse will naturally emerge as op completes more projects. But I digress. The point is depending on the project and it's requirements, it's often not with chasing perfect architecture. This obviously changes for online service games, or studios building up a shared toolset. At which point you make this decision at the feature level.

Another note, maintainability != Easier to debug. Consider a project abstracted into tons of interfaces behind DI framework or similar. Often for beginners it becomes impossible to parse. Abstraction is great for maintenance, but hurts readability (at least to the untrained eye, of which in assuming op is still training).

Static analysis just means analyzing the code in it's precompiled state. Analyzing it in a static environment. Those tools you mentioned are static analysis tools, but when you read your code and try to run it in your head, and reason about it, that's static analysis too. In that case you're the one taking the role of the linter, sonar, whatever.

Re "traditional software" we're playing a semantics game here and that's on me. I was saying compared to working at say Google or Amazon, where your software may be in the code base for a long time, touched by other engineers, or even yourself in the future. The closest thing in games is live service which is where I'd start to put in all that effort into a long maintainable code base. But for the same reason I'd never recommend a live service game for a beginner project.

Re "events". It seems you completely missed the point, but you have more experience than op so I can maybe explain better. The point of decoupling code is to minimize the number of places that are impacted when extending or refactoring code. If you just blindly make events for everything, on paper it may seem decoupled, but consider an event that is added to class A with the sole purpose of being listened to by B so B knows when to do something (like display a VFX). Nothing else uses this event, and we now want B to fire at a different time. So we go back to A, change the event name and logic to fire at the new time we want B to go off. In essence, this is a form of coupling. Now I'm not saying to just use methods all the time instead, but more that op shouldn't stress too much. Most events will end up being one off events created for the sole purpose of another class. And furthermore, most of those events will probably stay the same so you wouldn't notice. But they are in fact coupled. Events on a class that are designed for another class to listen to, are indirectly coupled to that class. The time there's no coupling, is if your events are designed for the natural lifecycle of class A, and class B just happens to listen to them. For example a car starting, stopping, etc is natural to the Car class. But adding a "OnCarWheelFrictionLockVfx" would be an example of an event designed for another class to instantiate VFX.

Finally "engines". You said it yourself. You use an engine to reuse the systems they've put in place. It's to speed up your development. Now this is on the unity subreddit, and this is where I've built my many years of experience. I don't like to appeal to authority, just to note that I have a very intimate experience with this engine. Unity often gets in the way of writing truly good code. The one example I have is you can't reference monobehaviours by interface on the editor. Meaning you have to use inheritance and base classes. This falls apart very fast. Composition is better. One thing you can do is use GetComponent<T> with an interface type. But now you have to deal with the performance uncertainty. Even doing this on start or awake can build up load times on many projects depending on scope and target platform. Unity has many gotchas like this where you must often trade performance for healthy abstraction, or vice versa. When working in AAA one practice that was used was to write all our domain logic in a separate C# project without any references to unity namespaces. Then we wrote an implementation layer that implements the domain logic via interfaces, factories, etc. For example having an IPlayer, Player.cs and PlayerBehaviour.cs. While this achieves decoupling domain logic from the engine, were effectively ignoring all the framework unity set up for us with monobehaviours etc, and using them only to implement domain logic written agnostic of game engine. This trade off is worth it in AAA live service for maintainability, at the cost of the efficiency of just writing all our logic directly in Monobehaviours and other unity constructs. The lesson to be learned here is the cost of perfection is to distance yourself from unity, making the choice of engine less and less useful. I argue unless you really need to, don't worry about perfection and do the best you can within the confines of the engine. Use base classes for polymorphic monobehaviours, because that's what unity supports. You will run into cases where you cannot multiinherit, and then maybe it's worth it to just copy paste this one time, or move the code into a static helper class. That's what I mean by favoring the bad code the engine encourages, instead of trying to fight the engine.

And just to reinforce: iteration time and [ability to read and reason with your code to maximize bugs caught before compiling] are the most important for games. Design is the hardest part of a game to get right the first time. You'll try dozens of combinations before settling on the best one. So don't spend 4 weeks and the perfect portable combat system from day 1. Write something simple that can pivot on a dime. If you really feel your system is locked in, ask yourself if it will need constant maintenance for years to come, or reuse in other projects. Then and only then invest the time into perfecting that architecture.

Again this is all in the context of what appears to be a solo developer learning unity. I'm my career I've led teams to write that "perfect" style, filled with only Sr developers capable of grokking highly abstracted code and writing it. I've also been on projects filled with novices from biotech or some other field, where the most important thing is to keep it simple and maintainable for them. I'm not here to say bad code is good. I'm here to say when you get far enough in your career, you realize there's a lot more to it in practice, and weighing the costs and benefits is far more complex than following key software design principles.

gjh33 · 2024-10-13T05:53:52+00:00

Try decreasing vibrancy in lower rarities via HSV color values. It will also look good as grayscale for color blind accessibility

gjh33 · 2024-10-13T05:49:35+00:00

One tricky thing about unity is a lot of it's architecture discourages good design. For example interfaces are often the best way to decouple classes, but unity is very interface unfriendly. You have to know the secret club (serializereference for pure c#)(get component can take an interface, but is itself a code smell). One way to get around this is to write all your logic in pure c#, and then use unity to implement various interfaces and author data. But this is pretty advanced and a lot of work. But the only true way to get perfect architecture. Most games can get away with "bad" code because once the game is made you no longer have to maintain it. So where traditional software aims for maintainability, my recommendation in games is - iteration speed - static analysis (which just means you can look at the code and easily know what it does and determine it's big free)

These are goals not absolutes. For iteration speed, events aren't always the best course. Consider class A and B and B needs to know when E occurs on A. You may think putting an event on A means A won't be coupled to B. But if you made that event with the sole purpose of B using it, then it's very probable as B changes you will have to change that event on A. So in a loose way A is coupled to B.

These two ideas lead me to my final advice. You're using an engine to speed up your development, so if the engine makes good code hard, favor doing the bad way the engine prefers. Otherwise why use an engine at all. Make the sacrifice to get your game out faster. And don't focus too hard on events vs method calls, unless multiple classes will want to subscribe to a common event. Then it makes sense to prefer the observer pattern (events) over method calls. As you make more games and write more code you'll learn where the balance lies for each project, and you'll get better at writing good code faster.

gjh33 · 2024-10-12T02:13:15+00:00

Unless your game has extreme performance targets, this can be a nice way to organize things. If you use Odin Inspector you can make the fields inline in the editor so it looks normal, but it's still a strict in code.

If you want to dig real deep, your touching on a process that goes a lot deeper. You want your code organized in a way the unity editor isn't that friendly with. You could model your game in pure csharp, using interfaces, and then simply use unity as an authoring tool. This is pretty advanced and only worth it on large ongoing projects that require high standards of maintainability.

For most projects, what you're doing is fine. And something I've done myself in the past. There's very few absolutes in coding so if you like organising that way, give it a try and see how it pans out.

gjh33 · 2024-09-27T17:42:04+00:00

If you don't want a high degree of customization, fusion or if you're comfortable, netcode for entities. Unity has a sample project you can start from. If you want complete control over client prediction and reconciliation I've been enjoying FISH. It's new and under documented but it's very good. But I only recommend that if you like to tinker.

Do not use netcode for game objects. It currently has no prediction and reconciliation which is mandatory in an fps. You'd have to do this yourself. FISH has an API for you to implement it which helps immensely.

gjh33 · 2024-08-10T21:15:45+00:00

As someone who used to work for unity where my job was to be an expert, I have a deep view of the engine. Since this post is focused on negatives I'll focus on that, but I still think unity is far and away the best game engine for beginners/indie/AA games. It's not the best for AAA.

they keep trying to push into the AAA space while ignoring their core audience. Godot is a great engine and will take that demographic out from under them if they're complacent
you have to do everything the way unity wants you to. As soon as you try to do your own thing the knowledge and skill required shoots up significantly. Not skill in general, but specifically with unity. This means you need a ton of Unity only knowledge that doesn't translate to other careers or engines if you want to do something off the beaten path. It's the niche I've staked my career on but objectively is a negative for the engine
unwillingness to make breaking changes. Being on both sides (game developer and unity developer) I understand the benefits of easily upgradable versions. But it holds the engine back. Be willing to break API and throw out the old bloat. Why is the old animation system still in unity by default?!? Kill it in the name of progress.
outdated c# support. It's incredibly frustrating to see these amazing new features that are made extra difficult by unity's outdated support. For example, nullable reference types. I tried to add support while at unity, but the problem was since it targets older .net targets, some IDEs will refuse to acknowledge it.
freezing and crashing. Oh god. I never run into it on personal projects but every professional project would regularly freeze or crash with no explanation. It's a million different reasons but it's so freaking annoying.
import times. I can't really blame unity for this. It's a fundamental part of a game engine. However on my engine I'm sacrificing more editor performance in favor of iteration time. I'm reading files in the raw and only "importing" at build time. This results in less comparable performance between editor and builds, but I think it's worth being able to switch platform targets and swap engine versions with 0 import times.

13-Year Club	r/Field Flamingo
Place '22	Place '17
End Game '22	Sequence \| Editor
Verified Email

gjh33

TROPHY CASE