Quick note that where I’m at, it reached 45 degrees C (that’s about 113 degrees F) yesterday, and is expected to reach similar temperatures today and tomorrow, and slightly lower over the weekend. They say that it’s the strongest and longest heat wave recorded here since 1908. (It’s hot enough that heat expansion was causing the train tracks to buckle, virtually shutting down a lot of public transportation during commute hours)
I’ll just say that these temperatures are so high that they overload my poor little portable aircon unit, which basically means that not only am I not in a productive frame of mind after work, but I’m not even entirely convinced that it’s safe to run my computer in that sort of heat. So depending on weather, all VectorStorm development is likely to be on hold until the weather cools off a little bit (early next week, they say). As always, I’ll post updates as they happen.
Ordinarily, hot days sap my will to do anything. So I’m not sure why I’ve had a productive evening today, but I did. Maybe it’s because Lord has finally reached the point where I can actually play and have some fun with it, instead of having the gameplay confined to being entirely within my head. It’s not finished by any stretch of the imagination, but all the elements are now there (as of yesterday evening). 
Anyhow, here’s an updated screenshot, for your enjoyment.
This is just going to be a very quick update. It’s been by far my longest “Game in a Week” (currently at a duration of 30 days. Not that I’m keeping count or anything.)
I finally feel like I’m in the home stretch of development. There’s about six hours remaining in the day, and I very well just might make it.
Notable new stuff in the past few days: Got the Win32 build working. Fixed rendering on 3D hardware which doesn’t support VBOs (this’ll generally be 3D hardware that’s more than about five or six years old, or poorly supported laptop video cards… of course, Lord is rather processor-hungry due to its distorting-terrain-rendering system, so it isn’t likely to run very well on really old hardware… but at least it’ll render). Fixed even yet more core 3D rendering setup problem; rotation matrix maths and a flipped rendering frustum.
Also, I managed to spend some time fixing a couple of bugs in the Lord gameplay, when I wasn’t ridiculously busy fixing the game engine itself.
So hopefully I’ll have something ready to go in about six hours! Watch this space.
[update, four hours later] I’m fading early; not going to make it to midnight tonight. Lord is close to done, but it still needs some love on the progression between levels, and some general tuning. But it won’t be too much longer; I’ve bought myself a DVD I want to watch, and I’m saving it as a reward for finally getting Lord out the door. So it’ll be soon, depending on how many spare hours I get after work, over the coming days!
Newly developed for Lord (this will eventually be migrated back into VectorStorm trunk, in case anyone’s actually using that code for anything), I’ve made a minor adjustment to the file parsing API, such that if you have a file with a block like this:
Field{
a b
c d
}
Then you’d get a single fsRecord with a label of “Field”, followed by six fsTokens ( {, a, b, c, d, and } ).
Now, you get a single fsRecord with a label of “Field”, and no fsTokens. Instead, the fsRecord has two “child” records, each of which have two fsTokens ( ‘a’ and ‘b’ for the first child record, and ‘c’ and ‘d’ for the second child record). If you have file reading code which assumed the old file parsing logic, you’ll need to update to the new system once it’s been merged into the trunk codebase.
There are a few benefits to this change. For one thing, it now means that you can put parsed data inside blocks, for logical or organisational reasons, and not lose the benefits of being able to load things based upon the label.
The other big benefit is that it’s allowed me to make the .vec file format use a single “VertexArray” block for either 2D or 3D vertices; now that it knows where linebreaks are, it can just do the right thing, based upon whether the data file provides 2 or 3 vertex coordinates.
…and I promise that my next blog update will be less scarily technical.
Missed the three-week mark, too. Part of this was that I had to fix yet another core rendering problem which was causing 3D geometry to draw incorrectly, particularly in widescreen views. I also had yet another 3D picking bug to sort out, which took far too much time to crack (For the programmers out there, as you move across pixels on your screen, you’re not varying the angle from the view frustum linearly. I know, it sounds obvious when I say it, but that mistake was yielding lots of subtly wrong behaviour for me).
But with the above out of the way, I’ve made some awesome progress today. The core gameplay mechanic is now fully working. The world now wraps around at the edges (in fact, I usually can’t even tell where the edges are!). You can now use the mouse to scroll around the world, instead of using the keyboard.
Stuff remaining to be done: Simple models for a few types of building. Metagame structure. Sound effects. Port to Windows (should only require compiling up a Win32 SDL_Image dll). And I need to contact a particular band to find out whether I can use one of their old songs for the closing credit scroll. (I probably shouldn’t; Lord is already going to be huge, as its main gameplay music loop is about nine minutes long.. I shouldn’t add even more music data!)
