OK. Another Exile related blog. Skip it if you want.
Now, as you may or may not know (or care), I use GIT to keep track of the work I do on Exile, and obviously for version control. I need to keep track of what I do, because given the crazy times I work on this sometimes, I tend to forget what I've done when I wake up the next day :PLuckily, diff. Or I'd be having fun trying to track down what I call 'drunk code'. Anyway, I exported my commit history. Take a gander, and start at the bottom (Oldest commit):https://dl.dropbox.com/u/11942397/verlog.txt.htmlA couple of things to note: > Most of my commits are either really close to or after midnight. There's even a 4AM commit somewhere in there… > At some point in there I leveled up and became 64Mega. > "…" is a perfectly legit commit message. > The inflation of my ego is linearly related to how many hours I have been awake. > It took me 6 revisions to fix the ATI related billboarding problems. > I have absolutely no idea what "Pre tweak LN07032013" is referring to.Anyway. Big updates to the engine. As you can see by the most recent commits, I've added scripts. Specifically for the levels. These level scripts are loaded dynamically at run-time, and use a simple mnemonic based language to do stuff to the player and world. They can spawn enemies, alter tiles, kill/heal the player, and all sorts of fun stuff. A couple of things I've done so far with them: > Extending bridge > Raising stairway like in the first/second level of Doom. > Elevators > Switches that do stuff. > Light strobingThe system works something like this. In the level editor, you add trigger zones:
Then, if the trigger zone is supposed to alter blocks, you Tag them with an ID:
Then you save and build the level. When you play the level in the game, it searches for <levelname>.grt. If it can't find it, it just ignores the trigger zones and carries on running. If it does find a .grt file, it adds the scripts within it to the script registry. Here's a script that will make those four tagged blocks rise up when you walk over the trigger zone:
script_begin(0) // This links it to Trigger zone 0
type = player_inzone_once // Meaning it activates when the player enters the zone
// Raise blocks with LoTag 1 by 10 units.
raise 1 10
// Display a message just because we can
message Something happens...
end_script
script_begin(1)
type = player_inzone // Triggers each time the player is in this zone
if player_hp > 1
delay 5
sub player_hp 1
else
terminate
end
script_end
Other things that the scripts can do include playing sounds, spawning items and enemies, warping the player, changing light levels, changing stats, and a few other things. So I'm hoping to be able to add a lot more life to my levels this time round.Well. This turned out slightly longer than I expected… I ramble when I'm talking about this kind of thing… And I didn't even get to the technical details…The scripting 'engine' itself uses a few things I picked up while learning OS development. Specifically, run-slicing, so that execution of all scripts appears to be happening in parallel, but without slowing the game down.Scripts are executed one instruction at a time, maintaining an internal stack frame and instruction pointer. They can also be set to repeat execution (Meaning they don't terminate, but get pushed back onto the list). The interpreter itself is naive: It ignored unknown instructions. So a shoddy script won't bring the game down, but it won't have the desired effect (If any at all). Mnemonics aren't case sensitive, and neither are attributes.Also, each script has four local vars it can access (A,B,C and D), and four global vars that are shared between all scripts (GA,GB,GC and GD).Anyway, signing off. I've got more stuff to add.
This is very cool! Good work, Mega - I always find these blogs interesting even if I don't always comment on them.
You've probably already discussed this in previous blogs, but what are you using to make this?C++ as the language, Code::Blocks for the IDE, GIT for version control, SFML2 for Display, Input and Audio control, and OpenGL to render everything. Oh, and a few personal code libraries for math and collision.
And thanks.This is cool as hell. How do you make use of variable height if your map-maker is in 2d? Also, do stairs and elevators work?
My memory of the original game is limited to swinging a sword vainly at a giant teddy graham, and walls disappearing at the edge of the screen, so I apologize if there are stairs and/or elevators in it, it's been a while since I played.There were stairs, though they were locked to square heights, making them look like Minecraft blocks. They're much smoother now. The original game didn't have elevators, mostly because the original game wasn't really 3D at all :P
Now, elevators work; perfectly, I might add.Also, I added decals to the game.Oh god yes. Decals should really help the overall look of the levels. Great job on adding the switches aswell. It'll be interesting to see how different (and improved) Exile is after these changes.
I'm not sure if I like decals. They remind me too much of Duke Nukem 3d, and I feel they usually end up looking artificial (like pasted-on graffiti)… but that's me.
P.S. Consider adding gamma settings so your screenshots become more comprehensible :)Eh, forget gamma. I'm just going to ramp up the base lighting by twice it's current factor and leave it at that. Apparently, my monitor brightness must be approaching eye-searing levels if I consider the game's levels as normal…