jefferytitan

Might I suggest that parlaying is only an option when your opponents (as a group) make it an option. For example, if you're proving too dangerous to kill, there's not enough profit in it for them, there's a bigger third-party threat (such as a saber-tooth tiger), or they are generally too tired/scared/demoralised. In that scenario there would be some visible/audible signal that they were willing to negotiate and you need to initiate at that moment (or at least generally not screw it up by attacking them).

I have experimented briefly with this. I did a far pass with near=100,far=10,000 then cleared the depth buffer and did near=0.1,far=100. It looked great except for some popping around the border, so I tweaked it so the two ranges overlapped slightly. Problem solved. I'm not sure how the framerate works out.

If you're writing software using object-oriented techniques, you rarely need getters and setters. Conversely, if you have a lot of getters and setters, you're not using object-oriented techniques, you're doing structured procedural programming. Don't fool yourself that because you use the 'class' keyword you're necessarily doing anything object-oriented.

An object-oriented ball doesn't ever need something else to tell it what its size is. Nothing else needs to know its size. It knows how to collide with walls and paddles. It knows how to draw itself.

I really like the way you stated that. I guess I have some thinking to do about the way my "objects" handle themselves.

Yes and no. I agree that other classes shouldn't be calculating using the ball size, e.g. doing collisions for the ball, etc. However no class is totally self contained. The ball needs to get it's size from somewhere, e.g. a constructor. Changing the size at runtime could be useful, e.g. power-ups that make it easier/harder by changing the ball size.

The hardware requirements aside (a field I know little about), I think people expect an AI to passively sit there being fed data and then kapow it's alive. Our intelligence (and that of animals) is very embodied. I think that our body is what allows us to get the continual feedback that high quality learning requires. Every time we move a muscle it affects our whole body via physics, which affects all our senses, so therefore there's a very tight and high bandwidth learning loop. Now I'm not saying that there aren't other good paradigms, but we know this one works.

Conversely our passive neural nets make screwball mistakes like learning from satellite photos that a tank is present if it's a sunny day because all it's tank training data was taken on a sunny day. I'm not surprised. It's getting one bit of feedback (present, not present). It really knows nothing about the properties of tanks or how you interact with tanks or why they matter. Light vs dark was the easiest neural net that matched the training data.

I particularly agree with SoTL.

Beyond that, clarity. Some things are very simple, or well understood in the industry. You won't know which things. In that case let them get on with it. If you want something more custom, it gets tricky. Some programmers you'll tell to do something and they'll just start. Sometimes that's a danger sign that they're making lots of assumptions. Or you'll tell a programmer what you want. They'll ask you to explain in more detail. You will. They'll look puzzled and ask for more detail, etc etc. For example, if you say you want a character to act cute:

Artist: Make the character act cute.
Programmer: What do you mean by cute? Big eyes and cute noises?
Artist: No, ACT cute.
Programmer: You have some animations you want me to play?
Artist: Well yes... but no. Like very happy but easily scared.
Programmer: Scared of which things? I can set up a system so you can tag which things it's scared of...
Artist: That's going to take an awfully long time tagging things... any other ideas?
Programmer: Er, scared of enemy characters and fast-moving objects? But we'd need to decide HOW FAST is FAST and if there are any exceptions. Also we'd need to add a sight system so it knows which enemies to be scared of... unless it's psychic? Psychic would be easier, just all enemies onscreen or within radius X. Hmm, but maybe disable this in cut scenes or things could get pretty trippy.

etc etc. Programmers have to (or at least should) consider all use cases, which is why the job can be difficult and pedantic. ;)