Welcome to Thanatos Enterprises's Work Log!
Name: Matt Rutherford
Email: [email protected]
Description: Programmer, Designer
Project(s): codename Resurrection
Last Updated: 3/8/2003 11:22:45 (Pacific Standard Time)
----------------------------------------------------------
3/8/2003
----------
The ArenaScript toolkit's complete!
Actually, it was complete two months ago. But time constraints, and the promise of my getting a dedicated web server failing to come true, have left me to reveal them until now.
PLEASE PLEASE PLEASE read the README included with ANY of the files above. It contains deathly important information about properly compiling the toolkit. Also, let me know if you're getting 404 errors; I'm a bit nervous about keeping these files on my school's server so I made a FortuneCity account to hold them.
Future plans/thoughts:
My original plan was to create my own archive format (think Zip files without compression). I have scrapped that plan. I want to get Arena: Resurrection done. Creating an archive system would be a great learning experience, but it's not entirely necessary. My motivation for creating it, aside from learning, would be to compress the multiple ubersmall script files into a single file. But it's cutting into my drive to make the game. So screw it.
My next stop: the technical document for Resurrection. I'm going to work as much as possible on it. I'll let you folks know how it goes.
After Resurrection, I'll start learning OpenGL and OpenAL. Target: Arena II. It's about time I started REAL work on my potential masterpiece.
12/31/2002
----------
Final Fantasy X: a review and discussion.
I finished the game. Yay. And now it's time to review it and figure out what we can learn from it. I mean the whole game, not just a particular portion of it. Whether out of guilt for neglecting Resurrection for a week or because I think it'll help, I'm doing this to see how I can benefit as a developer. This'll be a long one. WARNING: If you don't want spoilers then skip to the very last paragraph (my conclusion).
First, the basic premise of the game: save the world. Same as its predecessors. There's a few extra twists in the basic premise, like its predecessors, but the goal is the same. You can't really top that as a world-shattering event, so it's hard to fault the game for it. Better than making the premise to keep playing that goddamn Blitzball (more on that later). There are several plot twists throughout, but a few things are painfully obvious from the start (like Seymour, the fat Sephiroth wannabe, being evil). The ending is fantastic, if short. It's an interesting twist at the least. I'll talk about that next to last.
Next, I'll discuss the systems of FFX. The characters come last since that's my favorite part. I'll go in order of my favor (eg. the first thing I mention is my least favorite).
First, the equipment system. It's first, but it's not that bad. Your weapons contribute very little to your overall attack power; it's the abilities they grant that are the real boon. Things like Sensor (a never-ending nearly always working Scan), Piercing (hits armored foes with normal damage), and First Strike (the weilding character always gets the first chance to attack) are extremely nice to have. The really good ones are also really hard to find, but when Rikku joins the party you can add abilities to some equipment at a cost (some items). It's neat, but I wish finding a new weapon meant it could be useful. A lot of the stuff you find in FFX is totally useless.
Leveling system: practically nonexistent. This is proof that an RPG without a level- based system CAN work. All character growth is based on a grid of nodes. As you gain AP, you get "sphere levels," which allow you to traverse the board. Lesser sphere items allow you to activate various kinds of nodes that improve your character. Your characters have the traditional statistics like Strength and Agility, but rely much more on them than previous Final Fantasies (except maybe VIII, and perhaps IX which I have but haven't started). This sphere system is the best and ONLY way to get spells and improvements. Weapons and armor barely affect you unless they have cool effects (Rikku's Infinity reduces the MP cost of all her spells to 1). There's a definite path for some of the characters (Lulu and Yuna, in particular), while others just pick a route to go. While I'm not certain, there is no AP limit; if you're insane you could give every character every skill and ability.
Magic and skill system. Nice, but also severely limited. Spells are remarkably cheap: your Firagas and Blizzagas (the highest grade of spell) are 16MP apiece. Unfortunately, black magic isn't very diverse: you get three grades of your four elements, Drain, Death, Bio, and Ultima. There are probably more, but none that matter. White magic is somewhat better and more utilitarian: three grades of Cure, Nul spells for all four elements (nullifies one elemental spell), Regen, Esuna (Remedy), and three grades of Life. Skills are fairly interesting: most are free to use. But only a few are worth the time: all of Auron's breaks (lowers an enemy's stats), Wakka's status attacks, Tidus's Quick Hit, and Rikku's Use and Steal are the only ones worth anything.
Battle system: fresh and fast. FFX answers a lot of complaints with the previous installments and succeeds. Using a "Conditional Turn Based" system, there are no waiting periods between action and reaction. On the right side of the screen is the battle queue. You know, at all times, who goes when. Agility is the major stat in battle; the most agile gets to attack more often. This proves annoying when your slower characters have skills you need, but they never get the chance to use them. On the other hand, extremely fast characters can attack multiple times in rapid succession. Probably the coolest (but less-used) new feature of the battle system is the option to swap characters in and out of battle. Any character that's not in battle can be exchanged for one outside of battle (only three in battle, max). About the only time this is useful is when you encounter something nobody in your party can handle. Example: you encounter a flying creature, but your party consists of melee characters. You can mash the X button all day and hit nothing but air. In past FFs, you had two choices: keep mashing the X button until you hit pay dirt, or run away. FFX gives you another choice: switch a character with a magic user or someone that can hit fliers. In major battles this is rarely useful, but it's an idea that's long overdue. Limit Breaks still exist, though in a different form/name: Overdrive. Unlike previous games, you can change how you hit Overdrive (when you take damage, receive damage, heal, get healed, even something as simple as when your turn comes up). Each Overdrive requires a little dexterity and knowledge when executing: as an example, Lulu's Fury casts X number of spells based on how fast you can rotate the right analog stick. Summons (called "Aeons" in FFX, the equivalent to a Guardian Force or Esper) are much more involved than previous games: they have their own set of stats and abilities. They can still unleash uberpowerful attacks (Bahamut's breaks the 9999 barrier), but only when their Overdrive meters are full. Summoning is not always a good thing: it doesn't take much to kill one and everything they do aside from basic attacks and spells drop their places in the queue. CHEAT NOTE: get Haste and Slow as soon as possible; against some early monsters you can knock off 10k HP at 400 damage per hit before they ever get the chance to move.
Graphics and sound: the most beautiful of the series. The characters aren't total stiffs and can do more than shake their heads and try to look angry. This is also the first Final Fantasy with voice-acting, which is a mixed blessing. Some characters are painful to listen to (Wakka, Tidus, any of the Al Bhed), while others range from tolerable to a audible treat. Special effects are good, but nothing to really write home about.
The world's background and culture is interesting at the least, and I applaud Square for finally introducing some religious themes. I could almost taste the Catholic Church in the Yevonites. That aside, though, for the most part the game made sense. The one thing that doesn't is Blitzball. The game takes place in a big ball of water. Players swim aboit inside it and try to throw balls into a goal. The break of reality: these people can swim for hours without taking a breath!!! What the HELL?!?! It's the biggest reality hole I can find in the game and is fairly necessary for the plot, but there must be another way to accomplish it.
Now, the characters, in a particular no-particular order:
Tidus: the main character. A Blitzball player from Zanarkand, he's sucked into another
world when a beast called Sin attacks his town. His voice acting is atrocious, and as a
character he's inconsistent. He wasn't a likeable character, which is a HUGE turnoff from a
player's perspective. I would have cheered his disappearance at the end if it wasn't for
its complete sadness... poor Yuna. As a character, he's not my favorite. He carries a
sword and hits stuff. That's about it. His Limit Break Overdrive
involves hitting things with his sword or firing energy from his sword. If he has an
Omnislash or Lionheart I haven't seen it.
Yuna: the summoner, the one charged with the task of saving the world from the beast called Sin... for ten years. I never understood why nobody EVER tried to find another way to kill off Sin in a thousand damn years. Anyway, Yuna. She's sweet, kind to everybody, and as the game repeatedly tells you has an iron will. She's interesting, but definately not an Aerith. You don't fall in love with her as you do with other heroines, but you still care. She's the white mage of the group, and the only one that can summon Aeons. Her Overdrive allows her to call an Aeon with a full Overdrie meter, thereby allowing it to immediately unleash its own Overdrive (which almost always hits for big damage).
Wakka: the crappy Blitzball player. His team has lost every match since its creation. He even weilds a Blitzball as his weapon, and is the only one that can hit flying creatures with regular success. He's devoted to his religion, and serves as a guardian to Yuna as she travels to defeat Sin. I hate his voice too. It's hard to pin exactly, but it's grating, whatever it is. Of the secondary characters, he's the one that develops the most. He slowly gets over his hatred for the Al Bhed and machina (machines), and even denounces his religion when he figures out it's corrupted to the core (duh). His Overdrive (the only one you get without playing f'in Blitzball) deals heavy elemental damage if you line up three of a kind on a slow machine. It's not hard to do.
Auron: the mysterous guy. He's irritating, too: he speaks enigmatically and knows everything but never says a word. All he does is tell the party to keep moving. He eventually becomes a guardian of Yuna, and once served as the guardian of the last summoner to defeat Sin, High Summoner Braska. He's also extremely slow in battle. His Breaks are cool, and his Overdrive deals an insane amount of damage, but he simply doesn't get to attack often enough for them to matter.
Lulu: the black mage. Probably my favorite character, she's also the one that develops the least. You learn very little about her as you travel; all you know is that she's been watching Yuna like a big sister since they were children. She dresses like a goth, though an interesting goth: her fur coat hides very little (and she's well-endowed), and her dress is made of belts. Yes, belts. I honestly wish I learned more about her, but unless there's a sidequest I missed she remains an enigma. She carries a voodoo doll into combat, but its sole purpose is to boost her magic power so you can beat the hell out of things with her black magic. Her Overdrive is nice: she casts multiple spells in rapid succession, at no MP cost, depending on how fast you rotate the analog stick. The more powerful the spell, the faster you need to rotate.
Rikku: the little annoying thief girl. Aeire from Queen of Wands once described her as the Britney Spears of the Final Fantasy genre. This couldn't be closer to the truth: she's small, has next to no pants, and speaks like a little valley girl. She has more of a background than most of the other characters: she's an Al Bhed who befriends Tidus and Yuna. Beyond that, I have no idea why she joined the party as Yuna's guardian. She also has an abnormal fear of lightning thanks to a bad shot from her brother. She looks and acts like a little girl, but I found myself using her in battle more than any other character. She's extremely fast, and her Use/Steal abilities are infinitely useful. Physically, she's weak, but she's more utilitarian than offensive so she deserves a spot in the party. Her Overdrive has varied but almost always kickass results: you can Mix two different items to get interesting effects. Try mixing two Farplane Winds or a Light and Lunar Curtain to see what I mean.
The bad guy is a bore: a big beast named Sin. Sure, a few folks turn out evil now and again, but none of them are truly memorable. If you're hoping for another Sephiroth, all you'll do is throw a brick at the TV once you see Seymour. He bears a resemblance to the most famous baddie in Final Fantasy, but he's bland and stupid, not to mention fat. Out of shape villains are rarely memorable. At least Sin reminds you he exists, unlike X-Death or Zemus.
The ending, if you pay attention, makes sense. Tidus, being a dream made by the fayth (the dead), disappears once Sin and its controller are gone. The fayth can rest from dreaming, but because Tidus IS a dream, he disappears. I don't particularly like the logic, but it's a good twist. You expect him to be saved. You hope he's saved, if only for Yuna's sake. Thanks to my asshole roommate, though, I can't say much about what's beyond. There's no unanswered questions, except maybe what happens to Yevon now that the Aeons, the fayth, and Sin are gone. It's a good ending, and worth the trip.
Conclusion: Evolutionary, not revolutionary. The battle system fixes a lot of flaws in the old Active Time Battle system. A few rehashes exist for the sake of the series, but nothing you don't want. Most of the characters lack depth, but they're unique. Some say FFX is more an interactive movie than a game; they're partially right. There are a LOT of FMV and scripted sequences. However, this is partially due to the PS2's capability to make good use of them without stretching the game over ten CDs. The game isn't uninteresting, and I honestly don't know why people hate it so much. It's probably the best you're going to get before Square loses its independence and merges with Enix.
The bottom line, as a developer: Alternatives to the tradition work, but nobody will pay attention to them if you don't keep them in the game. If FFX faltered anywhere, it's the lack of player interaction. If the plot requires long sequences or it's not flexible enough to allow some player interaction, it's not right.
12/27/2002
----------
I did a brief cleanup and slight optimization of ASC. I haven't bothered to measure speed since ArenaScript is so small and simple that any speed difference I could make would be negligible. I'm sure that will change when I try to run it on my P166 running FreeBSD, but I'm not even worried about that.
I managed to shave 52K off the ASC executable, to a meaty 480KB. Similarly, I managed to cut ASMAKE's size by 42K to 332KB. Note that the biggest reason for the size drop is my replacing cout with printf (only the main modules for both programs use console I/O). Note also that I'm compiling with Visual C++ 6.0 Standard, which does not include an optimizing compiler. When I compile with DJGPP, I get somewhat smaller filesizes: 377KB for ASC and 306KB for ASMAKE with using the -O2 and -s switches. Better, but still large. I'm going to try and work on the virtual machine tonight if I can pull myself away from the PS2.
* (ASC) Fixed a bug that skipped one VID for each script compiled with ASMAKE.
* (ASC) Added limited enforced namespaces. Currently checks all locals and currently known
globals for duplicate names. There is the possibility that globals could be missed in
batch compiles (eg. in a six-script compile with ASMAKE where each script has an ASI header
file). The best workaround for this is to use only one header file for globals. That will
ensure perfect namespace enforcement. This will be improved in the next version of ArenaScript.
* (ASC) Removed the compiler options -c (single-script compile), -s (omit variable names
from the compiled script files), -32b, and -64b options (variable instruction size; all
instructions are now 128-bit).
* (ASVM) Reformed the console module to remove its header's dependecy on curses.h. Works
much the same as before, but the console module manages console buffers. Now STL headers
can be used anywhere (curses' macros mussed up lots of the STL's functions like clear() and
erase()).
12/25/2002
----------
I discovered a bug in ASC that cannot wait. Work on the VM is halted until I'm positive the bug's repaired. In the meantime, I'll perform all the cleanup I wanted to do after all the tools were complete. I was REALLY hoping to work on the VM, but this is totally unavoidable.
When I need a break from coding I might make this site a little more robust. I may also take a few days'/weeks' break to play with my shiny new PS2. Depends on when I can get ahold of a memory card.
Appended work log:
Progress: (ASVM) Further thinking of the VM's structure and the console's inner guts.
Todo: (ASC) Fix the way global variables are saved (current implementation erroneously
saves different VIDs for the same globals); current idea is to save a brief text database
of all globals once processing of the variables is done. Each subsequent compile would use
the text file as a database of possible variables, and if found they will assign VIDs
based on what's loaded. When the headers are all parsed, ASC will append all new globals to
the end of the file.
Todo: (ASC) *Enforce namespaces for each script.
12/25/2002
----------
I had a lesson in encapsulation last night. It's all fixed now, and headers can be included in any order when using curses. I'm a retard. I should have figured it out a long time ago, but I forgot that C nearly encourages rampant macros (every time I tried to use the clear or erase functions with an STL object I'd get tons of errors)...
Other points:
Progress: (ASVM) Finished defining all required objects/methods/functions for the VM, starting
work with the guts of script objects.
Todo: (ASC) Enforce local/global namespaces for each script, instead of forcing the
programmer to name variables in a non-confusing manner.
12/24/2002
----------
I feel happy.
I've pretty much cleared up the mess with the console. I'm primarily uses curses now, which seems to work perfectly when I don't put STL headers after curses.h. If it does fail, I can seamlessly switch to the Win32 console functions (I already had a header that chooses between Win32 and curses). I've implemented all the functions I need, and displaying other buffers is a cinch. I know how to work the screen buffers. I've already started working on the VM, and I have a few more ideas on the VM's console (runtime instruction interpreter, runtime compiling of scripts, etc.). Barring any distractions (like Christmas, which actually shouldn't prove to be much of any distraction), I should be done with this by the end of the week. Don't quote me on that.
I'll post what I implement as I go along.
12/23/2002
----------
While being an excellent learning experience, today has also been a major pain in the ass.
I started work on the Win32 console functions yesterday. I wasted half a day trying to get SetConsoleScreenBufferSize() to work, without any success at all. After learning of a curses port to Win32, I immediately dumped the Win32 console functions in favor of pdcurses. I renamed the Win32 sources from con_win32.x to con_win32.x.SATAN and turned to two other source files: con_curses.x. Then I ran into several other kinks: it didn't work unless I defined CPLUSPLUS in curses.h, and every time I included curses.h before any STL header I'd get tons of bizarre errors. I begrudingly returned to the Win32 console functions. Basically, I decided NOT to implement the ability to change the console window's size in the Win32 port. By this time, I wasn't sure if ports were going to be possible.
Of course, after I figured out that the Win32 functions WILL work for what I need, I fiddled with the order of headers in con_curses.x and discovered that I can compile fine if the STL headers go BEFORE curses.h. So I'll be using both curses and Win32 functions (the Win32 port of pdcurses actually uses the Win32 functions, but I have tons of control this way).
My current dillema: I managed to implement an immediate character reader, readimm(), akin to Pascal's ReadKey procedure (the one I used for Resurrection's 16-bit predecessor), but it doubles up on the input. Thus, by pressing the up key once, a cursor will be moved up two spaces rather than one. So far the only workaround is to call readimm() twice. That produces exactly the kind of output I need (one touch = one registered keypress), but it's a kludge that may not be necessary in ports (eg. curses). Another thought is to make a #define that calls readimm() twice, like:
#define readimm(x) readimm(x); readimm(x)
That won't work either. VERY kludgy. I'd have to define this in every source file that includes con_win32.h. And makes using readimm() in switch statements impossible.
I feel like an idiot for not being able to figure out something as simple as this. If anyone can look at the below code and figure out a way to solve this dillema, I'm all ears. CONKEY is a custom enumeration for the supported keys, and ConBuffer is a typedef for a console window (for Win32 it's HANDLE; for curses, *WINDOW). Currently, though, the passed ConBuffer isn't used; winmain_in, the standard input buffer, is used.
CONKEY readimm(ConBuffer target)
{
static ASULONG tmp; // only because ReadConsole bitches if we don't supply this
static INPUT_RECORD pir;
if(ReadConsoleInput(winmain_in, &pir, 1, &tmp) == 0)
return CONKEY_ERROR;
if(FlushConsoleInputBuffer(winmain_in) == 0)
return CONKEY_ERROR;
return (CONKEY)pir.Event.KeyEvent.wVirtualKeyCode;
}
12/22/2002
----------
Status update:
ASMAKE is complete. As it stands, ASC and ASMAKE will do what I need for Resurrection. There are a few things I can do to both program to make them leaner and faster (eg. for ASC, remove the option to omit variable names from the compiled files. They add unnecessary complexity to the program and limit the VM.), but that's last on my list.
I included the fix for ASC so it can assign proper variable IDs on its own. This resulted in a MUCH smaller ASMAKE program (I suspect it'd be 100kb larger if I had ASMAKE edit the compiled scripts itself), and a slight increase to ASC (about 16kb, to 520kb; my kingdom for an optimizing compiler!). The process actually found a bug in ASC that saved the number of script variables in an immediate file 44 larger. Fixed, disaster averted.
I started work on ASVM, including a basic technical document. Currently I'm messing with Win32's console functions. I can do basic reads/writes, change the color, and clear the screen. I can even create new console buffers on the fly, but for some reason even when I specify GENERIC_READ and GENERIC_WRITE it'll only write to buffers without trouble. This sort-of messes with my plans with a separate console buffer for the VM's console, but I've already thought of a few workarounds. I'll be messing with it for the rest of the night.
Here's the current list of features that will be present in the test and Resurrection versions of the ASVM:
- Execute single or multiple scripts. (test only)
- Load and store multiple scripts (test VM requires console input to run scripts,
Resurrection's will be loaded based on the main program)
- Supports cfg files for batch loading and editing certain parameters (test uses text files,
Resurrection will use binary files)
- Console mode supporting the following commands (note: the test VM REQUIRES the console
mode to do anything; Resurrection's will be turned off by default and will require a
command-line parameter to activate. Resurrection's may or may not include all of these):
12/21/2002
----------
Status update:
Of the four points I made last week, I've only started on the third (ASMAKE). I won't optimize until the very end and I won't work on the VM until the other tools are done. I may be doing the first bullet sooner than I thought, as I have thought of a way to make large projects much easier to compile.
As it stands, ASC has no knowledge of any compiles it has performed in the past. My idea is for ASMAKE to create a temporary file, globl.tmp, and store a mere four bytes: the variable ID to start with. ASC will read the file at the start and use the value as the starting point for assigning variable IDs (if the file doesn't exist, as for single script compiles, ASC will default to 43). ASMAKE's purpose, then, is to batch-process a list of scripts and create a VAR file from all the IMM files generated by the compile. ASC will be slightly more complicated, but I need to overhaul the loading of scripts anyway so now's as good a time as any to make the change.
Optimizations and ports come after ASC, ASMAKE, and ASVM are complete. I'll post a list of planned features for the virtual machine when I get the chance.
As an aside, I've started writing a series of short stories based on characters in the Arena II universe. I have two right now; I'll probably write another tonight.
Assassin's Loss - Chiisai Hana's Story
Long Days - Aila Sterling's Story.
12/12/2002
----------
What's left to do with ArenaScript 1.1.0:
12/11/2002
----------
Lack of news due to absence of anything to talk about.
I'm about 90% done with the compiler. The final test will be processing the results through a Virtual Machine. I also need to do some optimizations (the parsing technique I used is particularly messy), but that comes dead last. If it ain't broke, don't fix it.
Finals week is creeping up, though, and I'm getting fairly burned out. I don't know if I'll be able to do much, but I'm sure I'll find plenty of time during Christmas break. Keep tabs; I'll try to make further updates more interesting.
11/23/2002
----------
No comments on the instruction list. Ah well. Guess I'll have to seek out help myself.
The onslaught of school work, plus multiple other distractions, have kept me from doing any project work. I've caught up some, though. The script compiler's still in its infancy, but I've made some decent progress on it. Hopefully I can finish it over the break, with a test VM to accompany it.
I've decided to experiment with a simple DirectDraw rendering class I can use as a base to port to Direct3D or OpenGL. If I do it right it should work splendidly in anything I want in later projects. But that's a side; has nothing to do with Resurrection.
10/27/2002
----------
I have prepared a list of supported instructions in ArenaScript Ltd. v.1.1. This is subject to change at any time, but I doubt it will.
I was cursing the necessary task of creating a technical document for weeks, but I'm receiving several indications that it's the Right Thing To Do. In the last hour alone, I've discovered several potential problems and snags in the script compiler. Had I jumped straight to coding, these flaws would have appeared as I set up the compiler as solid as possible, making major changes next to impossible.
First example: When thinking about the compiler in the language specification, I didn't take into account the possibility that branching instructions would be used before points are defined/called. Sound stupid, but I didn't think of it until I started working on the exact method to compile scripts. I've found a way to allow points and branching instructions anywhere. Much better, though I'm probably not doing it very efficiently.
Second example: Another pretty dumb blunder on my part. My original idea for storing variables was to use a static vector in a global module to avoid passing messy vectors. This didn't take into consideration that scripts can have both global (accessible to any script) and local (accessible only to the one script) variables. The one module would only allow the storate of either global or local unless I changed something in the variable object itself. It becomes much easier to just make the variable manager an object. Problem solved.
Feel free to email me if none of that made sense. I'll try to clarify more in a later update
10/19/2002
----------
The hardest thing about a large project like Resurrection is keeping interest long enough to finish it. It comes with the territory, but it's still not easy. Luckily, I think I've found the solutions I need to proceed safely. I'll hopefully start coding by Monday.
Just about every time I sit down to work on the project, I find some new requirement I didn't think of the last time I did work. I found fewer and fewer as I go along, though, and they become less and less of a hassle to work around. This is after I sat down and spent hours defining the requirements of the scripting engine and virtual machine, so it gets frustrating. This will come to an end soon! Resurrection WILL be released!!
10/17/2002
----------
I've had a very productive day. It's a cold day (always good for motivation), I got my physics test done early today, so I got a head start on the project. Today was all about the scripting language and engine I'm writing for Resurrecion. Here's what I mean:
Rather than hardcode every itty bitty detail into the executable, I decided to write my own scripting language to automate actions in the game. This has the extra benefit of being extremely easy to update the game, and also allows users to make their own scripts in case mine really suck (and they do). Not everything will be scripted, but many things are in the hands of the scripts.
Example: Before every battle, a pre-battle script is run. By default, this script is null; no script is run. Scripts CAN be run beforehand, to set the mood/story/variables. After every battle, another script is run based on the outcome of the battle. If the player wins, no script is run by default (the handing out of bonuses is hard-coded). One can add a script, however, to trigger certain states or play an after-battle scene. By default, a sad death scene plays when the player loses; that, too, can change, even to the point where the game doesn't end when you lose. It makes for some interesting possibilities.
The language is extremely simplistic. Extremely minimum requirements to even be called a language. I still have a few things to work out, some of which are pretty trivial. Need I remind you folks that it's my first major project, so it's a big learning process for me. I'll probably reinvent the wheel throughout. Once I build Resurrection, however, I'll have enough experience to try a much larger project.
When Resurrection is finally released (GPL'd, probably), it'll probably be noticed that what I'm doing right now isn't exactly necessary. Small by most standards, a separate scripting language is overkill. Resurrection is small for a scripting language, but as I said before, it's an excellent learning experience. Future games (especially Resurrection's prequel) will almost require a scripting engine, so at least this way I can start small and work on the big guns as I go along.
Perhaps tomorrow I'll write some more about what I'm doing, but I'm short on time and energy. And the amount of stuff I have to write about is pretty overwhelming.
10/16/2002
----------
Hi! In the absence of my old webspace, I get to use my school space to log my work. Lacks the sophistication of PHP, but I don't have the money for webspace. This will do for now.
A few future plans:
I won't add anything today, because I've done quite a bit since the site went down. Tomorrow I get a good few hours of quiet work on campus, with just me and my laptop. I'll add more to this when I finish.