[JeuxOnLine]

Uther a publié le 10 août 2023 cette actualité sur JeuxOnLine :

Citation :

Le studio Clockwork Labs affiche de haute ambition pour BitCraft : en faire un MMORPG massif et sandbox totalement confié aux joueurs, grâce à sa technologie SpacetimeDB. Le développeur en partage le code source sur GitHub.

On connait les ambitions du studio californien Clockwork Labs avec BitCraft : concevoir un MMORPG résolument sandbox, totalement confié à des joueurs ayant vocation à coloniser collectivement un monde ouvert, massif et modifiable. Dans Bitcraft, les joueurs...

Lire la suite

Une réaction ? Une analyse ? Une question ? Ce fil de discussion est à votre disposition.

[Niyuuki]

Je ne comprend pas trop l'interet. ça fait des années qu'on peut techniquement embarquer pas mal de logique metier directement dans les bases de données et que quasiment personne ne le fait parce que c'est un enfer à exploiter et à maintenir. En lisant un peu leur doc je ne comprend pas ce qu'ils sont sensé apporté de plus avec leur système.

['Az]

Citation :

Publié par Niyuuki

Je ne comprend pas trop l'interet. ça fait des années qu'on peut techniquement embarquer pas mal de logique metier directement dans les bases de données et que quasiment personne ne le fait parce que c'est un enfer à exploiter et à maintenir. En lisant un peu leur doc je ne comprend pas ce qu'ils sont sensé apporté de plus avec leur système.

Bah ils donnent leur réponse, même si je suis moyennement convaincu :

Citation :

This means that you can write your entire application in a single language, Rust, and deploy it as a single binary. No more microservices, no more containers, no more Kubernetes, no more Docker, no more VMs, no more DevOps, no more infrastructure, no more ops, no more servers.

Citation :

SpacetimeDB is optimized for maximum speed and minimum latency rather than batch processing or OLAP workloads. It is designed to be used for real-time applications like games, chat, and collaboration tools.

C'est juste une approche différente du problème. Au lieu d'avoir un service de gameserver qui query une BDD on a une BDD qui query des modules gameplay. Et ils peuvent optimiser leur base de données pour la spécialiser dans le temps réel, plutôt qu'utiliser des solutions toutes faites qui vont avoir des tas de features inutilisés qui, même optimisées, ont un coût en temps d'accès.
Si TOUT est centralisé à cet endroit, je pense pas que ça soit plus compliqué à exploiter/maintenir qu'une solution décentralisé. C'est plutôt plus facile, comme ils l'expliquent.
Personne ne le fait parce que les base de données standard sont pas prévu pour le faire de cette façon et avec ce type de contrainte.

Et surtout parce qu'à l'heure de la décentralisation ça devient super casse gueule parce que ça va ralentir la BDD dont les performances sont le nerfs de la guerre.

Je suppose que c'est leur réponse pour limiter les coûts en devops, qui sont des profils quand même assez rare et compliqué à recruter, surtout dans le jeu vidéo.

Maintenant, sur la viabilité du truc, hum... mais ça dépends vraiment de la quantité de problématiques qu'ils ont su anticiper et résoudre via leur solution.

Je m’interroge particulièrement sur leur capacité de faire du sharding, qui va être prédominante sur un projet de ce type. Va y avoir des zones de villes saturées de joueurs et d'activité et des zones de campagne avec 3 joueurs à l'heure qui se baladent par là. Et personne ne sait à l'avance où les joueurs auront décidé de se rassembler, donc tout ça doit être dynamique. J'ai bien du mal à voir comment ils vont s'y prendre, sans serveur central là pour répartir la charge.

J'ai tendance à penser qu'ils vont avoir bien des mauvaises surprises quand tout ça va passer à l'échelle, mais j'espère que je me trompe !

[Niyuuki]

Citation :

This means that you can write your entire application in a single language, Rust

On peut utiliser Rust pour faire des procédures sur PosgreSQL, par exemple.

Quelquechose m'échape peut-être, mais j'ai l'impression que c'est exactement l'objectif des frameworks, et là ils essayent de réinventer la roue dans un domaine technique vraiment très compliqué.

Cela ressemble à une architecture de microservices où chaque microservice doit être lié à une base de données unique. Ce qu'ils appellent "module" ressemble vraiment à un backend.

['Az]

Bah c'est pas toujours un gros mot de dire qu'on va réinventer la roue. Y'a plein de bon arguments qui vont dans ce sens.

Quand tu as des besoins qui divergent trop des solutions existantes, tu peux très bien avoir de meilleurs résultats en visant, de 0, exactement ce dont tu as besoin, plutôt que passer du temps à tweaker une solution toute faite pour qu'elle colle à tes besoins.

C'est déjà l'argument qu'ont ceux qui utilisent des moteurs maison plutôt que les classiques UE/Unity (et à raison !)

Là déjà t'as besoin de faire du temps réel à haute disponibilité et faible latence.

Un microservice, au sens "web" du terme, c'est un process à part. Qui doit communiquer avec une BDD et/ou un autre microservice. Souvent à l'aide de socket. Et un socket, par rapport à de la mémoire partagé, c'est affreusement lent.

Même avec un serveur centralisé unique + une base de données, l'architecture la plus simple qu'on puisse imaginer, t'as cette communication serveur/BDD qui va prendre du temps (et qui était d'ailleurs un bottleneck sur plusieurs projets sur lesquels j'ai bossé).

Tu peux faire des tonnes de benchmarks pour trouver LA solution existante parfaite, écrire des plugins, ce que tu veux, mais à quel moment tout ça deviendra plus coûteux en temps et en perfs que si t'avais tout fait from scratch ?
Si t'as une solution maison, tu sais aussi bien mieux jauger ses contraintes et ses limites qu'une BDD monstrueuse où tu finis fatalement par voir un bottleneck et te demander si tu vas pouvoir le résoudre ou si t'as simplement atteint les limites du système.

Et puis... c'est tellement plus fun à faire. Mine de rien c'est à prendre en compte. T'auras plus de facilité à motiver et mobiliser tes ingénieurs si tu leurs file un joli challenge technique que si tu leurs demandes de faire des mois de formation pour une tech existante.

Y'a pas de réponse universelle, mais en soit l'initiative d'écrire une BDD, c'est burné mais ça me choque pas.

EDIT : après avoir fait le tour de leurs docs, en fait j'ai l'impression qu'ils cherchent à monétiser la solution et se voient à moyen terme comme hosters pour des MMO qui utiliseraient leur techno. D'où l'open-source. Bon ben bon courage à eux, mais ça me vends vraiment pas du rêve J'ai des gros doutes sur la capacité de leur solution à tenir un truc de l'ambition de BitCraft.

[Skiiks]

Une des phrases de leur github qui semble intéressante :

Citation :

This speed and latency is achieved by holding all of application state in memory, while persisting the data in a write-ahead-log (WAL) which is used to recover application state.

Ce qui voudrait dire que tous les états de l'application sont traités et vivent sur la mémoire vive, puis persisté dans une BDD ? C'est pas un des points qui rendrait la techno vraiment intéressante par rapport à une BDD plus standard que tu viens query ?

Je précise que je ne suis pas du tout qualifié dans ce domaine, donc je dis surement des âneries.

[Niyuuki]

Citation :

D'où l'open-source

Attention, les sources sont dispo publiquement, mais ça n'est pas "open source".

Citation :

The Business Source License (this document, or the “License”) is not an Open
Source license. However, the Licensed Work will eventually be made available
under an Open Source License, as stated in this License.

Concernant ton message :

Citation :

Bah c'est pas toujours un gros mot de dire qu'on va réinventer la roue

Je pense qu'on est juste pas en accord sur la définition de cette expression. Je l'utilise surtout en designant le fait de repartir de zero pour arriver a un résultat similaire ou équivalant a quelque chose d'existant. (Une roue, c'est une roue). Et c'est l'impression que me donne leur projet, à prioris.

Citation :

T'auras plus de facilité à motiver et mobiliser tes ingénieurs si tu leurs file un joli challenge technique que si tu leurs demandes de faire des mois de formation pour une tech existante.

Perso je travaille dans la tech et c'est tout le contraire. Les entreprises qui font leur truc maison je les fuis comme la peste (et c'est quasiment toujours bancale). Après libre a chacun de faire ce qu'il veut hein, mais la si je me replace dans le context de BitCraft, ils cherchent vraisembablement a vendre leur outil de dev, donc il faut une plus value.

