First question, what the heck is OGAD? That was usually the response I got when I brought it up. We could argue about the name that's for sure, but the thing it stands for is amazing. 

OGAD stands for One Game A Day.
At the end of this long and exhausting day stands a playable game. I started every day with a new concept, new mechanics and with a new Unity project. And everyone who works with Unity knows that the last part is the most time consuming one. The games itself were just a nice addition, the really important part of this project was the experience I gained. I focused on game design, scoping and finishing the games. Not on design, art or sound, that’s the reason I used assets from kenney. With those I could save some time and make the games visually more appealing. 

---

My Experience
I participated at several  game jams before and one of my biggest problems were scoping and polish. Overscoping is in general a big problem of mine. I did this challenge for 7 days in a row. I learned quality beats quantity, a well designed mechanic which is polished is better than several different ones. 

The games have a variety of mechanics. The quality ranges from meh to quite fun to play. Most of them have bugs, flaws and missing polish. 

Nevertheless the games have one thing in common. They were an amazing opportunity of growth. With every game I learned something, gameplay programming, game design, player feedback, engine stuff and a lot more. I learned to use my time wisely and focus on the most important tasks first. Everything that was not necessary was left out, saying no to things was usually a big hurdle of mine.

I made a lot of mistakes, had a lot of bad concepts, but all that didn’t matter, because the next day something different was made and I could use the experience I gained in the next game. The feeling of blazing through design problems that I struggled with the last few games was amazing. One Example was day two and three. Day two, a cave exploration game with a hook mechanic, took me about ten hours to create. Here I really struggled with the level design, because I’ve never created a 3D environment before. Day three, a jump’n’run game  with card mechanics, on the other hand just took me around seven hours to make. Here I designed the level much quicker, I already knew the tools and had the experience how to lead the player. 

Also going through the concept phase that often in such a short time was really good. My sense of what is a good idea got better.

---

What I’ve learned? 
There were 7 things that really stood out to me while developing those games. Those topics were present in every game and focusing my efforts on those improved the quality enormously.

• Concept & Planning Every game starts with a concept, idea or feeling you want to convey, right? Writing it down and breaking it into its smallest pieces helped me understand what it took to create this feeling and which mechanics helped. Also having a list of mechanics helps with the scoping. If my list was longer than 3 entries, I knew I couldn’t make it in time.
• Scope Having a tiny scope helped me a lot. I had enough time to implement the mechanics with the right amount of polish and I wasn’t overwhelmed at the end of the day. In general creating stuff takes more time than expected. For example, designing mechanics I didn’t design before took me around triple the time I thought.
• Mechanics Everything I did was just there to improve the quality of the mechanics. Everything that didn’t serve a mechanic in one way or the other was not implemented.
• Feedback & Impact Mechanics without feedback and impact are boring. I think as human beings we expect a response from every action we take. If the action has a big impact, it just feels more rewarding. So every action the player can take should also give a response. This could be visually or auditory. Therefore animations, particles and sound effects are great way to improve those fields. That’s the reason I started using particles on day four.
• Play testing Playtesting is the most important thing I learned. When I designed something with a expected behaviour in mind, more often than not the player did something completely different. I often used my friends as playtesters, because they were the first in reach and they could give me honest feedback. Seeing someone play your game is not just fulfilling it also gives you great insights into player behaviour and bug abuse 

One thing I really underestimated was the mental drain. After day 4 my energy levels sunk. Working seven days without a rest is really exhausting. This challenge took me to my limits, creatively and mentally. That was good. If someone would do the same thing, I really would recommend doing more breaks and free time after a day full of developing.