Search This Blog

Monday, February 26, 2018

7DRL: Turncoat Tomb --About those dungeons

2018 7DRL only DAYS AWAY.   I'm so excited I just can't hide it.

Since it is within the rules to use commercial or 3rd party graphics, build on pre-made game engines like the T engine, or even build on previous projects, I'm using some of the tech I developed when experimenting for my book Let's Make a RogueLike with Construct 2.

The dungeon is a grid of tiles that are 32x32.  I made several generic dungeon generators for the book in hopes of explaining different ways to do PCG levels. 

My first example of a "procedural level" was with a "pillar and wall" maze generator similar to how Berzerk mazes are made.  I explained this in my "Roguelike maze" tutorial on Scirra's site:

This is a very easy and super fast kinda maze algorithm.  It can give you labyrinthine hallways and sort of room like areas. If you want a pcg level in a hurry it's a good way to go.

This was meant to be short, easy to understand, and maybe help someone get started with really basic PCG in Construct 2.

At the time I was very naive and not as sophisticated in my approach to making pcg levels.

In the tutorial (and in subsequent ridiculously convoluted attempts) I made levels by placing wall and floor sprites on the layout, then checking for where these sprites are with "feeler" objects checking for collisions, then adjusting things accordingly.

There are a couple of big problems with this approach:

If you put a sprite down, say a wall, then check to see if there's a wall there, Construct will think there is no wall there.

 I didn't know it at the time, but Construct 2 waits until all the events are done and a tick happens and the screen is updated before the sprites you just created are really "there" for collision checks.   You can say "wait 0" and THAT EVENT ONLY will wait a tick so anything in THAT EVENT ONLY will then see your new floor or wall or whatever if its checking for collisions. 

Notice how I keep saying THAT EVENT ONLY in rage caps?  To take advantage of the tick that happens after a wait action, you have to have your checks in events that are in that same event tree further down.

Other events don't give a crap about your wait command and will go on their merry way like nothing happened... so in those events, your collision checks won't work.

This led me to make some ridiculous chains of "make a floor, wait, check for floor, do something if there is one, something else if there's not, make a wall or something, wait, check for walls and floor do something else make another floor wait again..."  It started to get really ugly because all these waits have to be in the same event.  God forbid I call a function or have a loop or something.

 The fact that wait works this way is actually really awesome.  It's a good way to have it set up for most situations, but it's no fun for trying to build a level.

Furthermore if you have a big level with hundreds of sprite tiles and you have to do a bunch of nested collision checks and stuff, things start to get really slow.  Building a  very simple"Rogue" sized level can take almost a minute which is hours in waiting to load time.  And that's without any game objects.

Also it tended to make redundant floors and walls over each other which happens when you're throwing stuff around random -willy-nilly. It required some clean-up which was more collision checks in nested waits or with timed triggers or something.

Digger method:

Intuitively I thought a good way to make levels was with what I later learned was called an "agent based" or "digger" method.  I have a little guy pop up rooms, turn a random cardinal direction, move a random amount (while making a hall) then pop up another room.  When our little room digger gets too close to an edge of the boundary, I have it turn back.

The idea was good, but the execution was a mess.

The solution is just to add an extra step and make your level in a two dimensional array, then once the array is done building, have the game draw the level with sprites.  No sprite collision checks needed.  All the thinkin' is done on the array.

1 build your level in an array
2 have a generic array-to-level draw routine.

This way no matter how you build your array, your "draw dungeon from array" routine should work the same.

Also it's fast as sh@$.

I returned to the tried and true method, similar to the one used in the original Rogue.

It uses a tic-tac-toe grid and in random squares of that grid it makes random rooms... then makes halls between them.  You end up with the same looking dungeons as the digger method, but there's more control.

It's easy to see what's going on here.  The problem is it's kinda boring.  The dungeons are similar and you just have rectangular rooms.  With the digger method you have more unpredictable shapes because the thing digs rooms out on top of other rooms.

So I just added a loop to make a number of random rooms on top of the initial random rooms.

With some tweaks in the parameters, I can easily set my dungeons to "Extra Chunky (tm)"   Extra chunky = extra fun!   All the control of the boring dungeon, but none of the boring.