Citation :

Et puis... c'est tellement plus fun à faire [...] c'est burné mais ça me choque pas.

Si on sort du fait qu'ils veulent vendre leur truc, oui c'est marrant de faire des truc un peu exotique de temps en temps !

['Az]

Citation :

Publié par Skiiks

Une des phrases de leur github qui semble intéressante :

Ce qui voudrait dire que tous les états de l'application sont traités et vivent sur la mémoire vive, puis persisté dans une BDD ? C'est pas un des points qui rendrait la techno vraiment intéressante par rapport à une BDD plus standard que tu viens query ?

Je précise que je ne suis pas du tout qualifié dans ce domaine, donc je dis surement des âneries.

Bah ça c'est déjà plus ou moins le cas partout.
Heureusement que tu fais pas SELECT current_hp FROM Player WHERE id="xxx" à chaque fois que t'as besoin de voir les HP de ton joueurs Tu montes les données de la BDD en ram, et tu query la base de données quand tu veux mettre à jour ces données (et si y'a des accès concurrent tu t'assures que les données restent à jour, mais d'façons ils ont pas l'air de gérer les accès concurrent côté modules, c'est du single-thread only, ce qui me semble être une des grosses limitations de leur techno).

Un des trucs cool dans leur solution, c'est que c'est transparent pour le développeur : tu fais un "player.currentHp" sans te soucier du stockage, et leur moteur de base de données s'occupe de le mettre en cache, de quand le sauvegarder sur le disque, etc...
Mais sur ce point, comme le dit Niyuuki, y'a rien de bien nouveau dans tout ça. Leur originalité c'est qu'ils englobent beaucoup plus que ça à travers une solution tout en un.

