[Progress] Just a heads up [not display]

Sorry no GIF for this Progress post, for the time being I've scrapped dozens of attempts to create a working HUD. I decided for the time being to use my original HUD with a few improvements until I can get some actual better ideas of why nothing I attempt seems to fit well. It's taken up more than any other issue I've had with development up until now.

With that said, once I finish my cobbled together makeshift HUD, I will be rebuilding my framework from the ground up. Having looked through some of my older objects, the GML is just a disaster. Pages of commented out obsolete code from earlier versions everywhere. Luckily I have been keeping a habit of meticulously commenting everything, obsolete GML or not. What this means is future development on Sokoban Crawler will be more organized and I'll be able to utilize my Sokoban/Grid Movement framework and use it for other projects.

With that said, time for some stuff about what has been going through my mind with the game. Temporarily I have disabled the "lockpick" item. Initially it was because after scaling up the sprite, it started to look more like a hammer. But then I realized, that one of my goals was to limit the amount of resources (coin, keys, etc) for the player to force them make their choices more carefully. So for the time being keys will open doors and chests.

Health (?) and Stamina bars. At the moment my intent was to just simply have the hero die if anything harmful touches him. I might add health to let players buy equipment/armor to give him a bit more protection from the elements of the dungeon. As for the stamina, it will be a fixed amount that can increase over time (under certain circumstances), and will only drain while pushing the boulder, another element to restrict careless play.

I think that I am just about to reach my initial goals of creating my Sokoban-like game. But the element of Sokoban itself seems to be not as interesting to other people as I thought it would be. The dungeon might become shelved and used as an alternative to something else with the game. Not sure yet, I'll deal with it once everything is settled down.

[Progress] HUD development - part 2

Not much to show for the weekend's worth of progress. Creating a HUD is a lot harder than I anticipated it to be. Well, I did expect some challenges, but poring through dozens of screenshots and discussing with a few of my friends about HUDs that have been used in other games and why they were good really felt like hitting dead ends. From what I've observed, the best HUDs were like good paintings with the shadows done correctly; you didn't notice them. It's only when something was wrong or ambiguous did it suddenly become glaringly obvious, and in some cases a hindrance.

For the time being, I finally went about replacing the text heavy placeholder HUD with a combination of sprites and numbers instead. The sprite-based window for the HUD background is a big improvement as well. I need to readjust the position of all the HUD elements again, but that won't be a huge priority for the time being. The sprite-based window is a script I plan to use for the upcoming menu system as well.

I need to carefully plan out and arrange all the elements in a way that can inform the player at a single momentary glance without any breaks in game flow.

[Progress] HUD development - part 1

Small progress update with the HUD. Finally realized why the WIP HUD was not properly displaying my item counter. A person on the Game Maker forums I frequent pointed out (even though I mentioned I had been aware of it) that my display was only showing "PICKS" and not "Picks: " as my code had stated. I pointed out that it would always be shown as "PICKS" because the font did not have lowercase, which only made me realize that the font may also not support symbols. Sure enough, there were no symbols. Switching the font to one that supported symbols fixed the issue!

I'm still in the process of trying to figure out how to proceed to the next stage of the HUD, replacing the counter with drawing the sprite instead. My initial attempt ended in a compile error which I will need to figure out what I'm doing wrong from there..

draw_sprite(global.inventory[i,4],0,x+16,y+32+(16*i));

That'll be for tomorrow. I'll implement all of the items and their counters via text formatting, and tomorrow I'll start manipulating the view so a portion of the top of the screen is dedicated to the HUD and does not intrude on the game screen. Hopefully eventually shift from text to graphics, makes it easier to glance at.

[To Do] Fix a bug, find a bug

Since my last post, I was able to iron out just about everything needed to get the game up and running at it's core. I am still trying to figure out a way to handle the player exploring the said "dungeon/puzzles". With the small demo I released to just a few close friends, they reported the bugs I had already been working to deal with, and a few pointed out ones I had overlooked. For the time being the biggest ones to tackle are:

• Redesign the HUD
• Work on a menu system
• Merge all puzzle rooms of the same dungeon into one room
  • But hide the undiscovered rooms until discovered/explored
  • Create a minimap
• Squash a few bugs that were pointed out from the demo:
  • Multiple directional key presses can cause obj_player and obj_boulder to have strange collision activity/issues.
  • While using 'R' for restarting an unsolved puzzle room, if your player is on a boulder spawn tile, he will become stuck.

At the moment, when a puzzle is completed, I have been using the instance_deactivate_object(); function to remove all instances of obj_boulder and obj_pressure_plate from any rooms marked as solve. This is to prevent the player from accidentally boxing himself into a room while pushing a boulder. Ideally, I want to keep their instances in the room but just no longer movable, since it seems odd to just have them disappear. It'll suffice for now though.

[Progress] Designing the dungeon - part 3

