Recon Game Devlog 1

In the beginning there were two friends trying to make a very complex games, and they thought it was good. There were a lot of complications on the road, and the games split in two. The more they learned about game development, the more they thought on reducing the games’ complexity and scope. That’s how Dark Recon, a game that mixed shooting zombies and recognizing patterns, gave birth to a game focused on the artsy side of the coin.

Just like Dark Recon, Recon started life in XNA and then moved to Unity in 2013. The game is based upon the pattern-recognition mechanics needed to unlock doors and collect power-ups, and the work of Victor Vasarely.

victor vasarely 1976

Genius dude, Vasarely

The first attempt in XNA was coded by me, and then Christian took most of the coding responsibilities when we decided to go with Unity. In fact, we had good feedback on those iterations; so good that somebody was willing to invest in the development of Recon thanks to the prototype he coded. The following pictures show how the game used to look like (left) and how the grid was built (right).

Despite its flexibility, the grid editor wasn’t user-friendly, so we decided to re-structure the game and start the codebase from scratch. I was getting dragged understanding Christian’s code because I didn’t help build it in the first place, and at the time it was difficult for both of us to schedule knowledge-transfer meetings due to his departure from the team.

However, I had improved my programming skills (especially Unity and Unity editor) during my work at El Canto del Autana. That gave us the chance to reflect on previous achievements and mistakes, so most of the work was going to be focused on the level editor. After a while, I managed to get the first iteration of a new editor using the Scene view instead of the Inspector window.

Julián learned the new editor’s pipeline, and we spotted some serious flaws in terms of level design. Even I felt frustrated after some weeks not working on the project and trying to create a couple of boards/levels. Nonetheless, the fact that I also felt frustrated by the editor I built, plus Julián’s feedback, gave me enough insights on what to improve, what to change completely and what to prioritize in terms of keep working on the project.

Again, we need to iterate. There are parts that can be reused and other that cannot, but right now I’m a different game developer that understands that game development is an iterative and experimental process that usually means either compromising architectural design for faster iterations, and iterations can lead to complete code rewrites due to change of requirements. A previous version of me would be a little upset having to go back to the drawing board or try to come up with a flawless design at the first attempt in order to move forward. Now I understand that finding out something isn’t the solution, means moving forward in order to achieve a better game.

We can’t foresee the future and expect everything to work right away, that’s just plain stupid. We do our best in order to find balance between software architecture and delivering times, prioritizing the latter. It is the iterative process that will give us the experience to make it better next time; the next iteration, or the next game.

vasarely artwork

No Comments Yet.

Leave a Reply