codeyperson
Low level - I'll write up the structure of what I want in the form of a set functions with defined inputs and outputs but without the implementation detail. If I care about any specifics with the functions I'll throw some comments in there. And sometimes I'll define the data structures in advance as well.
Once all this is set up it often spits out something that compiles and works first try. And all the context is established so iteration from that point becomes easier.
I think he wants to scare people a little in a somewhat controlled way to onramp us to this new reality as fast as possible.
50ms of input lag on the other hand is very easily noticeable. And makes games unplayable for lots of people.
Don't believe tabloid media. No it wasn't 'totalitarian'. I can't take you seriously now.
But I’m sure he secretly enjoyed the praise somewhat.
I think you could remove the UI options at the bottom entirely.
Instead have the user click on the adjacent squares directly. Basically if I click a red square on the board, that would be equivalent to selecting the red square in the UI options.
Then add have a hover state that indicates what is going to happen after they click. And make everything bigger such that so the user can't avoid mousing over the squares. If the hover state is good enough, it should teach the rules without the need for instruction.
Oh and make the color blind option the default / ditch the squares. The emojis look cooler.
Currently the probability of each tile is local * sphere. A simple approach would be to add some perlin noise on top to dictate different biomes, with each biome having their own tile probability distributions. Then the new tile probability becomes local * sphere * biome.
So in the ocean biome you might be less likely to get houses and other large structures. But islands and grass huts are ok. And obviously water tiles get a large probability boost.
Or… what if we took the tile approach further and have various scales of tile. Perhaps biomes are larger tiles (8x8) which also follow the same algorithm so that biomes have relationships to one another.
Personally, I like to continuously implement and clarify in small tight loops. It might look something like: implement a rough structure with lots of empty functions and very basic control flow. Ask questions. Restructure. Ask more questions. Restructure again and add implementation detail. Etc etc.
This way of working is tied with my thinking. It reveals the problem to me over time instead of all at once. I get a deeper understanding this way.
There is an assumption by some people that my process is wrong. They would argue that I should instead break the problem down on paper, or in my head, or using test driven development, or with design documents etc etc. But this is the process that I've found works best for me.
I can enforce a particular process to please interviewers (and I have). But solving the problem becomes much harder.