Learning in the development process

Hi! My name is Gabriel Brasil and I have been working in the past few months in a game called Crack In. It was a University project, so it is, currently, just a MVP of what we plan to release. In the next lines, I’m going to be talking about what I learned in the process of development and some difficulties I found while developing it.

The Game

THINGS I SHOULD HAVE DONE BETTER.

While we were working on this game, we have been following the agile manifesto and we were using Scrum framework, so we have been working with the agile methodology in mind since the very first meeting.

KEEP THE RHYTHM OF WORK.

However, while in University our mind is not so focused to work on a project as a real company should do. We have a lot of stuff to do, work, some courses etc. I tried to keep the rhythm, but it was hard for me. Every day I had to do something in the project (the code itself) but do king of stuff, like essays, problem sets etc. Somedays I could not code at all, but I studied to learn something new.

TECHNICAL KNOWLEDGE.

Sure we made games before, but Crack In was the first time to demand all this new stuff we planned to implement in the game, like the Facebook integration, the Ads system, the rechargeable lives that should recharge even if the app was closed and a lot of other stuff (like working with matrices on the real world).

Sometimes I knew what to do, but I realized that I was doing a very complicated logic to something that could be easily done by a particular tool of the programming language or the engine itself.

COMMENTING THE CODE.

It’s a practice everyone should adopt – and most of experienced programmers never forget to do – is to keep his/her code with comments that will help the other members of the team figure out what you’re doing or even help you to find what you’re looking for easier later on.

At first, I commented every class I was writing, but then we did not have so many time and in a rush to code and finish everything I ended up forgetting most of stuff I did later. This made things worse in the future, because the project scope got bigger and when I had to change something I did weeks ago, I needed some time to read and remember how things used to work.  The comments would really speed up things a lot.

(always comment your codes!)

WHAT I LEARNED.

I learned a lot of stuff with the mistakes I did above, but there were also things I did not know I did not have to do wrong to learn.

USING PREFABS.

Sure, we used prefabs before (actually, every single game will need prefabs) but just for objects we needed to instantiate or have with equal parameters every single scene. However, I learned the  benefits from using prefabs in a way I did not realize before. Say, in the canvas, we have to use the canvas to show the HUD, to control the pop-ups and everything else and we were adding pop-ups, changing the HUD etc. all the time, and when we changed it we had to change on all stages. Using prefabs, we could easily change on stage 1 and apply and the canvas would change on all stages.

Prefabs, they are cool.

UNITY MONETIZATION SYSTEM.

We have never added ads or anything like that in our games. In this one, we defined from the beginning that we would add and ad system that would reward the player when he watched a video. I did not know how to work with Unity Ads, so that is something I learned while developing Crack In.

RESEARCH BEFORE DOING.

As said before, sometimes I knew how to do stuff but not in the better way. I learned developing Crack In that I should search many ways to do a thing I wanted to, analyze the pros and cons of each one before doing it, and think which of them would fit better in the project. I also had to analyze how it would behave later on since the project was going to get bigger).

Links: 

- Facebook
https://www.facebook.com/CrackInGame/

- Apk Donwload:

https://drive.google.com/file/d/0B4nuuk3LblMRYUdkR2piSmliUkU/view?usp=sharing