An apology

Due to some unforeseen circumstances, Sokoban Crawler will be on hold indefinitely. I apologize and hope to pick back up on it soon! I'll still be working on other smaller game projects on the side until then. Thank you for following and I apologize sincerely for the long period of no updating.

[Thoughts] Directions

Today I was talking with a friend I had not spoken with in years. Turns out he had been a game designer in the past! I linked him to this dev blog and he requested a demo build for the game. He explained to me about finding a core loop for the game; something that the player goes back-and-forth between.

• Equipment can improve your stats and modify ways to interact with the boulder
  Town Improvement
  • competing with another town?
  • unlocking new stores that sell things to help you progress further into the dungeon
  • to defend against attacks from the outside?
• Go through the dungeon to find resources to upgrade yourself and your town.

I know that this is a bunch of repeated stuff, but at least writing it down here gives me a fresh view of what I should be working towards for my game's goals. Note that these aren't set in stone, but they are ideas for my core loop.

[To Do] Differentiating Feature Creep vs Core

Despite my previous post mentioning my approaching to "completion". I still have a hard time distinguishing between when adding another feature/function is necessary or if it falls under some form of bloat. My guess would be pruning out various things after they are implemented if they do not add anything to the game in terms of function or fun.

It's been a while since my last To Do post, and thought it was necessary to make my list to remind myself where I really stand in terms of progress with Sokoban Crawler:

• Work on Title Screen and Menus
• Inventory redesign and implementation
• Add a delay before pushing the boulder, and maintain a delay per cell.
  • Adding equipment
  • Player Stats
  • Perks?
• Optimizing hazard tiles + adding more trap varieties
• Further development on stamina mechanics
  • Adding monsters
  • Development of combat mechanics?

This is all that came out of the top of my head. Whether they are actually necessary or not, time will tell.

[Progress] NPC Dialogue(s) and Message Windows

It's not much, but it's a start. I need to figure out how to "unscale" the font sizes from my draw events. I suspect tinkering around with draw_text_transformed(); until I achieve the results is the best way.

This month-long project has taught me many things I did not expect from learning about game design and programming. I believe that I am approaching "completion" of the framework. I did not end up using surfaces as much as I liked, primarily due to my lack of complete understanding of it. However, I feel that it was not necessary to use them as much in this case, as I primarily removed objects and instances using while loops instead which netted a higher performance gain.

[Thoughts] Game Direction

My friend has been one of the people I know personally who faithfully reads the blog and checks up with me occasionally to see how Sokoban Crawler is coming along. He has made some very good points as to where I have been going and what I should be looking at. That and he really doesn't like Sokoban.

I don't blame him, I enjoy many simple things. But he's right, what I've been doing has simply been creating a mechanic that, by itself will appeal to a narrow audience. He made a good comparison to a game I had not played more than a few minutes of, ATLUS' Catherine. Which tethered the players between the dream (puzzle) and the pub (social/hub).

Some ideas that were bounced around in our conversation included introducing an aspect of competition involved. Whether it be having two players race to complete and progress further into the dungeon. Or some kind of Bomberman/Tetris aspect where you try to win while trying to interfere and/or end the other player. Perhaps the goal of the game is no longer about completing the puzzle itself, but simply doing what you need to get the key to get to the next room instead. Interesting food for thought and inspiration.

I don't know how to program fun. But I hope that this will shake me awake and make me more aware of the overall "end game" of this project.

[Progress] Lava & Ice Tiles

Started working on some nefarious traps to populate the game. At the moment just lava and ice tiles. You can probably imagine what they do. Damage (Lava) and uninterrupted sliding (Ice). At the moment the ice tiles cause a stamina drain, in hindsight I realize that is pretty messed up to have the stamina drain while the player is not moving, but sliding against their own will, I'll fix it later.

I'm still debating on how to manage the boulder logic when interacting with these tiles. For the lava one, I was thinking of setting a timer that runs in the background as long as the boulder is in the lava. When the player finally pushes the boulder out, and steps into the lava, the boulder will also be molten hot for a time (I haven't determined whether time should move only when the player moves or works indiscriminately). As for the ice tiles, I don't know if I want the player to be able to change their direction when they collide with the boulder, or if their momentum transfers into the boulder and pushes them and the boulder another spot over (unless the collision is between a wall, the player and an ice tile (in which case there can only be the option to change direction or a broken puzzle/room is created).

Once I finish up all of the rough trap tiles/hazards, I'll set in place a new inventory system, for handling the use and ordering of items. I'll need to begin assigning uses for the enumerators I made yesterday as well.

[Progress] Not much to show but a tremendous amount under the hood

Hello! I'm alive! I know there hasn't been much visible chatter on my blog for over a week! But I have just about finished reprogramming my entire framework from the ground up. Significantly less wasted space on redundancy, much more organized and no longer looks cobbled together!

As for now, I am indefinitely suspending work with the HUD. I will deal with that when it becomes an apparent issue that impedes progress on the actual game itself. For now, I have decided to implement Health and Stamina in the form of individual static bars, rather than a dynamically changing uniform bar. As you can see in the above GIF, I have the hero walking over some potions. The first set of potions do not immediately recover their respective bars because I have added an argument with the collision event to check if the shift key is held. This will prevent accidental wasted uses of potion. However, if the bars are all full, the potions will still go into the inventory as well. I felt that giving the players more control over their precious [limited] consumable resources would be for the better. Currently I am in the process of creating a transition system for my dungeon so I can allow dungeons to occupy one room, in separate views. While this doesn't mean much for the player, but for the designer, it gives me a lot more flexibility and ease of wasting space with the room editor.

For a while now, as I have been working on the redesign of Sokoban Crawler's framework, I have been thinking about the direction to take the project from here. Personally I've hit a block with my creativity so I have been adding a myriad of eumerators and global variables has been the first step, all of which currently don't have any integration into the game [yet]. Once I've finished with my transition system and a few other core groundwork, I will look into creating a combat mechanic, either making some kind of turn-based world, or real-time. The latter being much easier than the former. Worst comes worst, the turn-based/real-time combat could feel out of place and I just scrap it altogether.

Among things that have been tentatively removed (in the form of commenting out) from the game are Diamonds, Lockpicks (Keys work for doors and chests at the moment), and the Apples. I did not want to clutter the HUD with too many different things that did almost the same thing or had no easily distinguished use for them: Lockpicks looking a little too much like hammers, diamonds having seemingly no apparent use other than adding to a counter and inventory.

That's all I can unload for you right now! Oh yeah, I am starting to understand the basics of using surfaces. The HUD has been designed using a mixture of a surface for the background and a Draw GUI event for the items that populate the actual HUD window. It's not much, but it's a lot better than before.

Hopefully tomorrow night or even tonight I'll be able to show off the fruits of my labor with the transition system.