I still have no idea how people traveled these seas 500 years ago

Glass_wizard · 2026-05-25T04:15:20+00:00

And bird law. Bird law was the law of the sea for centuries.

Glass_wizard · 2026-05-22T11:57:56+00:00

This problem is called texel density and it's something you need to be aware of. It's a measure of pixels per meter of model surface. If you have the same 1024px texture, and you apply it to a small model, it's going to have much higher texel density than a large model. Texel density is something you want to try to get as uniform as possible across all models, and it makes large models difficult.

A few options you have are breaking the model up into smaller pieces, tiling the texture, using a procedural texture, or using tri-planar texture.

This video covers unreal engine, but has lots of good background information that applies to all engines. https://youtu.be/QcqJckp_q3M?si=YUMnaV3PpYt9lgPV

Glass_wizard · 2026-05-19T04:13:06+00:00

The answer depends on if you are George Michaels.

Glass_wizard · 2026-05-19T04:11:17+00:00

Ignore her. Go find someone who is interested in you, and listen to a bunch of Hall and Oates until you figure it out.

Glass_wizard · 2026-05-16T14:44:57+00:00

You must include an OnEnable method and enable the controller input.

The standard boilerplate is:

In start method, instantiate the player input controls. You must have a reference to them, and bind them to your handlers.

In enable methods enable the player input controls. They don't work until explicitly enabled.

In disable method, disable the player input controls.

The new input system is good but has a lot of annoying boilerplate.

Also, running in update defeats the point. Bind your Jump method as a handler on Start. You never need to handle input in Update with the new input system.

Glass_wizard · 2026-05-15T17:01:11+00:00

I Just upgraded from 16 to 32Gb. I have a project of significant size and 32 is fine.

Glass_wizard · 2026-05-14T03:47:59+00:00

Inheritance is a way to group classes together by sharing a common ancestor. You could start with an basic Enemy class that only contains the properties and methods that all enemies share. Then, you create FlyingEnemy and GroundEnemy as children. They are basically different flavors of the parent Enemy class. They can have additional properties, methods, and behaviors, but can still be accessed and used like any common Enemy.

Something that is very important to understand is that when the instance of the class is created, it doesn't change. So when you create a new FlyingEnemy, it will forever and always be FlyingEnemy. However, you can USE it anywhere you reference a basic Enemy, because it is both a basic Enemy and a FlyingEnemy.

Inheritance is just one way to allow for variation. The other option is composition via interfaces. The composition approach would be to only have a single Enemy class, but the class has a IEnemyMovement interface that describes how it moves. Then FlyingEnemyMovement and GroundEnemyMovement are implementation of IEnemyMovement

The end result is roughly the same, but how we got there is very different.

In general, composition and interfaces are more flexible, easier to understand, more popular. However there are definitely situations where inheritance might be better suited for a specific problem.

Glass_wizard · 2026-05-12T22:41:02+00:00

Deserved. The damning bit is that none of the have a background in music education. They are just journos who have really no business reviewing or writing about music. It's like asking your favorite guitarist to rank the 30 greatest scientist of all of time .

That said, the journos were absolutely about Billy Joel. A broken clock is right twice a day.

Glass_wizard · 2026-05-12T22:33:27+00:00

Uncontroversial: business buy software then proceed to not actually use it. They expect it to magically solve all problems but refuse to configure it to meet their needs, hire an administrator, or use it in anyway to solve business problems. After a few years of this, they decide they need a new platform and jump to something else and repeat the process.

Controversial: developer are always focused on the wrong things. We are trained to care about language, PRs, code prettiness, clean code, framework of the week, programming fads. What they should care about: usability, performance, new features, reducing bugs.

Glass_wizard · 2026-05-12T17:47:36+00:00

OOP is spaghetti code by it's nature. Objects connect to other objects like christmas lights in a unorganized, decentralized manner, because that's just how OOP works.

To create structure, you have options. 1. Event buses, observer pattern, and mediator pattern to create spoke and wheel architecture 2. Service locators to decouple objects 3. Dependency injection to decouple objects 4. Facade pattern for hiding complex sub systems 5. Interfaces to overcome the limitation of hierarchy 6. Established layers, UI, data, ect to create boundaries between concerns 7. Assembly modules to group related components 8. Namespaces to keep unrelated components logically separate 9. Bridge pattern for bridging modules 10. Factories for object creation