Citation :

Je pense qu'on est juste pas en accord sur la définition de cette expression. Je l'utilise surtout en designant le fait de repartir de zero pour arriver a un résultat similaire ou équivalant a quelque chose d'existant. (Une roue, c'est une roue). Et c'est l'impression que me donne leur projet, à prioris.

Ouais non là je suis pas d'accord, y'a quelque chose de vraiment pertinent dans leur démarche. L'idée c'est de dire : "vous êtes des gameplay developpers, vous y connaissez rien en réseau, en backend, en database, en devops ? Utilisez notre truc, y'a rien à connaître et presque rien à faire". Et pour le coup ça me semble vachement pertinent dans certains cas. Genre par exemple des petits jeux mobiles temps-réel-mais-pas-trop pour lesquels y'a pas trop de contraintes de haute disponibilités, de real time ni de congestions de joueurs dans des espaces localisés, mais qui voudraient quand même proposer un monde persistent.

Par contre, pour gérer un truc comme BitCraft en considérant la roadmap qu'ils présentent, j'ai des doutes.

[Skiiks]

Citation :

Publié par 'Az

Bah ça c'est déjà plus ou moins le cas partout.
Heureusement que tu fais pas SELECT current_hp FROM Player WHERE id="xxx" à chaque fois que t'as besoin de voir les HP de ton joueurs Tu montes les données de la BDD en ram, et tu query la base de données quand tu veux mettre à jour ces données (et si y'a des accès concurrent tu t'assures que les données restent à jour, mais d'façons ils ont pas l'air de gérer les accès concurrent côté modules, c'est du single-thread only, ce qui me semble être une des grosses limitations de leur techno).

Un des trucs cool dans leur solution, c'est que c'est transparent pour le développeur : tu fais un "player.currentHp" sans te soucier du stockage, et leur moteur de base de données s'occupe de le mettre en cache, de quand le sauvegarder sur le disque, etc...
Mais sur ce point, comme le dit Niyuuki, y'a rien de bien nouveau dans tout ça. Leur originalité c'est qu'ils englobent beaucoup plus que ça à travers une solution tout en un. [...]

Ok, merci pour les précisions