Saturday, March 11, 2017

"Arkham After Midnight" is now playable



Arkham After Midnight
 is now playable!

It doesn't have nearly the scope and diversity of plot elements I was hoping for, but it certainly serves as a strong tech demo for what I was thinking of.  If the game gains a lot of traction, I can fairly easily extend it with new content so that new mysteries can be generated (although I have since had some better ideas as to how to structure mysteries, so once the time pressure is done, I'd like to revisit the mystery creation process).

I'd also like to add in support for fan-created ploxels.  Since Lua has a way of building in sandboxed support for loading scripted content, it seems like this would be the perfect sort of game to support it. Fans could make their own "ploxels" and submit them to a central archive, and then you could download them, drop them into your "mysteries" folder, and get whole new adventures generated for you.

But for now, head on over to itch.io and check it out.  It's short and sweet, but hopefully you will enjoy it!

Thursday, March 9, 2017

Mid-week progress on "Arkham After Midnight"

Sadly, I haven't gotten as much done on Arkham After Midnight as I was hoping.  Despite taking several days off of work, I still have found myself with precious little time thanks to other pressures.  But it hasn't stopped me completely - I am making progress!

Here are some screenies:

  

Part of what ate up my time was having to go back to the drawing board a few times on the "ploxel" engine that undergirds the mystery generation.  I think I have a pretty workable, modular system now, but it took some doing to get it right.

It's taking me longer to create content than I had hoped, as well.  The sprite sheets are going quickly, and I think they look good, but the coding that goes behind them gets a little complicated to allow them to "play nice" with the generator.  For instance, I can't just create a gate to R'Lyeh that is opened with the opening ritual at the Standing Stones, because I want it so that as I add more ploxels, the gate can go to a different realm, the ritual comes from other places, and the location you open the gate can change.  Which means absolutely everything has a layer of abstraction on it that makes it a little hard to wrap your head around sometimes.

But it's working!  And it's powerful.  I can do things like spawn entire set pieces into maps.  For instance, I can have a ploxel add a whole ship to the harbor location, complete with bad guys, loot drops, etc., embedded in the sub-map in the same way I draw regular maps.

The main problem is that content is taking a long time to craft.  I think I'll have a playable mystery for the end of the seven days, but the mysteries it generates will be pretty uniform.  But with the modular setup, I should be able to flesh out the system with many more ploxels in the weeks following the 7DRL.  Like Lone Spelunker, I think I have a pretty good game on my hands that is passable as a 7DRL, but will really shine if I put some more work into it post-compo.  We'll see what the response is like - if people seem to be enjoying it and see its potential, then I will probably flesh it out more.






Monday, March 6, 2017

Monday Progress on "Arkham After Midnight"

Wow did I get a lot done today.

The ploxel engine is spitting out vignettes that actually hook up to each other.  For instance, I have an old shack in the woods where you can find mundane items, and an old tomb where you can find arcane items.  When I add mundane and arcane items into the mix, they show up appropriately in those locations.  There's a "thread" of a mystery going from scene to scene, and it's all working pretty well.

The down side is that it's a lot more complicated to make these pieces modular and yet sensical.  Things that would be straightforward if I didn't want the mystery to be procedurally generated get a little complicated, which gets in the way of producing the ploxels quickly, but I was still able to generate several ploxels tonight and the sprites to go with them in fairly short order, so I'm pretty happy.

Here's what the game looks like currently:






On the docket for tomorrow:

  • Add in hand-to-hand combat support.  Currently, there's only ranged combat.
  • Add in a character creation screen.  I've got several investigator sprites already made, but I need a way to let the player choose one.  I also want to give the player a little agency on what they start out with, although I have yet to come up with some good differentiators because there's not a lot of mechanical depth to the gameplay yet.  So far, about all I could do is adjust a balance of first aid resources to bullets to gun accuracy to gun damage.
  • More ploxels!  More sprites!  More enemies!
  • Figure out how I'm going to handle "finale" encounters.  I doubt I'll get to the implementation phase tomorrow, but it would be good to get some planning in for that.
But now, it's time for a break.

Sunday, March 5, 2017

Ploxel engine working

After some debugging difficulties, I think I have a workable ploxel engine constructed.  It currently has three ploxels, one with only a plug, one with only a socket, and one with a plug and a socket that match the sockets and plugs of the other two.

The engine successfully finds and connects them into a chain.  For instance, if I start with these three ploxels in the "open" list:

