This is a reflection on the first rapid ideation session. We ask these questions:

Did everything go according to plan? If anything, what went wrong? Is there a way you could build on your work from the first session? (Although we ask you to work on a new artefact, you might still consider using similar technologies or reflecting on similar themes).

Did everything go according to plan?

The plan was to “finish” a game, which I did. But…

If anything, what went wrong?

There are quite a few bugs in the software:

• polyominoes can’t be rotated otherwise they break the win condition logic
• game boards can’t be arbitrary sizes otherwise the solver gets stuck in an infinite loop in some cases

These could all be fixed (and I will). However, there’s an upside: I managed to deliver a playable game - an MVP (minimum viable product), if you will - using a configuration which is known to work, and even if the pieces couldn’t be rotated, they could still be placed to get to a solution. In the future I will take this direction again, as it’s good to deliver something playable soon and fix bugs later, rather than building the perfect code up front.

The second issue is that I could have used the ideation techniques more. I did some brainstorming and ICEDIP in my head on the night of the theme revelation, but completely neglected to do opposite thinking, SCAMPER (Recall that SCAMPER stands for Substitute, Combine, Adapt, Modify (Also Magnify and Minify), Put to another use, Eliminate, and Reverse.), crazy eights, round robbin (with my family), and so forth. I think with more ideas I might have been able to make a puzzle game which has at least one more extra memorable quirk or slant to it which players will remember (and which isn’t related to story, art or audio). In the future I’ll definitely use the afore-mentioned techniques more.

Is there a way you could build on your work from the first session?

Yes, I could fix the bugs I mentioned, and the polyomino solver code could definitely be re-used in a future puzzle game.

I’ve done some research recently into the types of games that are doing well, and the types of games that gamers really like to play. I have an idea for a game mechanic which I’m super excited about implementing.

However, the game mechanic needs networking, and I’m not entirely sure this is a component I should implement myself, or whether I must rather use a game engine with industry-standard networking (e.g. using Unity with something like the SteamWorks backbone). This raises questions around using Phaser 3 again, where I’d have to host my own servers and build a websocket-based component myself (which I could do given my skillset, but “could” doesn’t mean “should”).

I’ll let that decision simmer for the time being.

What else?

I might run out of things to quote from Tynan Sylvester’s book soon, but it’s so good.

Decision design is game design at its purest. While games can be enhanced by narrative, fiction, image, and sound, none of these is essential to the form. The heart of games is in interactivity, and the heart of interactivity is the moment of decision.

(Sylvester 2013: 120)

I like to think that my game jam game involves decisions, but it could be so much more. Currently, they are just decisions you have to make to get the pieces to fit, but it’s devoid of emotion. I think in my next game, I want to particularly focus on getting the player to make decisions which will make them feel a wider range of emotions.

More than in any other field, in game design decisions must be emergent to work well. So instead of writing them one by one, we have to create systems that can generate them on the fly.

(Sylvester 2013: 120)

Doing systems-based game design (Polack 2018) might be a first for me, but I’ll go through the backlog of games I’ve made over the years, see which comes closest to systems-based design, and report back here. That said, I’m excited to implement at least a basic system in the second rapid ideation session, with which to effect more emergent gameplay.

Bibliography

1. POLACK, Trent. 2018. “A Guide to Systems-Based Game Development.” Gamasutra. Available at: https://www.gamasutra.com/blogs/TrentPolack/20180104/312480/A_Guide_to_SystemsBased_Game_Development.php [accessed 3 Nov 2020].
2. SYLVESTER, Tynan. 2013. Designing Games: a Guide to Engineering Experiences. First edition. Sebastopol, CA: O’Reilly.