Beaster’s Dungeon Revisited: Part III

When I last left off, I managed to get the trap placement mechanic working as designed. Of the core mechanics I needed to get working, the last one remaining was enemy platform pathfinding…

Platform Pathfinding Challenges

As previously stated, the game’s object is to ward off hoards of enemies trying to navigate their way to your treasure vault by placing traps and barriers in their way.

The player can navigate the environment by moving left, right, jumping, and falling.  I wanted to give the enemy a similar capability:

In this scenario, an enemy character can walk left or right and can clear obstacles up to two squares (32x32px tiles) high and three across. Each scenario is numbered and represents the following:

  1. All possible ‘jump’/walk movements from a platform (1-3 across, 2 up)
  2. Walk left or right 1 square
  3. Drop down left or right
  4. Jump up left or right 1 square
  5. Jump up left or right 2 squares
  6. Jump up left or right 2 squares, illustrating that the platform might be floating (i.e. allows free movement beneath it)
  7. Jump across left or right 1 square and up 2 squares
  8. Jump across 2 squares (same height)
  9. Jump across 2 squares and up 1 square
  10. Jump across 2 squares and up 2 squares
  11. Dropdown 1 square left or right from any height to a platform below (this is implied in 3, but I wanted to illustrate it explicitly)
  12. Drop down to a platform of any height, 1 square left or right across
  13. Drop down to a platform of any height, 2 squares left or right across

While I found a couple of examples of this working/implemented in GML using a modified version of the A* Search Algorithm, I could never get them to work within my project. I discussed the problem with my friend Jason, who created a working prototype for me that met all of the design specifications. But not fully understanding how the code worked, I failed to integrate it.

Now that I have the time to troubleshoot it, I’m reluctant to do as I fear that I don’t understand it well enough to support it. Instead, it might be better to build something simpler…

Possible Solutions

Thinking through the problem, there are many other ways I could have solved this. Wrecking Crew for the NES comes to mind:

Enemies (and the player) in Wrecking Crew use ladders to navigate up and down platform levels. Why couldn’t I implement a similar feature?

Ladders

For example, instead of trying to make the enemy AI smart enough to navigate obstacles with a preset of constraints/scenarios, I could have them wander left and right across vertical planes, moving up or down when they reach a ladder, depending on whether the vault was above or below them.

Alternately, rather than placing ladders in fixed places, perhaps some enemy types could create erect them?

Stairs

Another option would be to use teleportation in the form of background staircases:

In this example, the enemies could access specific floors using “staircase” objects that would move them from point A to B and B to C, and vice versa.

Either scenario would necessitate creating two extra animation frames for each enemy sprite. Not a deal breaker, but something to consider…

Beaster’s Dungeon Revisited: Part II

Continued from Part I...

With Eric gone, I eventually re-coded everything, but never could work out how to implement the trap mechanic, so I shelved it and there it sat…until now…

###

I was talking with a friend who was admiring some CGA-16 color palette pixel art, which lead me to showing him the artwork I’d done for Beaster’s Dungeon. He asked if I had any intention of picking the project back up, to which I replied that I might, albeit with a reduced scope. I explained the difficulties I encountered with the trap mechanic, specifically, getting the cursor to snap to a grid.

This lead to a discussion of where I got stuck, and in order to illustrate this, I fired up GMS and started creating a prototype to illustrate the problem. I reached out to my friend Jason (who did the programming for ‘Milk Smugglers’) for suggestions, and he linked a forum post containing the floor/ceiling functions.

In that post was another mysterious function called, move_snap. Here’s what I did for the prototype:

o_cursor Object

///step event

//set coordinates of the cursor to the mouse's x,y position:
x = mouse_x;
y = mouse_y;

//snap the object to nearest grid coordinate 
move_snap (16,16);

Why is this important? Because it allows for precise placement of objects in a map comprised of 16×16 pixel tiles (or any predefined ‘snap’). Around this, additional rules and checks could be incorporated to ensure traps could only be placed where they were meant to be!

