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.

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

[Progress] Designing the dungeon - part 1

Finally! It's time to create a puzzle dungeon [by hand]. Designing a solvable puzzle while keeping it interesting/fun is a lot tougher than I expected. For the time being I'll just populate it with some simple puzzles until I figure out a better way to implement them (thinking smaller rooms, but it causes a lot of problems with my sprite scaling -- this is with interpolation turned off). Ideally, the doors would just transition the player into the next room, but the problem with creating so many small rooms, is it'll mean I need to create more physical rooms. That'll start to make things really messy.

Initially I had an idea of how to create the puzzles in my head. Create a start and end point, draw a solution line, and populate the map around that (by hand, since I figured it would be faster than learning and creating an entire algorithm dedicated to it.

Although you see the character unlock the door after moving the two boulders in, this is just because I spawned some keys into my inventory. I need to figure out a way to create a check for those two boulder points to change the state flag on my locked door to "unlocked". Something like this (pseudocode for the mode part):

globalvar nodesActive
global.nodesActive = 0;

And create a collision event of some sort for when the node and boulder collide. And then to reset the counter of nodes active when a locked door is used. Or create_instance(); when the nodes are active and make an invisible key become visible on the map.

Eventually there'll be more than just pushing the boulder into the nodes, such as traps, keys/chests/treasures. But for now I'll need to look over various texts about Sokoban design logic:

• http://sgd.cs.colorado.edu/wiki/Sokoban_Design
• http://www.games4brains.de/sokoban-leveldesign.htm

It's a shame Game Maker had removed their in-house transition functions. For the time being, I just have been using room_goto(); which does exactly what it sounds. It's a bit disorienting when I am doing test runs due to the fact you continue moving unless you release the movement key as you enter the dungeon.

Another change I had to make while trying to get the room changes to work properly, was to start relying on instance_create(x,y,obj_player); in the room creation code rather than physically placing obj_player into the room editor itself (although having multiple clones moving simultaneously was briefly amusing).

It's a start though!

[To Do] Framework nearing completion

• Work on a finite state machine, the boulder is going to need one when I start developing him further
• Surfaces?
• Add UI? Merge inventory into a HUD?
• Add start screen
• Polish up the inventory system and appearance
• More puzzle elements
• Add functions to the town

Today was productive, managed to tackle a 3-day long problem (damn boulder collision), while getting started on the inventory system. For the time being it'll suffice, but I'll have to find a non-intrusive way to display the inventory without causing as much clutter as it is. I may scrap it altogether and embed it within the UI and have it display a numerical value rather than the element itself. This would give more space to the player without feeling crowded in, the viewing size is only 640x480, so it does not leave me much room to create a spot dedicated to the UI out of the playing area, maybe orient it vertically with a smaller text size?).

I'll start designing a few demo puzzle rooms without anything too complicated to get a feel for how things should develop there. I want there to be a sense of urgency, without too much pressure. But at the same time to keep the player thinking, with the constraints they are given with, time, boulder durability (I'm really liking this idea already), keys available, traps, lives?

As for the last bullet point, I want the town to serve some purpose of some kind. The hero needs to rest after a long day of shoving a boulder. Perhaps this town is known for shoving boulders, and has a boulder smith to design better boulders/equipment to handle them better. I'm starting to go beyond simplicity at this point, but the point being, I'm hoping that the two rooms in the game: Town and Dungeon, will both equally serve purposes without starting to overcomplicate things.

[Progress] Inventory system - part 2

Okay that worked a lot better than I expected! While messing with inventory system I realized that ItemPickup(global.items[0,0]); that I used to pick up the items, could be similarly replicated to remove simply by reversing the script it was calling. Now my obj_chest carries a different function compared to items that you pick up.

opened = false;

if(global.KEYS >= 1 && opened = false) {
     ItemRemove(global.items[0,0]);
     global.KEYS -= 1;
     image_index = 1;
     opened = true;
}

else {
     //show_debug_message("already opened");
}

Guess that means tomorrow I'll start working on the locked doors and finally start the dungeons! Surfaces and state machines are going to have to wait.

[Progress] Inventory system - part 1