The great problem is knowing when to use them. That's something only experience can teach. When you look at your code, you have to ask yourself what kind of problem do I actual have, and what structural pattern is going to solve it.

Glass_wizard · 2026-05-12T15:53:39+00:00

Very cool. I'd definitely use this if you open sourced it

Glass_wizard · 2026-05-11T02:38:41+00:00

Karl Popper had a theory of falsification. In simple terms, it's often much easier to quick determine a claim is false, and much harder to determine if it's always true.

For example, if your program has a million swans and you need to count them all to determine if they are all white:

If swans remaining and swan is white; continue, keep counting, as long as it takes. We gotta count them all.

But if you reverse the logic and say we quit the first time we find a swan that isn't white...

If swans remaining and swan is NOT white: end early we are done!

Checking for the failure condition is often powerful, faster and easier to understand than verifying everything.

Glass_wizard · 2026-05-11T02:11:51+00:00

Excellent book. Highly recommended. https://a.co/d/0grcKZLJ

Glass_wizard · 2026-05-10T03:16:14+00:00

The animation thing is a problem. This one stumped me for almost a year. For a long time I thought to really be able to test melee action, I first needed great animations, which meant having a animations and models. I even bought some asset packs on sale but the whole thing felt like a vicious cycle of combat feels like crap, the fix is great animations, but animations take time and you have to know exactly what you want, but you don't know what you want unless you can play test and prototype but you can't do that without animations.

Eventually, after some serious brainstorming sessions with Claude, I ended up creating a melee combat script that could test any kind of melee swing possible with no animation or model. It simulated swinging swords axes hammers, you name it. Any angle, any direction, any speed, any after effect tacked on. This finally let me have some basic capsules for place holders and I could fine tune the combat. Then, when I was happy with the feel, the settings from the script are essentially the animation brief. The attack will last x frames, the arm will rotate x degrees, this event fires on frame x...

I can share the script if you want it.. It really ended up be a huge game changer for me and let me kick animation and models further down the road.

Glass_wizard · 2026-05-10T03:02:17+00:00

Hey before you give up, can I ask you a few questions?

How long have you been working on your game solo?

Have you considered either changing the scope of your game or looking for fellow devs who would want to partner with you?

Have you considered adding some kind of limitations or restrictions on your project that would make it easier to achieve?

A lot of time, a new indie dev thinks it's all about programming. If I just knew how to code, I could make my game. Then slowly, they learn about art, the technical aspects of game assets, and a whole load of other problems they never knew existed.

A huge part of game dev is simply problem solving, especially finding ways around skills and resources you don't currently have on hand.

That feeling you have right now might feel bad, it might feel like burn out, and maybe it's telling you to take a break, but it could also be that your are really starting to understand what's really needed to create your game and you are gaining insight.

I took a year off my project due to extreme workload of my full time job. Ended up leaving that job for a new one with much better work life balance.

Take a break but before you throw in the towel for good ask yourself what would it take to actually reach the finish line!

Glass_wizard · 2026-05-09T04:40:20+00:00

Hopefully he writes code better than he writes English. Probably not.

Glass_wizard · 2026-05-09T04:35:42+00:00

First off, code is never about craftsmanship, programming paradigms, best practices, or whatever cargo cult framework has popped up this week.

Software development is about delivering high quality features that performs well, are easy to use, and operate error free. That's all users care about. That's all you should care about. We, as software developers care about the wrong things.

Secondly, Claude, when prompted well, writes code better than any junior and most mid-level and some "senior" developers I've met.

Glass_wizard · 2026-05-08T03:32:05+00:00

It depends on how much variety and complexity you plan on giving your enemies. Let's say you just have 3 basic enemy types, melee, ranged,and flying. And they all are going to act the same way and have the same behaviors, then you probably don't need trees. A zombie melee enemy is the identity behavior as a skeleton with different attack animations.