At long last, I was finally able to implement the trap mechanic! The only thing left to complete the prototype was enemy path finding… This turned out to be far more complicated than any of the other mechanics combined.

Stay tuned for Part III!

Beaster’s Dungeon Revisited: Part I

Naively Ambitious

Beaster’s Dungeon was to be a 2D platformer where the player would try to stop oncoming hoards of enemies from reaching your treasure vault by collecting resources to build and place elaborate traps.

It was conceived by my friend Eric and myself in late November of 2016. We sketched out a rough outline and slowly refined it into a proper (read: laughably inadequate) design document by early December.

Progress was slow as Eric and I both had very steep learning curves to overcome. I (arguably) had the easier job of creating the artwork and animation, and had plenty of references to lean on for inspiration. Eric, on the other hand, had the dubious honor of trying to cobble together code from various YouTube tutorials and the results were about what you’d expect.

We were getting nowhere fast, and even what [naively] seemed to me to be the simplest features were a puzzle of Gordian complexity for which I decided to apply the Alexandrian solution: cut it all loose and start anew.

Somehow, I stumbled across John Janetka’s Game Programming Course, and by the third lesson, knew enough about GML to solve many of the programming problems Eric was stuck on. Encouraged by a possible way forward, I suggested to Eric that we complete the coursework together. For Eric, this would serve to build the foundational knowledge and concepts he needed to master in order to get predictable, repeatable results. For me, well partly as a show of solidarity and encouragement, but mostly so that I could help troubleshoot when he got stuck.

Eric [reluctantly] agreed and we set off – what follows are details I haven’t really shared before, but I will try to present them objectively in the hope that someone, somewhere will learn from them.

Sullenly Inevitable

Over the next few weeks, I dove head first into the well of knowledge, occasionally coming back up to share what I’d learned on this blog. Eric was less enthusiastic about this, seeing it as a chore, but went through the motions – at least for a while.

To me, each lesson represented one step closer to accomplishing my goals. To Eric, each assignment was a step backward, taking us further and further away from a completed project.

Toward the end of January, I was eager to test what I’d learned by making a simple game from start to finish – that game was Porker: The Quest for Tastiness, more on that below. Eric on the other hand was thoroughly demoralized, having completely given on up on the GPC, and would soon after withdraw himself from the project altogether. What went wrong?

Rowing in the Same Direction

“Much like a relationship, I don’t think a game development team works if the designers aren’t on an equal ability and similar mindset”
– ‘3kliks’ Philip Dyer

From the beginning, I recognized that if I wanted to develop games, I would need to develop my skill set which, as I often lamented, was lacking. But I worked on it and improved, little by little.

As an individual hobbyist, you can work at your own pace, are accountable to no one but yourself and your project(s) can drag on for months or even years on end. You can pick up where you left off, start over or let it collect dust in the dark recesses of a forgotten folder.

In a team of unpaid amateurs, some are genuinely passionate and are prepared to commit time, money and resources to realize their shared dream. Others are only along for the ride, hoping to be carried across the finish line. Somewhere in the middle are those who start strong, but lose steam quickly and eventually drop out.

This could be due to:

  • Change in personal circumstances
  • Distractions
  • Lack of commitment
  • Loss of interest
  • Discouragement
  • Unrealistic expectations
  • Disagreements and disputes…

In part 7 of his YouTube series called “The Game Making Journey,” Philip Dyer (AKA 3kliksphilip) begins by stating that, “Game design has a reputation for being a boring and lonely activity (probably), but it doesn’t have to be this way! Making them with other people is an exciting bonding experience that almost always ends in disaster. Much like a relationship, I don’t think a game development team works if the designers aren’t on an equal ability and similar mindset.

For Eric and I, there was a disconnect. When I committed to working on the project,  I threw everything I had into it. Between working sessions, I read everything I could get my hands on related to the subject from game design theory to level design concepts to lessons learned from other indie game developers, and tried to incorporate this into my thinking.

