I spent 5 days creating a simple card matching game, using Unity.  Today I’m going to reflect on what went well and what didn’t.  Why do a retrospective on something so trivial?  I believe that learning from past experience is a skill that will improve my trajectory as a game developer.  And like any other skill it takes practice.

What went well:

+ I made and delivered something. One year from now I don’t want to have a hard drive full of secret, unfinished work.  I want to plan and deliver tiny games and learn from my mistakes, over and over and over.

+ I picked up new skills in the process (UI Toolkit + UI data binding, saving progress to disk with EasySave, using DOTween for animations). I did this project to learn these specific skills, which I believe to be fundamental.

+ I included my kids in play testing and they successfully found bugs!

+ I broke the work down into tickets to keep me on track using Trello.  At first I did not do this given how small I thought the scope of the work was.  But I was quickly reminded  that my memory is terrible and I’d constantly forget what I planned to do if I didn’t write it down.

+ I successfully made coding mistakes that I can now look back on and say “I’d do that differently next time”

+ I gained valuable experience from a very small, low stakes project without wasting too much time

+ I downloaded sample projects to help me learn, in this case the Dragon Crashers project provided by Unity

What can be improved:

• I underestimated how long it would take me to deliver. I thought I’d be done in a day or two but it took five. Classic developer mistake.
• The things I underestimated the most:
  • The time it would take me to learn UI Toolkit, even just to the small extent that I used it. I suck at reading/comprehending Unity documentation.
  • The time and thought required to design UI.  I made the very dumb mistake of not designing what the game would look like in advance.  Instead I coded first and designed in my code editor through repeatedly building the UI.  Only towards the very end of the process did I wisen up and start iterating on design using an actual design tool, in this case, Figma.
• I didn’t take enough time to think through the user flow outside of the core game play.  The core game play rules and mechanics are so simple that I didn’t have to solve anything about them in advance.  But outside of the core game play there are features that I didn’t spend time to think through before coding (eg. saving and loading your fastest solve times to disk per difficulty level, creating a menu to change difficulty level, giving the player the ability to restart the game easily, etc) 
• Putting together the itch.io page, thumbnails and screenshots was done as an afterthought. In reality creating good marketing assets and a great store page is, I’m assuming, a hugely important task that can make or break your game's sales. Thankfully this game is not meant to sell or get views. I know to put more focus on this next time. In fact, I’m now thinking that whenever I make “a real game” I should create mock marketing material during my ideation phase, to help me find good, marketable ideas.

I think that about sums up my retrospective on making Memory. There is definitely a lot I can learn from doing this short project.

- Lodesa