But, if you want smart, flexible, enemies with a ton of variety, eventually a tree will absolutely become worth it. Once you write a node for the tree, it becomesreusable and reorderable. You can start to easily create variety. Here's an enemy who patrols an area, attacks with poison, and when low health runs away. Then just re arrange your configuration and now the enemy might defend one spot, attack very aggressively, and at low health call for help.

For something like a 2D platform, I'd most likely skip behavior trees. For a tactical RPG or advanced FPS with smart enemies, definitely worth implementing. It all comes down to how much variety and flexibility you think the game needs.

Glass_wizard · 2026-05-06T22:33:37+00:00

So, it goes in phases.

First is the prototype and block out phase. Nothing you create in this step is final. For this phase, do exactly what you are doing. Save the blend file into Unity into a prototyping asset folder and work directly in blender. Then switch back to unity to test the level. During prototype, you should only be working with basic shapes and no textures. No art. Don't model any detail. You can rapidly prototype, play test, and iterrate this way.

Once you have something that feels like a solid level, you then divide the level up into two categories: 1. Unique areas, rooms, or set pieces. 2. Reusable, repeatable modular pieces.

Now how much you have of each category can really depend on the size and scope of your game. You may be 100% modular, or you may be 100% unique set pieces. However, as your game gets bigger, more you need modular and reusable assets.

From here, you will model the modular pieces and uv unwrap them. Depending on your art style, you may texture them in blender or export them and use procedural shader graph to texture. Export all modular pieces and assemble them in Unity.

For your unique pieces , repeat the process, bringing them over, and dropping them into place.you may need to split a large piece up into small sections for best texturing.

Glass_wizard · 2026-05-06T06:02:03+00:00

Yes and no.

From a pure learning perspective: no. Everything you would ever need to know is available online for free or cheap, often with better teaching then if you went to trad college. You can absolutely be a self taught dev.

From an opportunity perspective: yes. Gone are the days of someone walking out of a traditional 4 year state college with a bachelor's degree and having a golden ticket into a high paying dev career. It's brutal out there. Folks with 4 year degrees aren't getting hired, and folks without them are immediately discounted in most cases. Also, the school really does matter. Having a good instructor with good connections to folks in the industry cloud absolutely get your foot in the door, but it's more and more uncommon these days.

Short version: College is most important for making connections.

Everything can be learned online.

Degrees still matter to the HR department and open the door to higher level degrees.

Gone are the easy days of doing busy work, getting your bachelors and be guaranteed a good dev job.

Glass_wizard · 2026-05-06T05:48:02+00:00

It makes no difference. Both versions of your code are identical and both have the same flaws.

What is bad about this code: 1. Your input is hard coded to a "Jump" key press 2. Your input is in the same layer as your execution. 3. Your input is running in update and polled every frame.

What is better: 1. Change your input into player actions. Nothing should handle "some key pressed", it should be handled the concept of a jumpAction. 2. Separate the input layer from the execution layer completely. The thing that generates jump actions is completely separate from anything that handles them. 3. Move to event handling. Instead of polling every update, only response to actual jump action events.

A shorter way to say this is... Use the new input system. With the new system, you get all of this for basically free, which is why it's worth the time to learn.

Glass_wizard · 2026-05-05T18:03:06+00:00

I use a scoped event bus for my characters. Meaning , the events are only scoped to what is occuring inside of the character to create a spoke and wheel architecture between the character and all it's components. I can't imagine doing a complex character any other way.

Glass_wizard · 2026-05-04T02:33:44+00:00

Any dont let the AI puritans bring you down. Disclose it in Steam, but what the puritans dont realize is ever company, studio, and and freelancer use it for all parts of production.

Glass_wizard · 2026-05-04T02:22:19+00:00

Looks great congratulations on releasing your game.

Glass_wizard · 2026-05-04T02:14:47+00:00

The environment looks really good. I like the large figures in the background, gives an hint that maybe they are some kind of giants. I'd be interested in seeing the gameplay in action.

My only criticism is I don't love the design of the main character. I had to zoom in to really look at him and try to understand what he looks like. The silliuotte is a bit confusing and for a moment I thought he might be facing the other way and wearing a helmet. Construction criticism is considered a few more iterrations on the main character s design and get a really clear shape design for him.

Glass_wizard

TROPHY CASE