To check if three memory modules were truly dead, I brought them to work this morning and tried them out in one of the Dell workstations. The system failed POST with a 1-3-1-1 beep code indicating DRAM refresh failure, so it's not my motherboard causing the problem. I filled in the RMA request forms last night and sent them to G.Skill support, so that should get things started here in a few days.

My desktop computer is functional again, though with only one memory module installed. Any attempt to use one of the other modules fails POST, so I think it's time for an RMA.

I acquired a PC speaker from someone at work, and that helped immensely. Without memory installed—with or without graphics card—the motherboard played one long beep and two short beeps. That indicated that the processor was working, so that was significant progress all by itself. With memory installed—with or without graphics card—it made no sound at all. That was somewhat baffling, so I called ASUS techical support.

After a long time on hold, I talked with a service tech who explained that one long beep and two short beeps was the motherboard complaining about (absent) memory. With memory working correctly, it should progress to the next step and complain about the (absent) video card with one long beep and three short beeps. If it didn't do that, the memory module was not working properly.

I went through all four memory modules one at a time, and only one of them progressed to one long beep and three short beeps. With the graphics card installed, it made one long beep indicating a successful start and later made a faint "complaint" sound presumably resulting from cleared CMOS settings or lack of a boot device.

Once I get home tonight, I'll put everything back in the case and connect it to the monitor to see what's going on. I suspect that the BIOS revision may have compatibility problems with some of the memory modules, so I'll try updating it to the latest now that things are at least starting. If that doesn't fix it, I may have to get some new memory modules. They have a lifetime limited warranty, so I may be able to get them replaced if they've gone bad.

My Shmup-Dev entry, "Laser Maze", actually has two three votes—none of which I put there. :)

I think Ray-Saber articulates the session theme better and has more gameplay, so I expected it to win. It isn't obvious at first how to use the player ship's weapon (the titular ray-saber), but 5parrowhawk noted that he originally intended to have a "main screen" level that also served as a tutorial. That would help new players immensely, but there's only so much that can be done in two weeks.

There was some great discussion in the voting thread, too. That's a good thing to see, and something I hope continues in future sessions.

I finally rebuilt my desktop computer with the motherboard I received while I was away. The system failed with the same blank screen and full-speed graphics card fan, and A CMOS clear didn't fix it this time. Even a minimal system consisting of motherboard, processor, two memory modules, and graphics card failed. I also tried running outside of the case just to make sure it wasn't an electrical short, and that didn't work either. I think the processor may be dead, but I don't have a speaker to listen for beep codes.

My entry for session 2 turned out better than I would have expected considering how little time I spent actually working on it. All I did was add Beam and Tilemap components, lay out the level with a Tilemap, and (on the flight back from Austin) give Aimer some simple obstacle avoidance so it wouldn't look completely retarded. The result ended up being simple but entertaining enough for a prototype even if it doesn't do anything especially clever with the prototype theme.

I found the Laser Ships far too deadly to serve as "normal" opponents, so I created a much weaker enemy: the Zap Ship. I took the Swarmer template from the main level, reduced its movement speed for the confined environment of the maze, and gave it a short-range "zap" beam inflicting one damage point. A single Zap Ship isn't that dangerous, but a large pack of them can cause a lot of trouble.

The level activates pairs of Zap Ship spawn points at regular intervals, allowing a gradual escalation over the course of about two minutes. The level then activates four Laser Ship spawn points, but that's about as hard as it gets; four Laser Ships in a relatively confined space is plenty. Gradually increasing the challenge level would help with long-term playability, but that's a separate issue.

On the message forum, Sparrowhawk suggested a use for the blue pods:

Alternatively you could take a page from "Defender" and, instead of the enemies destroying the blue pods, have fast-moving worker enemies (a third enemy type) that try to capture the blue pods and take them back to their bases, where they turn into laser ships? After all the blue pods are gone, no more worker enemies spawn; laser ships spawn in their place.

