Friday, November 21, 2014

Flash Game Mini-Review: Run 3

Run 3 is, as the title suggests, the third in a series of games called Run.  Run and Run 2 were decent little time-wasters, though Run 2 was a bit of a disappointment to me after enjoying the first.  So I didn't have my expectations particularly high when I tried out Run 3.

Fortunately, Run 3 is great.

Screenshot of Run 3
Use the lizard. Always use the lizard.
It takes what was great about the first Run and makes it better, while taking away the stuff that wasn't too good from Run 2 (or, at least, introducing those things more slowly, so they're easier to adjust to). Add to that a colossal amount of new (and awesome) features, along with continual updates, and you've got a game that lasts and lasts.

The Run series has you take control of a little alien guy running along a track in space.  All you have to do is avoid the potholes and make it to the end of the course.  You have your choice of two basic characters: the jumper, who goes a moderate speed but can clear some good-sized gaps, and the skater, who is faster but can't jump as high (so he's a bit more of the "expert mode").  In Run 3, you can unlock lots more characters with different abilities, including a child which lets you run over crumbling tiles without crumbling them, and a pastafarian who can cross empty spaces for a limited time.

Explore Mode has you moving through carefully designed levels, with the goal of trying to make it to the proper end of a branching maze of tracks.  New tracks get added slowly, so even after you've completed all there is to complete, you can come back in a month and see what's new.  Just recently a level pack called "Low Power Tunnels" came out, which has tiles that fade to black against a starry background, making them hard to see and harder to land on.

Infinite Mode is more about getting a high score--that is, getting as far as possible.  As you go, the pattern of the levels changes to become more challenging, so just when you think you're a master at it, you get something new.

On top of that, users can create and share levels, so there's always more and more to do.

Friday, November 14, 2014

Flash Game Mini-Review: no-one has to die.

"no-one has to die." is a short puzzle game where you have to save four characters from a building that's on fire.  You direct their actions and have control over fire doors to keep them from getting killed.

Well, okay, it seems someone sure has to die...
However, the plot is where things get tricky.  It's a bit convoluted, but quite interesting.  It's difficult to mention anything about this game without spoilers.  The spoiler-free version is this: the corporation that owns the building is up to some very shady business, and nothing is as it seems.  You, a delivery man, find yourself in a guard room with two dead guards, and you can communicate with the characters through instant messaging.  The questions are numerous:  Who lit the fire? Who killed the security guards?  What does the corporation do?  Why so many cockatiels?!

But most importantly: who are you going to save?

In each level, you are forced to sacrifice one character so the others can move on.  Who you choose to let die not only changes the plot, but also changes how the next level is played, because the characters that survived will be in different positions.  In this way, any given level after the first, while technically having the same layout, can be made into different puzzles.

The puzzles are pretty easy, so don't worry about too much brain-bending; the game is much more about solving the mystery.  The story is anything but linear, and I think the game did a great job mixing the gameplay and the plot, in both a literal and an abstract-design sense.

It definitely gives a new meaning to "replayability"...

Friday, November 7, 2014

DOOM: The Mine #2

More detail in The Mine:


This is the previous space from the first post, with more detail.  Now it has been shrunk a little bit, there's more obstacles/decoration, and the bump in the floor gives it a feeling of a new room even though there's no door.


This is the center so far.  The player comes in from the green marble area at the top, and the screenshots I've shown are of the very center.  Those smaller rooms on the sides house demons or barons, depending on the difficulty.



This is one of those side rooms.  Again, to keep it from being too much red brick, I cut the wall to have the stripe around the center.  It's still a bit pink, but pink is okay I think, as long as it's a little bit of variety from the red brick.  The pink intestines-looking bit right under the gun is similar to the bump in the way to the center area, just pink instead of beige.  I decided to make them different so when you're circling the middle, the beige one catches your eye, so you head that way to escape, while these pink recesses are more to be unnoticed and you freak out when you hear the monster shriek.

For instance:


The part on the left is the exit (the first screenshot above), while the part on the right is a niche with a baron in it.  I'm thinking of making this level more of a run-away-type than a real shooter; ammo will probably be scarce the deeper you go, so you might not be prepared for a baron (or three), and you'll want to get to the exit quickly.

Friday, October 31, 2014

Latchkey #61 - Recoding the Take Command, Parser

Figured out the crash with commands that are nothing but verbs.  At an early point in parsing, I splice out the verb, which means the rest of the input might be null, but I don't check for that.  I just removed the splices for now.  Thought it would be more efficient, I guess, but not really a big deal for now.

So in other news, it appears that the move and look commands work in a vaguely alpha way, if not a grammatically correct way.  So that's good.

Taking items works again now, too.  Some weird little bugs, but I've fixed the crashes that came up.  But now, although you can take the item, the item still stays in the room too, and I can't remove the duplicate. Eek.  It's basically because during the initial parsing, I don't differentiate between items in the player's hand and items in the room.

