I have been dreaming of building simulation games recently. My foray into sim racing has made me think a little about the shortcomings of some of my favourite sims. I’m not planning on going into detail about that in this post. Still, I did stumble upon a game developer on Twitch busy developing a simulation game and he’s had some fascinating insights.

The Master

This developer is Stefano Casillo, one of the co-founders of Kunos Simulazione, and he has a wealth of experience in building racing simulation games. He’s recently announced that he left Kunos and he’s starting up a new studio to work on something else outside of the sim racing world. His latest project is a catamaran racing game, and he’s made quite a bit of progress, but what’s cool is that he streams development of the game on his Twitch channel. He’s also still doing some work on the AI for Assetto Corsa Competizione which is also quite insightful. I struggle to follow the details if I put his streams on as background noise while working, but I’ve enjoyed watching him work.

Stefano is one of those hardcore developers who’s able to pull from a career of game development to solve various problems he faces. He’s shown a bit of an aversion to using a 3rd party game engine for building games, but he already knows how to solve most of the problems so he can build everything as and when he needs it. On one of his recent streams, Stefano was implementing wind gusts, and visually it was having quite an effect on the catamaran. I asked in the chat what his approach was towards building this and if he was following some generic architecture, to which he gave quite a simple answer. He knows the number of entities in this game will be very limited, so there isn’t a requirement to generically compose pieces of game logic together.

Constrained Game Development

I had previously written about constrained game development, and I focused a little on some of the tools that I felt lent itself nicely towards the approach. I see that Stefano manages to use his experience with game development to work within a constrained space. Fancy architectures and generic engines can do a lot in terms of providing a big toolbox that allows people less technically inclined to build some fantastic stuff. For a programmer like me who fixates on clean and re-usable code, it can serve as quite a burden when trying to make things from scratch.

Many times I’ve told people don’t go out and build an engine, but rather focus on making a game. It’s easy to over-engineer a purpose-built engine if you don’t already know how to use the various libraries that take care of stuff like physics and rendering. If you are comfortable with the various libraries and you know how to constrain what you’re building to just what you need, it can be very freeing as a programmer to make games. I don’t believe this will be the way to go if you have people less technically inclined, but there will be some trade-offs.

Conclusion

Making games is a difficult thing to do. Finding ways to make things simpler can be a very freeing experience. My reliance on Unity has been very apparent in the many attempts I’ve made previously. Still, I’m starting to think of ways to try and throw off the shackles and avoid getting stuck in the giant sandbox that is Unity. MonoGame is looking like the best candidate, especially given that my cousin and I are both software engineers who prefer digging through code. Stefano has been a massive inspiration to me, and I’m excited to see what we can do.

I’m hoping we get an opportunity to try out something very soon, and I hope to find it more satisfying compared to the frustration of feeling very lost when I’m trying to do something specific, only time will tell.