I've started uploading FissureVerse cards to Google Drive, which should be freely accessible if you have a link (clicky clicky). I've added the link to the main FissureVerse page as well for easy access. I'll be uploading more cards as they get created, replace cards that get updated, and of course adding instructions. Each card has been individually uploaded, so if you're playing and one of your cards gets damaged and you want just that one, you don't have to waste any ink printing out a page of eight cards. Though, I'll probably also add each full set as a PDF as well, so you can print out a whole set if you like. I've also organized the drive so there's space set up for new expansions, when they come out. At present, there are no Location, Frenzy, or Red cards, but of course that'll change as I get more permission from artists to use their work (or find new artists).
Think of the Google Drive as the current definitive versions of the cards; everything previous to that is old stuff. Of course I'll continue to make blog posts about FissureVerse, and make note whenever any cards get added, changed, etc.
Currently, I've got a total of 32 files uploaded (including card backs and tokens) out of an expected 195 for the base set... so I have a long way to go.
Wednesday, January 28, 2015
Friday, January 23, 2015
Fixed the Drop command to work with the new parser function. Should work, and I haven't yet needed to make it any shorter or longer, so that seems like a plus.
That's about it; no testing yet since I need to get the Take command working first, and preferably all the others. What I really need to do before this gets too deep is get the parser to take adjectives so it can determine which of multiple kinds of the same item/barrier is the one being talked about. Right now I'm reading in multiple items/barriers in the verb functions, but I'm only taking the first listed and assuming that's what the player wants. I think I'm gonna need a whiteboard for that, so I can make some flowcharts and then some pseudocode. It seems like a mess. But perhaps, like a lot of the things I dread, it'll be easier than I expect.
Friday, January 16, 2015
I went back and split the enormous parser function into bite-size pieces. That way I just get to the verb first, and check for other things as necessary. I figure, if the player types a command that in no way could reference barriers, there's no point in checking for barriers in the player's command, yet normally that's one of the first things to be checked. This new way of putting the verb first might possibly reduce unnecessary steps, but at the very least it should make things easier to understand at a glance. That parser command is big and nasty and I had trouble understanding what I coded, even with comments in place. This new change isn't fully implemented yet, but the functions exist without syntax errors, so it's a start.
It ends up chopping the parser command into five functions: the main one that gets the verb, then one for checking barriers, one for checking items in the room, the one for checking items in the player's inventory, and one for checking direction words. I'll also need to check for adjectives, which so far has been half coded in horrendous way, but that code should be scrapped and recreated in a smaller function, which will hopefully be easier and less confusing soon. Maybe.
Next Log: Getting the Drop Command to work with the new Parser Function
Next Log: Getting the Drop Command to work with the new Parser Function
Friday, January 9, 2015
I fixed the take command (in a haphazard way, as I do everything) so the player can't pick up an item they've already picked up, so now there's no more duplicated items.
Next, I recoded the drop command, so the player can now drop items again. Fortunately, that went off without a hitch (well, without many hitches).
I then discovered two more bugs in the take command when testing. First, if the player tries to take an item that's untakeable, he gets the proper message first ("It's too big or heavy"), followed by the wrong message ("Your hands are full"). This is due to some reworking of the take command which eliminated an extra if statement I no longer needed... or so I thought. The bigger bug (which I think comes from the same removed if statement) is a crash when you try to take anything that isn't there, including items not in the room, non-items ("take gobbledegook"), or nothing at all ("take"). But I think what I actually need to do is stop that stuff from happening before it even gets to the take verb, and instead blocks these from happening while in the main parser.
Perhaps, instead, I need to break down the rather large parser function into smaller bits, called upon by the verb functions themselves. That way there isn't much wasted time when parsing. For instance, there's no need to check for items if the player is just walking to the next room. That will take some time to recode, while I'm in the middle of recoding all the verbs.
I wouldn't want to be me right now.
Next log: Parser Work.
Next log: Parser Work.
Friday, January 2, 2015
For 2015, I'm going to attempt themed months. Each month will focus on just one project, other than the occasional review or article or other standalone post. Mostly, I feel like I get a lot more work done when I focus on things for a month at a time, rather than a week.
So one month might be focused on Latchkey, another might be focused on DOOM level design, etc.
For FissureVerse, things are at a crawl while I search for placeholder art and get permission from artists, so there will be no month-long sets for FissureVerse; that'll have to be restricted to updates whenever I can get to them. I don't have the funds to pay for commissions, so the art will have to be restricted to excellent hobbyists who are happy to see their old work used. Naturally, that's rare, so I have to get lucky in a lot of cases. Perhaps when FissureVerse gets enough playtesting and balance to be ready for a Beta release (at least the first set), I'll consider a Kickstarter or something to replace the placeholder art with commissions, and whatever is left over would go into the next sets. But that comes far into the future. For now, I just want it to look good to get people playtesting it.
As far as post scheduling goes: I'm going to push myself to do twice a week posts again. Sometimes it burns me out a bit, but, like doing month-long themes, I feel like I accomplish more with two posts a week. (Perhaps I even accomplish, dare I say, twice as much?)
So, for January, expect a month of Latchkey work. We'll see how long I can stick to that resolution.
|Happy New Year.|
Friday, December 19, 2014
Friday, December 12, 2014
In the eighties and early nineties, Sierra and LucasArts fought each other for the Adventure Game market. Sierra's strategy was to push out long-running series, like King's Quest and Space Quest and keep longtime fans through name recognition. Because of this, Sierra would often try new series and cut them if they weren't as immediately popular as their older series. One of the series they cut, which I mentioned before, was the Manhunter series.
A little later, Sierra tried their hand at another horror series, the Laura Bow mysteries. Like the Manhunter series, the Laura Bow adventures only got two games deep before Sierra retired the series, but it's unfortunate, because they are fantastic. Not only were they complex thrillers, but they were some of the first games that truly scared me as a kid.
The first game was The Colonel's Bequest, where you play a journalism student in 1925 named Laura Bow and solve a series of cryptic murders. At the beginning of the game, you are introduced to both Laura and her friend Lillian at college. Lillian has to go to a family gathering at her relative's estate, an old sugar plantation, and she invites you along. Once you are settled in (and locked in), people start dying. You have to try to figure out who the murderer is, of course, and do your best to stop them. The estate is full of secret passageways that allow you to spy on conversations, and of course there is plenty of classic adventure game puzzle-solving to push through.
The game is great for replaying, since there is so much going on, you aren't likely to catch everything on the first playthrough. While much of the mystery must get solved in the final act to reach the end of the game, you can be left with a lot of questions about the details, which warrants multiple playthroughs to discover.
|Like 'come and get' what? A human head, perhaps?!|
The biggest flaw of the game is a few of the cheap deaths. You can die by checking a closet, or taking a shower, or sometimes just wandering to close to a wall. Follow Rules for Adventuring #1: Save Often; Save Well.
The Colonel's Bequest uses a text parser for commands, in the style of King's Quest IV, so when you begin typing, a text box pops up and the game pauses while you type, so you can take as long as you need to.
The second game of the series, The Dagger of Amon Ra, bumped up the style of the game to be closer to King's Quest V, and the text parser was replaced by a pointer and a series of icons. You right-click to change from looking, to touching, to talking, etc., and then left-click to have Laura follow the command.
In The Dagger of Amon Ra, Laura is now a reporter on her first assignment. Your task is to attend a gala at a museum for its grand opening of its new Egyptian exhibit. The first act has you rolling around New York City, but once you're in the museum in the second act, you're once again locked in, and the bodies start piling up.
|Including, but not limited to, animals in creepy green vats.|
In the first game, you were a stranger to a family affair, and the obvious motive appeared to be that the murderer was eliminating people named in the Colonel's will, so you were fairly safe from being a target (apart from the cheap deaths). In the second game, you have no idea what the motive could possibly be, so the stakes are raised, since you might become a victim yourself. At the climax you find yourself being chased and you have to do some very quick puzzle-solving to get away. It's hectic and frightening--but then we get to the one fatal flaw of the game.
In the first game, the biggest flaws was cheap deaths, but that wasn't too big of a deal if you learned to avoid them and saved often. In the second game, the biggest flaw (and a deplorable one) is that you can be a dead (wo)man walking. In adventure games, the Dead Man Walking is when you are not in any immediate danger, but you cannot possibly complete the game without reverting to an earlier save (if you have one), or completely restarting.
|"Maybe I should restart my career."|
In The Dagger of Amon Ra, there are at least two ways this can happen, and unfortunately they're right at the climax. Being that there's an Egyptian theme, the Rosetta Stone is housed in the museum, which you have to find to allow you to read and write hieroglyphics (as if the Rosetta stone simply says Owl = A). The Rosetta Stone is broken in half, and you have to find both pieces. If you don't, you're hosed. One half is hard to notice, and you don't have much chance to get it. If you miss it, you're out of luck. Similarly, there's a special item you need to grab before you get to the chase, and just like the Rosetta Stone, you don't have much of a chance to get it, and it's a bit pixilated. Without a walkthrough (or some sharp eyes and good luck), you might never complete the game.
It's a shame, because beyond that, The Dagger of Amon Ra is just as good as The Colonel's Bequest.
But, knowing this ahead of time, be sure to save in multiple slots. Even with this problem (which, in fact, a lot of Sierra adventures were prone to), the game is thrilling and ups the stakes from the first.
|For instance, there is this guy.|
Sadly, after the second game, Sierra put Laura Bow to bed and continued on their other popular franchises, despite some positive critical praise.
Both The Colonel's Bequest and The Dagger of Amon Ra can be found on most abandonware sites. Take a look and give the games a shot, if you like horror, adventure, mysteries, or just old games.