Sunday, October 15, 2017

In-depth look at Filler

 Why hello there reader! I know, I know, I know... it's been a while. But don't think I've been sleeping on the job. Though it's been over a year since my last post, I've been working really hard on a lot of different projects. I plan on giving this blog a well-deserved overhaul soon, and keep you guys up to date on my recent projects. But I couldn't let this very opportunity pass by: my first publicly-released game, Filler.

The mechanics and goals of the game are incredibly simple: fill all the empty spots, reach the target at the end. So, you might be thinking: "With such a simple concept, I bet Hugo pulled that out of his bottom in a couple days". Weeeeeeeeell, make that roughly 9 years. It all began a long, long time ago...

 I don't remember exactly when that started. I am only approximating that I was about 12, but I could be wrong. Back then, I barely knew the internet and didn't have much to do on a computer. However, whenever I did get on a computer, I'd make the most out of whatever tool I had at my disposal, no matter how simple they were, or whether they were even designed for such ends. For example, with a cheap webcam and MS Paint, I'd make fake pictures of "twins" of myself, or even stop motion out of a Santa Claus toy. In PowerPoint, I'd make fake computer interfaces, or mouse maze games. Then I got to Excel...
 The reason why Excel was so different for me was that, even though I didn't know at the time, it had the right tools to kickstart me into game development: a grid-based interface, formulas to manipulate numbers and user input, mouse-activated macros and even programming itself via Basic. After a bit of experimenting with basically no prior knowledge of programming, I somehow managed to put together the very first version of Filler. It had very simple levels and a very rough interface, but the game was functional!
 After that, I just... moved on. I didn't think much of it, as was the case with most of my childhood/teenage experiments. I'd work on them, then try something else. Then in 2016, I decided I wanted to work on a small game to release as my first. I knew I wanted it to be a puzzle game, to have simple mechanics, and to be easy enough to be made relatively quickly. I didn't want to spend years into my first project. I wanted something simpler that would both kickstart my game dev endeavors and provide me quick feedback before I could move on to bigger projects. Then, after looking through my folders, filled with hundreds of papers with sketches, notes, plans and projects, the memory of a silly puzzle game I had made years prior came up.

 For the second half of 2016 and the first half of 2017, I was determined to shine a new light on that old, but interesting, project of mine. I knew from the start that there would probably be dozens of games similar to this, especially given how simple of a concept it was. But I also knew that, as long as the final product was fun to play, original in some aspects, and visually appealing, it'd still work out for me. I started it simple, with a simple grid, simple tiles, and no puzzle elements. However, I made the sorry mistake of prioritizing aesthetics over gameplay, and that came back to bite me. I spent most of my time trying to fix visual glitches or trying to improve aesthetics, and that happened for several months. The project had become so frustrating to work with, with so many bugs and such a lack of optimization, not to mention the lack of proper gameplay, that I abandoned it altogether. Below, you can see what it looked like shortly before I left it to collect dust.

Half-working level editor showcase

 Even then, I had some of the core ideas for Filler: multiple targets, walls, and I had just started working on synchronized players. But alas, it was doomed for a long time.

 Skip ahead a few months, and I get formally introduced by user quat to PuzzleScript, a web-based, minimalistic, 2D game engine. I didn't give it much credit at first, but then I started playing more and more games made with it, and started to see its true potential. Out of curiosity, I decided to poke around making a game. I chose Filler, but I didn't have big plans for it. I just wanted to give it a quick shot, nothing too serious. Maybe spend a week at most, and never touch it again. But me being me, I should have known better...

 I started with the main mechanic: moving player that leaves a trail behind, and must "consume" the empty tiles it passes by. It wasn't as easy as I first thought, but I still managed to do that with a few workarounds. Then I coded in targets, which were incredibly straightforward. Then I came up with crossroads, and the coding difficulty spiked. I couldn't just have them be required to be passed by twice. I had to consider all edge cases: the player entering vertically and leaving horizontally, the player blocking its path before entering it, multiple crossroads side-by-side, the direction through which the player entered first, blocking adjacent crossroads when one of them got blocked, etc. As you can probably imagine, I got quite carried away, and before I knew it, I was spending weeks tweaking that game.

