One of the most important things I've learned is to be honest on how much fun I'm having with my own games, not as a game developer, but as a player. Because if I'm not having fun with my own game, probably other people won't have fun playing it either.

This week I realized that exploring sectors sucks. Whenever I had to do it to test something, I just feel I don't want to do it. It's very boring to just click "move" and wait for something to happen, and since exploration is one of the core experiences of the game, something that you will do very often, I have no other option but to change it and make it fun.

I succeeded at my initial goal, which was to simulate the experience of giving orders to an employee which is on the sector exploring, you should not be able to see anything because you are supposed to be inside a robot, you just receive information of what the explorer sees. In the end this experience is very boring.

Even though I succeeded in creating the experience I initially intended, I need to forget that direction I committed to, and change it for the good of the game and its success. This was not an easy decision to make, I wasted a lot of time designing and coding this part of the game, but I also realize I need to design something better, or else this game won't be fun enough, I will not enjoy it, and nobody else will enjoy it.

I hope to not make the same mistake again ( even though testing ideas is what prototypes are for, I could have saved a lot of time and effort ), so I started to write the design of my game in a slightly different way, now I write ideas in this order:

1. Always keep in mind that the mechanics are just a "means to an end", not an "end" in themselves. The end is to make the player go trough a meaningful, emotional experience.
2. First: define an objective, the experience I want to player to feel.
3. Second: define requirements to be able to reach that objective, the things that need to happen in order to reach it.
4. Third: propose a mechanic designed to achieve the objective, one that fulfills the requirements above.
5. Fourth: define "why" each aspect of the mechanic exists, this is to make sure that each part of the mechanic exist for a good reason. Some ideas seem good at first, but should be discarded after finding that their "why" does not contribute to the objective.

Once I write the first draft of the mechanic, I correct it again and again, until I get a final version I can analyze further.

To analyze a mechanic its very useful to make a diagram of it, like the one below, where I write a step by step guide of the player experience.
Then I analyze each step of the experience, I can write things I need to avoid or correct, I can write what possible thing could happen, that's why from one box can grow many arrows that point to other boxes.

(the starting point is in yellow, the red things are things I need to avoid, the dark green part is the exit).

Besides the experience diagram, I also draw screen mockups with all the basic elements that could appear:

Well, that's it for today, I hope I created a better exploration experience, next week I'll start coding it.