So maybe we should also consider the other direction.
Well, with the risk of sounding negative, bottom up isn´t really a design philosophy, more of a design by accident.
Most project i seen that claim they use a bottom up philosophy actually run a broken and poorly managed top down. I most cases there actually is some kind of top administration, i.e. delegation of graphics, code and sound. I Never seen a example of a multi person project with a successful bottom up philosophy, and I can really find any example of it at all. Well of cause a bottom up can be used in a block of top down project. Most people tend to wana use bottom up because its easier to start with, and of cause, in small project bottom up is quite easy in total.
your credibility drops sharply when you start talking about databases
A database is a database what ever you wana call it. I call it a database because that is what it is. I didn´t dismiss anything. Start micromanaging to begin with is always wrong. The project is in its infancy what every you want to believe. I would bother more about your credibility than my about management.
How about starting at the hard end and work your way up, easing things up?
because it does´t work that way, If you start in the hard end it will only get harder. Well off cause, it will become harder in the easy end to, but then you end up were you began in the first place.
Or, starting somewhere in the middle, understand the problem domain and then design the solition naturally
Then you just fool yourself believing you solving the problem while actually creating a top down project inside of a bottom up.
so both technical constraints are taken into consideration, but without gory impelementation details obscuring the view?
There is no problem considering technical limitation in a top down philosophy, actually, quite in contrary, that´s the only way all limitation is visible from the beginning. The whole point of design trees is to make every detail generic, thow obscuring the view, making it possible to think out side the box. Sounds like managing mombojombo? Well it kind of is, but it works. Its not about doing what feels the best, but do what actually works.
Implementation requirements _always_ incur additional constraints on the design.
That is exactly why every detail is limited by boundary, thow making boundary's in the limitation.
What does the physics engine demand? What does the economics engine demand? What does the routing engine demand? With bottom up, you don´t actually know to your finished. With top down, its easily divided and is possible to simply decided it.
Instancing and batching place certain constraints on the design of the game world. If you omit them now, then you'll end up with a ton of workarounds for problems which those constraints place.
With bottom up, yes, top down, no, then you can simply ignore them, no rework needed.
It is wise to design an uniform way of displaying trees and buildings that will separate those classes of objects from themselves. At the same time most trees can be efficiently rendered using shader branching and exploting the cellular nature of the game.
That´s exactly why top down is to prefer, because then you can treat every object in a optimal fashion for the different process. I have a problem with how you thing, your seems only to be concerned about graphics.
Notice also that towns and forests interact with the player differently, thus constraints we placed will have ramifications in the complete gameplay.
Well, have you actually thought about that before you wrote that?
This _never_ works.
It does work, because I have tried it, its actually how all big software projects work. Well, of cause, its not the solution to everything, but it help progress along quite nicely. At a point, the blocks have to be interconnected and run in larger blocks and larger. Well, how do you know it don´t work, have you tryed it?
Firstly, we already know the high and medium level requirements. The software structure is also more or less known. What is required is someone, who is not me, that also has that knowledge and can route required software tasks to other coders.
What you really are saying is that you actually don´t know anything. You cant route workloads with out proper planing, it don´t work. Well, try it all you like, it wont work.
Im I hard? Maybe, but do you want to know the touth or not?
You might be a great coder, I don´t doubt that, Im a very bad coder, I know that, I never clam anything different. Its not your coding skill that's the problem, its the managing skills.