I recently reached Step 10 - Place Dominant Gas Giant in my quest to automate Jon Zeigler's Architect of Worlds star system generation system when I read his post on how reality is impinging on his development plans. While I agree with his approach, it got me thinking about how I want to deal with this particular issues and future updates to the program.
Something I have done from the start is break the program into functions for each step with a main function that calls them to build objects that are linked via parent-child relations with the system object as the root. For me, the advantage of this approach is twofold: I can go back and update individual steps as need be and I can tell where in a star system any given object exists by following its parents up the tree. Conversely, and how this may end up working in the long run, I may have to go down the tree from the parent, pulling information on each child and their children to fill out a report on the system.
This all brings up my thoughts on eventual data storage. For now, the program just outputs to the console in not-that-ugly format that I can personally read easily. I am convinced this is how UIs like that of xfoil get made. So eventually, I plan on saving the generated data to tables in a SQL database and creating set of reports that generate pretty, easy-to-read datasheets on the system as a whole, binaries, stars, planets, moons, etc. The idea is that the generator program is run and then the database is opened in MS Access and reports run.
As I have said before, I do not know if I can pull this all off with my current degree of programming knowledge and skill, but I am hoping that I will grow in capability throughout the course of this project. So if anyone sees any issues with my approach, plans, or otherwise, please say so in the comments. I am looking to learn through this.
No comments :
Post a Comment