SALT SWEEPER

WRITING THE GDD

All good games begin with an in-depth game design document. Over the years, I have learned that the GDD isn't some place to create the entire game and detail evey mechanic. Its somewhere to start and iterate on throughout development.

I began by writing what I knew I needed: a core gameplay loop flowchart, specifics on the world generation, combat specifications, and UI drafts. This gave me a basis to begin my prototype with, and would be iterated on throughout my development.

CREATING THE FLOWCHART

One thing in pre-production I'd like to highlight is the flowchart for the main gameplay. This was the most important thing in the entire document to nail down because it is really a complete overview of the game and gave a basis for development. This was something that I continued to iterate on throughout development.

UI CONCEPT -> REALITY

I mocked up a lot of the UI in aseprite, making everything in rough shapes and titles. IT WAS VERY IMPORTANT TO DO THIS because UI in Gamemaker is notoriously difficult to make edits to (editing would mean a lot of work). With a good plan in place, there shouldn't need to be too many changes made besides general positioning... I made the mistake of not doing this for a couple sections of UI in this game.

SYSTEM DESIGN

I knew that I wanted to have a lot of diverse weapons, items, and spells -- which presents the problem "how did I manage it all?"

To begin, I contemplated working with a json that I could pull from, but I found that it would be simpler and nearly as efficient to just use a .csv to store all the data.

I designed the sheets to be easy to read and edit, making adding new items trivial -- the only thing I acutally needed to do in engine was to upload the sprite.

The dialogue system uses the same data-driven approach. I needed to manage hundreds, if not thousands of lines in the final game, so I made an indexing method to keep everything organized. For example, Freya's second story dialogue could would be under the index F-1, but an optional event would be indexed F-E1.

Combining this with some cells to host the dialogue choices and to call events, made this system robust, and made the creation of events simple.

Another little bonus that I'm proud of is the item drop calculations. At first I was just using a simple random number generator that would shuffle an array, but that would mean every item has an equal chance of being spawned in a chest. My solution to this was to create an easily editable sheet of percentiles for each item!

COMBAT DESIGN

Turn based combat often feels slow, and that didn't mesh well with the feel of minesweeper. During playtests I learned that players would quickly get really fast at traversing areas, but would be slowed down and have to wait for combat. They was a complete disagreement between the two paces, and I chose to adapt the turn-based combat to a faster pace to compensate for this wanting from the player.

I did this by reducing timers and animations, limiting the player's options, and keeping everything at a relatively low health (keeping the weapons balanced to this so the game wouldn't be too trivial). Typical enemies shoukld be able to be killed within a couple turns, and bosses might require a little more than 10 on average.

PLAYTESTING

Playtests were conducted for each major build of the game. The build was released to the team, and they played the build wit no direction or instruction. Then, they would answer targeted questions and fill out bug report sheets. This allowed me to quickly adapt to player feedback following each build.