Bug fixing and text formatting —
Started ripping out the temporary text lines I’ve been using for testing the scrolling information. Had all sorts of fun and games creating a routine to load in a text file and then display the text using a DS_list. Because I’d been editing it on the virtual PCÂ it had inherited all sorts of stupid formatting codes that weren’t visible and caused the formatting to go all over the place. Eventually got that all sorted out and finally had reasonably formatted instructions doing what I wanted.
Got her indoors to help out choosing some colour combinations to swap around for the displays as the idea is to break up the routine by displaying the original Paradroid loading screen that Andy had on the C64 between runs. Due to the way the surface scrolling works, and how i’ve clumsily used two objects, I’ve got to streamline it all again back to just one system doing all the background stuff as things are going all over the place when I try to add little features here and there. Put that down to a job for next session along with some advice from Aaron about using two views to save constantly creating and removing objects while running the title sequence.
I’ve mentioned previously about using a file loading system to bring in the text so it’s easy to modify it on the fly and eventually turn it into internal data once it was finalised. I was hoping to just stick with the load system as it works pretty well, but it turns out that external files added to the project aren’t built into the main executable at compile time, so it would be easy for anyone to modify the text after installing the game to do all kinds of naughty stuff like changing credits, or potentially breaking the game with overloaded text lines. So I’m going to have to shunt the formatted text into data within the code, although it’s not something I plan to do right until the end.
The only external data for the game is going to be probably ini files for saving and loading configuration stuff, and maybe a save game system, if we decide to build that in.
Got another build of Aaron’s part of the game today. As well as already having all the maps set up, he’s now also got the lift UI and code in, so it’s possible to test all the different decks of the ship. There’s a couple of position faults, and wrong lift shafts highlighted issues still to get fixed, but it’s all working pretty well.
I talked him into doing a test run of double speed movement for your droid if it’s moving around on an empty deck. It can be quite tedious wandering around trying to find those last couple of droids when you’ve almost cleared the ship. Wether it stays like this, becomes a feature you can activate, or a hidden thing has to be decided as I like it but he doesn’t.
Time to email and see if i can get someones permission to use a tune of theirs for the game music now. Hopefully they will say yes and also help out with some of the sound effects as it seems they’ve managed to emulate loads of them within the actual music itself.
Categorised as: Development | Game Studio 2 | Paradroid
Leave a Reply