No there will not be apples in my game. It was just a random asset I used as a placeholder. I've gotten the inventory more or less set up. As you can see, the player initially tries to open the chest, but it doesn't until you pick up the key. I just haven't figured out how to remove the key from my Draw GUI event. The primary reason I chose to use Draw GUI as opposed to Draw, was just so it was always fixed in the same place on my screen no matter what happens. Just about ready to start making my dungeon puzzles. Also this is a toggle so you can hide it when you do not need to see the inventory window.

I was surprised to see interest when I was showing my friend what I've come up with so far. And if anything, I think I have a more solid idea of what the framework will include near completion:

• Boulder durability (HP?)
• Traps, keys, lockpicks, doors, chests

Going further into boulder durability, I haven't finalized what it could mean. Either the number of times you can roll the boulder, or how many traps it can set off for you in your place before crumbling (so you can't just drag the boulder across the entire puzzle safely). Maybe there'll be different kinds of boulders that have different properties? For now, it's just a simple brown boulder.

[To Do] Keeping it simple

• Still read more about finite state machines
• Understand surfaces
• Add UI
• Add start screen
• Add inventory sytem
• Add basic puzzle elements/objects (keys, locked doors, traps?)

I suspect the first two items on the list will be tinkered with every now and then while I work on the more fun puzzle elements instead. Hopefully I'll juggle them all well.

I feel that keeping my list minimal, helps keep the development simple. Once the list grows and the backlog gets bigger, it'll become overwhelming to maintain a feel for a steady pace. It's too easy to play the "Wouldn't it be cool if" thought process while forgetting to put yourself into the developer side of things. I want to keep the core simple, and expand upon it in several ways.

Simplicity: The entire game will most likely be located only in two "Rooms". The town and the dungeon, although I don't understand enough about A* Pathfinding (click-to-move, and/or enemy logic) and data structures/BSP trees (procedural generation), I believe the core of a puzzle game can work with or without them.

Scalability: Many puzzle games are able to do both without any problems because they are stripped of the "bloat" (stories, etc). I don't mind committing time to this side-project, ideally designing a simple framework would allow me to set the pace for the flow into the rest of the design.

Uniqueness: As someone who had actually never really played the original Sokoban games, I have played concepts that relied on those mechanics. Where am I going from here? I'm not completely sure yet, but I do want to create a balance between exploring the dungeon and returning to the town. Perhaps rescue NPCs to unlock perks, not sure yet. Maybe restore a town via rescuing NPCs, or amassing resources to buy the upgrades/improvements to the town from a carpenter.

[Progress] Collision detection with boulder pushing - part 3

My friend introduced me to GifCam, which after double/triple/quadruple checking to make sure this was not the Malware version, works much better for creating animated gifs than using Gyazo (which the previous pictures were captured with). I record it at a lower FPS, to compensate for a much smaller filesize. It saves the dimensions of the recording window too, so all the future recordings will be the same dimensions. It's still going to be choppy, but at least the perfomance of the GIF will remain more accurate than the stuttering found with the Gyazo ones. With that said..

Today is the third day of tackling this problem and I would like to say it is just about perfected. I just removed the collision event between obj_player and obj_pushable_boulder and replicated the player's movement and modified the statements to account for !place_meeting(x,y,collision_controller) instead. Now it behaves just like a player, but also moves at the same speed as the player, thus eliminating the strange "soccer-like" movement. But the best part is, I can remove the comment around my instance_destroy(); code that I had set up for performance boosting again.

if place_meeting(x,y,obj_player) && !place_meeting(x,y,controller_collision) && keyboard_check(ord('D')) {
     if (obj_grid.cells[(x div 16) + 1, y div 16] == 0) {
         isMoving = true; // Lets start moving
         moveTimer = gridSize; // Ready moveTimer for countdown
         speedX = moveSpeed; // Set horizontal speed
         speedY = 0; // Set vertical speed
     }
}

If I'm understanding what I did, I am able to skip out on offsetting the x and y values for the collision because I have already assigned it to a grid value identical to the player as well.

I have not flagged (tagged?) this problem as [Solved] because there still are some issues when it comes to multiple key-presses that causes the boulder to move off the grid (thus messing up all collisions). But for now this will be what I need to finally make some actual progress with the rest of the game.

[Progress] Collision detection with boulder pushing - part 2

After messing with toggling solids and such to get my collision issue working [almost] perfectly. I realized when my player collides with the boulder, his movement halts at the moment of the collision. While not noticeable at first, it becomes apparent when you are not restricted to a confined area (say a hallway or something with very limited direction). I'll need to figure out where to insert a !place_snapped(16,16) function into the player, without freezing him in position.. Ideally I was hoping the whole movement thing to be simultaneous, but even changing the x += 10 values to 16 did not work.