This would combine play mechanics from Rip-Off and Defender/Stargate, and would make a much more interesting game. I had a vague notion of doing some sort of "pod abduction" mechanic for the main game but never did anything about it. Maybe it's time to add it.

Unlike the dozen or so entries for the first session, there were only three completed entries (including mine) because several members were busy this round and couldn't participate. That was somewhat disappointing since I like seeing what other people come up with for the theme. There's a strong possibility I could win this round based on the positive responses so far, but I would have preferred more participants even if it reduced my chances of winning.

I got back from Austin early yesterday afternoon, and went in to work (after posting my entry for the second Shmup-Dev rapid prototyping session). I wouldn't have bothered ordinarily, but I didn't have quite enough vacation balance to take off Monday. Amusingly enough, I got back just after a big weekend of last-minute submission-blocker fixes so things were fairly dead that whole day. I ended up leaving around 6PM since nothing much was going on and I wanted to take my now-repaired motherboard home.

While I didn't plan things this way, the timing of my vacation kept me away from about two solid weeks of serious crunch time. I'm sure I'll find something to do over the course of the week, even if it ends up being preparatory work for Mercenaries 3.

While I have a decent system in place at the moment, Aimer might be well-served by a PID Controller. It requires no understanding of the internal workings of the system that it's controlling, just tracking of current error (for the "proportional" part), accumulated error (for the "integral" part), and delta error (for the "derivative" part). Aimer could then work with more complicated systems at the expense of three gain parameters (proportional, integral, and derivative) and two stored error values (previous error and accumulated error).

Aimer currently uses a PD Controller with distance for the proportional part and speed for the derivative part. Adding an integral part wouldn't be that hard, though it would need lower and upper bounds for the integrated value (an enhancement seen in some of the samples).

As part of an experiment with level design, I added a set of blue-team bullseye targets that will eventually serve the role of "humanoids" in Defender/Stargate (or possibly the "canisers" in Rip-Off). I noticed that the Laser Ships tended to oscillate wildly around the specified "close" distance, often ramming into their targets on the first pass.

The first problem was that the close-distance repulsion (and far-distance attraction) effect had no damping whatsoever. I added tunable "spring" and "damping" parameters for each distance, and that helped a lot. Coming up with good values for these parameters takes some trial and error, though.

The second problem was that the move vector was normalized to unit length instead of clamped to unit length, so movement was always set to maximum throttle. That was not what I had intended, so I fixed it. That made unit movement much smoother and more precise.

The only flaw is that unit movement is now somewhat "robotic" when attacking stationary targets. That's more a function of the tuning parameters than a fundamental problem, and the result is still much better than what was happening before.

As a separate issue, Aimer is starting to require way too many attributes:

<aimer
    range="512"
    focus="5"
    attack="128"
    leading="0"
    angle="30"
    evade="1"
    close="64"
    closedistscale="0.0625"
    closespeedscale="0.015625"
    category="4"
    bit2="0"
    bit3="0"
    bit4="0"
/>

These attributes fall into four distinct categories: targeting (range, focus, category, bit*), moving (leading, evade, close, closedistscale, closespeedscale, far, fardistscale, farspeedscale), aiming (leading), and attacking (attack*, angle*). Each category should become a separate component, since they're relatively independent.

Submitting another entry using the same test level is out of the question, so I decided to create a level layout based on the "complex" tank maze from Atari 2600 game Combat. The walls would provide opportunities to take cover, an important consideration when enemies fire laser beams. I saved a screenshot, cropped out the maze, shrunk it by a factor of eight (the granularity), converted it to black and white, saved it to a 40x24 bitmap, and converted the pixels to characters in a text file. I decided that time-consuming and error-prone placement of individual wall pieces by hand would basically suck, so I needed a better way to do it.

