Collecting 100% of the souls with Bob (the demon) is now possible!
Resolved clipping issues in the levels “Stilted Pond” and “Toad Hall.”
Gamepads, including PlayStation, Xbox, and Super Nintendo-style controllers, are now generally supported*. See the notes below for additional information.
Updated the Purgatory Purgers Manual to include gamepad button mappings
Special thanks to @ABitNosthalgic for suggesting that we make it possible to collect 100% of the souls with one character or another!
Gamepad/Controller Support Notes
*Most PC-compatible controllers with a Direction Pad (D-Pad), Start and Select buttons, and four face buttons shouldwork. The game has been tested on the following devices:
Logitech F310
X-Box Elite Series 2 Wireless
Megafire 412-NO5 (generic PlayStation 2 Style Controller)
8BitDo SN30 Pro (SNES-style controller)
@ABitNosthalgic reported that the Suily brand NES-style controllers did not work for him. While I haven’t tested this myself, the reviews seem to suggest that problems, particularly with the D-Pad, aren’t that uncommon.
Resolved a bug (warning, spoilers!) that would destroy objects unintentionally when two blocks collided
Added a spawn/respawn animation and sound effect
Reworked the Passphrase mechanic (used to continue to a previously visited level) to display the Passphrase on the pause screen under the main menu as well as the Game Over screen.
Updated the Purgatory Purgers Game Manual to better describe the Continue/Passphrase mechanic and other menu features.
Special thanks to @ABitNosthalgic for catching the bug and Jason D for passphrase feedback!
Back in September ’23, I announced that Eric and I were working together again after a 7-year hiatus. We’d agreed to start small, and after some initial discussion, Eric committed to taking on the roles of Game Designer and Level Designer. I would do the programming, artwork, sound effects, and music.
When we initially brainstormed game ideas, Eric fondly recalled the time he’d spent playing Chip’s Challenge on an old Windows 3.11 system and suggested we create something like that, starting with the core mechanic of pushing blocks into slots.
After some discussion, we settled on a Purgatory theme. Eric proposed two characters, an angel and a demon, each with their own unique abilities. The ‘demon’ (Imp) could push blocks, and the ‘angel’ (cherub) could fly over obstacles (e.g., water).
Eric didn’t remember any of the specifics of Chip’s Challenge, so I watched some gameplay videos and got a very rudimentary idea of how the game worked, focusing first on orthogonal, tile-based movement and then the “Sokoban” mechanic of pushing blocks into designated places.
I didn’t have a clear vision of the art style and started out with the intent of creating 32x32px tiles and character sprites. Here’s an early rendition of Bob:
Although he looks pretty good, the bigger the sprite, the more detailed it needs to be and the more time it would take to create. In addition to the player character, there are also the enemy sprites and tile sheets to consider.
Early sprite sheet designs were 32x32px tiles and single-height, meaning that the tops of the walls were on the same plane. This was simpler but didn’t look very good.
I eventually scrapped this all in favor of simpler, 16×16 tiles with fewer animation frames, akin to something you might see on the NES, albeit a slightly larger color palette (64 colors instead of 52, and support for alpha channel, which wasn’t something the NES could do).
In an effort to work in parallel, I’d asked Eric to block out level designs with primitive tiles that we could later replace as the finalized tile sheets were created.
This worked well initially, but as the tile sheet began to take shape, we encountered two issues that set us back:
Eric’s designs were more complex than what my simple tile sheet was capable of, and absent the correct tiles, Eric would ‘wing it’ with the ones he had.
The levels Eric created assumed features we hadn’t previously discussed. I was still working on the core mechanics and did not even have a working prototype of the basic gameplay yet.
In order to get this under control, I knew that I needed a playable game, and by mid-September ’23, I had one. I asked Eric to build a simple test level so that we could playthe game. Here’s what that looked like:
The First Prototype
Having a working prototype can teach you a lot about your game. Is it fun? Does the core gameplay loop (i.e., the thing the player does in the game) work the way you expected? Is it complete?
I watched the Extra Credits video series on Making Your First Game. I’d watched dozens of GDC videos on game design. I knew that our focus needed to be getting the game to a playable prototype so that we could see what worked and what didn’t. I knew this – Eric did not…
How could he? He’s never made a game before. To him, game design meant thinking up cool ideas. That’s only natural, as that’s how a writer might approach the problem. A game designer needs to be able to articulate, in great detail, the logical systems that make up a game, the rules, for instance, and how to resolve problems you might encounter.
Take the angel for example. In our original discussions, we wanted the angel to be able to fly over water, so I focused on getting that mechanic working without thinking about why. In order to facilitate this, I had to create a test level and realized that simply moving to areas the demon couldn’t get to on his own wasn’t all that interesting – then it hit me…what about a bridge? What if the angel could lower bridges, allowing the demon and a block to reach places he couldn’t previously access?
This would not have occurred to me without actually playing the game.
Iterative Refinements
Initially, the movement system I created moved the character one space per key press. This worked fine on small levels, but with big, expansive ones like the test level he’d created, it was very fatiguing. To address this, we opted for continuous movement.
The more I played, the more I realized that half the fun of the game was exploration and collecting the souls, and the other half was the puzzles, but you had to have both. You can read more about Purgatory Purgers’ level design philosophy here.
As we talked through new features, I tried to corral Eric’s ideas into building on existing mechanics to create more value, using the example of secret rooms and passageways. The mechanic behind this reuses the water tile in a novel way. Eric suggested “hiding” the secret room, but there wasn’t an obvious way to do this due to the ‘skybox’ background we were using at the time.
By scrapping the sky tiles in favor of a plain black background, we could use an opaque black rectangle that’s destroyed on contact with the player to reveal the secret area. This was both easy to implement and highly reusable!
Creating the UI
We knew that we were going to need a UI for the game, so we discussed what should be in it, and Eric went to work on a simple mockup. Here’s what he came up with:
We initially discussed a scoring system in which the player earned points based on souls collected, gems slotted, completing a level, and number of moves made. Our game resolution was 480px wide by 270 pixels tall (1/4 scale of a target screen resolution of 1920×1080 in a 16:9 aspect ratio).
I found that even using the smallest font I could find (~5x5px per character), it would be impossible to cram all that information into such a small area. To get a sense of proportionality, I started with a simple shape and put it on the playfield:
As I began to play with designs, I arrived at something closer to the final one but found that placing it over the playable map didn’t look (or feel) good:
Moving it 16px to the right and adding a black background seemed to do the trick, but I also modified the camera (which was set to follow the player) to include a buffer equal to half the width of the level to keep the player centered on the screen – this would prevent the player from getting behind the black border (128px or approximately 8 tiles):
With the general layout done, I had to figure out how to populate the information it contained… More tweaking! I scraped the score (we didn’t have a solid design, and it felt a bit arbitrary), making more room for other elements. I also decided to stretch the UI a bit vertically to make more room for label text:
Finally, I added the animated ‘judged soul’ graphics, which brought it all together:
I noticed there wasn’t much room for the soul counters, so I incorporated some additional code to change the font once it reached the triple digits, but that came much later…
Mid-Development Hell
By October ’23, the core of the game was finished, save for creating a menu system, secret levels (and a system for accessing them), and additional levels to flesh everything out. Eric and I argued frequently.
We could not agree on a shared vision for the game, what a level should look like, or even the definition of Game Design!
For example, Eric spent what might have been several hours creating a very faithful rendition of the Pacman maze. While very well done (for what it is), it did not fit the theme of our game (not to mention possible copyright infringement).
Purgatory Purgers II: Copyright Infringement!
Then there were the logistical obstacles… I had Eric create the levels in Tiled, and then I’d recreate them by hand in GMS2. This meticulous process took hours because each level comprised several tile layers (e.g., Walls and floors, decorations, water, object instances, etc.).
As the month came to a close, I was nearing my deadline for completing a very difficult certification Exam for work, so I put my development efforts on hold for the next 2 months to focus on that.
The Last Mile
At the end of December, I passed my Exam and was ready to resume work on Purgatory Purgers. Over the next few weeks, I started investigating ways we could improve our workflow and allow Eric to create levels directly in GameMaker.
My first thought was to try to implement source control, but not knowing what I was doing almost ended in disaster. I kept at it and was eventually able to work out how to import room resource files.
Although we’d overcome the technical hurdles, Eric wasn’t used to using GameMaker as all of his previous work was mocked up in Tiled, and then (re)created by me. Naturally, Eric did not create levels as quickly as he could in Tiled, nor were they of sufficient detail to meet the current standard. This isn’t to say that my levels were perfect either, and in fact, after playing through the game over and over again, I ended up redoing my first level and making significant cuts to other levels I felt were too bloated.
“…[sometimes], You must kill your darlings.” – William Faulkner
I came to the grim realization that Eric and I had fundamental disagreements that wouldn’t get resolved in this project. Eric had lots of ideas, but the concept of testing them and killing off the ones that didn’t make the cut was abhorrent to him. He placed alot of value on his individual ideas as well as his ability to generate them. Still, he did not understand that the idea itself represented a tiny fraction of the overall effort required to execute it. Our imaginations are limitless; my time and abilities are finite. Sometimes, you must kill your darlings!
The only way forward was to create the remaining levels myself, along with the endings, menu system, and artwork, which I spent the next few weeks working on. By the middle of February ’24, I was done!
I took a few days to recover, then went back again to finalize it for release.
Publishing Purgatory
I originally intended to publish on GameJolt and Itch.io and advertise in the official GameMaker forums.
Unfortunately, I couldn’t edit the content on my GameJolt Developer page without encountering an “ERR_TOO_MANY_REDIRECTS” browser error. The platform is covered in ads, which suggests it’s either dead (or dying), so I decided to abandon it and move on to Itch.io.
Itch.io turned out to be a good choice. It is simple, easy to use, and straightforward. I captured a few screenshots and then spent about an hour creating a YouTube video to promote it. I spent a couple of days creating an old-school-style instruction manual and packaged it with the game.
Posts in the “Made with GameMaker” thread on the official forums require moderator approval. What confused me was that my post was initially visible to me and then disappeared later, leading me to believe it had been deleted. Thankfully, after reaching out to the moderators, I was assured that hadn’t happened, and a short while later, my post went live.
Reception and Payout
The only people who played and/or bought the game were a handful of personal friends, acquaintances, and a couple of kind folks from the Official GMS Forums. Jason D., John J., and others pointed out bugs and potential exploits, and I fixed what I could.
Overall, I spent about 480 hours on this project over 8 months. The proceeds were around ~4.2¢/hour (gross, 3¢/hour net).
Lessons Learned
Communication was a constant problem for Eric and me. Because we had different schedules, we could only speak in real time once per week. Between our weekly calls, I’d try to share my thoughts on progress with Eric through Discord messages. My DMs to him were too verbose, and his responses were too succinct.
It was difficult to discuss complex design topics this way. Often, a conversation would begin with, “Would it be possible to do [insert_feature_here]?”
I read somewhere about ‘Mu,’ the third answer to a Yes or No question, and it can be interpreted as “Your question cannot be answered because it depends on incorrect assumptions.”
A lot of what Eric was asking about sounded simple and straightforward, but it usually lacked sufficient elaboration to explain exactly how it would fit into the game. When I asked Eric if the juice was worth the squeeze, I was trying to convey to him whether he wanted me to pause work on implementing core game features for the one-off feature he was asking about.
From my perspective, Eric’s question was lazy and uninformed, and from Eric’s perspective, I was dismissive and impersonal. While we eventually talked it out, it took a lot of heated arguments to get to that point.
For me, Purgatory Purgers was never intended to be my magnum opus; instead, it was one more step towards learning how to be a game developer. Eric had more faith in the project than I did, but as far as I can see, that faith was more wishful thinking than anything else. Would I be upset if Purgatory Purgers was a runaway success? Absolutely not, but I also understand that some games, charming though they are, don’t have mass appeal and never will.
I guess the biggest takeaway is that my next game ought to be more memeable :).
Since then, Eric and I have been creating levels to round out the game, and with a little over an hour’s worth of content, I’ve been looking at some of the larger levels to see which parts I can cull so that the game doesn’t get dull/outstay it’s welcome.
Level design is difficult to do well. Purgatory Purgers’ level elements can be broken down into a few different components:
Features
At its heart, Purgatory Purgers is a puzzle-exploration game. Each level is a series of interconnected rooms of varying shapes and sizes and could include:
Gambits: Rooms with one or more dangerous enemies
Treasure Rooms: Filled with lost souls (the primary objective of the game/scoring system) and free lives
Puzzles: Moveable blocks, bridges, etc.
Secrets: Hidden rooms and passages marked by a small crack in the floor or an odd-looking bush.
These aren’t mutually exclusive and could be combined to form interesting and progressively more challenging areas.
Flow
A good level shouldn’t railroad the player down a specific route; instead, there should be 2-3 branching paths and reward players for exploration with additional lives and/or hidden shortcuts through the level.
Embellishments
To bring the Purgatory Purgers levels to life, I created lots of additional tiles to add flavor and mystery to each set of levels. Locked doors, sewer grates, pools of water, grass, grates, blood spatters, arcane symbols, and even emptiness in the later levels.
Putting It All Together
A good level combines all of the above to form a cohesive package; the level is:
Good looking (i.e., makes good use of the available tileset and avoids excessive repetition)
Intuitive to navigate (it doesn’t require a lot of backtracking)
Sufficiently diverse in enemies, puzzles, and mechanics
Above all, fun to play (read: sufficiently challenging, but not too difficult)
I’ve been looking for a way to allow another user to create rooms for my existing project using templates I’d created with consistent instance, tile, and background layers.
After my experiment with source control ended in disaster, I decided to shelf that for the time being and try a simpler approach:
Procedure
On PC1, I Exported the as-is project as a .yyz file (File > Export Project > YYZ) and then saved the file to a network share.
On PC2, I downloaded the [MyProjectName].yyz file and Imported it (File > Import Project > Path\To\.yyz file).
I updated the project on PC2 by creating a new room, and then I saved the project.
I opened File Explorer on PC2 and browsed to the project’s rooms subfolder (i.e., C:\>Users\[MyUsername]\Documents\GameMakerStudio2\[MyProjectName]\rooms).
I located the corresponding folder to the new room I’d created, then copied the room2.yy file back to the network share.
Back on PC1, I created a subfolder in my project with an identical folder name and then copied the room2.yy file to that location.
I opened GameMaker Studio 2, right-clicked in the Asset Browser, and selected “Add Existing“. After navigating to the room subfolder from the previous step, I selected the .yy file and clicked “Open.” Nothing happened!
At this point, the rooms list didn’t update with the new asset, nor did I receive an error.
The Missing Step
After opening the game’s project file (.yyp) in a text editor, I could see a list of resources, including rooms, along with their relative paths:
After saving and closing the text editor, I fired GMS2 back up, opened the project, and after an agonizing minute or so of loading, the project opened without error!
To my delight, there sat the imported room in the asset browser. I double-clicked it, and there it was:
Alternatives Considered
Someone on the official forums had suggested having Eric submit asset packs – I have no idea what that means exactly, but he seemed to suggest this was less than ideal.
Eric’s original levels were created in Tiled, and then I’d manually recreate them in GMS2, which was inefficient and very time-consuming; however, I’d heard that there were tools that could convert a Tiled map to a GMS2 .yy room resource file but couldn’t get it to work properly with my project. This is because our maps utilize multiple tile layers sandwiched between an instance layer (where the objects live) and the background layer. Most of these tools assume you are working for a single tile layer to another single tile layer, and none of the address how to get the room.yy file back into your project.
Caveats and Disclaimers
In order for this to work, all of the resources used in the room (i.e., objects, sprites, tilesets, etc.) must be present and unchanged in both the source and destination projects
GMS2 is known to not play nice with Cloud-synced project folders, so make neither system
I’ve worked alongside development teams for most of my professional career, and they all used source control. So, if I wanted to do things the “right” way, I also needed to use source control [with GameMaker Studio 2]. But alas, the map is not the territory, and you really screw things up if you don’t know what you’re doing. I didn’t know what I was doing.
Initial Setup
Although GMS2 offers [limited] native support for source control, it seemed simpler (and easier) to install GitHub Desktop and point it to the project folder.
Using this method, I was able to upload an entire project to GitHub, then install GitHub Desktop on another PC and clone (download a local copy of) the entire repository (i.e., the project folder) onto the second PC.
Once I got it working to my satisfaction on my end, I went ahead and walked Eric through it over Discord/screen share.
Where It All Went Wrong
Eric volunteered to clean up the tile layers of several maps – little mistakes where the incorrect tile was used for a given room that needed to be updated. Eric and I both thought that he’d pushed these changes to the repository, but the mistakes were still present.
Initially, I’d assumed these were regression problems that Eric introduced, but after looking at the same levels on my second PC, I realized these problems were present in older versions of the project, meaning Eric’s updates didn’t get pushed.
By then, I’d already fixed these problems on my end and pushed the updates to the repository. When Eric introduced his changes on top of mine, the levels were suddenly missing.
Recovery
After quite a lot of troubleshooting, I eventually decided to make a backup copy of the broken project, export the backup I had on my second PC, and then manually redo the changes I’d made over the last 24-48 hours.
This worked, and I was able to get back on track despite losing a day of productivity.
Back in May, my life was starting to slow down enough to spend some time on game development again. Shortly after, I reached out to my old friend Eric to reconnect.
After a few weeks and several emails back and forth, we decided to start again, this time on a new project.
Game Mechanics
Eric suggested Chip’s Challenge (specifically, the Windows 3.1 version) in brainstorming ideas, which incorporates a few key elements:
Collecting McGuffins (computer chips)
Pushing things (similar to Sokoban)
Avoiding enemies
While Chip’s Challenge is more complex than that, we decided to focus on those 3 design ideas and start there. Eric proposed the idea of the player controlling an angel and a demon trapped in limbo. The two would have to work together to solve puzzles to advance to the next level.
The McGuffin would be souls, which would be set free from limbo to either ascend to heaven if collected by the angel or descend to hell if collected by the demon. Collecting all of the souls would allow the player to exit the stage and move on to the next level.
We incorporated a Sokoban-like push mechanic and decided to give this ability to the demon. Blocks would be used to obstruct enemy movement/line-of-sight and also to solve key/lock puzzles.
But we also needed something for the angel to do, so we decided to include water tiles that only the angel could traverse, using the same key/button that the push mechanic utilized.
After getting these features working, I had the idea to introduce bridges that the angel could lower, allowing the demon (and, by extension, blocks) to traverse areas that would normally be cut off by water.
Next Steps
With most of the core mechanics working, there’s a lot to do insofar as creating assets (art, music, etc.), levels, and the like. Eric is primarily responsible for level design, so I leave it to him to work on cranking those out while I work on polish.
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:
All possible ‘jump’/walk movements from a platform (1-3 across, 2 up)
Walk left or right 1 square
Drop down left or right
Jump up left or right 1 square
Jump up left or right 2 squares
Jump up left or right 2 squares, illustrating that the platform might be floating (i.e. allows free movement beneath it)
Jump across left or right 1 square and up 2 squares
Jump across 2 squares (same height)
Jump across 2 squares and up 1 square
Jump across 2 squares and up 2 squares
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)
Drop down to a platform of any height, 1 square left or right across
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…
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.
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 myfault 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!
