Tilting at Windmills

So, I wrote up my attack routines for melee, ranged, and sorcery attacks. The source file size was considerable; the only larger one in my directory was the one for display functions. In the end, it clocked in at 1168 bytes of code.

Yeow. That’s gotta come down. It’s a large chunk of logic, to be sure, but I should be able to cut that in half.

The main source of bloat is the fact I have three separate routines for each attack type, each of which has a lot of the same pattern of code. Check for this state, check for that state, do miss check, do critical check… this could and should all be in one monolithic function that just has data stored to indicate which state, which values, etc. to use for calculations.

I got a suggestion to just alter the attack/defense bonuses and other factors when states are active directly, so that no “updates” are needed in combat. A nice idea, but then I just end up moving this logic from the combat routines into the “state check” routine that occurs round by round. All they do right now is decrement counters, and they’re only for the players, not any monsters, since it also operates in travel mode. Finally, this data is stored in a VDP data array, which means accessing it is slow; not something to do bit by bit.

Also, every attack is unique. If a defender has a spell that increases the attacker’s chance to miss, for example, this affects the attacker, not the defender. That means  you can’t pre-process values in, because they are dependent upon who is attacking whom, and what states they have active.

So, I decided to do several things:

• Expand the player array to include fatigue costs for all actions (move, melee, ranged, sorcery) and critical ranges. This reduces the amount of dynamic checking needed
• Alter some of the more problematic spell effects to be easier to manage. For example, one spell granted a bonus to melee attack and speed and a penalty to melee defense. Instead, I’m going to have it increase critical range and melee fatigue cost. This keeps the spirit of the spell I had in mind, and makes it less problematic to track as it only affects attack
• Express the different states and their effects in data format instead of in code. That way my attack routine becomes a data-driven engine instead of a bunch of linear IF/THEN type statements
• One minor change is to make the light counter and tracker a party-based one instead of individual character-based. My original envision was that the party had to have a “torchbearer” who had to sacrifice an offhand slot to carry a light source. This is way too much trouble, though, so I’ll just have light sources get “used” and it grants N rounds of R radius light to the party

These changes will increase the size of the player array which is no big deal. The save file is presently 512 bytes, and a good portion of it was unused, for future use in party quest tracking. I’ll have to make a ton of regression changes, though, to accommodate moving around values in the array. And redo my statistic screens again…

I’ve got the changes to the stat screens done. I moved equipment off to the second page so I had more room for stats on the main page. I thought about just not displaying some values, but I’m already concerned about the lack of feedback being too frustrating, so I’ll err on the side of caution for now.

Now I’m back to regression programming and testing for a bit.. then I’ll tackle Attack Routine 2 : Faster, Better, and hopefully Smaller…

I found the problem with movement… quite simple, really. I had byte vectors that weren’t quite accurate. A -1 applied as a word requires the whole word to be formatted as -1, not just the right byte. Otherwise you end up with units moving diagonally. A few quick fixes and my units aren’t moving over top of each other or in odd directions anymore. The code base is ready now for the actual “attack and defense” routines, which should be interesting, since there’s so many factors to account for. I also need to find a way to cleanly map area attacks to units affected… preferably with a single routine that can “map” the damage area.

For your entertainment, I recorded a video in Classic99 to show off the start of the combat engine. In particular, you can see the units don’t move in quite the expected order.

Hopefully this gets SOME comments…

Okay, I now (hopefully) have the final form for the major components of the combat statistics done. This HAD to be done before I could go any further with actions.

I had to update my spreadsheet (Excel is VERY useful for design and tracking) to accommodate the changes to the player array structure, and also determine where I would need to make regression changes in the code. The program is large enough at this point that I don’t know quite everything that needs alteration, so I do text searches for labels to find the relevant bits. And I still miss a few.

New Statistic Screen

New Spell Screen

The ding this time came from the statistic screens. It turned out I had all of the coordinates in one place with one label, using offsets. So with all my offsets off, lots of stuff ended up in the wrong place. Whoops! Fortunately, I was able to correct these with a minimum of fuss. For now, there’s only one spellbook in the demo so it’s pretty easy to store just one set of spell data in memory for now. For the full game, I’ll put that data out to disk; there’s no need to burn 128 bytes of memory on it.

