- Feb 23, 2022
- 357
- 623
- Thread starter 7767
- Start date
- Jun 21, 2018
- 257
- 224
That escalated for no apparent reason. Bro just blew his load. Full unload boys
After skimming this whole automation talk, I'll add my 2c.
First thing Diconica, I've certainly done my share of "trying to help random more junior developer than myself do things better," and at a certain point if those people take the opposite view it's just not worth pressing further because you aren't going to change their mind. Eventually they might learn that you're right, and after a developer has had a few situations where someone more senior who they disagreed with in hindsight happened to be right, they tend to be more open minded. It's usually very difficult to change the mind of a developer who hasn't gone through that process, and most strictly-solo developers have not, although I do not know if this describes Mr. Unaware's experience or not.
Getting angry that someone isn't following your advice is not a good look. At the end of the day, why is this important to you at all? It does come across as kind of sad to be honest. No matter how right you are, you owe Mr. Unaware an apology.
To complicate matters it's also possible for more senior developers to give bad advice. Sometimes because of dogmatism. Sometimes due to a lack of breadth. Sometimes due to assumptions on how the more junior developer has built their systems, most specifically that everything else around the thing being discussed has been done "properly." If you don't have eyes on the codebase, that last mistake is an easy one to make.
The most productive thing you two could have done would have been to set up a screen share, look over the code, and talk about it. You keep saying automation, and Mr. Unaware keeps reiterating his philosophical aversion to that concept, but I'm not sure you're even using the best term. I really did skim, so it's possible I missed something, but it sounds more like you're suggesting general OOP and DRY best practices: having appropriate interfaces, inheritance, and polymorphism, with an architecture that facilitates easily adding and modifying traits while minimizing extra work. That makes sense. To the extent you're removed from that ideal you're left with difficult to maintain, bug-prone spaghetti. You're suggesting something that works "automatically" or functions in a "plug and play" manner, as opposed to an approach where each new trait requires a lot of manual work. That's all great as far as the thousand-foot view goes, but isn't much of a help if Mr. Unaware isn't already approaching things this way. If he isn't, then the problem isn't that he's misguided, it's that he doesn't know how to architect his systems better. Again, what would make the most sense would be to look over the code in a conference call and then, if needed, advise concrete, ground-level changes rather than a thousand-foot proclamation that boils down to " you should write better code."
First thing Diconica, I've certainly done my share of "trying to help random more junior developer than myself do things better," and at a certain point if those people take the opposite view it's just not worth pressing further because you aren't going to change their mind. Eventually they might learn that you're right, and after a developer has had a few situations where someone more senior who they disagreed with in hindsight happened to be right, they tend to be more open minded. It's usually very difficult to change the mind of a developer who hasn't gone through that process, and most strictly-solo developers have not, although I do not know if this describes Mr. Unaware's experience or not.
Getting angry that someone isn't following your advice is not a good look. At the end of the day, why is this important to you at all? It does come across as kind of sad to be honest. No matter how right you are, you owe Mr. Unaware an apology.
To complicate matters it's also possible for more senior developers to give bad advice. Sometimes because of dogmatism. Sometimes due to a lack of breadth. Sometimes due to assumptions on how the more junior developer has built their systems, most specifically that everything else around the thing being discussed has been done "properly." If you don't have eyes on the codebase, that last mistake is an easy one to make.
The most productive thing you two could have done would have been to set up a screen share, look over the code, and talk about it. You keep saying automation, and Mr. Unaware keeps reiterating his philosophical aversion to that concept, but I'm not sure you're even using the best term. I really did skim, so it's possible I missed something, but it sounds more like you're suggesting general OOP and DRY best practices: having appropriate interfaces, inheritance, and polymorphism, with an architecture that facilitates easily adding and modifying traits while minimizing extra work. That makes sense. To the extent you're removed from that ideal you're left with difficult to maintain, bug-prone spaghetti. You're suggesting something that works "automatically" or functions in a "plug and play" manner, as opposed to an approach where each new trait requires a lot of manual work. That's all great as far as the thousand-foot view goes, but isn't much of a help if Mr. Unaware isn't already approaching things this way. If he isn't, then the problem isn't that he's misguided, it's that he doesn't know how to architect his systems better. Again, what would make the most sense would be to look over the code in a conference call and then, if needed, advise concrete, ground-level changes rather than a thousand-foot proclamation that boils down to " you should write better code."
Last edited:
- Apr 19, 2020
- 367
- 269
Watch where you step...
Anyway, Mr. Unaware, I noticed the comparisons to Insexity. From what I've played, I find myself switching between both games daily now, cuz one offers stuff the other doesn't and vice versa. Insexity caught my attention when I realized I was gonna be using a masseuse. Instant win, one of my fav porn types is softcore massage table antics. Girl goes to masseuse, masseuse gropes girl, girl is unpleasantly surprised but ultimately gives in to perversion. Unfortunately Insex does that the opposite way. Customer expects more, masseuse needs the money and does it.
In your game, dangers of the city are more in play. Can't walk down the street without being anal fingered. Pass out on the street, and you probably aren't a virgin anymore when you wake up. Plus the background changes things. I'm an aristocrat with mad charm, who is also considered prey. Got the looks, smell like a rose, got money, and got a lotta pervs plotting her pregnancy. Also got a stubborn vaj that gives less exp.
Cheats are ON it says. Can they be turned off? Does using them affect the game? Like disabled saves, bad ending, no events... things like that? Or can I just use them with impunity sandbox style? I have the urge to #MaxMyLewd and get a street whore license, then go back to my current [2 Lewd virgin] self and walk around as a pure virgin aristocrat with a license to whore.
Thank jeebus you added zoom.
In Insex, all you can really do is work and sleep. Sexy stuff generally happens during work, which is similar to this game. But in this game I can do other things. In Insex all I see is "wish I had time to do this thing" coming outta my own character's mouth. I am currently doing those things in UotW.
Looking forward to Unaware in the City. About that: Is that a new ground-up project, or just a graphical overhaul of the current game?
Let me take another stab at this. The wrong abstraction is infinitely more evil than not having any abstraction at all, as I'm sure you're all too well aware Diconica. You never just tell a junior developer "abstract this." That can easily end in disaster. If it's an especially smart individual who lacks much real experience, they'll almost certainly come up with some unholy Gordian Knot that becomes a major stumbling block later on. If you're going to suggest abstracting some non/under-abstracted system, you should have some feel for the code first, and you should be at least somewhat hands-on.
My primary reason coming to this site was just adult games.Why is someone with your experience and knowledge spending his time on this forum? Sounds a bit sussy-wossy if you ask me. But I know nothing.
For a while I had a mod for Lab Rats 2. But after shit behavior on some people's part I stopped providing it on this site and helping with fixing the issues with the game.
Why offer advice to people so I can play better games. I don't just like making them I like playing them. I like seeing what others create. Which is why I was on flipcode.com when it was up. Why I run several tutorial sites and have tutorials online and why I have material used at multiple universities.
All in all it is a fair question you asked. We really never know who we are talking to on here. Most people tend to make a false assumptions about people they are talking to and themselves. Questioning is a better response than making a bad assumption.
You appear to have concept correct. The work it saves in setting stuff up. It can be used to generate automated stuff like he is thinking but the part it shines the most is in creating manually developed stuff because it creates all the boiler plate work for you.
Really it is just a variation on the observer pattern what we are talking about. In some cases it is called a manager class.
You can tailor it for different stuff. In my game engine I use it for a lot of stuff. I have a version that manages assets like images, video,audio it creates reference to them. All the loading and unloading his handled by the manager and any time something needs it it can access it in multiple ways reference, index, name, filename ...
It saves countless hours of work.
I use it in AI development for building stuff like traits, behaviors, actions, events, dialog ...
I use a version that is similar to the asset manager for my menu system, stores, generated buttons, images, sounds, text, fonts...
It saves on the time it takes to create an add new features and systems. It increases performance. It reduce memory issues.
I only have one area of code to debug for the issues. There is no shit like searching through a nest of a if else mess.
He's using unity. I'm assuming he is using C# with it. So it should be fairly easy to implement.
That said you are correct I don't know what his code base looks like. Implementing it in this game may not be ideal.
It might be something best saved for a new game if he makes one.
About a month ago. I converted another person code similarly. The work consisted of building the class to handle the work. Then we wrote a python script that is a simplified parser to convert the old nested if else to entries.
The point is you can automate most the work in some cases when converting over.
I remembered this series.
You must be registered to see the links
I haven't looked at it fully. But the concept of attaching functions or actions to objects is similar the difference is you are just attaching the attribute you create to the character rather than the object.
There may be some better videos or source out there. I'm not that heavely involved in using unity. My own engines, unreal and some others.
Last edited:
Funny.
I think that is more a factor of people learning to program in the last 10 to 15 years.
Back when people were required to learn ASM in school before other languages it was quite a bit different working with people from that time.
Honestly, back 20 years ago I could write an abstract short document giving a general over view of a programming concept with in a day I would have 20 people email me asking me if this is what I was talking about and maybe 1 of them wouldn't be right.
These days I could write a book with the source in it put it up on github provide it with an included disk ...
I would get several message asking how to download the code, I would have a dozen from people who tried to type it in and mistyped stuff and blame me for their mistakes.
How do I know that because I have books out and websites with the code on it including on github. That's exactly the type of shit I see daily.
- Apr 19, 2020
- 367
- 269
Super easy, barely an inconvenience. C# has a built-in implementation of the observer pattern called
You must be registered to see the links
, although I'll point out for anyone reading that 99% of the time you'll want to use Func<> or Action<> as opposed to a basic delegate. The functionality of the event keyword is to encapsulate a multicast delegate so that it can be publicly subscribed to, but only privately invoked.For sure. If more novel functionality is needed you might be able to accomplish something with reflection. Or you architect something new. But even if something like an observer pattern makes sense and is all that is needed in this context, for someone who hasn't used it before just pointing out that it exists doesn't mean they will be able to connect the dots and know how and where to implement it. It really helps to be able to look at the code and be able to point out exactly why something works poorly and a specific alternative works better.
Sorry guys, not gonna join the discussion on whether I know C# basics or gonna waste the time I don't have on re-writing my code because it can be better, but since you all are missing the point in the whole discussion, let me quote myself:
AwfulArchdemon Cheers, mate! But I literally answered this UiTC question last time:
He proposed me to lock trait X by picking trait Y, and I said no. That's it.
AwfulArchdemon Cheers, mate! But I literally answered this UiTC question last time:
That was a suggestion and I gave an example of how it can be used.
You also harped on how shitty automation was while not understanding what was being discussed.
The main discussion at this point is around design patterns. He was just making an observation on the one issue.
You must be registered to see the links
- Jun 21, 2018
- 257
- 224
Graphical overhaul. This new game is going to be an upgrade from the old one. Effectively the game and it's gameplay is the same, and this next update is a massive visual upgrade, before addition of new content resumes. I guess it's different on a development/technical level as well
Heh, sorry if anything came across as demeaning there. Wasn't my intention. While talking with Diconica I've granted a few assumptions for the sake of discussion and posited a few hypotheticals, but none of that was meant to say that you definitely fit any of those assumptions or hypotheticals. I probably should have sprinkled "I don't know if this describes Mr. Unaware or not" a few more times in there.
FWIW, I went and decompiled 0.27c so I could see what all the fuss is with this trait system. Traits themselves are pure state, no logic, while there's a controller that goes through traits and modifies the character. It's straightforward, concrete, readable, not too clever, not too verbose, and does nothing like what Diconica and I have been talking about. It's perfectly fine for what it is. I would not encourage you to abstract it or rewrite it to use an observer pattern. I don't see the benefits of that move outweighing the costs. The exception is if you want to expand the usage of traits to more than just the main character, so for example, if NPCs could also have traits. At that point I think your implementation will become difficult and a more OOP approach will work better.
Because there was some talk about locking out traits, I will point out that if you decorate ETraitsPositive and ETraitsNegative with
You must be registered to see the links
, there's a very straightforward change you can make (which you'll spot when you read the docs) to allow a trait to lock out multiple other traits, and generally be more expressive when multiple traits interact or are conditioned with one another. The Unity inspector will then render fields of those enums like, for example, the Culling Mask on the camera component, where you can select all items that apply.The issue with design patterns is that they give developers the ammunition to ruin their projects while feeling clever. In any instance where patterns are used but aren't needed they make code harder to read, increase cognitive load, and while they add flexibility in some areas they also create a huge amount of rigidity elsewhere. The wrong way to use patterns is to pick a pattern and then design a system around it. Too many programmers, especially academics lacking real experience, do this and it ends in disaster every time. The right way is to be aware of patterns and only use them as the need arises and only when a specific problem has manifested that you know is a good fit for a specific pattern.
Last edited:
I didn't see anything wrong with what you said.
I on the other hand just fired back at him because of his attitude. Granted I could have just ignored it and let it go. The primary reason I replied is he made comments about programming aspects that was purely false. I figured if someone else reads it they might believe him.
No disagreement with this. Even made a comment a while back it was only a suggestion that it may be more suitable for a future game. Going back and changing something can be work. I hadn't looked directly at your code. I can tell from how it runs what I will basically find.
While yes this is good when it comes to having lots of characters. There is another place it shines even more. When you want to add more functional changes without trying to rewrite everything. If you looked at the video I linked in the previous one you see they add new functions based on it being attached to various objects. The AI comes in the room, it gets the list of objects, goes to an object and the functionality is contained there how to use it. That however is a limited version. You can have the AI keep the functionality and store it. You can also make the functionality extremely complex. Lets just say it can allow you to build an AI that can learn new routines, adapt them and trade them with others even very complex routines.
Patterns are just a tool. You should always just use the right tool for the job. A design pattern isn't always the best choice.
I think most the issues with programmers is in how we teach these days. They don't place enough emphasis on structural and functional behavioral recognition instead they focus a lot on memorization of stuff. This leaves people who can use something when it is something they done similarly to before but it means when it isn't they end up struggling.
I'm from he old school days as you know. When you have 48K of ram. You learn to do stuff small and efficient as possible.
The less code you write the less chance you also have of making an error. It also means you have less code to debug.
I use a design pattern when it is the most efficient way of doing something.
- Apr 19, 2020
- 367
- 269
Mr. Unaware I keep waiting for this roommate who's supposedly a woman and 2 guys stopped by. No one ever came by again so I reset the roommate data on my phone and both guys came back again on the same day, but my girl's waiting for a girl.
How long does it take for her to answer the ad? Does something need to happen first? These guys are quick to show up but a week went by after them and no girl ever showed up.
How long does it take for her to answer the ad? Does something need to happen first? These guys are quick to show up but a week went by after them and no girl ever showed up.
His attitude was fine. He kept his cool and you didn't. To the extent you believed his responses might mislead others, there was a nicer (and more effective. When you blow your lid you become the opposite of compelling) way to go about offering an alternative view. But believe me when I say, no one is going through that conversation with rapt interest outside of its participants.
Problem is there are so many tools and no-one knows all of them. Of the ones we do know, we are more comfortable with some than others, and we tend to gravitate towards those. Or we gravitate towards tools that we're learning so we can develop proficiency. Design patterns are powerful tools for specific jobs. My issue with the way they're used nowadays is threefold:
1) when they're taught too early (especially academically) and with too much emphasis, which they often are, they get abused.
2) design pattern abuse is one of the worst things you can do to a codebase.
3) the more important patterns are things you can and will eventually develop yourself, or find out about when you Google a specific problem, without ever picking up GoF, and discovering a new tool this way is much more enlightening. In the meantime while you figure things out, you won't be murdering codebases by abusing patterns.
Diconica I can clearly see that it was never about me or my game, but all about you. You are just desperately seeking attention. Though it made me laugh when you mentioned that others people behavior made you drop modding. That was a good one, since I never pussied out from modding or game making due to other people behavior, and I certainly won't drop this one either. Anyway, I'm done with you. Bye bye!
fakehb Thanks, but the trait system works as intended and I don't need to change it.
AwfulArchdemon 3rd flatmate (Rachel) isn't in the game yet, so you can meet only those 2 guys.
Now, would you guys kindly stop making an off-top? It's a hentai game thread.
fakehb Thanks, but the trait system works as intended and I don't need to change it.
AwfulArchdemon 3rd flatmate (Rachel) isn't in the game yet, so you can meet only those 2 guys.
Now, would you guys kindly stop making an off-top? It's a hentai game thread.
I still do the modding I just don't provide it on here or help the group on here fixing bugs any more.
I share it with those who I get along with.