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.

http://www.roguelikeradio.com/2017/08/episode-138-golden-krone-hotel.html

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:

http://humbit.com/gkh/gkh-v1.0/index.html

...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.  

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:

https://www.youtube.com/watch?v=yC05ACgSbtA

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.

...

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...

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 .

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 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.

https://www.scirra.com/tutorials/4831/rogue-like-random-maze-tutorial-pt-1

(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.

RogueLike Radio changed my mind about something in my "Let's Make a Roguelike" book!

Roguelike Radio Changed My Mind (and I'm only on the first year)

Still working on my how-to book, Let's Make a Roguelike with Construct 2

Here's an excerpt from my initial draft

...And here's a link to the Roguelike Radio podcast.

http://www.roguelikeradio.com/p/about.html

Apart from consuming everything I can about modern game design and programming patterns, particularly procedural generation, I wanted to uncover more of the mystery about what makes something a good Roguelike and gives players that "Roguelike" feeling.

So I decided to listen to EVERY episode of Roguelike Radio.

I have been immersed in books on game design, level design and the history of video games as well as every GDC or PAX talk on anything to do with Roguelikes I can find... and my favorite resource so far is the Roguelike Radio podcast.

I'm only on episode 18 now and just catching up with 2012.  The podcast is fantastic and even after the first season I'm beginning to unravel the mystery.

The podcast generally 2 or 3 talkers, Darren Grey, Andrew Doull, John Harris, with a special guest developers like Daniel Jacobsen, Nicholas Vining and David Baumgart of Dungeons of Dredmore, or Edmund McMillen of The Binding of Isaac.  They've even had the original creators of Rogue,  Michael Toy and Glenn Wichman.

So far I've learned a few things that make a Roguelike.  The speakers, generally aren't sticklers for turn based play or ascii graphics, but they definitely have things they like and don't like generally.

I know it when I see it

When defining what makes something Roguelike I am reminded of the phrase famously used in 1964 by United States Supreme Court Justice Potter Stewart to describe his threshold test for obscenity:

"I shall not today attempt further to define the kinds of material I understand to be embraced within that shorthand description ["hard-core pornography"], and perhaps I could never succeed in intelligibly doing so. But I know it when I see it..."

But one thing that comes up over and over is the idea that items and weapons should be there to change the way the game is played.  Not and I quote "Trading a plus 2 sword for a plus 3 sword."  This indicates a kind of linear player progression that doesn't really change the gameplay or add real variety.

Same S#$%, Different Numbers

I think it's something I noticed in other RPGs that made me bored and want to quit playing.  I call it the "Same s#$% more hitpoints" effect.

When I played Secret of Mana, a beautiful ambitious RPG for the SNES, after getting higher levels, I realized I was just attacking the same exact things but they just had more hit points and did more damage and I did more damage and had more hit points.  It was basically the same exact thing as the first dungeon, only the decimal point had moved.  Even the higher level spells didn't really change the game much.   They were like the low level spells but did more damage, or healed more... again same stuff different numbers.***

In RPG maker there's even a graph for this progression.

What's the point?  The above graph really soured CRPGs in general for me.  As Ed McMillen said in their interview, "There hast to always be a mystery."

*** This is given a strong caveat that Secret of Mana was in most every way a wonderful game and I got a lot of enjoyment out of it.  As far as SNES expansive for the time RPGs go it's pretty amazing, and was rated exactly that by IGN:  HERE 

So it's not so much THAT game, it's what I believe to be a flaw in the kind of game it is.  The potential for repetitive progression in RPGs in general... and I have run into that same problem in a wide range of games from The Bard's Tale for the Commodore 64 to Borderlands on Xbox 360.

I think there's a point in most any RPG including Dungeons & Dragons when the monsters just seem like numbers and it loses its fun.  Maintaining this fun and mystery is what a good Roguelike can do.
In a random review of Borderlands 2 I found, one blogger said it:

"Fiddlefarting over whether to sell Gun A that does X damage and has Y% of this effect or Gun B which does  X+1 damage but doesn’t have that effect but another is not role-playing...  ...the development curve and sense of progression in the game remains completely screwed up- it’s too long, drawn out, and rewards perseverance and grinding rather than good play and player skill-building. " --Michael Barnes'  blog

This is very close to the same things the Roguelike Radio podcast said in their Diablo episode.  "...If I fail it's because I didn't grind enough." (paraphrasing from memory).

So now that we've identified the problem, what is the solution?

I'm going to have to listen longer to find that answer, but one part of it seems to be having the player not just progress, but change.  In The Binding of Isaac, getting different weapons changes how the player looks and plays dramatically.  It's far beyond adding another +1 to your sword.  Different resources should add variety not just progression.  In a Roguelike, some form of resource management is a major part of the game, and how it is executed is as important if not more so than procedural generation.

So here is my new "big three" list.  Because it's important to have things in arbitrary 3 item lists.  

1. Procedural Generation
2. Permadeath
3. Player Progression  Resource Management

After one season of Roguelike Radio, I have changed my mind about my 3 most fundamental properties of a Roguelike.  Originally I thought that it was 1. Procedural Generation.   (still cool with that one) 2. Permadeath.  (It's important)  3.  Player progression.

But player progression isn't the best way of saying the "roguelike element" I'm trying to describe.

They described a better and I think more essential to the Roguelike experience game mechanic, and dedicated an entire episode to it:

Resource management.

First free clipart I found when I did an image search for "Resource Management."

The combination of things you collect and use should shape how the game plays out as much or more than the random layout of the dungeons or distribution of the monsters.

So I'm changing it to Resource Management, and I have much more to say about it, and I will improve the inventory and skill management parts of the book and sample program.

Yay research.  Only 4 more years of podcasts to go.

As far as the book is going I'm working on several generic dungeon making algorithms:  Traditional "Rogue" rooms and hallways,  Cellular Automata Caves, Agent based level carving, pre-made rooms in bitwise patterns... and more.


...back to work.

Roguelike Radio: Episode 133: How to Make a Traditional 7DRL

Roguelike Radio: Episode 133: How to Make a Traditional 7DRL: This is episode 133 of Roguelike Radio, where Darren Grey  and Jeff Lait  talk about how to make a traditional Seven Day Roguelike

Wait Waits For No One (A few words about Construct 2 System Action wait)

Wait Waits For No One

(A few words about Construct 2 System Action wait)

If you have a System action “wait” set to wait for 3 seconds, it does not make the game wait for 3 seconds.  It only makes that event wait for 3 seconds.  In fact, it only makes that particular instance of that event wait for 3 seconds.  The rest of the game and its events go on their merry way as if nothing happened.  

In other words if you have an event with a set of actions like:
If condition is true:  

1. do action a
2. do action b
3. do action c
4. wait 2 seconds
5. do action d
6. do action e

It does actions a, b, and c immediately, then puts actions d and e on the shelf for 2 seconds while it keeps running the rest of the events and behaviors in the game.   The game might go on for many ticks before it picks up actions d and e.  Nothing else waits except those two actions in that one event.

In fact it will go on repeating that same event every tick for every object that can be checked for that condition.   For example you could open another door while the first one is closing and it will work just fine with one event thanks to the wait action.  One wait doesn’t care what the rest of the program is doing or even other instances of itself.

This is handy for something like a door or monster that might have a timed series of actions.. But only for that particular monster or door.  Technically for the group of objects that meet the criteria set up in the event’s condition.

But  use wait with caution.  It can cause some problems as your code gets more complex.

Say you want your boss monster to do a shimmy - shake dance.  You might have an event that looks like:

1. Shimmy
2. Wait for 1 second
3. Shake
4. Wait for 1 second
5. Shimmy again, Shoot some bullets...
6. Wait for 1 second
7. Shoot a giant missle at you.

You will expect when this series of actions is called, your monster will, after a shimmy, wait, shake, wait, shimmy again wait, fire a giant missle at you.  Once the action is called, the monster will fire a missle at you after 3 seconds.

There’s one problem.  

Once that action is called, the monster WILL fire a missile at you in 3 seconds.  What if one second later, you kill the monster and it should be lying down dead?  That action is still “sitting on a shelf” from 2 seconds ago, waiting to perform it’s “shimmy again, shoot some bullets...” action and then fire a missle at you, has no way of knowing it’s supposed to be lying down because of some other unrelated events somewhere.   

It will fire the missile anyhow.

Wait creates an asynchronous action.  In computer science, this is related to the concept of a “promise.”   

A promise is different from a condition in that a condition says “If A is true…then I’ll do B”  while a promise says “when A is true, then I’ll do B.”  (If then) is checking if A is true right now, and if so it will do B right now.   A promise says as soon as A is true then I’ll do B.  

When you have a promise set up to happen later, There’s really no way to make it not happen without putting some kind of “unless” clause in the promised action.  Like so:

1 shimmy

2 wait for 2 seconds

3 if not dead
4 shake. Fire some bullets.
5 wait for 2 seconds

6 if not dead

` 7 shoot a giant missile at you

Every time you have a wait, you need to have a condition to make sure it’s still appropriate to perform that action.

So somewhere in that promise you better think of an “unless” if you can think of any times you don’t want B happening.

Wait can be a powerful tool, but it can create unexpected behaviors that are hard to debug. And if you try to do wait in a loop, forget about it. You probably don't want to do that. Instead use wait for signal and consider why you are trying to wait within a loop. There's another even bigger problem:
Since nobody but the actions in the particular call of that event following the wait are going to wait, that same event is going to be called again EVERY TICK. So you need another big "Unless" in there to make sure the monster isn't ALREADY doing this. I like to use a variable called "state" and give it easy to read values like so:

If monster state is not "ShimmyShaking" (and whatever) 1. set monster state to "ShimmyShaking" 2 shimmy

3 wait for 2 seconds

4 if not dead
5 shake. Fire some bullets.
6 wait for 2 seconds

7 if not dead

` 8 shoot a giant missile at you 9 set monster state to "DoingSomethingElse"

In fact those "if not dead" checks can probably also be checks for the "ShimmyShaking" state since if the monster were dead it's state would probably be something like "dead." Using the System.wait action is explained in depth in the manual section by that name on the Scirra website: https://www.scirra.com/tutorials/56/how-to-use-the-system-wait-action

Obama Vs Devil Chickens v 1.1

OK Took a break from Let's Make a RogueLike to finish a game I started a couple of years ago called Obama vs Devil Chickens.

Basically I saw that iconic Obama skeet shooting picture, and thought Hey why don't I make a game out of that!   I opened up Spriter, used lots of images and added a bunch of weapons and power ups and stuff and came up with Obama Vs Devil Chickens.

I released it on Obama's last day in office, and now after some feedback I've updated it adding a pause / continue option that saves your game position so when you can start where you left off, even if you close the browser.  I also fixed a couple of bugs and added AutoLoader and clip increases from Joe Biden if you activate him.

Controls are simple just point and shoot.  Hit an ammo box to reload unless you have auto loader, and shoot coins and chickens.  Shooting coins increases a red line on top that allows you to get better weapons and activate Joe Biden.

Anyhow Enjoy.  (click link below to play)

uberdroidgames.com/obama-vs-devil-chickens

Let's Make a Roguelike!

Get The Human now available for Windows at uberdroidgames.com

Let's Make a Roguelike / With Construct 2

If you look at my post in September entitled, Bob's Discount Dungeon, I was working on a Roguelike game with procedurally generated dungeons.  I have since become obsessed with procedural generation and "the making of" Roguelike games, so much so that I made a simple tutorial about how to make a random maze with a guy walking around in it with a line-of-sight shroud and everything. It was linked to in RogueLike News.

https://www.scirra.com/tutorials/4831/rogue-like-random-maze-tutorial-pt-1

Making a Roguelike is, among other things, an exercise in procedural generation.  You're making something that MAKES things.  So I took it one step further than that.   I'm making a book that tells people how to make something that makes things.    I'm on about page 80 now well into my first step by step walkthrough.



Here's part of the introduction:

Then I go on to tell what those are:

1. Random level generation.
2. Permadeath.
3. RPG character advancement. Resource Management (see my later blog post)

To me it boils down to simply go to Steam, or itch.io, and type "Roguelike" in the search engine, then observe what the results tend to have in common. It's those 3 things.

Anyhow back to work...