So now I'm in the middle of fixing that mess.  Which also means I'm rewriting the code for figuring out which item the player is talking about when they use adjectives.  I'm perhaps halfway through that, but it gets tricky.  The old code for it was quite sloppy, and wasn't perfect by any means, so I've got to get it a bit better before going further.

Tasks within tasks.

Friday, October 24, 2014

DOOM: The Mine #1

To get back into the swing of things with DOOM (and hopefully getting back into Sacrifice), I'm making a quick one-off level to warm me up.

The purpose of this level isn't so much to be great design, or intricate, or anything, but mostly to work on my decorating skills.  I often find that my levels tend to look bland, either by being big open spaces or tight little corridors, with the same texture often repeated.  So for this level, I'll be trying to split things up into sections, and adding as much fine detail as I can.  We'll see if I go overboard.

But level design-wise, the idea for "The Mine" is to work in concentric circles.  The inner most circle will be the end, but since measuring things all out perfectly beforehand is impossible, and I probably wouldn't give myself enough room in the middle if I started from the outside, I'm instead starting at the end, and working my way out to the beginning.

Visually, the start of the level will be outdoors, with a cylindrical building in the middle.  The building will start with a sci-fi (or at least building-ish) theme, then go into a more natural rock formation, since the building was created over a mine.  Going deep enough into the mine, in turns itself into the green marble motif, and finally into a red hellish motif, ending with one final hole to jump into. The whole level will drop in elevation as you go.


This is the first try at some detail.  It's very, very red.  Probably far too red, which is why I tried to provide some variety with the candelabras.  But more importantly, I'm trying some things with the ceiling, which is something I often forget about.  I'll be trying a lot of funky things with the ceiling as I go.

I wanted the level to be a lot darker, at least this portion of it, but things seem to go gray over distance when the lights are low.  Perhaps I'll lower the brightness later, but for now, it's at the default.  There is a smidge of brightness-changing here, with the center hole being brighter than the rest to draw you in, but it may be too subtle, so lowering the ambient light will help.

Perhaps I'll also figure out how to break up the floor, so it doesn't seem so bland.

But that's what this level is all about, so I'll continue with lots of little tweaks and details as I go.

Part 2...

Friday, October 17, 2014

Latchkey #60 - Recoding Examine and Move Commands

The good thing about pausing on programming and coming back to it is that problems are easier than you feared.  The bad thing is that you forget how much you already coded and write lots of extra code before seeing that you've already written it once.

I fixed up the Examine command a bunch so it's a bit cleaner and appropriately displays barriers when you ask.  Though, at the moment, it basically reiterates what you already know in the directional box, because adjectives haven't been properly implemented.

Next I started to work on movement, to get that fixed.  Since the common way to move would be to say "move [direction]", I had to go back into the parsing function to peel out directions separately from anything else (I thought I'd have to, but forgot about it).  This gave the added bonus with the examine code, so now the player, when examining a barrier, they don't have to say "look at door", but can just say "look north" and get a description of the barrier in that direction.  Oddly, you can't say "look up" or "look down", but must say "look above" or "look below" instead.  Right now if you say "look up" it lists all the items in the room, which is more or less the error message saying "I know you're looking at something, I just don't know what."  I'll add that to my bug list.  Too annoying just now to fix.

Bigger bug that needs fixing: just typing the work "look" without anything you want to look at causes a crash.  Oops.

In any case, movement now works again (except for the same error with the examine command: you must say "above" and "below" instead of "up" and "down")... and the crash.  Seems to be if you just type a verb and nothing else, you get a crash.  Don't know why yet.  So that'll be fun.

The code is getting big and ugly.

Part 61: More recoding...

Friday, October 10, 2014

What's New, Pussycat?

This week has been tiring.  Mostly I think it's flu season coming on, so I expect this is the beginning of something worse next week.  If I can't post something real next week, I'll at least post a little status update like this.  But I've put a little work into Latchkey, just not enough to post about this week.  So perhaps next week there will be something there.

What I've really been itching to do recently is make a some Doom levels.  I've been considering picking "Sacrifice" back up and reworking the first level, or finishing the second, but to get back into gear for it I may want to make an unrelated one-shot level.  Though I'd take my time on it, rather than push full-steam ahead like I did with the Monthathon.

While I'm working on Latchkey and Doom, FissureVerse will be put on the backburner, so I can catch up on getting permission for the art, or finding new art altogether.  Some artists I've contacted have given me permission, and I've put links to their pages on the side menu.  Though if that gets too unwieldy, I'll move it into the main FissureVerse page.  Other artists have requested I remove their work, others haven't yet responded, and still others I haven't yet found their contact info.  So it's a bit of a clustermug right now.  Once all that's cleared up, things should go smoother.