I hit upon the solution of using a "tile map" to convert the contents of that text file into procedurally-placed instances. This turned out to be fairly easy--after getting burned by XML collapsing each run of whitespace (including newline) into a single space. A tile map defines the grid coordinates with origin (x and y) and tile delta (dx and dy), maps characters to templates with a series tile definitions, and then defines the contents with a series of text rows. This representation provides tremendous compression and, more importantly, a visually-intuitive structure.

The entire maze required a single wall template (a 32x32 collidable square) and a single tile map:

    <tilemap x="-624" y="-368" dx="32" dy="32">
        <tile name="#" spawn="wall"/>
        <row data="########################################"/>
        <row data="#..................##..................#"/>
        <row data="#..................##..................#"/>
        <row data="#......................................#"/>
        <row data="#.....###......................###.....#"/>
        <row data="#......................................#"/>
        <row data="#.............###......###.............#"/>
        <row data="#.............#..........#.............#"/>
        <row data="#....##..........................##....#"/>
        <row data="#.....#..........................#.....#"/>
        <row data="#.....#..........................#.....#"/>
        <row data="#.....#...##................##...#.....#"/>
        <row data="#.....#...##................##...#.....#"/>
        <row data="#.....#..........................#.....#"/>
        <row data="#.....#..........................#.....#"/>
        <row data="#....##..........................##....#"/>
        <row data="#.............#..........#.............#"/>
        <row data="#.............###......###.............#"/>
        <row data="#......................................#"/>
        <row data="#.....###......................###.....#"/>
        <row data="#......................................#"/>
        <row data="#..................##..................#"/>
        <row data="#..................##..................#"/>
        <row data="########################################"/>
    </tilemap>

Easy!

I even converted the sixteen starfield instances into a tilemap just because I could, reducing them from 48 lines to 7:

    <tilemap x="-1536" y="-1536" dx="1024" dy="1024">
        <tile name="*" spawn="starfield"/>
        <row data="****"/>
        <row data="****"/>
        <row data="****"/>
        <row data="****"/>
    </tilemap>

Update: Packing row data into an attribute string eliminated the whitespace collapse and made double-quote the only "illegal" character. Excellent! (I updated the XML quotes to reflect this design.)

I've finally started making progress again on the laser prototype, after making no appreciable progress over the past week. Much of this was lack of inspiration, though the jam-packed side trip certainly didn't help matters.

I already had the player ship firing lasers to prove the Beam component worked, but the prototype level lacked beam-firing enemies. Looking to classic arcade games, I created a slightly modified version of the Laser Ship from GORF. It emits a visually obvious "tracer" for a couple of seconds before firing a high-powered blast capable of destroying the player ship in one shot. I may have to adjust the damage level in the future, but the Laser Ship is still beatable even with that one-shot kill.

As I have done for the past few summers, I went on a family side-trip to my grandmother's house in the Memphis, Tennessee area. My father stayed home this time, as my sister and nephew were coming along this time; she hadn't been in ten years, and my nephew hadn't been at all. He was finally old enough to make the eleven hour drive, and did remarkably well. A portable DVD player did help, though. The visit itself went fabulously, and he acted like he belonged there. My sister had been telling him about various relatives and showed pictures, so he pretty much knew them already.

(I ended up showing him the shmup while I was there, and he was fascinated. He will even ask to see a specific variant.)

Weapon-tethering works now, though the implementation is definitely a hack. Weapon now contains an optional "flash" template identifier separate from the "ordnance" template identifier. On firing, the Weapon instantiates the "flash", fakes up a link template using the fire point offset, and uses that link template to create a link holding the "flash" entity in place. This bypasses the normal template activation process and relies on the link getting reasonable default values when it looks for a link template that doesn't exist. I'll try to come up with something cleaner at some point in the future.

Tethering works great for extended-duration beams, though one consequence is that the Beam component has to update its intersection distance every simulation step even when it doesn't do any damage. It might be worth having the beam update skip that update if it isn't attached, though separating entity lifetime from beam lifetime might be better.