This is how fast it can generate complex dungeons in real time.  (The top is slowed down a lot).

Mmmmm. Chunky.

The "chunky" ones look  like playable levels in a more modernerish game.  Yes "modernerish" is a word.  It is now.  You're welcome, colloquial English.

Instead of taking 30 seconds to make a level you can make the same level 10 times a second.  At least.  Turns out it's a LOT faster to check numbers in an array than it is to check sprite geometry collisions on a layout.

Also there's less clean up because one value in an array can't be 2 overlapping things (unless you want it to --which I'll explain below).

A bit about my generic level array:

If you want more than just one thing on a given square --for example maybe you want a floor and a door or a wall and  a torch sticking out of it...   you will need to have more than one value in the same "area" in your level.  To do this you might want a 3 dimensional array instead of just x and y so you can stack values in each spot.

This seems like over-kill since most squares in say a 200x200 or 40,000 square dungeon  will just have a wall, a floor or nothing. Every step in the third dimension is another 40,000 values of mostly thin air.   That's a whole lotta nothin' going on.

What I did was keep just a 2 dimensional array, but use bit values. Bit 1 is a floor or not, bit 2 is a wall or not, bit 3 is a door or not...and so on.  This gives me the freedom to have any combination of 8  different things with a single number from 0 to 255.

To be continued:

Sunday, February 11, 2018

7Day Roguelike 2018: Turncoat Tomb


If I'm going to write a book on how to make a roguelike using Construct 2, well then I should be able to make a Roguelike using Construct 2 in 7 days and succeed in the 7DRL challenge or else why would anyone want to read my book?

I have been heavily inspired by the game Golden Krone Hotel. One of the things that makes it fun is the idea of factions --Vampires vs Humans.

You can be attacked by a horde of vampires in the middle of bloody combat, then drink some vampire blood and suddenly they'll stop attacking you. Oh you're one of us! It's all good! No hard feelings! And they even talk to you saying things like:

"I killed a man once... Couldn't kill him twice!"

...but then humans will attack you because you're a vampire. I love that whole really simple factions angle and plan to really lean into it with my 7DRL.

What is glaringly missing in this is the fact that human and vampire npcs never attack each other! It's just you for some reason.

I figure NPC humans and vampires don't attack each other because of some pact... kind of like the Continental Hotel in John Wick movies.

Image result for john wick inside the continental hotel

This is where another one of my big influences comes in. A much older one:

CROSSROADS for the Commodore 64.

Now THESE enemies kill the hell out of each other! In fact the first minute of each round is mainly just staying out of the way until the enemies reach a sort of equilibrium leaving you to clean up what's left. The enemies are different colors and the different colors and types hate each other while others can get along. They all hate you, but sometimes it seems somewhat less.

You're not so much participant let alone instigator in the main battle, but more of a bystander trying to survive the harsh ecosystem among the combatants let loose in the maze.

This was a game released as pages and pages of hex data the would be player had to enter by hand into a commodore 64 from Compute magazine in the 1980s and it was absolutely genius.

Imagine if Robotron were in a maze and the robots all hated each other.

So my game will have factions based on color and the enemies will also fight each other like in Crossroads, but leave you alone if you were in their faction (by donning their color) like in Golden Krone Hotel.

There's something magical that happens when you see NPCs fighting each other. From the first time I saw a Berzerk Robot shoot another Robot in Berzerk, to the first time I played HALO and saw the Covenant in the distance fighting the Flood on the snow levels.

Here I am witnessing this battle in the distance that has nothing directly to do with me and I feel more immersed in the world than ever.

My first real encounter with factions outside a war strategy game was Mercenaries: Playground of Destruction.

This game has 4 factions that are always in varying states of hostility toward the player with one special faction, North Korea being always hostile.

This hostility varies based on what you do in the game and some missions, for example fighting Chinese soldiers on a mission from the Russian Mafia will increase how much China hates you, but also increase the friendliness of the Russian Mafia toward you. So you're always juggling the varying factions and their attitude toward you.

Another special faction is civilians, who don't hate anyone, but cost you money in fines if you accidentally harm them.

What seems to be missing, and I could be wrong about this is that the hostility of the factions toward each other is not variable in the same way.

They hate each other or not pretty much without your intervention.


In my RL I want to have basically 6 factions:

GREY: The human faction

RED: Monsters

BLUE: Monsters

YELLOW: Monsters

GREEN: Monsters

BLACK: (Shadow/Undead)

Each color will have a corresponding dictionary containing floating point numbers indicating how much they hate each other color.

Magic in TT is heavily geared toward manipulating monsters and their factions. From slightly influencing how they feel about some or other monster faction to switching their faction altogether, joining their faction yourself, or utterly dominating them.

Sunday, November 12, 2017

Golden Krone Hotel and my Zombie Ray Casting Construct 3 Template

Golden Krone Hotel and my Zombie Ray Casting Construct 3 Template

Playing Golden Krone Hotel and it's kicking my ass! 

Those FN Snakes!  It had to be snakes...  But because it's a Roguelike in the truest sense, it always feels like I could have just done something a little different --which keeps me coming back.  When playing on normal and not playing very well, it has addictive feel of pulling a slot machine lever.  Just. One. More. Try...

The soundtrack is immersive and the game just *feels good.  Solid.

I was turned on to it by RogueLike Radio episode 138.

They interview the creator Jeremiah Reid.

It's hard to believe this started out as a 7 day Roguelike.  It seems really big in its scope.   The idea of making a Roguelike that fast with any kind of complexity at all.. I find somewhat intimidating.  Ill have to check out what the 7 day RL was like....

I didn't have to wonder long, because the original 7drl release is still available right here:

...And it's not at all comfortingly incomplete.  It's a really complete and playable game with the light and dark vampire mechanics in place.  It's a fantastic for a 7drl. 

Anyhow it inspired me to get to work on SOMETHING, because I've been really non-productive game wise the past few weeks.

I'm still working on my Construct 3 RayCasting game template which I would like to release on the Scirra store.

I'm making a zombie shooter as a template with indoor and outdoor areas.   Just walls.  Very old school ray casting.   Pretty cool for a 2d engine though.  

Tuesday, September 26, 2017

Retro 3d fps in Construct 3

*Update... I'm now using actual ray casting for the walls, but still the 2d sprite frames for the other objects like trees and grave stones. 

I made a simple ra-casting style 3d fps "engine" using Construct 3 with no plugins just Construct 3 events and some clever use of sprite animations.

My son wanted to know if I could add 3d capability to a roguelike game for Construct.  I can easily with Construct 2 using the 3js plugins, however

1. Publishing a game to android is a pain for me in Construct 2 and it's a breeze in C3.  Easy peasy.
2.  It's very satisfying to make all the 3d on my own and it have it even work badly.  It works!  I didn't think it would even work.
3.  Threre's a cool really retro feel to it that you don't get with a modern engine.  Something is magical about tricking a 2d engine into doing 3d ish things.

The way it works is I make a block in Milkshape, export it to a direct x object then use a program called "SpriteMe"  which can be seen in action here:

and I make it spin 90 degrees and capture about 1 frame for every degree.  This makes a roughly 90 frame animation.   Then with a little math inside Construct 3, it picks the frame depending on the angle it is to the pov.

Combine that with scaling based on the distance from the POV and you have some playable, primitive looking pseudo 3d!

That takes care of blocks but what about things like bullet holes or rounded paintings or small windows?  For those I just make them thinner when you get more of an angle to them.  If you're facing straight on they're wide, if you're looking at them at an angle they get thinner.

After lots of trial and error math it works.


Thursday, July 13, 2017

Let's Make A Roguelike with Construct 2 is coming along

Let's Make A Roguelike with Construct 2 is coming along...

I'm on page around 145 now and I'm thinking about taking some things out. I ran into some dead ends, did some things over and some parts just don't fit anywhere. I may have an appendix for these similar to "bonus content" deleted scenes you get on DVDs.

For example I started out using a dictionary data structure to store the player's stuff. This became cumbersome, however since a key/value pair can only easily hold so much information. What if the item was worn out but another identical item wasn't?

Since Construct 2's dictionary object can save itself to a JSON string, I thought hey why not have a dictionary OF dictionaries? The value of a particular Item you have could itself be a dictionary of key value pairs like "name: SwordBlade, worn out ness : 30, cost : 25, damage : 10, etc:etc" for the item "longsword1" or something.

But that got too complicated too fast and in my opinion introduced unneeded clutter and created more problems than it solved. It's not good to give yourself too many options. The data structure might as well be called "can of worms."

Instead I came up with a way where all the needed values are stored in the "items" sprite and those sprite instances can be stored right there on the HUD. So literally the sprite you pick up is the item in your slot. It's not a sprite that represents the item you are carrying, it IS the item you are carrying.
That way items can be used, have charges, or ammo or whatever and those values are stored for that individual instance with no complicated middle man data structures.

Anyhow page 145 and I still haven't got to the procedural parts yet. First I'm making the game play with a manually generated dungeon. The game should not care how the dungeon is made whether you draw it in construct, use a cave algorithm or lego style grammar based methods.

And thus far it doesn't

Moving right along...

Tuesday, April 25, 2017

Roguelike Radio: Episode 105: Dungeon Hacks, a book about roguelike...

Roguelike Radio: Episode 105: Dungeon Hacks, a book about roguelike...: This is episode 105 of Roguelike Radio, where we discuss Dungeon Hacks , a book on the history of roguelikes by David Craddock .

Monday, April 24, 2017

Back to working on my book and still listening to RogueLike Radio

I just listened to the episode with David Craddock, author of "Dungeon H@cks:..."(see below) and really the one who inspired me to begin writing "Let's Make A RogueLike with Construct 2" in the first place.  That and "Stay A While..." are some of my favorite books on the subject.

Dungeon Hacks: How NetHack, Angband, and Other Roguelikes Changed the Course of Video Games by [Craddock, David L.]

Dungeon Hacks at Amazon

What really got me started was making this simple tutorial I called "RogueLike Random Maze Tutorial" which just showed Construct 2 users how to make a simple maze and do line of site lighting.

(And looks like I'm using the Stone Soup tiles )  Didn't know it at the time.

It's nothing even as fancy as the original Rogue dungeons, and was more about showing how to use groups and functions.

basic Rogue dungeon with rectangular rooms
I just got done with a modular implementation of the original Rogue "tic tac toe" grid dungeon formula that readers will be able to download and plug in to their own projects.

more varied rooms

odd room shapes and sizes. some inner architecture
By tweaking a few variables, the architecture can vary widely.  The rooms come with room order and it knows where to put doors so the dungeon comes with a built in mechanism for where to put locked doors or barriers.

It's addictive just to hit the space bar and watch a new dungeon pop up and imagine the kind of narrative adventure that is possible in that space and then how to make the program look at it and imagine that same thing.

This is just one of several methods I plan to fully explain:

  • Basic Rogue (with adjustable variation)
  • Room and Hall "agent based" digging method (This is how I first thought to do it with no background and it's still my favorite)
  • Pre-cooked room and corridor "lego" method.  This one you can hand-craft your rooms and lay them out procedurally.  I like this method too.
  • Berzerk Maze Method.  Makes for good labyrinth type areas.  Very fast and cheap.  You could easily have a fast bullet hell type RogueLite with the maze changing in real time with this one.
  • Cellular Automata cave (not my favorite in fact I'm only including it for completeness if I decide to at all)
  • Agent based cave carver method:  Is my favorite because there's no doubt you can get everywhere and you get nice caves.
  • ?? I plan to explore other cavey methods like using a fluid simulation style algorithm.
Also toying with another procedurally generated  "Regions" with the dungeon area to help determine themes and entities.

...and looks like I better give 'em a map.  Gotta have that map.

 But I'm only on the first one as a complete plug-in with nice comments and in any presentably modular and optimized form. And I may start that one over.

Making a book like this is a lot like trying to make a game, in a way this is both,so I have to cull my ideas early and often if I want to get something complete and together.  The readers should have the concepts they need to get started and should be able to use my modules and procedures and make a successful 7drl.

7 Day Rogue Like

That's a decent goal I think.

But I don't want to promise more than I can deliver.  Right now I think it would be a swell book if it were only a guide to a basic game with procedural dungeons, saving with permadeath, items, basic enemies and inventory and some method of attack / health... with only real time shooting mechanics or something.   We'll see where this goes.