Designing from details instead of abstract mechanics

I was always angry at the need to compress constantly games to make them playable as a board game, a thing I would not have to bother with when making a video game due to the lack of physical restrictions. This is why most people design a game based on mechanics because it already fits as a board game format and only adaptation and re-theming is possible.

It seems that the original way I was designing was like they do in video game: You have the expansion phase where you shoot all your ideas and the cool things that could in the game, then you have the compression phase where you sort out and remove stuff unnecessary. But now you need to search for a mechanic that would abstract those game concepts into a game mechanic. This is where the process is really painful and I have an hard time succeeding.

First, I though I lacked of abstraction capabilities (I hate poetry), which could be true, but if that was really the case, how come I could abstract Eldritch Horror as Eldrich Express and Star Wars Rebellion as 9-Minute Rebellion (Idea in development). If I truly lacked abstraction, it would have been impossible.

But no, there was something else, and I found it today. When I made Eldrich Express, I made an abstraction of a game that exists, but when I have a game idea in my head, I am trying to make an abstraction of a game that does not exists.

It feels like if I asked you to build a classification system for games on board game geek with an empty game listing. You have nothing to work with, you cannot do an inventory of games and start making groups because your list is empty.

So that's the same problem with board game design, you have nothing to work with in the first place, so trying to abstract something that do not physically exists makes the process painful. Even if you do have a mechanic idea, you can easily run into a white page syndrome.

Another reason why I like designing variants, because you have something to work with in the first place.

So this is why I thought of a new approach. Not sure it could work, and possibly more suitable for solo games, at least the early testing would be made with only 1 player.

You start directly with the details, with minimal rules and components. It reminds me a bit of then project spark video game when you design a new game and end up with an island in the middle of the map and nothing around it or on it.

For example: Let say you want to make a pirate game. You say the essential mechanics is to move a ship and sail the seas. So you use a block for the ship and choose a map of your choice. You move around with your ship on the map following no rules at all, or you make up movement rules.

Then you get bored, you say to yourself that it would be cool to visit cities. So you add cities to the map and now you can move to new destinations.

But then again, what can you do with those cities. Maybe you need to keep track of your ships supplies which can be refiled in cities, so you add a supply track and some rules to handle supply exhaustion.

Then again, you wander for no reasons in the sea and think it could be cool to do some trading, so you add a market system and cargo markers with some economics rules to buy and sell stuff.

Then you think it could be interesting to attack cities, and need to implement a combat system. And it goes on like this.

At some point, the game will become large and complex, now you might start doing some compression by grouping together similar mechanics, abstracting certain mechanics to make it easier to manage. Now it's much more easier because you have something tangible to work with.

Instead a feeling of compression (with the "fit the elephant in the shoe box syndrome") you now have a feeling of expansion. Now I understand, that infinite expansion can lead to bad design, but think of it like construction lines in a drawing. They are necessary to build the drawing, but once your shape are drawn correctly, you do not need them anymore.

That is the same thing here, those mechanics you add bit by bit could be construction mechanics that will help you design the more abstract mechanics. It might be seen like a waste of time, but you have a much better sense of progress this way then when you have the white page syndrome.

I don't know if what I say make sense. I should give it a try in my next design and see how it turns out.