Matias Beckerle

A random thought on tech leaders

Technical leaders don't have any reason for not sharing their code with their fellows.

  1. They also make mistakes.
  2. Due to their technical expertise, they are also educating with the example.
  3. Sharing code changes will make other fellows aware of what recently happened and why.

I'm not a TL. This is my point of view as a developer.

I asked a colleague of mine (a TL, someone which I really admire) and not only confirmed what I was thinking but also told me that even if you're in a hurry, you should create a pull request for your teammates. You need to merge it immediately, but your fellows can take a look and be aware of.

We should not even speak about commiting directly into develop/master and don't let anyone know about it, like if Git doesn't have a history to look for... come on, we can do it better!

by the Sea meetups

Last couple of months I have been inspired by several people which I had the pleasure to know. It wasn't really obvious until a normal day I figured it out: sharing.

Some folks were involved in a new project they started with the purpose of sharing knowledge, using the meetup format which they called by the Sea because we are living in a city near to the coast.

At some point they offered me to expose any topic I want so we can all discuss and learn from each other. Why not? I decided to give some advice about the things no one told me before the first day at work.

If you missed it, you can watch it here on YouTube.

So the whole point is to share. Wherever you are, even if it seems insignificant. Don't be afraid, someone could learn from that. You learned from someone. I learned from someone. There is someone out there who might learn from you.

Follow by the Sea on Facebook or Twitter.

The things no one told me before the first day

The things no one told me before the first day

The things no one told me before the first day

Thanks to Marian, Farza and Ulrich for helping me.

Pictures taken by Fede and someone else.

The Talos Principle

The answer that came to me again and again was play. Every human society in recorded history has games. We don't just solve problems out of necessity. We do it for fun. Even as adults. Leave a human being alone with a knotted rope and they will unravel it. Leave a human being alone with blocks and they will build something. Games are part of what makes us human. We see the world as a mystery, a puzzle, because we've always been a species of problem-solvers.

- From The Talos Principle.

I've recorded the audio but I'm not the owner (please look at Croteam and Devolver Digital).

I didn't finish the game yet but I already love it. I started this new year playing that part and it feels like I've found a missing piece. Thanks to everyone involved in developing this masterpiece.

If you got the chance please play this video game. You will never regret it.

The making of PERSPEkTIVA

Before I start, you can download and play the game using the following link:

. . .

This year I failed too many times to conceive a video game. During mid August I decided to start again from level 1: learn the basics as expert people recommends. And they were right, so right.

If you are a beginner gamedev as me (it doesn't matter if you are already experienced with coding) you need to do this first. Trust me, because starting to make a video game is easy, finishing it is not. Finishing it is the most difficult part.

My primary objetive was to make a classic or something with fixed and small scope. Mechanics, aesthetics, sound, music, menus, polish, testing. Everything like a pro video game but without the PR work because I didn't want to sell it, just learn from it.

A breakout-like video game seemed the best fit for me. I chose to open source it. If it helps you, please use it.


PERSPEkTIVA was released only a week ago but here they are. Take into account the video game wasn't really exposed.

  • 222 store views.
  • 2 Linux, 1/5 Mac, mayority Windows. I can't be precise because I released two different versions and I lost the first numbers.


I finished the whole gameplay within the first two or three weeks. The remaining time was aesthetics, sound, music, effects, polish, testing and publish-related tasks. This point is interesting because I didn't expect more time doing polishing than the gameplay.

What went right

  1. The final result is nice. Yeah, I'm glad of what I achieved. It is not perfect but it feels funny and enjoyable. I finished the game which it was the whole sense of making it.
  2. Round two for aesthetics. Everyone who knows me know that I can't draw a single pixel. At the beginning the video game had another set of colors and aesthetics in general. Luckily at some point I decided to spend more time on it. The final result is prettier than before, I know is not a big deal but... was made by a programmer (doesn't look so bad, right?).
  3. The worst bug lead me to an interesting mechanic/feature. At an early stage you couldn't go for slow motion and shoot the ball to a random location after releasing a button. The truth is that I was trying to fix the worst bug where the ball doesn't bounce as expected. Once the player enters in that mode the game turns boring. I though: "Ok what will happen if the player has the possibility of apply a random force to the ball?" Then the feature was born.
  4. Music. I had the luck of finding an amazing artist as Secheron Peak who gave an entire album under the Attribution-NonCommercial-NoDerivs 3.0 Unported license. I strongly recommend to listen the whole Slow Gravity album. I think the music fits amazingly with the aesthetics of PERSPEkTIVA.
  5. Platform support. The video game seems running nice on Windows, Linux and Mac. All the credit goes to Unity, I almost didn't make anything.
  6. Unexpected help/promotion. I didn't exposed the video game through specialized magazines, forums, websites, youtubers or ads. But I made a few publications on social networks and dev forums. It was nice to see people retweeting or talking. Thanks to everyone of you, I really appreciate that.

