Building a puzzle starting from a pretty basic dig idea (Ludum Dare 48)

( I wrote this for the Ludum Dare page, then I realized I should probably post it here too. Here's the original post)

It was my first ranked Game Jam

It's been a year, I am starting to be more serious with my game designer goals so this time and a special LD # 48 seemed like a great opportunity.

Designers have various priorities with their games. In my case my top concern lately is the mechanics. My goal is to make enjoyable, interesting puzzles and I think that at the center of it is, or should be an interesting set of mechanics. Once you have the interesting mechanics, even building the levels is pretty fun to do.

Had to deal with the theme

On Friday the theme was announced: "Deeper and Deeper" . This was, in fact, one of my least favorite themes from the voting :/ Mostly because all it makes me think of is digging. And when I think digging, the first mental image I get is digging Super Mario Bros 2 - style:

I tried and I tried and this is where I kept defaulting towards. Maybe we can add rocks? Then it would be something like platforming sokoban. Except that this has been done quite a bit. It was getting late so I started coding.

Using puzzlescript

I am not good at making game graphics or sound or music. I know some code, but not video game code... I do have access to a secret weapon: puzzlescript. With Puzzlescript it's completely possible to make a game , including sprites and audio all from its editor and without having to be very good at either of them. It's puzzlescript, everything is 5x5, so your sprites don't need that much detail.

Most importantly, it helps me implement new mechanics quickly and play with them using the editor.  Figure out if they work out...

Finding the interesting thing

How about, instead of just moving the rocks , you are throwing them? And they roll. This is when I've decided to post my first preview image.

But the main mechanic is supposed to be digging. It sounds weird that digging doesn't do much, then?  What I was missing was a way to have chain reactions. That's where this idea came from, what if, after digging some earth, adjacent earth would fall down?



That's what's cool about puzzle script, you can prototype these things quickly and see how they fare when you are trying to design levels from them. I was able to notice that something still lacked. Digging is destructive. I even added a mechanic that makes rocks destroy earth when they hit it. It was so destructive that levels had a tendency to go to one direction and there was never a need for backtracking.

Added a paint of coat

But time was moving on so I also had to make the game look and feel better. My goal in the second day was to focus on that sort of stuff and make levels. Even though I wasn't really completely happy with the mechanics, still missing something...

Puzzlescript only lets you have 5x5 sprites. But there are ways to avoid making the game's looks be *too* simplistic. One of the first things I do is add borders to walls, combining multiple wall sprites into the same object. This gives them more of a body. Another thing that's really important is the color scheme. For this stuff I use a special tool called gPick, it lets you find colors and generate color variations.



It's subtle but the walls aren't of a solid color, there are some variations there, same with the sand. Gpick is also useful for finding shades.

And a shiny mechanical cherry on top

I was supposed to build more levels but I kept having issues with the directionality of the design.  I was starting to shuffle teleportation ideas. If there was a way to return to an area after destroying some sprites and falling down, then there would hopefully be more flexibility in levels. But the problem was how to add teleportation without making it too hard to code (and draw) and also without making the game sci-fi, because it's supposed to be about digging.

I settled for this gem idea. In games about digging in dungeons there's usually treasure. It's odd that the game didn't have treasure. But what if... MAGIC GEMS.



Gems expand on the second mechanic, picking things. And they also combine with the other things, they are affected by gravity, so they expand on the falling-ground mechanic. And once I had those gems, the level ideas became more exciting. It was already late in the compo, so this addition only affected 3 new levels, but it was so much fun to build them.

Please check my game out, it's in need of ratings!

If you like puzzle games where the mechanics are the priority, even above graphics and other things. Using an engine that's built for these sort of thinky game, because it has an undo button and a level skip. Then give my game a try.

• Play the game at itch.io
  
• Give the honest rate at the game's page
  

 

 

Part 1: What I've learned from Kye

Recently I've felt a big urge to write about game design. So let me start with a story.

I was a Bolivian kid in the later 90s whose family just acquired a computer. Something my parents did really well was nurture my love for computers. So I would always convince them to buy me a new Magazine about computers. Back then we didn't even have cybercafes so computer magazines, were the way you'd acquire shareware software. The magazines would come with these CD-ROMs full of software selections you could try out.

What I loved the most, were the games. Which were pretty rare. Most of the times the CDs would come with mostly utilities like stuff like icon editors (I actually loved to make icons?). But every once in a while, they would come with shareware games. It's strange how, regardless of how many of those I must have tried over the years, there's only a handful that I actually remember.

One day I found a true jewel. Some guy from the UK made a charity ware game called "Kye", with some really random ideas. You were a green circle, which apparently is supposed to represent the author's dog. There were monsters for some reason. But mostly the soul of this game was puzzles involving blocks. You can play the original 2.0 version for free at archive.org

From what I remember, at first I wasn't even able to really beat level 3, but the good news is that there was a level editor. There must have been something about the weird visual style or the simplicity of the level editor that I've made countless of levels. None of them were any good, but in the process I did discover some interesting iterations between the objects. It was also very practical that levels were basically txt files. You could actually "see" the level when editing it with a text editor. I guess the fact that it had 'arcade' elements such a monsters was the main thing that made me want to make levels, it was all about obstacle courses back then.

Kye's gameplay

If I were to make the simplest Kye level that explains what it is about, I would make this:

The goal of Kye is to get all the "diamonds" (those blue things). You get diamonds by moving the player character (green circle) to their cells. You move the player character using the cursor keys (You can also use the mouse if you are a horrible person). But what's interesting here is the yellow squares with a red arrow drawn on them. These arrow blocks will always attempt to move towards the direction indicated by the arrow, and will only stop when something is blocking them. In this case, the diamond in the middle is blocking them. But if you were to grab the two right-most diamonds, a thing would happen:

Now, Kye (the player) can push arrow blocks, but in this case it would only bring more problems:

Kye is trapped. Kye should have started with the left-most diamond and this wouldn't have been a problem.

All of kye involves making this sort of choice. There are many elements in the game that just make this choice more interesting. Some blocks can make the arrow blocks rotate. Other blocks are just normal static blocks that you can use to stop arrow blocks or do other things. There are "black holes" that will just destroy anything that you push onto them or any arrow block that moves towards them. There are "Bouncers" that can push any block, including the arrow blocks. Rounded arrow blocks slide diagonally when they hit another rounded object. Clock blocks will constantly create arrow blocks. And the magnets can allow you to bypass some of these complications, or they can also stick to you in  a way that traps you in a similar way.

But the Coolest thing about Kye, just happens to be the main thing you learn from the solution to level 3, the level that I initially had no idea whatsoever how to fix. And it is that Kye is a real time game. The arrows, the bouncers and the monsters won't wait for your moves, they have a life of their own.

This is what happens when  you attempt to solve Level 3 without thinking:

So you can't really get that top-left diamond because the arrows will block the path. What now?

The trick to solve this (and maybe if you really want to give this game a try, you should give it a try before reading this) is to plan ahead and make sure the bouncers are synchronized correctly. The bouncers will clean up the arrows by themselves.

 

And this, this is the power of Kye. There's 20x30 cells, which at first may seem like a huge amount of cells for this style of a puzzle game, but the reality is that the level designer will need plenty of room to be able to build of sorts  of machines, combining the various elements. These machines are the real core of Kye's gameplay. That's why it is a real-time and not turn-based. 

 This is ultimately what I've learned from Kye. It's all about the machines. Different gameplay elements can make something bigger than the sum. But it all requires some thought about what the elements will be. If done correctly, levels can take a life of their own.

Undusting the old blog. Some changes to come.

It's been a long couple of years. The last year was particularly long and I'd like to reopen this blog and site. There's some new things I want to share. The focus will no longer be programming contests. Although I do plan to participate in some of them in the short term, just because I participate in something it won't mean I will write explanations for that contest.

I want to have a voice for computer-related talk. So first, some recaps of what happened since the last post in.... 2018! 

• The real job meant that I am much less likely to be able to participate in a contest and I haven't really practiced much. In fact, my C++ skills are really dusty. My performance in programming contests has been abysmal. And that's one of the reasons I haven't been very open to talk about it. If I kept blogging like before my posts would go like "I opened 500-points problem I thought I had it but there was a bug, and I didn't have time to submit 250"
• I kept improving Cloudy Conway. Or maybe I made it worse? Because its twitter account is far less popular now than it was back in 2016.
• 2019 Was the year I returned back to Super Mario Maker, due to the release of the Nintendo switch version. Since then I've been using it as a creative outlet and to practice my level design muscles. Recently I've released a Super World containing 31 puzzle levels. Some of which are good.
  
• During the Pandemic, I decided to start a Plex server (Plex is a software for making a media server so you can organize your media library and also watch your media in any device that runs their app). One thing led to another and I ended up forking a project that was called "pseudoTV". The name of the fork is "dizqueTV" . It's a tool to creat e your own fake TV channels out of the videos (and audio files) in your plex library.
• And now in 2021 I decided to quit Mario Maker and instead .... Uh Oh , that's a  long story talk I'll leave for tomorrow.
  

Recently I've restarted my twitter account. The new official way to find me is @vexorian_  in twitter.com