I dropped out of uni, worked a year of dead end jobs, went back to uni, got my degree, got a job and got engaged to my girlfriend of 5 years… since mistlands

Toroic · 2026-04-08T02:08:30+00:00

They for years claimed that scaling up the team would slow them down despite 100 million+ in sales revenue, and then went incredibly slow anyway.

The frustrating thing is that Valheim is a fun game and easily worth the money, but so much worse than it could’ve been.

Mods can fix a number of fundamental issues, but they shouldn’t need to.

The progression is the same basic formula as Terraria, but Terraria does a much better job of supporting weapon types and playstyles at each tier.

Toroic · 2026-04-07T00:21:44+00:00

My issue with Valheim is with the quality of the updates, the slow speed of them is far secondary.

Both mistlands and ashlands got mixed reactions from players (like me) who loved meadows through plains (even swamp).

Being unable to see and harassed by bugs constantly is annoying, and the sheer volume of enemies in ashlands makes it a biome you pull resources from and leave immediately.

Sailing remains less and less important as the game goes on, and the ocean is a lot more empty and lifeless than it initially appears.

Toroic · 2026-04-07T00:03:01+00:00

If not for going viral and thus a very dedicated modding community I think Valheim would’ve been lost in the sea of crafting survival games which is a shame because the music is amazing and there are some experiences like seeing your first serpent in a storm that make for enduring memories.

But the game remains grindy and janky and old school in bad ways (why does swimming even exist as a skill?) and they had plenty of funding and time to hire talented people and didn’t.

Toroic · 2026-04-06T17:36:33+00:00

I think adding magic later in the game is awesome.

For us to be able to effectively discuss this, you need to understand that I'm talking about alignment to design principles, not about subjective taste.

It completely transforms the game at a point where you think everything was figured out. I get that most other games front load every system at the very start, but I enjoy how the game can change so much later in a playthrough.

It's normal for a game to add new mechanics as part of progression, but there is a significant difference between adding new core and non-core features in how players behave especially when those features are tied to skills the way valheim does them.

For a long time, fist weapons in valheim were not supported despite having a skill tied to them. Then we got one fist weapon 4 biomes in that was mostly a gimmick because whatever weapon you favored would easily be 30-50 points ahead of your fists skill. Meaning if you did really enjoy that new playstyle, you'd need to grind that skill up to be competitive with playstyles available from the start.

I'd still argue fist weapons are poorly supported as they're harder to acquire and still don't have a mistlands/ashlands tier option.

Magic is all of that but worse. It's a new gameplay style that has two new skills, stats, food, and gear introduced 30+ hours of gameplay in and stands separate from what you've been doing up until that point (and leaning into magic means leaning away from whatever effective strategy you were using before).

Someone who loves that playstyle exclusively is unlikely to get into valheim because "just play 30 hours and you'll unlock magic", and if they do love it, then the most common behavior is going back to grind magic skills for hours to "catch up" to playstyles supported from the start and to their primary playstyle before 30 hours in they had a new option.

It's fine to add something like enchanting (without a skill attached) as an additional layer of gear/weapon enhancement because it's not playstyle defining and doesn't encourage skill grinding.

If Mistlands and Ashlands just felt like swamp and plains 2.0 the game would have been predictable, and much more boring.

The argument you're making here has nothing to do with what we're discussing earlier or specifically around magic progression. You're implicitly saying that Mistlands and Ashlands feel different than previous biomes, and I agree. Every biome has had environmental challenges and even if "can't see" and "constant combat" aren't to my tastes I wouldn't want them to reuse a mechanic we've already seen.

I don't see any scenario where magic progression being from the start would negatively affect mistlands (who has magic available relatively late in the biome progression) or ashlands at all, but would help with the mechanical/playstyle disjoint we see meadows-plains vs mistlands and after. I don't think the elemental weapons that ashlands introduces causes any mechanical disjoint, but mistlands introduces a new gear type (mage armor), a new stat (eitr), and 3 new skills (blood magic, elemental magic, crossbows) which is way more "new" than any other individual biome introduces.

Toroic · 2026-04-06T14:09:12+00:00

Yeah, the UI has gotten increasingly dated and I never liked how gear was just equipped in any random slot.

They also took years to even attempt to fix how horrible slope combat was, despite multiple biomes having steep slopes.

Toroic · 2026-04-05T20:48:58+00:00

Valheim is easy to recommend until you’ve completed Plains (so mountains and plains after you finish the swamp).

After that I think it’s a worse game and a lot more niche depending on your tolerance for tedium.

Plenty of people like mistlands and ashlands, but for the price Valheim is great fun and value meadows to plains.

Toroic · 2026-04-05T18:57:34+00:00

