Tis the season to be scary

I recently had traffic spikes from two different sources.  Hello new people!  Come for the reviews, stay for the dev logs!

Blog update time:

For the blog itself, there won't be much change next month.  Certainly half of the posts will still be about the horror text adventure, and the other half will be other stuff.  I have a couple of review ideas in mind, so they might show up soon.

But I've also made a little Cafepress shop for some random items, both game-related and not.  I may add new designs as I come up with them.  My markup is basically as small as possible, so they're as cheap as I can get away with (that is, if I understand what I'm doing; the site is not as user-friendly as it could be).  I may switch to Zazzle or another competitor if I find one of them is cheaper for customers.

That's about all the news for now.  Since we're approaching Halloween, have a couple of scary adventure games (multiple chapters each!):

Deep Sleep

The Last Door

Dev Log: Horror Text Adventure #25

I've now changed the temperature fluff from linear to being based on height variance.  It works better, with no more out of range exceptions, though it's still not the greatest.  Eventually I'll find a far more dynamic solution, just to mix things up, but for now at least it's interesting.  The only problem really comes in when the player starts in a room that's "so hot you think you're going to faint" or "so cold your toes feel numb."  Eventually this will be far more than flavor text, and might have some kind of measurable impact, so it wouldn't do to have the very first room put the player in mortal danger.  But again, for now, since it's just flavor text, it's more of an experiment that can be applied to other circumstances later.

However, all that's just goofy fun stuff.  The really meat I accomplished is adding "examine" to the dictionary.  When the player types "examine <object>" the game checks the room for that item, and spits out the item description.  If it's not in the room, it checks the player's inventory.  I'm thinking to make the game slightly more realistic, the player will have to have a limited inventory.  Bags of holding are silly.

But, in any case, the player can now walk, take, and examine.  We might have the start of an adventure game here!

Extraneous Monkey

Dev Log: The Vortex #30 - Card PDFs

Since I rearranged my Dev Logs & Projects tab, I realized how many projects have been postponed.  Let's fix that.

The main reason I put The Vortex on hiatus was because I live in a gaming dead zone where I can't get testers easily.  But why let that stop me?  Just like my Dominion mods, there's no need to make them truly local.

So even though I can't watch people playing this game, they can still test it.  Here are a bunch of PDFs of the cards for you to print out and play, as well as a PDF of the current ruleset.

Each set of cards is in a separate PDF because there's hundreds of cards and putting them in one PDF would make loading it take forever.  It's easier to print them out this way.

The Blue, Green, Red, Yellow, and Locations each get printed out once.  Rogations and Frenzies get printed out twice.  Obviously, print out as many copies of the rules as you like :p

Blue PDF

Green PDF

Red PDF

Yellow PDF

Frenzies PDF

Locations PDF

Rogations PDF

Rules PDF

Feel free to print them out and play, and leave a comment about anything you feel sucks and should be changed (also comments saying what's awesome is also welcome).

Note: all the images are purely placeholder and are not my own.

Dev Log: Horror Text Adventure #24

So while I was taking my dog for a walk, all bundled up against the biting cold, I decided to add temperature as some flavor text, determined (for the moment) by your z coordinate.  As you go down, it gets hotter, and as you go up, it gets colder.  It was a quick little job, throwing in a case statement for particular floors (though I'll make things more complicated later).  At present, the cold and heat only go up and down to around floor 10 and -10, respectively, and a quick trace error on world creation lets me know when the world is too tall for it.  It's interesting to watch, since sometimes the world sprawls out horizontally without too much variation in height (and I get no errors), while other times I get dozens of errors because the world is like a skyscraper.

Of course, it's not really an error, I just need to have the temperature make more sense.  But as a test for world-determined (instead of room-determined) flavor text, it works.  I will probably also mess with the odds of a change in z, so the skyscraper effect is more rare.

The real error I discovered when I did this is that I've connected rooms backwards.  At first I was confused as to why going down made things colder, then figured out basically when two rooms were connected, and one z is less than the other, the former room was connected above the latter.  That, of course, means that not only did I have my z logic wrong, but east means west, and north means south.  That was quickly corrected.

I also came up with a quick way to randomize what items are in a room, and as a test, a hallway may or may not have a painting hanging on a wall. I can also determine the exact odds of any given item in the moment of (potential) creation.  I may need to generalize this later, when the number of potential items gets large, but for a quick couple of lines, it works for now.

Punk-O-Matic 2: Flash Game Mini-Review

I first discovered the original Punk-O-Matic on Newgrounds many years ago.  It was a simple music maker, allowing the user to make punk music with predefined licks and chords and play it.  You could also extract a code that you could then post so anyone could copy it and listen to the tune you made.  The comments section was full of great music, and it was certainly a fun tool to waste an hour on.

A few years later, I discovered Punk-O-Matic 2 on Armor Games.  This seriously updated it and turned it into a rhythm game.

A pretty neat interface, too, that's much more intuitive than Rock Band.

In POM 2, you start as a garage band, earn money by playing gigs, update your image, learn cover songs, and of course, create your own music with a far more robust system that allowed for not just various kinds of punk, but if you really worked on it, you could make metal and ska (minus horns), too.

A music maker that's fun to work with? Absurd!

POM 2 has a storyline, humorous cutscenes, and the ability to play any of the four instruments.  Best of all, on Newgrounds, Armor Games, and Kongregate, you were no longer restricted to creating codes for your music, but could simply upload them and browse other users' songs as much as you like.

POM 2 was created during the height of the Guitar Hero craze.  Of course, you can't exactly plug a guitar into your computer to play, but instead use six grouped keys on your keyboard.  Two players could also share the keyboard and play together.

I spent ages making music on POM 2, let alone playing the songs in concert.  The problem came in a bit later when, for some reason, parts of POM 2 started breaking.  Scrolling became a problem, and even the controls for playing got buggy.  I couldn't quite understand it.  My only thoughts were that browser Flash updates broke it, and then it never got an update.

But I recently discovered a downloadable version, which works great.  The community disappears because you can't publish your songs to a game site server, but the controls and scrolling are no longer broken.

Now that I've found a working version again, I can recommend giving it a shot.  You can download Punk-O-Matic 2 from punk-o-matic.net.

Don't forget to turn num lock on for second player controls!

Dev Log: Horror Text Adventure #23

Why was I doing things the crazy way I've been doing?

I keep abstracting out the way the world works because in my mind the world is not truly in 3D space the way, say, an FPS is.  But it makes far more sense to give each room an xyz coordinate set.  Now I'm no longer creating rooms within rooms, and creating an inefficient "snaky" form of maze.  Instead, I just create rooms with an xyz, and on creation of each room, change one of those coordinates by one, plus or minus.  Then check to see if I'm accidentally overlapping rooms, and make corrections with recursion.

That part's all set now.  And with that proper world gen in place, I have much more easily set up barriers.  Now barriers aren't created when the room is created, but is instead a separate process because rooms need to know who their neighbors are before barriers can be made, and if their neighbor hasn't been made yet, it would need to be corrected anyway.

Right now I've made it so if a room has a neighbor in a particular direction, there is a passage between them.  If it doesn't, there is a wall.  This is of course too simple for my goal, but for now I'm doing it that way so I can see at a glance what the structure of the world is.  It actually doesn't work out too bad.  It seems like any given room has at least a couple of walls, and some rooms at the edges are dead ends.  This is exactly what I want, and it was decently easy to get it that way.

This is far less convoluted now and nicely top-down, instead of the sideways structure I had before.  I think it's bug-free, too, so I can start moving on to other things.  Maybe I'll add some fluff text, or perhaps I'll tackle doors next.  The doors, especially locked ones, will require a bit of thinking.  Adding doors is easy; it's locking them and putting the keys on the right side that's the tricky part.

Sustainable Gameplay

There are some games that never get old, and I can go back to again and again, and my only wish is that they were longer.  I think I'd still play any early Tony Hawk game (keyword 'early') if one was handed to me, and I regret getting rid of some of those discs.

Turn back! Turn back! You've gone too far!

Other games are perfect or near-perfect in how long they last: the gameplay is interesting and fun 'til just after the end, so you never get bored throughout, but you don't clamor for more; you just feel satisfied from a great game experience.  I think Super Mario Bros. is like that.  If you beat the game by warping, you don't quite feel completely satisfied, so you re-challenge yourself to beat the game by completing all 32 levels.  After that you feel like "Yes, that was quite enjoyable, but I'm done now."  Really no need to beat the second run through that becomes available with different enemies, I assure you.

Then there are other games that you give up on, because the gameplay was interesting and fun at first, but it overstayed its welcome.  This is a line hard to describe, since everyone has their own opinion on what games are too long.  But I think for me, often RPGs are too long considering their gameplay.  I remember playing Earthbound Zero (Mother) and getting around 95% of the way through before simply giving up.  Not because I died or it became too challenging or frustrating, but simply because the grind got boring.  The gameplay was fun and enjoyable, but it just didn't go barely far enough to be interesting to the end of the game.  If the game were only 5% shorter (no story changes, just shrink a few levels), I would have finished it and been satisfied.  I was interested in the story, too, but my desire to finish the story did not override the plodding gameplay.

I'm pretty sure I never figured out why my house was haunted.

And it's a fine line to cross.  I'm sure many people thought Earthbound Zero was great, espcially RPG diehards (as a generalist who enjoys almost any genre, I'm not the target audience for RPGs, and find that most of them overstay their welcome). I've also heard the tired argument that "It's about the story, not the gameplay" in RPGs.  Sure, story can take precedence over gameplay, I have no problem with that; but gameplay should not undermine the desire to even finish the story.

And it's hard sometimes to determine, from a conceptual standpoint, how long the gameplay will last for the target audience.  You might have a great mechanic that's enjoyable for fifty hours, but you have no way of knowing that until far into the development process, and your game is expected to take about sixty hours for the average player to complete.  Well, you just got hosed, and it was hard to determine that without an extreme amount of testing before making all those assets.

One way to get it right is to betatest, getting gamers who have never played the game to go from start to finish and use their feedback to determine if the game is too long or too short (the former sin being far worse than the latter).

Too short, but I'm okay with that.

The other option that was a fad for a while (and is it still a fad? I hope not) was to incorporate minigames to break up the main gameplay.  I remember Final Fantasy VII had a kind of tower defense minigame on a mountain (before the concept of tower defense was even a thing; oh, that hipster Square).  Tony Hawk's Pro Skater 4 added baseball, tennis, and other nonsense.  The problem with these is their very intended purpose: to break up the gameplay.  They feel jarring and hurt the overall experience.  Sure, they make the player want the normal gameplay back, but only because they were given a diversion that was far worse.

Thankfully, I haven't seen that happen too much anymore, and when it does, it's a much smoother transition that works within the game so you hardly notice you're doing anything different.  Something like the pegasus rides in God of War II might be an example, since you're still doing approximately the same thing you did on land (kill things), so it's not a total departure.

The other way that most games prefer to do things is to introduce new mechanics throughout the main game that enhance gameplay.  In RPGs, you get new skills, items, spells, etc.  In first-person shooters, you get new kinds of weapons.

But sometimes I feel like that's just delaying the inevitable.  If the core mechanics constantly need something new to perk it up, it's just slapping one band-aid on top of another.  I've played too many games where the gameplay has just started to get boring, then a new weapon appears like a deus ex machina to rescue the game for another ten minutes.

Some games do new mechanics well, adding new dimensions of gameplay without overshadowing the original gameplay.  But that works because the gameplay without the new mechanic is still fun and interesting by itself.  Take, say, Mario 64.  Before you get any caps, the game is awesome, and when you start to get caps, it opens up new possibilities and locations you couldn't reach before, provides new challenges, and adds significantly to the experience.  Yet it also does a great job balancing these mechanics, by making caps a rare thing to get.  Only certain blocks give them to you, and they only last for a limited amount of time.  The caps don't overstay their welcome, and the gameplay without them doesn't get diminished after their discovery.

There is a preponderance of upgrades in games these days, I think.  Seems like too many games give you a new upgrade or weapon or ability every five minutes, as if you're a baby and each mechanic is a bigger set of keys being jangled in front of your face.  At some point, the keys get too loud and bright and you get overload.  And let's stop this metaphor before it becomes stupid.

Anyway, I often feel that these upgrades try to distract a player from bad gameplay by making it addictive instead.  You want to know what you'll get next, even though you don't enjoy playing the game in the first place.  If you think about Super Mario Bros. again, there are three upgrades you can get: the mushroom, the flower, and the star.  All three are introduced in the first level, so you know what to expect, and they become a standard part of gameplay that you work hard to keep from losing.  But you don't get a new upgrade in the middle of the game that significantly changes the gameplay.  I think it would be quite damaging to the game if you had to wait until world four to get your first fire flower.

I remember Manhunt, that game where you sneak up on people and kill them in all sorts of delightfully gory ways.  There is a point in the game where you operate a magnetic crane with a fridge on it, so you can whack bad guys around.  I thought it was a funny diversion for a couple minutes, but then it lasted just a little extra too long so I wanted to get the heck out of the crane so I could play the main game again.  It was a minigame that was funny at first but overstayed its welcome.

Then came the point where you stop sneaking around and the game turns into a shooter.  I turned the game off.  That completely changes the gameplay and it wasn't the game I paid for and was promised.  But I see why they did it: the sneaky killing was getting boring.  Well, instead of changing the gameplay completely, they should have just shortened the game.  I would have been perfectly satisfied if the game ended just a hair before the mechanics got boring, so there would be no need for gunfights.

So it wouldn't devolve into every other game ever made.

True, the game would have been short compared to other games, but it would have been exactly the length it needed to be.

I think there is this idea that games need to be extremely long to be worth the price, but what's that maxim? "Quality over quantity."  I think the mechanics of a game should determine how long the game lasts, and nothing else.  If the story needs more gametime, then perhaps the story should belong in a game with gameplay that is interesting for a longer amount of time.

And then there are the games I mentioned right at the beginning, games which seemingly never get old.  The gameplay is just so good that you'll be happy to play the game until you upgrade your console or computer and it no longer works.  And these games certainly do exist; take any successful multiplayer game.  All the infrastructure required, the servers and support teams, bank on the gameplay being so good it's worth all that cost.

But perfect gameplay for single-player doesn't translate to perfect gameplay for multiplayer, so it becomes an even trickier puzzle to solve.  But I think that's for another article.

What we can say is that this does not work for multiplayer.

Dev Log: Horror Text Adventure #22

I am in the process of creating barriers between rooms: walls, closed doors, and empty passages.  I have to recode a fair bit to accommodate them, but I think it's better to do it now before movement gets any more complicated.

Basically right now any two rooms are doubly linked, and only empty passages connect.  Of course I need to add doors, especially locked ones, but I also want to be able to connect rooms by an impassable wall, so the player can't move through them, but ghosts can, and the player can hear through it.  The system I have in place doesn't allow for it.

So I'm recoding it know so rooms will connect in a particular direction to a Barrier object, so I can make checks to see what type it is, and if it's a door, if it's unlocked.  Having a variety of barriers allows for more variety of descriptions, as well.  So if there's an impassable wall separating two rooms, the player won't get any sort of room description like "there is a bedroom to the north" because the player can't see it.

I've got some of the code for that completed, mostly in the Barrier class itself.  Now comes the implementation...