ckob: Same.
That said, first thing I did with my current project was come up with a basic idea of what I wanted to do with it. Then I expanded upon it with a rather large document (something like 50 pages of mindless crap that only I could understand because it happens to use loads of terms that I made up during my last projects) detailing all aspects of the project, what would be required, and priorities. I code in a modular way, so everything is essentially a sub-object of the core (upon initialising the engine [yes, it's an engine] you are given the option to initialise its sub-systems, for example, the GUI, shader system, scripting engine, etc. so only what's neccessary is created- you can, of course, initialise sub-systems after the engine is initialised in the case that you need to start up one when needed). All of these sub objects rely upon information provided by the core system (which handles math, input, and the window), and typically they do not rely upon any other system outside of the core.
Anyhow... back to how I organize my projects. After writing up the documents on what's what and goes where, I design a few flow charts to illustrate how the systems work, what their relations to the core/other systems is, and what they need to handle their operations efficiently.
Then comes the part I enjoy quite thoroughly: coding. This consists of creating a project group in Protean and working on the highest priority systems first (the core being at the top, obviously- in the case of my latest engine, it goes core system, stack, math, string, buffers, and so on and so forth) until I get to the last and most insifignifigant piece of the project and finish it.
Throughout these steps I revisit the documents and flow charts to see if there's a way I could revise them to make them better and more descriptive. Appropriately changing code where neccessary.
It's a bit of a messy way of organizing a project, I think, but so far it has worked fine for this project.
That said, first thing I did with my current project was come up with a basic idea of what I wanted to do with it. Then I expanded upon it with a rather large document (something like 50 pages of mindless crap that only I could understand because it happens to use loads of terms that I made up during my last projects) detailing all aspects of the project, what would be required, and priorities. I code in a modular way, so everything is essentially a sub-object of the core (upon initialising the engine [yes, it's an engine] you are given the option to initialise its sub-systems, for example, the GUI, shader system, scripting engine, etc. so only what's neccessary is created- you can, of course, initialise sub-systems after the engine is initialised in the case that you need to start up one when needed). All of these sub objects rely upon information provided by the core system (which handles math, input, and the window), and typically they do not rely upon any other system outside of the core.
Anyhow... back to how I organize my projects. After writing up the documents on what's what and goes where, I design a few flow charts to illustrate how the systems work, what their relations to the core/other systems is, and what they need to handle their operations efficiently.
Then comes the part I enjoy quite thoroughly: coding. This consists of creating a project group in Protean and working on the highest priority systems first (the core being at the top, obviously- in the case of my latest engine, it goes core system, stack, math, string, buffers, and so on and so forth) until I get to the last and most insifignifigant piece of the project and finish it.
Throughout these steps I revisit the documents and flow charts to see if there's a way I could revise them to make them better and more descriptive. Appropriately changing code where neccessary.
It's a bit of a messy way of organizing a project, I think, but so far it has worked fine for this project.