You also notice more data on the stat screen. I shortened the labels to make some room; obviously, the instruction manual will come in handy to explain what the values mean. The “M” columns indicate the failure chance of a miss with that given attack type. So Forestall here is pretty lousy with melee weapons (1/8 miss chance) but far better with spells. (1/12 miss chance).

The defense column shows the success chance of a defense against an attack that hits. They are parry, block (with shield or foci), dodge or resist. Not all are available in every situation, and a success costs the character 1 fatigue (or 2 fatigue for a dodge). Forestall, again, sucks at martial defenses, but is extremely good (1/4 success chance) at resisting hostile spells targeting him.

My original plan had been to have a limited number of defenses a character could take in a turn. But tracking these is a major hassle, requiring me to maintain and wipe data arrays each turn. And while some of the defenses can be improved with items, they’re mostly fixed. So you can’t really turn a wizard into a powerful fighter, even with the best gear. I’ll have to be careful to cap off the bonuses as well; it would not do to have divide by zero errors or negative numbers.

Now back to debugging move actions, and getting started on the “strike” code, which must determine hit/miss and damage, factoring in all spell effects.

Oh, bonus points if anyone can identify the source of the name of the “beginner’s” spellbook listed in the equipment of Forestall Grimm.

And yet another quick update…

Work was super-busy all week, so I haven’t made much progress on action processing. I tried taking a video of it in action with Classic99, but curiously, it didn’t record any video. Also, when my units tried to move on top of one another all sorts of interesting (buggy) things happened, so there’s some work to do with that yet.

Actually, what I spent most of the week on was in design. I had always planned to have some defenses in place. The basic “combat resolution” is only used to determine damage suffered. I wanted potential misses, parrying, blocking, and dodging in the game, though, so the question was, how to represent it? I decided on making it fixed to the classes, so some are better than others in various areas that are fixed. Luck may or may not contribute, as well as spell effects and items. I had to redesign my player data array to accomodate some new statistics, fortunately, I had some new room freed up with another change.

Spells and spell usage has changed over the years. (I’ve been at this WAY too long…) My original plan was to have the players hold spell books that contained a fixed number of spells, and they could only cast the spells their class was capable of out of the book. However, I dropped this in the last redesign in favor of permanent “learning” of spells. I was never quite happy with this, though. In my opinion, it made the spell-using classes too powerful, and I regretted losing the spell books that had names of 99′ers in the community, past and present.

So as part of the new statistics, I added a spell “affinity”. This means that with ONE school of spells, the class is more powerful; they are less likely to miss and do more damage/have greater effect when used. I won’t bother restricting spells to classes; by tying spells to books again, each character has a practical limit of 8-16 spells at the most. And I even freed up enough space to increase player inventory to 10 items each!

The necessary changes to accommodate this redesign will take some time and involve some regression testing, but it shouldn’t take too long, and it feels “right”… And I don’t have to create any kind of annoying spell training system. Find or buy the spell books!

On another note, I’ve noticed I haven’t gotten many comments of late. I don’t know if it’s because of the move to Wordpress, or if I’ve just reached that “Put up or shut up” stage where until I actually get something workable out that people can play with, no one’s going to say much. Maybe I need to increase publicity? Ah well…

Another quick update…

I have my orders getting sorted into actions, with randomness and base speeds all added in. It was one of those kinds of jobs where the only way to really tell it had worked was by using the debugger in Classic99 to view the memory areas where the array was populated to see that it was correct.

Now on to the first of the fun but frustrating parts… turning those actions into actual on-screen results!

Action results are split into two forms, the effect (the change in the unit’s state) and the FX (the audio and graphical changes on-screen). I’m putting off the FX portion until all the effects are finished. The reasons are:

• Effects are the most “crunchy” part, like calculating which units are affected by an area spell, how much damage each unit takes, and so forth.
• Graphics and effects are a different kind of design, involving timing, dramatic effect, and other more “artsy” metrics. Better to do them on their own from the actual results.
• I may end up sidetracking into audio/graphic updates as part of FX design

My current order of implementation for the combat engine is as follows:

1. All action result effects, like moving, casting spells, attacking (melee and ranged). Includes feedback text and appropriate delays
2. All FX for spells, attacks, items, etc.
3. Monster AI
4. Combat start/ending (Battlefield preparation, unit placement, mob updates, return to travel mode)