{
id = "Cthulhu",
name = "Cthulhu",
ilk = "enemy",
description = "Cthulhu lies dreaming, and must be defeated.",
describe = function(self)
 print( "Connection = " .. self.plugs[1].connection )
 return self.description .. "  He sleeps in " ..
  mystery:ploxel( self.plugs[1].connection ):describe()
end,
plugs = { "lair" }
}

{
id = "R'Lyeh",
name = "R'Lyeh",
ilk = "middle",
description = "the sunken city of R'Lyeh",
describe = function(self)
 return self.description .. ", which can only be reached by means of " ..
  mystery:ploxel( self.plugs[1].connection ):describe()
end,
plugs = { "gate" },
sockets = { "lair" }
}

{
id = "Passage",
name = "Passage",
ilk = "trivial",
map = "maps/manor.lua",
description = "a passage to another world",
describe = function(self)
 return self.description .. ""
end,
plugs = {},
sockets = { "gate" }
}

Then, when the mystery is generated and describe() called on the topmost enemy ploxel, it will spit out Cthulhu lies dreaming, and must be defeated.  He sleeps in the sunken city of R'Lyeh, which can only be reached by means of a passage to another world.

So the engine is successfully starting with a "big bad" and connecting ploxels to it to flesh out the mystery, based on the character of plugs and sockets.  A "plug" is an "aspect of this thing that I will need to generate something for."  A "socket" is an "aspect of this thing that can fulfill a requirement for another ploxel".  In the above example, Cthulhu has a "lair" plug, because it needs to find a "lair" socket on some other ploxel to connect to.  R'Lyeh has a lair socket, because it can act as a lair to a big bad.  Thus, they can be connected, giving Cthulhu a lair.  But the lair itself has requirements of its own; a gate to that mysterious location is needed, so a gate plug is created for it.  Eventually, the plug finds the matching socket in the passage, and the gate to R'Lyeh is established.

It took a bit of doing to allow the ploxels to "play nice" with things like functions in the ploxel objects.  I wanted to be able to serialize the mystery structure without having to save all the ploxel data in the save file (especially difficult-to-serialize things like functions).

My goal for tomorrow is to get maps generating in a way that is informed by the ploxel representing the map in the mystery.

Saturday, March 4, 2017

Getting started on "Arkham After Midnight"

So I am starting work on the game.  Thanks in large part to the Löve port of rot.js, I have an engine up and running where you can load up a map (built in Tiled) and walk around in it.  Here's what it looks like currently:


It has line of sight working, movement blocking working, but there are no enemies or moving between levels or anything like that working yet.

That car is like the stairs in most roguelike levels - you go there to leave the level and go to the next place.

