I think its really just the trappings of game development being full of tribal knowledge.
The tutorial probably should have instructed you create box colliders for walls (giving a greater area for the physics engine to catch collisions) rather than a simple plane/quad which would lead to the exact issues you had, or at least explained why a box works better than a plane.
I guess you have to balance the necessary information with overload in your tutorial or at least have an aside or additional reading that really helps understand many of these internalized understandings.
That's not a bug just an inherent problem with using very thin colliders with a discrete collision detection system.
It's not a Unity problem and Unity allows you to configure continuous collision detection to prevent tunneling https://docs.unity3d.com/6000.3/Documentation/Manual/Continu...
Game development is full of domain knowledge like this because games need to make compromises ensure completing simulation updates at no lower than 30Hz.
For a while now Unity has an incremental garbage collector where you pay a small amount of time per frame instead of introducing large pauses every time the GC kicks in.
Even without the incremental GC it's manageable and it's just part of optimising the game. It depends on the game but you can often get down to 0 allocations per frame by making using of pooling and no alloc APIs in the engine.
You also have the tools to pause GC so if you're down to a low amount of allocation you can just disable the GC during latency sensitive gameplay and re-enable and collect on loading/pause or other blocking screens.
Obviously its more work than not having to deal with these issues but for game developers its probably a more familiar topic than working with the borrow checker and critically allows for quicker iteration and prototyping.
Finding the fun and time to market are top priority for games development.
Do you not plan to go grocery shopping or do you always do it on the spur of the moment?
I'm not sure what the issue is. If you need to pick up something small from the store on the way somewhere you can definetly get a small always carry on you bag that will fit in a pocket.
When you're going to actual go grocery shopping just bring the bigger reusable bags. If the purpose of the journey is shopping it's not inconvenient to carry those bags and you'll have to carry the grocies back anyhow.
I get that it's less conventient to have to remember a bag but it's not some insurmountable task and it does seem to reduce the amount of plastic bags that get caught by the wind and blow around as trash.
There's more of tangeable value from buying property in virtual game worlds in the sense people get to use those property or items when normally in the game they would not be able to.
For things like ship preorders on Star Citizen it's much more of a risk that the value will ever be delivered but it's still offers more than just a note of ownership of an abstract token on a blockchain sequence.
If someone decides to honor these tokens as proof of ownership of property/items in the real world/ a virtual world then they may offer some value but there's a very great risk that will never happen.
When you reallocate your array you will in memory have your old array and your new larger array while you move your data over. At the very least you're using 2x and the extra memory for your expansion.
For your other points if you'd mentioned them in the interview you'd probably have been better received. Copying is really only that fast for POD objects (your objects copy constructors may need to do reallocation themselves or worse) so if you're suggesting a general solution you should be aware of that (or at least mention move constructors if they were available at the time) .
I would be surprised if any of the games you worked on actually shipped with an amortised resize of dynamic arrays (at least not for anything that didn't matter in the first place) so I don't know why you'd suggest it as a general solution in a game dev context.
It's not great to have to double your memory usage while you reallocate your array. On more limited devices (see games consoles or mobile devices) you'll end up fragmenting your memory pretty quickly if you do that too often and the next time you try to increase your array you may not have a contiguous enough block to allocate the larger array.
There's also the cost of copying objects especially if you don't know if the objects you're copying from your original array to the resized array have an overloaded copy constructor. Why copy these objects and incur that cost if you can choose a datastructure that meets their requirements without this behaviour.
If you're holding pointers to these elements elsewhere re-allocating invalids those, and yes you probably shouldn't do that but games generally are trying to get the most performance from fixed hardware so shortcuts this will be taken, its a least something to talk about in the interview.
I can see why they were confused by your answer as its really not suited to the constraints of games and the systems they run on.
Exactly, the smaller your chip is the more you can fit on a silicon wafer.
If your chip is too large it can even make it practically impossible to manufacture at scale due to the increased chance of defects as your chip size increases.
Yeah I thought it was just a scare tactic and something the licence 'enforcers' could say (i.e. 'our detector van says you have a tv') to try and catch people out.
They surely can't get too much of a return paying people to check up on only potential licence 'evaders' so investing in a fleet of actual vans with drivers and operators would further reduce any return.
The M1 is on a 5nm process from TSMC. I'm sure if AMDs Zen 3 (eg Ryzen 5600x) was also on that process instead of 7nm the perf/power ratio would be similar
I'd second ImageOptim on Mac or PNGGauntlet on Windows https://pnggauntlet.com .
I'd be careful using pngquant as well, as it will only ever give you 256 or less colour image or your original image back. PNGGauntlet and ImageOptim will optimise your PNGs losslessly.
I believe there's a python static webpage generator that's been around for a while that already makes use of that name: https://github.com/thanethomson/statik
They might be concerned that one of 'you' had their consciousness terminated prematurely, if only for them wondering on the next transport if they get to continue experiencing life as 'you'.
The tutorial probably should have instructed you create box colliders for walls (giving a greater area for the physics engine to catch collisions) rather than a simple plane/quad which would lead to the exact issues you had, or at least explained why a box works better than a plane.
I guess you have to balance the necessary information with overload in your tutorial or at least have an aside or additional reading that really helps understand many of these internalized understandings.