allthesethings

I definitely got a sense of something like that while visiting earlier this year. It's a place where things are working as they should, at least on the surface, so there isn't much to complain about, but it's also built on momentum and institutions left over from when Japan was the industrial power of Asia, stuff that just hasn't broken yet, so nobody has reassessed it. And there's a conflict likely to emerge in that setup, but it's not going to be a full-blown crisis until later, so "contentment" rules the day.

Contrast with the USA; the crisis - social, economic, political - is here, and it has been for a while. Everyone has something to scream at each other about.

Civ Revolution is the "streamlined" version of the game for consoles. It's a good introduction to the series as a whole and a joy to play in shorter sessions. (I haven't tried its followup)

Of the mainline series, 1-4 is a straightforward progression that doesn't rock the boat too much. Civ1 is still fairly easy to get into but has a lot of crude, unbalanced or easily exploitable elements(e.g. the AI has a random chance of building a Wonder of the World every turn instead of having to actually allocate a city's production to the project over many turns like the player). Civ2 has fewer exploits and more polished 90's-era graphics, but now the number of units and cities explodes into a very tedious, micromanagement heavy late game - the degenerate strategy of Civ2 is called "smallpox" because it involves spamming a lot of small cities across the map. Civ3 added a lot of additional balancing and finetuning and graphical flair, and Civ4 does more-or-less the same. I have trouble remembering Civ3 after Civ4, really. But the basic feeling remains consistent: Most Civ strategy is focused around optimizing fine details across your entire empire towards a focused direction, so that you survive now and gradually get ahead of the AI players later. And the late game slows down because a lot more is going on in each turn. It gets hard to keep track of things.

The games after that make more drastic changes. They still feel like Civilization, but with major changes to the cities, board and combat components that differ from the "Empire" model that had been employed since the first game. The ways in which you have to make tradeoffs of "now" versus "later" or the kinds of capabilities to emphasize are more varied. And they have higher system requirements - Civ5 at release was quite heavyweight and buggy, and Civ6 has gone similarly. But these are things that everyone expects will get smoothed out with time. With the newer Civ games, it's more a case of the designs just being different versus being definitely better, with emphasis placed on different things.

Likewise, an argument can be made that developers should reach for Excel more often, because Excel is what the business world knows and uses.

We have so many great, specialized tools. But the act of development often bifurcates into "problems that don't have to scale, or even present a great interface" and "problems that need extensive customization at every layer and support millions of users" and our stacks reflect that.

So tooling choice is often more dependent on maximizing leverage while setting appropriate cutoff points for scalability - in almost all production scenarios you are better off simply to design the system down to the featureset of available off-the-shelf tooling and anticipate a hard break where it migrates upwards, versus thinking you have to boil the oceans immediately so that all facets can be transitioned smoothly and all features are possible right now.

The problem with making guesses about any of the technical decisions is that this is a software project with hundreds of people in multiple studios. There are no design efficiencies to be had here: somewhere within those hundreds of developers a rationale for taking on a more complicated architecture arises - a specific feature, or combination of features, that causes a cascade of requirements inflation.

For example, one reason they might want higher precision is for editing and processing persistent data: a need that doesn't apparently have anything to do with the physics simulation, but subsequently ripples down into "well, if we want to allow editing in real-time, then..."

It is interesting work, but nothing that you would want to emulate as a best practice for making a Better Game. It's just a result of the software aspects being scoped and executed in such an uncompromising way. A good majority of the work to date has been on the organization-building work of teams and processes that can execute at this scale.

When the skill gap is too large and the junior is too inexperienced(and with school projects we're talking about a skill gap that could be "my first day ever programming" versus "2000+ hours over a few years") there isn't going to be collaboration going on, just mentoring and handholding. But there are things you can get out of that process too, in setting up an environment where they could get up to speed, are given appropriate forms of challenge and encouragement, and don't fall into typical student tropes of procrastinating and leaning on you while not really understanding the material.

Here is a particularly devious strategy: write simple code that you already know works - nothing too abstracted, just the most direct route to a solution you can come up with - and then add a bug to it and ask your partners for help, so that they have to read and debug your code and work really hard to understand what's going on(i.e. build up all the most fundamental programming skills). Then "discover" the fix at the last minute to get the grade, if they run out of time. Everyone gets the grade, plus you will have partners that are slightly more competent each time.

I mean, there are still plenty of folks playing games with obscure puzzle solutions and little design for accessibility. It's just that they've moved to different venues for them, like ARGs.

You don't necessarily have to convince the manager, given a few prerequisites: it's possible to get at the code and build it locally, and you're willing to go around the team and do testing on your local machine. Not an easy task, unsupported, but it can be chipped away at over time, and if the project really is as stuck as it's made out to be, there will be parts of it that aren't changing rapidly and make for good low-hanging fruit.

Gradually that test suite will accumulate enough stuff that all OP has to do is walk into work, pull the latest, and make a few easy fixes before they finish coffee. They will look like either a hero or a monster, depending on how the politics work out. It's risky, but either way something will have been stirred up.