While working on switching the new game/instant action/tutorials over to reading data from xml files instead of being hard coded into the executable I needed some more info added to the save game file – now that research was being read in via xml I needed the save game file to have a link to the research file. So as usual I added it in to the save game file as plain text, predictably the game crashed on a load, my method of saving and loading is very primitive and relies on an exact sequence. The crash was caused due to me not obeying the exacting rules, usually I’d look through the code and mirror the save/load, or find some typo, but this time I decided to do away with the primitive method and switch over to the xml tags method as I’ve been doing for quite a while now.
And after two days of fairly boring coding in between spending time with relatives, I’m to the point that saving and loading work again, but are most likely very buggy. The good news is that crashing on loading should be mostly a thing of the past, however having the game crash during this stage of development isn’t always bad, it immediately told me there was a problem, and usually led me to where the problem is fairly quickly. Still this method is better, is much more flexible, easier to manage and will even lead to save games not being incompatible with every little change I make – which will be very handy during testing.
Now that the save game files are xml they are very human readable and thus editable, I’m not sure if I’ll throw in some protections against editing the save game files, all the other data files are easily editable for modding so there may not be much point, but we’ll see.
I’m itching pretty bad to add something substantial (and more creative coding wise) to the project, once the holiday season is over and I still have some days before another semester starts I’ll focus on the AI upgrades.
Progress is going to slow down a bit, Christmas is coming up which traditionally would be a big boost to me since I tend to take a lot of time off, but with Christmas this year came a guest and lots of sightseeing and activities.
So when I do have time I mostly stick to small tasks. That don’t require too much creativity/thought, but mostly visual observations on things that are obviously missing and/or need fixing.
Asteroids now spawn “baby” asteroids when hit by fire. When destroyed an asteroid may split into one or two pieces.
I’ve worked on objectives, rewards and triggers a bunch. Refining them, adding to them, that sort of thing.
Hmm… this could also be a good time to do bug fixes… maybe I’ll designate a few hours here and there to do that.
While re-vamping the start new game/start tutorial system I thought that the first “flight basics” tutorial shouldn’t include an asteroid base – to cut down on complexity and laser focus on the tutorial objectives. But a barren map wouldn’t be appropriate either, so enter asteroids. I’ve been meaning to add these since forever, but finally got the motivation to do it. There are a few different types – ones that move and ones that don’t – the movers move depending if your ship has enough mass to move them when there’s a collision.
The future of these objects yields some neat possibilities – shoot larger rocks to make smaller rocks. Particle effects around bigger ones – dust clouds, smaller rocks, hollow asteroids and quite a lot other neat potentials.
Via the battle editor duplicate button I can quickly generate some fairly “OK” fields, the battle editor automatically randomizes the rotation of the few rock models that I have so far, so that they don’t appear completely alike. Even at this very basic state of asteroid field generation they add a lot to the emptiness of space. Now to teach the AI to avoid them…
In other news, there are now 3 new ship models, 1 new station model, about 5 asteroid models, a few new turret models, new torpedo models and another station mostly done. So content wise we are heading in a good direction as well.
Did a lot of behind the scenes overhaul, got rid of a lot of noobish programming practices – using strings (eg: ship names) instead of their memory addresses to identify/compare/assign objects. The newer method is both faster (though CPUs are so fast it doesn’t really matter) but also easier to debug and error correct.
I was about to overhaul the AI, but I felt somewhat hesitant, I didn’t have the exact method in mind so I wanted to hold off a bit so I did a few battle editor changes, you can now specify targets for ships, and link stations to bases (so that a shipyard can produce ships using the base’s resources). Also you can specify backgrounds and light parameters in the generated files.
Next up I decided to tackle tutorials, they’ve been text files for a while now, but not in “xml” type format so I decided to convert them to make them easier to maintain. This will also impact objective files for all game modes – and basically overhaul how games start and load, before game starts were hard coded, after these changes they will be read from xml files meaning that they will be open for modding and easier changes.