[Progress] Collision detection with boulder pushing - part 1

I finally got it to work! I needed to comment out a part of my obj_grid code that was deleting all controller_collision child instances (to save memory). I might just make all of the instances invisible for the time being.

After a lot of frustration and doing my to understand my mistakes, I realized that I was going about the checks incorrectly. Rather than creating a separate place_meeting() event for checking my collision object obj_wall_marker which inherits the properties from it's parent controller_collision to determine if the space it was pushing into was not occupied by a collision object. Instead, it should be performing that check simultaneously with respect to the position to where the player is. Another mistake I made was having x = 0; for the collision check, as it would set the x-position go 0 rather than "do nothing". And finally, it is important to remember that the image mask starts at (0,0) rather than the center, and these images are all 16x16 which means I was checking as far as an entire grid over, causing preemptive collision with the player. Anyways, here's the old code in it's messy non-functional glory.

if place_meeting(x-8,y,obj_player) && keyboard_check(ord('D')) {
    x += 10 ;
    }
if place_meeting(x+8,y,obj_player) && keyboard_check(ord('A')) {
    x -= 10 ;
    }
if place_meeting(x,y-8,obj_player) && keyboard_check(ord('S')) {
    y += 10 ;
    }
if place_meeting(x,y+8,obj_player) && keyboard_check(ord('W')) {
    y -= 10;
    }


if place_meeting(x-16,y,obj_wall_marker) {
    x = 0 ;
    }
if place_meeting(x+16,y,obj_wall_marker) {
    x = 0 ;
    }
if place_meeting(x,y-16,obj_wall_marker) {
    y = 0 ;
    }
if place_meeting(x,y+16,obj_wall_marker) {
    y = 0 ;
    }

move_snap(16,16);

The best part is the new collision code takes up even less space than this

if place_meeting(x,y+1,obj_player) && !place_meeting(x,y-1,controller_collision) && keyboard_check(ord('W')) {
    y -= 10;
    // Check South, push North
    }
if place_meeting(x+17,y,obj_player) && !place_meeting(x-1,y,controller_collision) && keyboard_check(ord('A')) {
    x -= 10 ;
    // Check East, push West
    }
if place_meeting(x,y-1,obj_player) && !place_meeting(x,y+1,controller_collision) && keyboard_check(ord('S')) {
    y += 10 ;
    // Check North, push South
    }
if place_meeting(x-2,y,obj_player) && !place_meeting(x+1,y,controller_collision) && keyboard_check(ord('D')) {
    x += 10 ;
    // Check West, push East
    }
//show_debug_message("PUSHED")
move_snap(16,16);

It's still cluttered, but it'll suffice until I start working on a Finite State Machine.

[To Do] The Foundation

• Read up and learn about finite state machines
• Fix collision logic
• Understand surfaces

By all means this list isn't set in stone. But I figured were the most important things for building the foundation for this game. I'll have to convert my current input logic into a Finite State Machine, perhaps one to handle collision as well. Surfaces.. will be saved for another day.

Decided to start keeping a dev blog

My personal experiences with maintaining and working with a blog is minimal, so forgive me for my poor layout and lack of content. While learning and furthering my understanding of GML, I decided that creating a simple game would be a great way to go about keeping track of my progress and growth, as well as posting the progress to gauge my potential.

And this is where we bring in Sokoban Crawler. What started initially as an attempt to understand grid-based movement (instead of pixel based), became the foundation for it. As for the name, probably just a placeholder as I think using the word Sokoban would be a breach in some patent. But the title coarsely defines the point of the game. Sokoban with some kind of Adventure aspect of it.

Although I've only been working on it for about a day, I've learned one thing about the Room Editor for Game Maker: Studio. It is terrible. Either that, or I'm going about it the wrong way.

The editor reminds me a bit of the RPG Maker interface, but tiling and object placement has a clunky feel. And for some bizarre reason despite having the ability to create hundreds of thousands of layers. Yoyo Games omitted an ability to label them..

Among other headaches, I'm still trying to figure out how to get my collision to work with my "object pushing" function.

I'll update this post as I figure things out. For now there isn't much to see. Just the "home" map and an empty "dungeon" map which will be for the puzzles.