As far as “code” goals go, my main concern is that the game’s total engine fits in the upper 24k RAM on the TI. As of this moment, before effect implementation, I’m standing at about 15,200 bytes. Better than expected! I figure I’ll cross the 16k mark (and have three E/A #5 files) by the time I’m done with #1.

If for some reason I get close to the 24k mark, I can still finish the game, but it gets burdensome. I’ll have to start moving dataspace around in the lower 8k RAM to make room for code, which hopefully will be only a little spill-over. I do have some space there, but we’re talking less than a kilobyte at best. I hope it doesn’t come to that; I’d rather hunt down ways to optimize the code.

After the combat engine is finished, I still have the quest and NPC interactions, and the inventory management, both personal and buying/selling. There’s some open design issues here to solve as well, but I don’t expect them to be overwhelming.

A short update…

I’m about done with the control system. There’s some item controls I will need to finish later, but the bulk of the targeting and order selection is done, more than enough to test with. Debugging wasn’t too bad… most of the errors were simple; wrong register in a bad place or a number off, that caused spectacular crashes but once fixed were quite sedate. I suppose I’m getting better at the code design.

Now comes the tricky bit… putting the orders into an actionable form.

All the units on the screen can have up to four orders. These are processed to determine how “fast” each order is. This depends on external factors, such as the relative base speed of the unit (with armor penalties applied), weapon speeds, spell speeds, haste or slow spells, and so forth.

Since I want first actions to take place before last actions, each action gets a “base” value added for speed, to indicate sequential order. The base is reduced for each action in turn, so that for a single unit, all actions occur one after another in sequence. Each order also has a random value added or subtracted from the speed.

After all speed values for all orders have been fully calculated, I then sort to get the highest values in order, and build an array containing the exact number and sequence of actions to occur in the round.

Coding this is turning out to be a lot more of a headache than I thought. Since I’m working in vintage assembly on a tight-memory constraint, I have to do things carefully.

I realized last night that I should pre-prepare the speed values before the players even go with the random values, and actually put the order speed changes directly in when a player selects them. This means I don’t have to reprocess orders later to get speeds. After all players have gone, I know exactly how many actions each took, and I can add the base values.

So, that’s what I’m working on now… testing it will be tricky, I may want to disable the random factor at first so I know exactly what order to expect.

After this, it’s action results! I expect some redesign to occur at this stage, because I don’t have all my combat mechanics worked out in totality. This was deliberate, as I wanted to leave myself some elbow room to play with concepts.

I’m working on the combat option system. So far, it’s not quite done, but debugging all the code I’ve written over the last week or so hasn’t been as bad as I feared. Generally, writing code is like building a house of cards… one bad one at the bottom causes the whole thing to come tumbling down.

The first bug I ran into was a regression; the statistic screen for player spells caused the VDP to go “wild”, switching modes and going into psychedelic colors. When this happens, it’s usually means you have a runaway video write going on, usually with a totally illegal value. The top two bits of a word are used to indicate VDP write modes, so even a negative value can cause it to go off quite spectacularly. An investigation quickly showed that I was using an archaic method to generate the spell lists, and I was able to leverage some new routines to do the job quicker and faster.

The other problem was the command going back to travel mode while still on the combat screen, among other bugs… this I traced to having subroutine returns in the wrong places. I use a stack tracked by a static register to store return addresses, allowing me to branch and link in multiple layers rather than just one. This works pretty well, but it’s easy to lose track of where you’re at. Then I found a bunch of problems with the sprites, such as them not being in 16×16 size mode. This was occurring because the contents of VDP register 1 are set to the value in the scratchpad at address >83D4. Every time you call the ROM routine to scan the keyboard, it does this replacement. Why I don’t know… fortunately it only needs to be done once.

Chosing a target

As you can see on the screenshot, I finally have a working target cursor. You can’t see it, but it is blinking, courtesy of a sprite animation routine I have in the system. Unlike Tunnels of Doom, you do not move the cursor around until you are on an enemy; instead it lets you cycle through the targets. Only area-effect spells allow free targeting anywhere on the screen.

Right now, I’m still debugging each command one at a time until it’s perfect. I added a cancel routine so you could remove the last order given, or all of them. Unfortunately, I can’t provide much in the way of tracking what each order was; I don’t have the icons to really show a complicated command with only one or two letters. Attack or move in a direction, easy. Attacking THIS unit or casting THIS specific spell is quite another. For now, I use single letters, like ‘M’ for move or ‘C’ for cast spell. It will be up to the player to remember what he ordered.

Why so much trouble, tracking actions? Well, my goal here is to not have your actions occur in a sequential order by player. Instead, each individual action will be given a speed, based on the action taken and a bit of randomness. Monsters actions are determined in a similar fashion. This means that you’re not certain most of the time WHEN your actions will occur.

I got the idea for this from a reading of the old AD&D 1st edition books. In that rules system, combat was divided into strict segments. Initiative wasn’t the only determination for when things happened. Weapons speeds were a factor, and spells never went off quickly. This allowed things like interruptions and granted advantages to faster weapons. As far as I know, very few people actually played the rules this stringently… AD&D was notorious for being over-complicated, and most players house-ruled a lot of things in, or ignored what didn’t work well. (For example, critical hits are NOT in the original rules, but most players add them anyway.)

I don’t know yet how fun this system will turn out to be. I’ve reduced the randomness quite a bit from my first design; I realized that since players would be blind to the exact numbers most of the time, too much randomness would make it seem arbitrary and chaotic. Hopefully it makes the tactical system more interesting than frustrating.

Well, didn’t get around to working much on the code this weekend, but I’ll get back on it. Regrettably, I usually find I’m most motivated when I’m at work… at home I just want to relax. I really envy people who can take that work attitude home with them.

I found a new TI forum lately, at AtariAge. I’ve been there a few times in the past, there’s some great retrogamers there from all over the world. Much to my delight, they’ve started a TI-99/4a programming board, and a number of 99′ers hang out there discussing pet projects. There’s even a contest going to write a retro game! I’d join up, but my own project is not likely to make the deadline…

And now a sedge-way into some coding discussion…

An interesting programming issue on vintage systems is the need for complex mathematics, but only using integers. Granted, most old computers did have some form of real number implementation, but it was rarely used. Why? Here are the reasons:

• Real numbers take up more memory than integers
• Real number handling requires special routines, either in hardware or self-written
• Real numbers are rarely needed, and not worth the trouble to implement

The TI-99/4a has a very good floating-point number system, which uses the radix 100 implementation. The numbers are 64-bit; 8 bits for the power,  with 14 significant digits in the mantissa. This particular implementation was usually seen more in accounting and business than science, but is easier to manage than bit-wise implementations that modern processors use. The TI could beat PC’s of the era in floating-point accuracy quite handily.

However, using floating point on the TI is really annoying and expensive in time and resources. All numeric variables in BASIC and Extended BASIC are floating-point, which is one reason it’s so slow. A number of routines for manipulating floating point are present in the ROM and GROM chips of the console, but accessing them requires using the XMLLNK and GPLLNK utilities provided, or writing your own version of them. (Something I have not done myself yet, and am in no hurry to do.)

Generally, what I need floating point for is usually very specific tasks. For example, determining the distance between two points on a coordinate plane. This is easily done using the Pythagorean theorem, which states that the distance is equal to the square root of the added squares of the differences between the two points, or:

This particular calculation could be done using the GROM routines for both power and square root, but why do that? Why not use integers? (Assuming you don’t care to have accuracy beyond a single whole number…)

Before calculators and clever programmers, there were methods to calculate square roots, as accurate as you needed them. One method is the Babylonian method, described by the greek mathematician Hero of Alexandria in the first century AD. It is a quadratically convergent algorithm, which means it doubles in accuracy with each iteration. Here’s the description:

1. Start with an arbitrary positive start value x₀ (the closer to the root, the better).
2. Let x_n+1 be the average of x_n and S / x_n (using the arithmetic mean to approximate the geometric mean).
3. Repeat steps 2 and 3, until the desired accuracy is achieved.

It can also be represented as:

So, how to do this in assembly with integers? Well, first you need the deltas between the two coordinates. This is easily done with subtraction. Then you need your arbitrary value, or pseudo-root value. I decided the average between the two deltas would be all right. Technically, any positive value would work. But choosing something closer to the actual value reduces the computation cycles. Then you simply do some division and addition in loops changing the pseudo-root value each time, checking if the new value is equal to the prior value. (Ignoring the division remainder and focusing on the quotient only.) If it is, the cycle is complete and you have your distance!

Here’s the code in TMS9900 assembly. It’s VERY nice that we have multiply and division opcodes in the language; this routine would be more complicated in 6502 assembly:

* Distance calculator
* @XD - X Delta
* @YD - Y Delta
* Returns value in R0
DICCLC MOV  @XD,R0
       MPY  @XD,R0                     * @XD^2 into R1
       MOV  @YD,R2
       MPY  @YD,R2                     * @YD^2 into R3
       A    R1,R3                      * R3 = Seed value
       MOV  @XD,R4
       A    @YD,R4
       SRL  R4,1                       * R4 = (XD+YD)/2 (pseudo-root value)
DC1    MOV  R3,R1
       CLR  R0
       DIV  R4,R0                      * Divide Seed by PRV
       A    R4,R0                      * Add PRV to result
       SRL  R0,1                       * Divide by 2
       C    R0,R4                      * Compare to original PRV
       JEQ  DC2                        * If equal, value found, end routine
       MOV  R0,R4                      * Else, replace PRV and reloop
       JMP  DC1
DC2    RT

Well, that was fun. Let’s look at another…

Another floating-point function I rather wanted to have was sine and cosine. Why? So I could have sprites move in circles and arcs. Trigonometric functions are located in the ROM of the console, but of course, we want to use integers, and on the TI screen, we really don’t need all those digits anyway…

As a quick reminder, in case math class was a long time ago for you:

Sine

The sine of an angle is the ratio of the length of the opposite side to the length of the hypotenuse:

Cosine

The cosine of an angle is the ratio of the length of the adjacent side to the length of the hypotenuse.

These two functions can be used to determine the exact coordinates around a center point. Radius is used as a multiplier on the ratios. The center position coordinates are just added to the results for each. Where the point for angle 0 starts depends on which one you use on which coordinate, X or Y.

This is a bit more of a difficult implementation, namely because even calculating sine and cosine using integers is a lot of work. Instead, I use a data table. This isn’t a new idea; until dedicated floating-point hardware existed in 3D video cards for the modern PC, most PC games used data tables for their trigonometric values instead of calling functions. And for the same reason we use it here, speed and efficiency!

I only need to have a quarter-circle of ratio values; the other three quadrants can be determined by inverting signs on values. The ratio divisions and angle use the range of a single byte, which is accurate enough for my purposes. By just running angles from 0-255 through the function, I can continually update a point’s position so it does a circle around the point.

The routine below will generate a position change on an X or Y coordinate to move it to the expected point for the radius and angle. Changing the radius along with the angle will make it spiral inward or outward. Increasing the angle differential in the loop will speed it up, making the angle differential negative will move in the opposite direction. Very cool!

* Data block for trigonomic values
TRGDAT BYTE 0,6,12,18,25,31,37,43
       BYTE 49,56,62,68,74,80,86,92
       BYTE 97,103,109,115,120,126,131,136
       BYTE 142,147,152,157,162,167,171,176
       BYTE 181,185,189,193,197,201,205,209
       BYTE 212,216,219,222,225,228,231,234
       BYTE 236,238,241,243,244,246,248,249
       BYTE 251,252,253,254,254,255,255,255

* R0 = Radius
* R1 - Angle (0-255)
* R2 = Position Adjustment
TRIGX  AI   R1,64                      * Add 64 to angle
       ANDI R1,>00FF                   * Keep in 0-255 range
TRIGY  MOV  R1,R3
       SRL  R3,6                       * Divide angle by 64
       JEQ  TG1                        * If 0 (first quadrant) goto TG1
       CI   R3,1
       JEQ  TG2                        * If 1 (second quadrant) goto TG2
       CI   R3,2                       * If 2 (third quadrant) goto TG3
       JEQ  TG3                        * Otherwise is 3 (fourth quadrant)
       MOVB @TRGDAT(R1),R2             * Copy ratio of angle
       SRL  R2,8                       * Adjust for full register
       AI   R2,-256                    * Adjust angle by -256
       ABS  R2                         * Make angle absolute value
       MPY  R0,R2                      * Multiply radius by angle
       DIV  @W256,R2                   * Divide total by 256
       NEG  R2                         * Negate position change value
       JMP  TG4                        * End routine
TG1    MOVB @TRGDAT(R1),R2             * Copy ratio of angle
       SRL  R2,8                       * Adjust for full register
       MPY  R0,R2                      * Multiply radius by angle
       DIV  @W256,R2                   * Divide total by 256
       JMP  TG4                        * End routine
TG2    MOVB @TRGDAT(R1),R2             * Copy ratio of angle
       SRL  R2,8                       * Adjust for full register
       AI   R2,-256                    * Adjust angle by -256
       ABS  R2                         * Make angle absolute value
       MPY  R0,R2                      * Multiply radius by angle
       DIV  @W256,R2                   * Divide total by 256
       JMP  TG4                        * End routine
TG3    MOV  @TRGDAT(R1),R2             * Copy ratio of angle
       SRL  R2,8                       * Adjust for full register
       MPY  R0,R2                      * Multiply radius by angle
       DIV  @W256,R2                   * Divide total by 256
       NEG  R2                         * Negate position change value
TG4    RT                              * End routine

That’s all for now!

AtariAge TI-99/4a Programming Forum

TI-99/4a Tech Pages (Real number section)

Wikipedia: Methods of Computing Square Roots

Since I got a new blog space, I’ve felt that little nudge of conscience that tells me “Hey, quit screwing around and get some work done on the CRPG!”

When I last left off, combat needed the controls defined. This is one of the scariest parts of the codebase because it could so easily burn up a ton of precious bytes I need for special effects, quest management, inventory, and so forth. Writing the controls is fast becoming a major snowball. Every time I think I’m about finished, a dependency rears its head.

For example, today while coding the targeting systems, I realized I had to go back and determine the exact code structure for item and spell selection. Depending on what item or spell you’re using, a second targeting call may be needed. So the structure must support multiple calls. (One to select the item/spell, another for the item/spell itself…) Plus for items and spells it has to mass-load all the names into memory for the scrolling menu, and then load specific spell/item data to determine their needs. Fortunately, I already had a good file support system for this.

After that part was done, I realized that in order to have a movable cursor on screen, I need to implement the sprite animation I’ve planned for awhile but not coded yet. This includes animation interrupts as well as instantiation. I’m limiting myself to a maximum of four sprites, so this helps me keep it under control. Sprites can have up to two colors and two patterns that alternate at two potential different speeds, currently. This may all change later when I get into FX development, but as a placeholder it works.

So I get that done… THEN I realized I had to create a helper function to build lists of viable unit positions for menu selection. ARGH! I’ve hard-coded that the first four units are ALWAYS players, but monsters may end up with dead units, so I have to be careful. Also, the on-map coordinate system doesn’t exactly match up to sprite locations, so some adjustment is needed. Still, I got that done too.

Of course, none of this has been compiled or run yet. It will almost certainly collapse in a pile of errors. I find that most of my bugs come from single instruction flaws, like a byte offset by one or a slightly wrong instruction. (A very bad one is a subroutine return in the wrong place; this can totally cause the program to go berserk.)

Also, I’m really starting to feel that glowering irrational hatred for the user, who can’t just “think” his options into the registers and make my job easy.

I plan to try and wrap up controls and action storage this weekend so that I know all player actions are being dutifully recorded into an array. Correctly. Once that’s done, I can get to the slightly more fun part of the combat engine… the monster AI and the action determination.

It’s interesting how history repeats itself…

Eight months ago, Yahoo shut down their blog service, Yahoo 360. Given that it wasn’t a very good blog service in the first place, I didn’t shed many tears. However, I was left with the problem of where to locate my blog. Yahoo generously offered transfers to Wordpress, but I had it in my mind to move to Blogger instead. Several of my friends used Blogger, and it looked like it had a lot of flexibility and control.

Moving over wasn’t easy, though. Blogger had no support for importing Yahoo 360 blog entries, so I had to actually create a Wordpress blog first, and then transfer from that! And then Blogger didn’t get any of the comments for my older posts. Still, I was willing to forgive and forget.

And now, Blogger has decided it’s too much trouble to offer FTP services. Instead, they’d rather make all their users use their web hosting services. Since the majority of their users use it for free, it’s not a total surprise. However, a lot of FTP users were that way for a reason… they had a lot of custom content that required their own server, or they already had domain space to use, etc. I think Blogger’s going to find the fallout from this move far worse than they thought it would be. In addition, the fact that Google owns their servers may hurt them as well; Google’s reputation for security has gotten rather tarnished of late…

Anyway, I’ll be updating the CSS for this blog in the next few days to make it something more unique and to my tastes over the standard appearance. Wordpress looks like a good blog service, I hope to stick with them. And I like that I got all my old comments back as well!