Joost van Dongen's Expert Blogs
A lot of people feel insecure about the way they they create. In the past I never dared record the cello songs I wrote. This post is about setting aside my creative pride and focusing on the result instead of on whether I consider my methods 'cheating'.
Most major platforms offer similar generic room-based matchmaking. In this post I explore how they work and discuss the pros and cons of using these systems instead of building your own from scratch, based on our experience developing Awesomenauts.
We did a very bold experiment: we let people play whatever game they wanted and we improvised a live soundtrack based on what happened on the screen. In this post I explain our approach and what we learned about what works musically and what doesn't.
Good matchmaking requires thinking about what your game really needs, and maybe even redesigning some aspects to make matchmaking work. This post explores which things to consider and why you need to limit requirements to avoid endless waiting time.
We did a couple of live stage performances where we improvised a new soundtrack to someone playing Journey and Ori And The Blind Forest. This post shares a video compilation of the performance and explains our approach and what did and didn't work.
Reading code from your team members is easier and faster if all code adheres to the same formatting and naming conventions. Also, some C++ code constructions are better avoided altogether. That's why we have a rather strict coding style guide at Ronimo.
Building large codebases requires a structured way of working. This post discusses the coding methodology used at Awesomenauts devs Ronimo. It shows the methodology document we use internally and explains the reasoning behind some of the rules in it.
[Previous Joost van Dongen Blogs]