Eventually, the maps will be "procedurally assembled" - as opposed to procedurally generated - from a series of pre-made "geomorphs", which will be pieced together using a procedurally generated mystery as a guide.  (That's the plan, anyway!)  For instance, the "woodland clearing" map will be the same in every game, but whether it shows up will depend on the mystery it generates, and it will have spaces where interesting things that further the mystery can be placed, such as unmarked graves, mysterious stone altars, sites of ritual murders, etc.  The maps themselves are not procedurally generated, but how they are assembled will be, in service to the higher-level mystery.

Having learned the hard way that you should always start with your games being able to be saved and loaded, I am starting out with saving and loading in mind.  So one of the first things I have written is a save and load screen.  My goal is to keep save/load parity with all game features continuously throughout the project.

The tileset is inspired in large part by the old Ultima games, which used a heavy black palette.  I've always liked the look, and I thought the unusually large amount of black pixels would lend itself to the feel of a horror based game, so I ran with it.  I'm pretty happy with it so far.



Friday, March 3, 2017

7DRL 2017: Arkham After Midnight

I just officially threw my hat in the ring for the 2017 Seven-Day Roguelike Challenge.

My goal is to make a Lovecraft-themed roguelike that procedurally generates the investigation threads, rather than simply making "levels" with monsters to kill.  We shall see how it goes!

One of the nice things about this theme is that I have quite a bit of original art lying around from previous projects and other activity.  For instance, here is an image I drew in the DrawQuest iPad app a few years ago, which will make a perfect splash screen for the game:


I've got several other images available from when I was working on Arkham Investigations (a fan-made board game expansion for Arkham Horror), and since I've programmed several roguelikes before, I've got plenty of boilerplate code lying around to accelerate development, too.  If all goes well, I'll have a fun new roguelike to show at the end of next week!

Sunday, March 6, 2016

Hacking ICE in the world of "No Crypto For Old Men"

It's the end of day two of the Seven-Day Roguelike competition, and No Crypto for Old Men is coming along really nicely.

Today, I really focused on getting some interesting things to do into the game while fighting the "Intrusion Countermeasures Electronics", or ICE.  Basically, this is the combat system of the game, but instead of fighting monsters with your sword, you are fighting security programs with terminal commands.

My goal with this combat system was to help the player feel like a clever hacker, just like in the movies, where they pop into a network, type some esoteric commands into a console, and watch the expensive and high-tech servers fall like dominoes.  And make it all look really easy when it's done.

To that end, you have a pretty limited number of things you can type in the console, and the gameplay revolves around figuring out when to type what.  There's an onboard wiki and help system that should (hopefully) make this a fairly simple task, but it will require some reading and poking and experimenting to get it right.

Once you understand the handful of commands, it's just a matter of sussing what you need to do to circumvent the ICE.  For this part of the game, I took a lot of inspiration from the excellent co-op game Keep Talking and Nobody Explodes.  It's an easy game where you have to defuse a fictional bomb by looking up esoteric instructions in a bomb defusal manual.  The challenge comes from executing the complicated instructions under a time pressure, but what was interesting to me was how well it conveyed that sense of doing something important and "smart" just by following instructions.  Even though you were just doing what the manual said, the game succeeded in making you feel like a bomb squad expert during play – especially when you defuse the bomb!

So I'm taking that idea and running with it in a new direction here.  The conceit of the game is that a newly-elected President Trump has demanded that all data is available to the FBI (this policy position, sadly, appears to be the only part of my game that is not science fiction).  All ICE is now hackable by definition; every security system must, by law, have a back door.  And as anyone in IT knows, that's the kind of genie that won't stay in a bottle.  Within days of the policy decision, there is a "Hacker's Wiki" that details all known back doors, and it is usable to quickly defeat the encryption on bank transactions, personal communications, surveillance systems, etc.

The player can thus look up any (well, most) ICE they encounter in the Wiki and find instructions on how to defeat it.  In essence, you get the instructions for the puzzle.  Then, you merely need to execute the actions to solve the puzzle.

To achieve this, I've got a pretty robust ICE description system in place in the code.  Each block of ICE has a cadre and a release that can be used to learn about the general class of ICE and the specific instance in the wiki.  And it has a modular description system to describe when it should fail.  I've created several of these modular pieces so far, and they can be mixed and matched to create any number of back door types.

For instance, some of the weakest ICE is susceptible to the Hammer command, which creates a bunch of workers that attack the ICE with buffer overflows.  Each block of ICE has a publicly-viewable registry of icons (either "+" or "-") that would normally seem to be meaningless, but if you count the number of "+" signs, you'll know how many Hammer workers you should attack the ICE with to get it to shut down.  Thus, one of the modular pieces is a note that the ICE shuts down if it has as many Hammer workers as it has plusses in its registry.  Another would shut down the ICE if it has as many Hammer workers as it has minuses.

ICE from the same cadre will tend to have similar solutions, so that as you play, you should pick up on which ICE blocks behave in which way, and not need to reference the wiki, which will make you feel like even MORE of a hacker.  "Oh, this is the Nakatomi series.  I can take that down with just a few buffer overrun attacks.  Shouldn't be more than a moment...there!"

Another modular rule looks at the Drain workers attached to this ICE, which attack certain channels of the registry.  Instead of a simple count, Drain workers toggle the channels in the registry on and off, and the goal is to turn all the registry items to the same symbol.

A third modular rule might be to just allow access when you type the correct username and password.

In addition, these modular rules can be made sequential, so that you might need to do several of these steps in a row, or parallel, so that if you fulfill any of them, the ICE falls.  These can even be nested, so that you can do sequences of parallel tests.

Using these modular pieces, I should be able to make any number of interesting tests and puzzles for the "hacker" to attack.  I've already got a library of eight fairly robust ICE blocks, and more will be easy to create.

Hopefully, this will end up being a really unique, interesting, and engaging departure from traditional roguelike combat while still capturing that roguelike feel.  In many ways, it has parallels to the higher-level experiences in popular roguelikes, where you need to cleverly use your potions, your armor, your scrolls, etc., to navigate the death labyrinths, so I think it's a pretty solid direction.