Eric wasn’t really interested in what the outside world did or thought, and to my knowledge, never actively sought information or did research. Perhaps he was afraid his ideas would be polluted by outside influences and lose their originality, or perhaps he was afraid that doing so would somehow detract from the magic of it.

A Kind of Magic

To him, creating videos games was a kind of magic – you simply needed to learn the incantation, wave your arms about and the computer would either reward you with your desired outcome or punish you for your insolence by refusing to work, or worse yet, play a trick on you and give you something you didn’t expect.

One dream, one soul, one prize, one goal
One golden glance of what should be
It’s a kind of magic” – Queen, It’s a Kind of Magic

Having spent the last 20 years of my life (and career) working with computers, I knew this couldn’t be further from the truth.  If something didn’t work right, it was my fault for not understanding the syntax or behavior – garbage in, garbage out! The computer had no will of its own, and had no choice but to interpret the commands I gave it in the order they were received, and the order of things mattered.

Larger problems are broken up into smaller problems, and smaller problems can be solved, provided they’re well-defined – no room for ambiguity here!

Never Say Never!

By February 1, 2017, I’d completed the GPC. I wasted no time and dove into re-coding Beaster’s Dungeon. By this point, Eric had stepped down from coding and wanted to try his hand at game design. I created a Game Design Document (GDD) template for him and set him to work while I tried to build a prototype.

By the end of the first week, basic movement was finished, and I was struggling with the trap placement mechanic. I had no idea how build this, and had to take a step back.

Despite all of the effort I put forward insofar as music, graphics and now code, I still wasn’t a “Game Developer” because I had not yet produced “a Game.” This bothered me a lot.

I was discussing this with my friend, Jim, and while talking about GMS, I pulled it up in Google Hangouts and started showing him things. He was drunk, and we were having a great time – he’d shout out silly ideas to me while I coded the game. The artwork was mostly modified from open-source images found here and there. Still, it had that late 90’s flash game charm and worked well enough – it didn’t have to be a great game, but I did have to finish it, and after two days of work, the result was, “Porker: The Quest for Tastiness”, which we released under Jim’s website, porkcircus.com.

###

I never did get back to Beaster’s Dungeon – forever confounded by that damned trap mechanic – until yesterday!

To be continued…

Development Progress Update, Week 3

Summary

Game prototype is 67% complete!

I finally received verification on my code-signing certificate. While I was able to successfully sign an .exe file using the cert, I’m still getting a SmartScreen warning when running the file.

Further research suggests that I might need an Extended Verification (EV) code signing certificate (which isn’t available from my Certificate Authority (CA)), and/or publish the application on the Windows App Store.

I’ve received assurances from my CA that the certificate I purchased from them should work fine, and that the problem was with my Certificate Signing Request (CSR). Having rekeyed the request at least twice already, I feel sure that I’ve done everything correctly.

The only anomaly at this point is that Publisher is being displayed as the entire Subject string (i.e. state, city, country, organization etc.) rather than just the common name, “V-Toad Games.”

This is a big enough issue to warrant my full attention as a SmartScreen warning could deter potential players from running my games.

Development Progress Update, Week 2

Summary

Game prototype is 65% complete!

I lost a couple of work days due to illness…

I managed to get combination actions working (i.e. Jump+Down to drop down from a one-way platform). I may extend this later to allow look-down (using just the down key) to shift the camera a bit further once I learn how to use the view functions.

With the help of YYG Support, I was able to get the HTML5 module working, more on that later, and look for an update to my previous post.

I coded a virtual D-Pad for use on touch-screen devices, and while it works perfectly, I would need to adjust the resolution for it work on mobile devices.

On the business side, I’ve gotten together the required documentation needed to setup my Code Signing Certificate request submitted, and am awaiting verification.

What I’ve Completed This Week