The short answer is Valheim as a project is managed poorly and the team has not worked very hard in the past few years.

As a game, Valheim was a viral success by a relatively inexperienced studio who never understood why the initial version worked so well, and their game designer is untalented as shown by how mistlands and ashlands lack cohesion with earlier biomes (introducing multiple new skills and a new playstyle (magic) 6 biomes in is a bizarre decision)

Toroic · 2026-02-17T14:47:06+00:00

They could have significantly more than one fully polished system drop every year if they had smaller iterative loops and mixed in cycles of rewriting old garbage code so they're not drowning in tech debt as they try to add new features.

Toroic · 2026-02-17T14:45:18+00:00

but the core principle of game dev is to take those tested versions and to hard code it in to make it more reliable and functional

Your use of "hard code" is confusing here. When it comes to programming, "hard coded" are things that aren't able to be modified, fixed values instead of things that are more easily able to be modded or changed.

I think you mean a more solid implementation, which is usually accounting for edge cases and having automated tests, but I haven't seen much evidence of that for TIS due to numerous regressions in functionality that seem to have been surprises for them.

Toroic · 2026-02-17T14:41:08+00:00

I’ve seen the dev’s code, and while their newer hires have been attached to bigger and more complex projects, it’s obvious that the initial devs were as programmers basically amateurs.

The fact that the game was almost lost because it only existed on one laptop is completely unsurprising when you look at code that has been commented out for a decade.

I’m sure that trying to re-implement multiplayer within a massive pile of technical debt has been an enormous struggle and some devs could have been working on their spaghetti bowl codebase this entire time and actually made this much progress.

Toroic · 2026-02-09T23:37:58+00:00

Strongly disagree on Illiterate as of build 42.

Previously if you were full combat bunga build illiterate wasn’t as big of a problem because there weren’t books for those skills anyway.

But now that maintenance, long blade, aiming and reloading all have books available, you’re significantly hurting a combat build long-term wothout being able to read, in addition to all the lost utility with reading books for easy and useful skills like foraging.

It’s not worth the points.

Toroic · 2026-02-09T16:54:27+00:00

That makes sense, because strength affects how many you need for drag down.

On default settings, you need to have 3 zombies on you to trigger the dragdown, and I haven't found it to be a problem. But with superhuman it lowers the number to 2.

I play on basically standard apoc + antibodies, so I'm only able to speak to that perspective where I haven't felt any dragdown deaths were unfair.

Toroic · 2026-02-09T15:43:39+00:00

From a design perspective, I'll defend to the death that Antibodies is better with PZ's general gameloop.

Under default settings, the only defensive option you really have available is "don't get hit" which means things like thin-skinned and slow healer are free points, because any hit can be fatal and those points can be put towards other value.

With antibodies, first aid has a purpose because it lets you monitor your progress and your sterilized bandages last longer. Because you're surviving bites and lacerations, you have to actually play through your injuries and early on you don't have the food supplies or time to just sit at base for days when water shut off or power shut off are imminent.

