Off screen
First and most notably, the display for my stationary machine gave up its breath. It was very undramatic; I rebooted and then it was all black. Yesterday I confirmed that it wasn't due to a bad cable, the signal seems to be going through, and the OS recognizes it as a working display, but no pixels are lighting up. This is bad because it was a good LCD, no more than four years old. I had hoped it to survive twice as long, and there is no way I can afford a new one right now.
This impacts development as even though I do most of the coding on the netbook, I need the stationary for large rebuilds and for doing artwork. Anyone willing to donate EUR150 for a new one? No?
Script-design mess
The other thing is that I'm going to have to scrap three-four days of code-work. I've been trying to flex up the Vehicle code (I talked about this before) so that it would be easier to define motion behavior. I wasn't satisfied with the previous way; each Vehicle component has a list of Behavior objects, all implemented in C++ code.
I wanted more flexibility so I tried a different approach with each Vehicle having a reference to a stored Lua function that implemented its behavior. The benefit would be that each Vehicle could use either some common function, a custom combination of such functions or a custom implementation all together. The drawbacks, that I found out, was speed of course since this would cause a large number of calls to Lua each frame. The slowdown could probably be mitigated somewhat by optimizing and calling selectively, etc.
There was also this deal-breaking drawback that all behavior definitions had to reside in Lua. This would work fine with explicitly defined entities, like the player and enemies, since they are all defined in a Lua script at startup and can access anything else within the script machine. The problem is that implicitly defined entities, like bullets, are created within the engine and are not aware of Lua-defined behaviors.
Right now there are two options. Either I extend the experiment so that the Lua-defined behaviors are registered and made visible to the engine-defined entities and vehicles. That would probably be the first step towards a perfect hell of cross-calls between C++ and Lua. Or I admit this wasn't such a good idea from the start and try to improve the old implementation instead. Right now I'm bent on scrapping it and going with number two.
Yeah, it sucks, but I guess this sort of failures are good in the long run. I mean at least it has led to new design decisions.