Coding

  • Wrapped up player movement (combination keys to jump down)
  • Got HTML5 Module working
  • Got Virtual D-Pad (touch screen support) for mobile devices working
  • Got the trap mechanic started, but needs more thought with regard to implementation

Assets

  • N/A

Miscellaneous

  • Setup an account on GameJolt (allows me to publish and sell games both in .EXE and HTML5, hosted on their site)
  • Received an update on my Code Signing Certificate and provided additional documentation
  • Upgraded GMS to v1.9.525

 

What I’m Working on Next Week

Coding

  • Complete trap placement mechanic
    • Spawn cursor corners, spaced to fit any size trap object
    • Spawn/placement sound effects
    • Placement coding with checks to verify place is empty (no stacking/placement inside walls etc.)
  • Begin work on enemy AI

Assets

  • Background textures artwork
  • Scenery/flavor object artwork
  • Continue work on BGM 2, 3 and 4
  • Other SFX as needed

Miscellaneous

  • Follow up on Code Signing Certificate
  • Digitally sign an .EXE file and test it

Development Progress Update, Week 1

Summary

Game prototype is 60% complete!

I’ve begun coding the basic features of game, starting player control. This is the most important piece as the majority of the time spent in-game will be centered on movement and exploration.

I’ve coded it to utilize both Keyboard and Gamepad support (should I elect to port this to Xbox Live, PlayStation 3 & 4). The next piece will be getting the trap mechanic working, followed by Enemy AI (which are my goals for next week).

What I’ve Completed This Week

Coding

  • Basic platform physics (gravity, collision, one-way platforms)
  • Player movement: left-right, variable jump height, drop-down*
    • Keyboard support (WASD, [space])
    • Gamepad support (analog stick and d-pad) – Tested on a Logitech F310
  • Sound Engine:
    • Walking sound effects play and change based on surfaces
    • Landing sound effects play and change based on surfaces hit
    • Sound effects use random variable pitch to break up monotony
  • Basic inventory array
    • Keeps track of what spells you have
    • Allows you to toggle betwen spells

Assets

  • Sound effects and music:
    • Jumping
    • Landing on normal surfaces
    • Landing on wet surfaces
    • Walking on normal surfaces
    • Walking on wet surfaces
    • Collecting currency
    • Collecting resources
    • Collecting spells/secrets
    • Collecting bonus items
    • Detriments
    • Lob
    • Two kinds of projectiles
    • Damage
    • Title screen BGM (Background Music)
    • First level BGM
  • Player sprite animations:
    • movement (left,right)
    • Idle
    • Jumping
    • Falling
  • Resource sprite animations:
    • Arcanum (currency)
    • Iron Nodule (resource)

Miscellaneous

  • Converted all .WAV and .MP3 files to .OGG (faster and smaller)
  • Registered the DBA (fictitious name) of my business with the state
  • Send an inquiry to the SSL provider to request a Code-Signing Certificate (required the business to be registered)
  • Updated the vtoadgames.com website to use SSL
  • Acquired GMS Professional (v1.4)  and the HMTL5 Module**

*I’d like to modify this to use a combination of the Jump button and down, but haven’t gotten that working yet

**It doesn’t work out of the box, and I have no idea what I have to do differently to ensure that my games will work when ported to HTML5. Submitted a support request 5 days ago, awaiting feedback.

What I’m Working on Next Week

Coding

  • Wrap up player movement (combination keys to jump down)
  • Complete trap placement mechanic
    • Movement of the trap ahead of the player
    • Spawn cursor corners, spaced to fit any size trap object
    • Spawn/placement sound effects
    • Placement coding with checks to verify place is empty (no stacking/placement inside walls etc.)
  • Begin work on enemy AI

Assets

  • Background textures artwork
  • Scenery/flavor object artwork
  • Continue work on BGM 2, 3 and 4
  • Other SFX as needed

Miscellaneous

  • Follow up on Code Signing Certificate
  • Follow up on HTML5 export module issues