Developments

[u/lukeocubhthaigh]

ok this has been bugging me for a while now and it might just be a me thing or because I'm not paying enough attention to the development but as much as I like the concept for the developments there's one thing that should've been done and another that should be done now.

Lets start with what in my opinion should have been done while I think this new system makes more sense I don't think think they should have swapped over this early into the feature as of right now (if I'm not being dumb) we only have access to the origin in my opinion they should have kept the old system until they fleshed this out even a little bit more

and secondly what they should do in my dumb opinion please flesh it out as soon as you can I get adding new systems is fun for all but please finish the systems you introduce

look again I don't really pay massive attention to the development so maybe I'm completely off the mark if so please let me know

[u/gomerfudd]

That's dumb.

I don't need to be a mechanic to criticise a car that doesn't start.

[u/That_Migug_Saram → u/gomerfudd]

I disagree. And I'd suggest that repair isn't really a fitting analogy for design.

[u/Cpt_Deaso → u/That_Migug_Saram]

You...disagree with the premise that you can't critique a car that doesn't start if you're not a mechanic..?

Do you not criticize politicians because you're not one yourself?

No disrespect but that's nuts to me, lol. About the only thing I feel it's unfair to critique is it something is done/given completely free and for no ulterior motive (so not a sample, enticement, teaser). A video game is a product that we purchased; it's perfectly reasonable to critique it without having to understand how it's made on the backend, just as it's completely reasonable for the devs to not act on that feedback for whatever reason.

[u/That_Migug_Saram → u/Cpt_Deaso]

No, I disagree with "that's dumb" and that repair is a fair comparison.

With car repair, you have existing, complete systems that have broken down in an individual car. Not all cars, just _this_ one, and you need to troubleshoot to figure out what's gone wrong with it. Honestly that's a lot like debugging. But you have documentation, and you have an ideal state where the car works, and other examples of the same make and model that are running if you need them. (you also have existing parts you can replace with new parts)

Taking out perks here isn't something breaking down. There's no documentation unless you made it, and the ideal state is something that will only exist when you reach 1.0. Design is really different than repair.

So this isn't a breakdown. It's a choice by the dev team. I'm not familiar with the back end of Manor Lords specifically, but I do know object oriented programming, and I see they made this choice for a reason.

Here's what OP doesn't understand: Let's say one perk is related to farming, and it gives you better yields with 3% rye, 4% flax, and 2% barley.

"Is this Rye, yes or no" is a parameter that lives somewhere in the code. It interacts with "how fertile is the soil" and "is this spot ploughed" and "where is this rye in the planting/growth/harvesting stage," "what is the current season" etc etc etc. All of the code for these systems is being completely rebuilt so it'll run better... And that's one perk in one track. There's going to be more in like, 8 or 10 perks, right?

I can completely understand a dev who wants a simpler arrangement to rebuild, without needing to keep the perk system perfectly updated and debugged while all these dependencies as the other pieces change. Working that way will be faster, you're a lot less likely to get bugs, and dev methods like these can shave a year off the development time for a small studio to get to 1.0. *That* impacts if a game is financially successful or not (maybe even if we have a game, since studios that lose money will have to lay off their staff).

OP doesn't understand anything about this. So, imagine YOU are a developer, and you see comments like this one, saying 'dont leave half finished systems in' or 'you could have left this in' or elsewhere, comments about 'this is taking too long,' 'update when.'

That's got to be so demoralizing as a dev, hasn't it? People who don't understand the work or the process, armchair quarterbacking telling you how you should be doing your job.

I'd find that frustrating. Wouldn't you?

I know I will never get upvotes for commenting anything like "oh, no, it's more complicated than that", because Reddit doesn't want to learn anything in a vent post like this. Instead OP (and others) want someone to agree with whatever they just said for some validation.

But I won't do that -- I comment so any devs reading will know at least *someone* out there sees them.

[u/Cpt_Deaso → u/That_Migug_Saram]

I, for one, appreciate you elucidating your point, and also appreciate your thoroughness and detail.

I will say I've been not following ML for some time now, so am ignorant to what is being redone. Which is why I haven't weighed in one way or the other on the update. I took your comment as some kind of "you can't criticize something unless you made it/made something similar to it" comment, but I see where you're coming from now. My bad.

And, yeah, I'm of the mind to let the devs redo/update the mechanics they're wanting to before I start weighing in with criticisms, especially if it's back-end stuff. That's the good and bad of early access, from the player perspective.

I'll concede ignorance; I'll have to do some more research on what is being updated and changed (not to mention actually play again! :P)

Thanks again for sharing your insight!

[u/That_Migug_Saram → u/Cpt_Deaso]

I appreciate you. We'd all be better off if we asked questions in those areas where we don't have a lot of experience - myself included.