Matias Beckerle

The Witcher or...

...one 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.

Conclusion

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.

Multiplayer game with Node.js and Pixi.js

I have been reading about networking for some time because multiplayer games are really fun. There is a few models to choose which one fits better for your game but I decided to try with server/client model.

I couldn't find an entire example (code) for what involves making a server/client multiplayer game but I've found a really useful information. These links really helped me to understand what was going on behind the scenes:

So I decided to try something just for learning purposes and the result is kind of good, actually. I could achieve something! Yeah, not a big deal but it was helpful to understand these things.

I've developed a game (?) under authoritative server and interpolation concepts. I don't know if is fair to call it a game because it isn't fun. It is more like a proof of concept. The code is entirely written in JavaScript because I wanted to learn about Node.js too.

Server/Client model

The Node.js server sends snapshots of the current game state to all the connected players several times per second, using a small structure to identify uniquely each instance of the game objects. Is responsible of keeping the game alive and serving the resources too.

The client was developed with Pixi.js 2D game engine. Consumes the snapshots provided by the server and handles all the game objects (populated with the game engine information) in the scene.

The communication between both sides is handled by socket.io.

Code and game

  • You can play the game in Heroku where is hosted by free. Try the multiplayer stuff opening two browser tabs.
  • The code is available at GitHub. Take a look, I hope it helps!
  • More information here.

Disclaimers

The assets being used are from Doom. None of them are from my property. I hope id Software doesn't take it bad. I'm trying to reach them to let them know about it. I've choosed them because are such an inspiration for me and they rock!

Take into account that anyone who wants to make a fast-paced multiplayer game would need to handle a LOT of things that I'm not showing here. The interpolation in this example is like a joke, seriously.

Please don't take anything as a rule because it could be wrong. Maybe there are better solutions. Remember, is my first time with networking and I'm kind of a newbie with game development. I've just wanted to share a code that is working.

They know how

There is a reason for categorizing some game companies like Blizzard, id Software and Valve of being the best. They know how to make things right and epic. They even doesn't have release dates for their games. A game is "done when it's done".

A place that does not exist

This week Diablo 3 has its third birthday and if you are playing these days you will find some strange stuff, like cows. Lot of cows.

Ghost of the cow king

At the beginning there was a lot of expectations and rumors about if we could ever see again the cow level. Even when you had to wait to load a campaign... a subliminal message mentioning the cow level appeared.

But in this week we have our lovely cows in this game too. Blizzard delighted us with an excelent demostration of being awesome.

The cow queen

Finally the time has come. Enjoy. Thanks gstn to let me know about this. Thanks Blizzard too, just for being awesome.

Are you really willing to test?

If the answer is no then you should leave it. Don't writing tests is preferable than writing bad tests because you start to lose trust in the code when you discover the first one not-so-successful-test.

Another bad thing about unit testing is when you don't keep it updated. That's wrong because everyone in your team or even you start to get lazy. The testing start to fall little by little.

There is a lot to say about unit testing but I'm not deep qualified in the matter to talk about it. I prefer to leave you with some questions to identify bad unit tests:

  • It takes a lot of time? A unit test should run really fast. Maybe you're not faking everything. Integration test is coming to my mind.
  • You have to execute the tests in a particular order? Sounds like a dependency.
  • Running tests individually (or isolated) to achieve greenlight? Could be a particular one messing with your setup.