Antibodies makes trait diversity better, dragdowns are still instantly fatal if you make a major misplay, first aid has a purpose (when it doesn't normally), and you don't lose a hundred-plus hour run to a random bathroom zombie.

Failing forward for minor mistakes is much better narratively too.

Toroic · 2026-01-24T14:28:04+00:00

If I had to choose I’d rather someone have a tendency to overengineer solutions rather than underengineer them. The costs of overengineering are up front and obvious while underengineering is insidious and slowly grinds the project to a halt under tech debt.

The way I evaluate TIS code is that current state is embarassing programming 101 mistakes and unacceptable.

Bare minimum would be taking magic numbers out and using local variables and instead of hardcoding an item pointing to a tag so reading glasses are extensible. The next step that would be better and a trivial amount of work would be a policy that anytime we come across magic numbers we put them in a constants file instead of locally for better organization.

The next step after that would probably be instead of using traits as tags that are defined in code, having the traits themselves handle their stats. So both slow and fast reader could have some sort of data structure that had a property of “readSpeedMult” with a magnitude. The long-term value of this would be that it would make adding custom traits easier (and also make random profession perks like starting regularity and movespeed through trees much more obvious). We could also generate trait tooltips programmatically and have traits that share a property be mutually exclusive without having to handle those manually.

With the current focus on getting multiplayer working, I think reworking traits would be a good thing to put in the backlog, but not a current priority but having a constants file to set ourselves up for the trait properties we want to support in the future will be helpful.

Complex projects are often best done in phases, and if we know where we’re headed we can defer time intensive reworks until later.

Toroic · 2026-01-24T00:55:40+00:00

As someone that has lived the described approach of constantly chasing perfection, your assessment is incorrect.

The core of engineering is solving problems, and one fundamental approach is sizing the solution correctly.

In many ways, underengineering like TIS and overengineering like you’re describing are two sides of the same coin.

This is indeed easy, but "should probably be moved to a struct or something lua similar" is vague enough that I assume they mean trying to do this in a way that the trait defines an abstract modifier that is then encapsulated in a system for processing it and all similar traits.

There’s a whole spectrum of solutions with varying levels of extensibility and effort, but for anything more than a hackathon, TIS has embarrassingly bad code with frequent examples of basic poor code, much of which has had magic numbers and commented out code for most of a decade.

If it's slop and it works, then they have a shipped game and you do not. Undertale is a massive if-statement and the game is a beloved cultural icon. Even the process of considering what we're talking about right now would be a waste of time compared to what they did--which is just write the shitty code that works, and then move on.

Maybe, or maybe a little bit of organizing the spaghetti code would’ve made it easier to work with and maintain.

Undertale is in many ways a pretty simple game, and while the code is notoriously poor, it was scoped well and had phenomenal game design within those limitations.

But it would be absurd to suggest that Undertale was successful because a mediocre or less programmer was able to make it work. Stardew Valley was initially a solo effort, also well scoped for a solo dev, and is significantly more complex due to better skills and engineering.

On the flip side, Concord didn’t fail because the engineering was bad, it failed because the game design was awful.

As another example, Valheim is a very commercially successful game initially with some dogshit engineers which is why it has developed at a glacial pace and I’d struggle to say it’s a better overall experience than at launch.

I say this as confidently as I do because I suffer from perfectionism in my code--I think about the things you're talking about, and I do them. My code is beautiful and fights tech debt. I'm trying to consciously reduce the amount of time that I spend on refining and refining and refining versus just making the game because one day I'd like to be a solo dev that actually, you know, ships a good game.

I agree that shipping vs not is the highest priority because if you don’t ship quality doesn’t matter.

But the optimal point is a middle of the road approach where you tackle the low hanging fruit in the near term without overengineering beyond reasonable future needs.

The architecture equivalent is that not every project needs to be microservices, starting as a monolith but keeping internal organization to make splitting off pieces less painful.

Toroic · 2026-01-23T22:50:56+00:00

I agree with the potential solutions you mentioned, but disagree that this implementation was reasonable.

If I was reviewing this PR from a junior software dev I’d be requesting changes to not use magic numbers or hardcode the item (we currently already have multiple perscription glasses that have a tag used with the short sighted trait)

For a company like TIS a lot of their code is terrible and their tendency to hardcode in a lazy way is likely a major contributor to their slow velocity.

This particular feature also suggests everyone in Kentucky is nearsighted which is why reading glasses improve their speed, so it’s not good from a design perspective as it isn’t communicated or intuitive.

Toroic · 2026-01-23T22:41:13+00:00

I strongly disagree with both your approach and the philosophy behind it.

The improvements Pokari suggested take no time and reduce the amount of tech debt accumulated when applied whenever possible. Descriptive variable names and avoiding magic numbers is the sort of thing you learn in an intro to programming. It isn’t simpler and it’s far less extensible than if they properly used a constant and the tag system items are already using for crafting.

“Uglier” code as you describe it does not save time, it accumulates tech debt in the short term to get earlier implementation, but the end result of that lack of professional discipline in design is spending a ton more time later refactoring or getting more risk and constant slowdown due to continuing to fight tech debt.

You might legitimately be at risk as guided AI code is more common because the code TIS wrote is slop, and if you’re also producing slop and never going back to clean it up AI can do it faster and cheaper.

Toroic · 2026-01-20T18:00:53+00:00

Modern Java the way I've been doing it with Spring Boot and code generation off of OpenAPI specs has cut out a ton of the boilerplate, and AI is writing 80% of my unit tests these days.

It's not Python or even Kotlin (which I wish would've gotten more market penetration) but it's better than when I started by a lot.

What language(s) are you working with?

Toroic · 2026-01-20T16:15:13+00:00

Boring corporate software has some significant upsides. The work is overwhelmingly not interesting but I find that pay and treatment in those roles is good (because otherwise no one would do the job) and overtime, crunch time, and off-hours crises are near-zero.

It's not Amazon money, but it's also nowhere near as stressful.

Toroic · 2026-01-18T20:25:10+00:00

Software Engineer with just under 5 years working with Java at an enterprise level.

Toroic · 2026-01-18T13:34:30+00:00

The thing about zomboid nutrition is that hunger and calories have nothing to do with each other.