So in today's GIF, you'll see I reset the room once midway. This was to show that the pressure plates will only trigger the spawning of obj_key when both of the plates are pressed simultaneously. I'm aware at the end of the picture the player steps into the void, that'll be addressed immediately. Also ignore that ugly green rectangle with the word "PICKS" in it. That is just an unfinished side project for reincorporating the UI into a HUD rather than an inventory window..

I had been stuck with figuring out how to design my pressure plates to work properly for the past three days with no luck. After bouncing around ways to approach a solution with a few people, and learning a *lot* more about handling object creation and management.

Normally when designing with the room editor, I would "hard place" the objects onto the room via clicking and placing it. Later it turns out that doing it that way can make it harder to identify certain objects as well as generating an identifier that I, personally had not been able to utilize. Instead, I created a room with just the tiles instead, and had the objects within the room placed down via creation code called upon another object (obj_dungeon_1 in this case).

Create Event

switch1 = instance_create(6*16, 1*16, obj_pressure_plate);
switch2 = instance_create(8*16, 2*16, obj_pressure_plate);

instance_create(4*16, 1*16, obj_boulder);
instance_create(7*16, 4*16, obj_boulder);

key_spawned = false;

Step Event

if (key_spawned = false && switch1.pressed && switch2.pressed) {
     key_spawned = true;
     instance_create(6*16,2*16, obj_key);

     //instance_destroy(obj_pressure_plate);
    }

Doing this, gives me explicit control of where the objects will be, what their names will be, and any arguments between specific [duplicated] objects! This was the problem I was having with my pressure plates in the first place! Differentiating the obj_pressure_plate from each other!

Now it is [almost] safe to say the framework is just about done. Pressure plates will behave similarly to traps so the foundation for that is already done. My inventory array is already handling adding/removing items in the inventory, and adding currency will just be another element into the array.

Speaking of arrays, it was a topic I brought up when talking about how to better understand them. For the longest time I was pretty sure I was using 1-dimensional arrays. After she had explained to me the differences between the dimensions, I realized I had been inadvertently using 2-dimensional arrays [correctly], which was a huge relief on my end. She pointed me towards a couple websites for supplementary reading to further my understanding:

• http://www.homeandlearn.co.uk/java/multi-dimensional_arrays.html
• http://stackoverflow.com/questions/12231453/creating-two-dimensional-array

The reading gave me a better understanding of how to handle my grid movement code, allowing me to improve it further! I am grateful to have friends and other people who can be a bountiful source of information and a deep repository of programming resources. Even more, for them not doing it for me, but just pointing me in the right direction and letting me figure it out on my own.

[Progress] Designing the dungeon - part 2

After struggling with the previous tileset, I resorted to using a basic set which has worked wonders for placement. Removed the animated nodes for a pressure plate tile instead, boulders utilize pressure plates a whole lot better than they do with ethereal nodes.

I haven't been able to get the pressure plates to work quite yet. I'm still going through trial and error with figuring out how to determine when a puzzle has been successfully completed. A few things I attempted were using room creation codes to make the obj_key objects invisible at the start and toggle their visibility after the appropriate collisions were detected. However the player was still able to pick up the key by walking over the object even when invisible. Another problem was creating trigger events that would even spawn the key in the first place using instance_create();. The documentation explaining instance_id(); was extremely disappointing and lacking for what I could potentially use it for sadly.

I decided to shelve the initial idea of having all the puzzles interconnected in one large room, as it did not allow the player to be surprised with each new room they enter. Honestly, the primary reason I had initially had them all interconnected was due to my inability to understand views properly. After a lot of experimentation, I finally clicked. As a result, rooms will all be separated and I will eventually add sliding transitions to make it feel like one large dungeon that you are exploring.

Lastly, more collision issues as always. At the end of the GIF you'll notice my character is pushing a boulder against the locked door, which is causing some interesting behavior. This might be because of my move_snap(16,16); line I have at the end of all the movement code for obj_player. I'll have to mess around with adding another !place_meeting(); argument to my movement checks I think.

[To Do] It feels like a floodgate has opened

• Surfaces + state machine
• Revamp/improve UI + inventory management
• Start screen
• Puzzle design theory
• Give the town purpose

Even though it is quite minor, I gave the boulder some animation states just so it feels like you're pushing it as opposed to watching it appear to be effortlessly sliding across the map with the hero in tow.

Here are some thoughts/lessons that I came across as I tackled the things I did during today's progress: Use relative values whenever possible, it'll save yourself time and a headache in the long run (especially if it is creating instances), don't make a puzzle game unless you are willing to take the time to make sure they are 1) Solvable and 2) Interesting/Fun. If you don't have fun with the puzzle, the rest of the puzzles are going to feel like a drag. Even designing the puzzles can give me a sense of soul crushing defeat, in the sense that I have failed to create a lasting/interesting puzzle with some challenges (maybe because there are no unique elements implemented quite yet). Although any veteran coder would already know these things; something I am not.

Tomorrow evening I'll go full sprint with the puzzle design and compile a demo for my friend to play. It helps to have a second pair of eyes to know what the game is lacking, and I know it's lacking a lot. But some direction would definitely give me a second wind.