Using Explosion as a basis, I now have a working Beam ordnance component. The current Beam works very much like its Battlezone 2 counterpart, performing a line segment test to find the closest hit object, applying a damage impulse to the object, instantiating the optional spawn-on-impact template, and persisting separate from the weapon ("afterimage"). It's already fairly useful in its current state, but I still want to add damage over time and weapon-tethering for extended-duration beams.

(I need to do weapon-tethering anyway for "muzzle flash" effects.)

I just introduced my three and half year old nephew to monster trucks and Bigfoot via YouTube. He seemed to like them.

And so it begins...

Start Date : 7/7/2008
End Date : 21/7/2008
Theme : Laser Mayhem: Enemies only fires lasers (beam going from enemy to end-of-screen/wall), no ordinary bullets.

Adding laser beams shouldn't be hard at all, but I need to come up with some original gameplay and levels that express the theme well. For me, this session will be more about building up higher-level structure to make a game that is enjoyable for more than a few minutes..

I'll be flying out to Austin tomorrow and staying there for a bit over two weeks. I originally scheduled this and got it approved while I was working on Lord of the Rings: Conquest, and that prior approval carried over to Mercenaries 2 despite the recent request that people not schedule any new time off until the end of the project. I managed to get through all of the issues assigned to me for the big Beta candidate submission push, so I should be fine until I get back.

Shmup-Dev's second rapid-prototyping session starts Monday, with the theme revealed that day. I don't plan to let it dominate my vacation time, as spending time with my parents, sister, brother-in-law, and nephew is more important; this is a hobby, not an obsession. I do plan to come up with an original level instead of recycling my test level, though.

While I was home for lunch, I reinforced the shipment box internally with cardboard panels from an empty Amazon.com box, taped it up, and took it over to a nearby Box Brothers for shipment via UPS ground. The total cost was just under $18, far less than the $400-$500 for a new motherboard and processor. I'll save the difference for an Intel "Nehalem" processor and motherboard later this year.

I finally disassembled my desktop computer and packaged up the motherboard for shipment tomorrow. All I need to do is tape the box closed, fill out a shipment label with the RMA number on it, and send it off. I'll get a replacement in about two weeks.

Finding the protective cap for the processor socket took a while, as I had put it in the power supply box along with the bottom cap for the processor. I should have put it in the motherboard box, and the bottom cap in the processor box, as that would have actually made sense. In any case, I did find them.

I currently have the Thinkpad connected to the monitor, webcam, speakers, keyboard, and trackball as a temporary substitute, and it seems to be working well. I won't be doing much gaming, but I'll manage.

The system failures seem to be getting more and more frequent. Whether it fails to resume from standby, or the display blanks out spontaneously, powering down and restarting leads to the same result: no video output, video card fan spinning at full tilt. The only thing that brings the system back online is a CMOS clear, and that involves pulling out the video card and removing the CMOS backup battery for about a minute; fortunately, moving the awkwardly-placed jumper block turned out to be unnecessary. I then have to re-enter all the BIOS settings and set the system clock. I switched back to stock clock settings to see if that makes a difference, but I'm not confident. (Update: That didn't help; it still seized up this morning after resuming from standby.)

I had planned to keep my current system running until late this year or early next year when Intel's next-generation Nehalem processors come out. They will not be backwards-compatible with existing motherboards or heatsinks as they use an entirely new socket. Any Socket 775 motherboard or cooler I buy now would be a waste. However, all signs point to my motherboard failing, so I was about to order a new motherboard (ASUS P5Q Pro or Deluxe) and processor (Intel Core 2 Duo E8400).

It turns out that my current motherboard has a three-year warranty, so I've started an RMA for it. I have the original box and everything that went in it, along with the NewEgg electronic receipt. While I won't get the performance bump of a newer chipset and processor, this has the advantage of not costing me several hundred dollars. I'll need some thermal paste to re-mount the heat sink, but that's not hard to get.