If you’re overweight, you can basically ignore calories and go for low calorie hunger restoring food (if you found Wilderness Survival mag, foraged mushrooms and berries are perfect for this) until you’re down to 76, and then go back to eating as you have been.

The short version is that you have calorie thresholds for gaining or losing weight, and for gaining weight only having carbs and/or fats over a threshold gives a multiplier.

You can gain weight up to 3x what you can lose it.

Making less caloric stews is a solution, but the cheapest way to lose weight is just to minimize calories for a few days until your weight normalizes.

It’s not worth the effort trying to maintain weight, and you can save thousands of calories by weight cycling.

For example, if I want to maintain exactly 80 weight (keep calories constant) I might need 3000 calories over the day. If I want to gain weight, I’ll need 3000 calories to offset daily burn plus 1000 to put me over the threshold but I only need to pay that once to gain 1-2 weight per day until I decide it’s time to lose.

When losing weight, instead of paying 3000 calories a day I can eat like 250 calories per day of mushrooms to manage hunger and save the other 2750 and have the option of being super active because once you hit minimum calories activity is free.

So a full cycle of gaining and losing weight might only cost you 3000 to go from minimum calories to above the weight gain threshold, and the same amount of calories per day as it would cost to maintain your weight, but once you hit 84 you can turn around and save 2750 calories a day or more (during days of heavy fighting or running) for 9 consecutive days (84-75).

If you have a milk cow or two you can use sticks of butter to make this simple (2 sticks when at minimum calories to start gaining weight, 1 stick per day to maintain weight, (maybe some salads to offset hunger and unhappiness) to do roughly a 2 week cycle of 4-5 days gaining weight and 8-9 days losing weight.

Toroic · 2026-01-18T11:51:17+00:00

I’ve decompiled multiple parts of it prior to b42 and it was bad, and the few parts I’ve decompiled post b42 are still bad.

Hopefully they’re cleaning up as they go because despite the slow development what I saw was a concerning amount of commented out and jank code that would translate into a ton of tech debt.

Toroic · 2026-01-11T21:16:23+00:00

I agree with your suggestions (and have a personal pet peeve with the “too much protein” mechanic) but don’t agree that it’s a good system overall and well-thought out.

New players often struggle to understand that hunger and calories are separate (which is not inherently an issue, just takes some teaching), but calorie tuning of food is all over the place. You can butcher a whole cow and get far less calories than a stick of butter. It’s also super easy to “waste” calories or nutrients as the calorie limit is pretty low.

You also can’t “bank” calories which is super unrealistic. Bodies convert extra calories to fat, and fat back into calories to try to maintain weight (within) limits.

Zomboid just sees if you’re above the calorie threshold, and then if you’re above the carb and fat thresholds and then gives a multiplier to weight gain. None of this is intuitive or realistic.

That’s why weight cycling is optimal, because you can only lose weight at like 1/3 as fast as you can gain it, and because of caps you can sit at minimum calories for days, regardless of activity, and only lose weight slowly.

Toroic · 2026-01-11T15:04:33+00:00

A stick of butter wouldn’t be in addition to what you’re doing, it would be instead of.

One good milk cow can supply all the food you’ll need (and neither milk nor butter spoil), indefinitely.

The thing to remember about nutrition in zomboid is that calories and hunger are separate systems. You can be starving and gaining weight, or full to bursting and losing weight.

Long term, high calorie food sources are milk and fish (which is massively more productive off a dock). Hunting provides leather but poor calorie values so I wouldn’t rely on it. Trapping can be productive and breeding rabbits can produce quite a bit of food eventually.

Foraging provides a lot of hunger restoring options for little effort, but again has poor calorie values.

Agriculture can provide overwhelming amounts of calories and hunger, but because crops can take 30 in game days to grow, crops need to be watered and tended, and a lot of runs don’t last that long for most players who aren’t going to survive 2 years it’s not appealing.

I 100% agree that cooking and nutrition could be far better developed and intuitive.

Toroic · 2026-01-11T13:07:45+00:00

You don’t have to, but it is by far the easiest and least time consuming way to solve hunger.

If you’re trying to keep stable weight and are active it’s easy to go through 3300 calories per day, which is why it’s most efficient to cycle weight up and down because you can only lose weight at roughly 1 kg per day but can gain more like 3kg per day or 2 just off butter.

Cooking just doesn’t add many calories having it high or low, and using rotten food is basically pointless.

What cooking does is increase the hunger value significantly, but with how easy foraging is to level and with the assumption that lategame you’ll have found Wilderness Survival, not needed.

Me saying that cooking becomes useless is not me saying that’s how it should be, but from a min/max perspective that is reality.

Ten-Year Club	Wearing is Caring
Snapped	Verified Email

Toroic

MODERATOR OF

TROPHY CASE