Matias Beckerle

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.

The Witcher or... of the best games that I've ever played. For so long I have been far away from video games that now I'm kind of disappointed with myself. That's why I'm playing a game from 2007. What an amazing game. I wanted to say thanks to everyone involved in the development. Thanks for letting us put on the skin of Geralt of Rivia. Thanks to my bearded friend for recommending the game.

The Tower

Creating a nice pull request

Working in a team requires more than development skills. You need to push yourself harder and try to imagine what your fellow needs. On a team there are pull requests. Here is the GitHub's definition:

Pull requests let you tell others about changes you've pushed to a repository on GitHub. Once a pull request is sent, interested parties can review the set of changes, discuss potential modifications, and even push follow-up commits if necessary.

Seems easy, right? Well... that is not true for all teams. Sometimes I see pull requests without information.

Asking a review

To create a good pull request I will give you some useful advices (in my opinion):

  • A short title with a meaningful overview of what are you trying to introduce in the codebase. This title could also contains a code for reference.
  • Descriptions are awesome. With a description you could explain a little more your changes, give a substantiation for a specific solution, advice or warning about something. Provide context, your mate possibly doesn't know anything about your tasks. Remember: your teammates are busy too, the more information you give, the less time you consume of them.
  • Mention the reviewers. Don't be anxious: pull requests are async. They will take a look only when found some time to do it.
  • Answer in the pull request, always. If you talk by private messages another fellow will not know about that talk. A response is useful for everyone. Also serves as a registry.
  • Don't take a correction or suggestion as an offence. I believe every developer in the world want to work in a wonderful codebase. Corrections and suggestions are to keep or improve that.

Making a review

  • Be polite, always.
  • Sometimes a quick example in pseudo code could be more valuable than a thousand words.
  • Ask for more information if you can't understand the whole meaning of a change.
  • We know bad code happens but wait: there is awesome code too. Give your fellow a congratulation when achieves something valuable or that deserves a recognition. A proper emoticon could help too.


A code review is useful for anyone. Yes, tech leads can't know everything. Pull requests and code reviews serves to everyone for different reasons:

  • You can let everyone know about your changes.
  • You can learn from others.
  • Others can learn from you.
  • The codebase grows solid and better.

Finally remember that you are the owner of the code introduced by a pull request. When sometimes goes wrong, you are responsible.

. . .

Some time ago I read a really good post of Mark Seemann. I strongly recommend you to read it because he mention important things to take care on creating a pull request.

Thanks to Andrés for all his wisdom.