I think in some ways, the more you can separate things out into `modules` that are sort of self contained and not too (if at all) dependent on each other, the better, because then you can pretty much work on parts without having to worry so much about it breaking all kinds of things. Organization is pretty important in a bigger project. For me I would probably write some stuff down and get a sense of the total project, what it will basically include, and how you can break that down into parts, and then sort of build around that. That's definitely better than going with a procedural spaghetti mess. You don't have to try to be an object-oriented purist, and although OO helps the programmer it doesn't necessarily help performance sometimes... but some balance between the two is good.
Also when the project is large you might not really know ahead of time how certain parts of it are going to work or how it needs to be structured. I'd say you need to pin down the areas that you really need to know about `from the start`, e.g. like networking or if you're going to use some kind of large spacial partitioning scheme or something like that e.g. a quadtree with all objects in it or something, then you need to design that first and get it right cus it won't be easy to convert it later.
Overall I guess make sure you are confident about the big stuff that you won't be able to change later, and go from there.
|
