I’m done! The code rewriting is finished! The main bulk of it only took a few days, but I that ran into a couple of problems I was a little reluctant to fix. My system of only updating paths when there was a change in the game’s state was horrible to work with – it made every change have to be implemented in about four different places.. BAH! I only noticed one of these errors when I tried to add “Chargers”, which is what prompted me to have another change.
I sacked it off completely, the game now recalculates the path every single frame as well as having real time collision ‘monitoring’ on the shots. Now… “bad” I hear you say? Nuh uh! I have a percentage value which represents the ratio of how long it takes to do one frame of logic and draw that frame against the total time available to achieve 60fps; this value usually ended up being around ~6% on my desktop at ~15% on my laptop in battery saving mode. It increased by only 1%.
This has taught me a valuable lesson that I already knew but should be taking more notice of – stop trying to pre-optimise. I really shouldn’t care at this point if my code takes a long time to run (this is MUCH different from how well written it is); if it ever gets to a point where I need to optimise then that’s when I’ll do it. It’s an unnecessary waste of time to do it before hand – in my case that was one or two percent trying to work around a problem that was much easier just to ignore.
Fun fact: I can handle about 15,000 shots before I start to take an FPS hit, I find it unlikely there will be ever more than 200 in the most extreme cases.
Here’s the current state of the alpha:
The main “difference” visually is the colour scheme – I just made in more in-line with some of the things Simon has shown me. The coloured tiles around the splitter are filters and they simply apply a colour to a beam. It doesn’t just work with white and another colour, you can see a colour wheel in the above screenshot. Unfortunately there isn’t a simple solution for mismatched colours (e.g.Red + Cyan). At the moment I’m just not doing anything, red beam + cyan filter = red beam. This will have to change in the future somehow.
The functionality is also there for any object to have a colour that is applied to the beam, but it didn’t look right on reflectors so I stopped using it. It’s not abandoned, it’s there to use if I find a good situation for it; it might work well for splitters (why didn’t I just call them prisms?).
The other new object in the screenshot is a charger, I’m toying with the idea of shots having some representation of health – mostly likely power/illumination. Different objects will dim the shot until eventually it dies. This is neat solution to stop the player having shots that continue on indefinitely by either redirecting shots back into a splitter or simply just getting a shot trapped between two reflectors. You can only charge a bullet once though, there is no allowance for recharging! This is because infinite loops (recursion in this case, kinda) cause crashes, the path tries to go round and round in a loop forever-more which means the program runs out of memory. The inability to recharge can be explained by overloading/overcharging the shot and it going poof!
There a few things I’ll be looking over the next week or so: black holes, switches/sensors, doors and walls; visually, Simon wants me to do something I have no clue how to do: dynamic light for shadows (I reluctantly see the sense in this..) and finally, looking at how a player would actually play a level which involves, I guess, having an ‘editing’ mode and a ‘solving’ mode as well being able to load levels in from files.
I’m sorry about the 10 day hiatus; it was ‘nice’ having to not think about having something to write… so I may shy away in future from religiously trying to have a daily post, especially when all I can write is “Didn’t do much today!”.