What went wrong

  1. Bugs. There were 3 important bugs. The worst was the one I already told in the "what went right" part of the post. The second is still happening I believe. It is really weird and I can't reproduce it. I think it could give a bad impression to anyone who discovers it. The third one was about performance. I took all the considerations to make the video game really fast and to work nicely on slower machines. I even used the profiler. Everything seemed really good until I noticed an unexpected FPS drop on the ball camera in computers without graphic cards. I thought it was related with that at first. I launched the game knowing it. Then I decided to review it again and there it was! An unwanted setting in the ball camera. Lesson learned: if you know something is wrong, don't discard it quickly as it is the fault of something/someone else.
  2. Testing. I didn't make any exhaustive testing, specially on Linux and Mac. Mostly because I develop on and use Windows. Tests were through friends. Thanks to all of you! Lesson learned: for the next project I will try to have some virtual machines at least.
  3. Announcement error. I was preparing a post for Indie DB but I misunderstood the platform. Almost 300 visits saw the announcement one week before the release, without the possibility of playing the game. Lesson learned: I don't know... the UI of the platform didn't indicate properly what will happen. I guess I didn't see something important and it was my fault.


Seeing this in retrospective I can say that it was a complete success! At least in what involves to complete my objectives. I learned a lot and that was the whole point.

  • Art is more important of what I thought. Basically, without artists you can't make anything. I could handle PERSPEkTIVA without an artist for graphics because I used primitive figures with solid colors (no textures). But what about my next game? I'm in trouble.
  • When I started adding effects everything becomes more delightful. I think it is because you start to feel the game is almost complete, so you want to play it entirely, share it.
  • It is not everything about doing the game. You will need time to test it, write about it, prepare animated GIFs, get feedback, etc.
  • Being a solo dev is hard. Everything demands you time and it becomes worse when you have a full-time job. Things could go wild. I spent the majority of the development time on weekends. At some point you got obsessed... it is a strange feeling. Like if you only want to spend time doing your game. That is good and bad at the same time. Good because you love the game, you trust on it. Bad because makes you an outsider and you stop taking care of other stuff. You need to balance your life.

. . .



The solution is out there

You may be guessing that I'm re-watching too many episodes from The X Files. That's correct but I'm not going to talk about the series. Today is about something that I learned several years ago and still happens to me.

Last week was a mind exhaustive one. I couldn't put any time in my current personal project. Yesterday was Saturday so I decided to spend some time coding on it. It was really great because in 3 or 4 hours I have achieved a good progress and a funny bug too:

One does not simply 'shake it off' the camera

One does not simply "shake it off" the camera. That one was fixed already, don't worry.

Today I spent some time developing too but without any achievement. It was hard to recognize but I spent similar amount of time just to achieve not even a single commit. When the problem was taking too much I chose to abandon for some time. The problem won the battle but not the war. The idea was to take some air, relax and come back when my mind is clear.

Luckily 10 minutes after leaving the PC and while taking a shower the solution came to my mind. I was seeing the problem from the wrong angle. Simple as that. If you are struggling with something maybe is time to take a break and come back after. I've found that viewing the problem with a clean mind helps to find solutions. I'm not the only one saying it: several people from different communities says the same thing.

Some things requires time. It's pretty similar to an architect: building the foundations for a house requires a natural time for the materials to settle. That's why I do not support working extra/exhaustive amount of time. In the short time everyone loses, not only you for pushing yourself harder and harder. While crunching you are contributing to build an unmaintainable and unusable software thing. At the end everyone asks: why? Inside and outside the team people blame other people. Why don't you look at yourself and think for a while? Please have the courage. You will find the answer.