Having to consider all possible states, fails
and outcomes was quite the challenge

 The more puzzle elements I came up with, the harder the challenge became. But given how easy it was to work with PuzzleScript, I wasn't hindered by it: I was encouraged. I wanted to keep working on it more and more, and more and more ideas came along. Most of them I ended up dismissing for being either too convoluted, too simple or just that other ideas could be worked as such. One such example was having buttons and doors: the player would have to pass by a button before they could pass through the door. But that turned out to act more like "forcing a path" than being a clever mechanism. In the end, I decided that the current set of elements was more than good enough to allow for enough flexibility and interesting puzzles.

 Targets were the first. They were present in the Löve2D project, and still served a vital goal in the game, as they could be used both as ways of alternative solutions, and as ways to masquerade the actual solution. However, I tried my hardest not to abuse said features, limiting myself to using multiple goals mainly if there were two or more solutions I was happy with, and if the one solution planned was easily given away by its target.

 Walls were also planned since the previous attempt at making Filler. They too serve two purposes: the first and most obvious one is blocking the player from walking in a certain axis between two tiles, which is quite useful for preventing unintended solutions and forcing certain paths; The second use is making "unidirectional" gates, if you want the player to only move horizontally or vertically.

 I'm not entirely sure where the idea for crossroads came from, but I knew they'd be an amazing new addition to Filler. They could be used in a wide variety of manners, to bring all sorts of interesting puzzles, from "knottingly" confusing to overly simplistic. I tried hard not to make levels where there are dozens of them strewn across and overwhelming the player. In the few levels where there are a lot of them, I tried making sure the actual solution was simpler than it might have seemed at first glance, giving the player a greater sense of achievement.

 Portals were kind of an interesting concept. Obviously I didn't come up with them on my own, they were inspired by Portal, but I knew that, in order for them to work for this game, they'd have to be more than just take the player from point A to point B. Not only do we now get multiple distinct pairs of portals, there is also a new mechanic that I'm going to cover below.

 Unsurprisingly, ice is also one of the most versatile puzzle elements. It works exactly as you'd expect - and like you've probably seen in many puzzle games. If you move through it in a direction, you won't stop until you hit something that blocks your way, or if there's an empty tile ahead. That brings a lot of possibilities: together with crossroads, the player can cross large chains in a single move. By themselves, might require the player to pre-block their path before sliding through. They can also be an obstacle when they force you somewhere you don't want to go.

 Players were planned for the Löve2D version, but when I tried implementing them, most of the game fell apart. Luckily for me, PuzzleScript's way of handling players allowed me to have that feature with only minor tweaks to the code. They offer a unique way of thinking around a puzzle in that, not only do you want both players to reach the goal, you also control both at once. So while at a certain keypress, one player might be pressing against a wall, the other player could be moving around in a different part of the puzzle. That allows for a plethora of different mechanics, such as one player blocking the other, both crossing the same crossroad, etc.

 Portal splitting/rejoining was more of a "happy accident". There was nothing in the code preventing more than 2 portals of the same color, so the logical question was "what if I have 3 portals"? While I had to tweak the rejoining mechanic, the splitting worked completely on its own, and I decided to implement it with the "Players" levels. When a player enters one of three portals, two players come out the other portals. Likewise, if two players enter the same portal color simultaneously, a single player leaves the third portal. A perfect fit for the final chapter.

 And that about concludes our tour through Filler. If you want to give it a try, you can play it for free on your browser RIGHT HERE. You can also check out the original post on the PuzzleScript forums for the solution to all the puzzles.

 As for the future of Filler, I am probably not done with it. Although it was mostly a failure, I still want to give the Löve2D version one last shot. I want to gather what I've learned while working on the PuzzleScript version and apply to it, making it more accessible to people, be it platform-wise, design-wise or map-making-wise.

 I've mentioned this before but I gotta reiterate: many, many thanks to Demon Arisen and HankyMueller for all of their help with this game. Without them, it would have taken maybe twice as long to publish, and I might have even missed out on some bugs that they found, as well as have missed some of their great suggestions and, naturally, their very well-designed puzzles.

 That is all for me for today though. I will try to post in less than a year. In fact, I've got quite a few projects to show, but with a new job under my belt, it's quite hard to balance my free time. I also want to give this blog a long, long due revamp, as well as get a domain. But either way, I hope to see you again really soon. Thanks for the read!


  1. This comment has been removed by the author.

  2. Hello. I'm a fan of all you guys' Portal work. Filler has been great so far. 5-9: Light Bulb has stopped me dead though.

    I didn't quite know how to solve these puzzles. Some puzzles are so loose that pretty much anything you put down will work, so one should draw first, ask questions when the grid is almost full. Some are unique with deductions far from the draw path, so they beg for being solved in an image editor. And some pick from both columns, leading you to draw at random while committing large chunks of the map to memory.

    This feels like an interface issue, requiring either the non-sequential drawing of an app like Alcazar or the notational mechanisms of something like , or croco-puzzle. Since puzzlescript would make any such thing a nightmare, could we possibly get a series of useless checkmarks, so that checking them before bifurcating would make clear how much undoing would lead to a safe state?

    I suspect my issue may be alleviated in later levels, as ice and extra portals are sequential elements, so deduction at arbitrary points of the path should be less common.

    There are a lot of paper puzzle styles that work in this way: Simple Loop and Pipelink and such. There is an interesting, relevant discussion of solving techniques starting with and ending at . And of course, Jordan's theorem comes to apply in any encirclable part of the grid with a couple of undetermined connections crossing your circle- this still works with careful accounting for portals, but I expect it often breaks when men are multiplied. There are also directionality from edge arguments to be had in the format, but these break early with intersections.

    1. Just played through Alcazar and gave it a closer look. I can definitely see where you're coming from. I have considered how Filler would work on paper, and it's not as efficient, since it relies on movement way more than state of the puzzle. Likewise, developing a "sandbox"-like interface for Filler wouldn't really work, not only because of dynamic puzzles with portals or multiple players, but also because of PuzzleScript's limitations. Maybe you had Alcazar's puzzle-solving techniques in mind for Filler, which works in some cases, but Filler has a few interesting differences in how it works such that those strategies won't always apply. I personally never felt the need to draw attempts at solution, though I have met people who did, so it's kind of personal I would assume. I've played Filler so much that I've also developed a lot of techniques for solving its puzzles, which I suppose gives me an advantage over new players, so I don't always see where they struggle. I appreciate the time you put into playing and criticizing this game, though! Tweaking the current version might not be possible for most suggestions, but I may or may not rework this game in another engine to give it more flexibility, as well as work on mobile and on desktop. I hope you liked playing it so far!

  3. I can't clear the last stage. please tell me the answer.

    1. You can check the solution to all puzzles in this page:!topic/puzzlescript/bUXjCSwqoLg

    2. Thank you for your kindness.I have cleared all stages.

    3. Congratulations! I hope you enjoyed it. Thanks for playing!