ERIC PRIEPKE

Software developer et programmeur principal de l’architecture interactive de Barrels of Fun

Eric Priepke occupe une fonction centrale dans les quatre premières machines commerciales de Barrels of Fun. Jim Henson’s Labyrinth, Dune, Winchester Mystery House et Bon Jovi changent de designer, de rules designers, d’univers et parfois d’organisation créative, mais son nom reste associé au software ou au coding. Cette continuité en fait l’un des principaux artisans de la cohérence logicielle construite par le fabricant depuis son lancement commercial.

Son travail se situe au point de rencontre de disciplines qui restent pourtant distinctes. Le game designer définit l’architecture physique du jeu. Les rules designers organisent objectifs, progression, scoring, modes et stratégies. Les équipes artistiques, audio et animation produisent les contenus. Priepke doit transformer cet ensemble en un système capable de suivre l’état de la machine en temps réel, commander les mécanismes, déclencher les séquences audiovisuelles adaptées, gérer les priorités lorsque plusieurs événements se superposent et restituer au joueur une réponse immédiate.

Cette fonction prend une importance particulière chez Barrels of Fun. Les machines du fabricant utilisent de nombreux mécanismes motorisés, aimants, displays multiples, éclairages dynamiques, effets sonores réactifs et séquences visuelles qui ne peuvent fonctionner comme des éléments indépendants. Leur intérêt dépend de la façon dont le logiciel les coordonne avec les règles et avec la bille. Priepke ne dessine donc pas les playfields de Labyrinth, Dune, Winchester Mystery House ou Bon Jovi, mais son code détermine une part essentielle de leur comportement une fois la partie lancée.

Carte d’identité

Barrels of Fun | Une fonction structurante dès le premier jeu

Jim Henson’s Labyrinth place Eric Priepke au software dès la première machine commerciale de Barrels of Fun. David Van Es signe le concept et le game design, Travis Moseman intervient sur l’ingénierie et la mécanique, Phil Grimaldi et Bowen Kerins travaillent sur les règles. Priepke doit faire fonctionner cette architecture collective comme un seul système.

Le défi dépasse largement l’enregistrement des scores ou l’allumage des inserts. Labyrinth combine des mécanismes physiques nombreux, des aimants, des diverters, des targets, plusieurs séquences thématiques, de l’animation, des callouts et un environnement visuel étendu au back panel. Chaque élément doit réagir au bon état du jeu et conserver une logique lorsque plusieurs objectifs progressent simultanément.

Cette première machine établit déjà la nature de son poste chez Barrels of Fun. Priepke n’est pas présenté comme rules designer principal ni comme game designer. Son rôle consiste à prendre ces architectures et à les convertir en comportement logiciel exploitable par une machine physique.

Jim Henson’s Labyrinth | Implémenter un ruleset d’aventure

Labyrinth demande au joueur de traverser progressivement différentes situations issues de l’univers du film. Cette structure convient naturellement à une machine narrative, mais elle impose au programme une grande quantité d’états intermédiaires. Le logiciel doit savoir ce qui a été commencé, ce qui a été terminé, quels objectifs sont disponibles, quelles informations doivent être affichées et quels événements peuvent être empilés.

La difficulté augmente parce que la machine repose fortement sur sa matérialité. Le code ne déclenche pas seulement des animations. Il doit également piloter des éléments physiques dont le comportement réel peut modifier le timing prévu. Une bille retenue, libérée, déviée ou déplacée par un mécanisme ne respecte pas toujours une durée parfaitement fixe.

Priepke doit donc gérer en permanence la relation entre état logiciel et événement physique. Cette contrainte distingue fondamentalement le programme d’un flipper d’un jeu entièrement numérique : l’ordinateur décide, mais la bille conserve une part d’autonomie.

Labyrinth | Un lancement ambitieux et un développement prolongé

Labyrinth arrive sur le marché avec une architecture déjà très ambitieuse pour un premier titre. L’ampleur du ruleset, la quantité de contenus et la sophistication des mécanismes donnent immédiatement de la profondeur à la machine, mais le jeu continue aussi d’évoluer après sa sortie.

Cette progression post-lancement constitue l’un des traits que l’on retrouvera ensuite chez Barrels of Fun. Le software n’est pas traité comme un bloc figé au moment de l’expédition. De nouvelles fonctions, améliorations et contenus peuvent être intégrés après commercialisation.

L’avantage est évident pour la longévité. La limite l’est tout autant : une machine peut atteindre son meilleur niveau logiciel après les premières livraisons plutôt qu’au jour où les premiers clients la découvrent. Le travail de Priepke doit donc être évalué à la fois sur la richesse finale obtenue et sur l’état du produit aux différentes étapes de son développement.

Software et rules design | Transformer les règles en comportement

Le travail avec Phil Grimaldi et Bowen Kerins sur Labyrinth puis Dune illustre particulièrement bien la séparation entre rules design et programmation. Une règle peut être décrite sur le papier avec beaucoup de clarté et devenir nettement plus complexe lorsqu’elle doit cohabiter avec tout ce que le jeu fait déjà.

Un multiball peut démarrer pendant un mode. Une ressource peut être gagnée alors qu’un autre système attend une validation. Une bille peut entrer dans un mécanisme au moment où une transition audiovisuelle doit commencer. Deux événements peuvent demander simultanément la priorité sur l’écran ou sur l’audio.

Le software doit résoudre ces situations sans exposer ses arbitrages au joueur. Lorsque le système fonctionne correctement, le résultat paraît naturel : le bon événement arrive, la machine réagit et la progression continue. La complexité du travail apparaît surtout lorsque cette cohérence disparaît.

2025 | Dune | Une architecture logicielle beaucoup plus dense

Dune élargit fortement le champ d’action du software. Le jeu associe plusieurs progressions parallèles, des ressources, des cycles, des items, des modes, différents multiballs et de nombreux états intermédiaires. Phil Grimaldi et Bowen Kerins construisent les règles, David Van Es et Travis Moseman le game design, tandis que Priepke assure leur implémentation logicielle.

La densité du système change directement la nature du travail. Dune ne se contente pas de faire avancer une succession de modes. Plusieurs couches peuvent être préparées ou exploitées en parallèle, avec des interactions entre ressources, états du playfield et opportunités de scoring.

Le code doit donc suivre un grand nombre de variables sans perdre la cohérence de l’ensemble. Cette capacité participe largement à la profondeur du jeu, mais elle contribue aussi à sa principale difficulté : Dune peut demander beaucoup au joueur avant que la logique globale de ses systèmes devienne immédiatement lisible.

Dune | Cycles, ressources et états simultanés

Le cycle jour / nuit donne un bon exemple de cette architecture. Il ne s’agit pas seulement d’un changement visuel. L’état du cycle intervient dans la manière dont certaines ressources et opportunités sont abordées. Le software doit conserver cette information, la communiquer et synchroniser plusieurs réactions de la machine avec son évolution.

Les ressources ajoutent une autre couche. Eau, épice et objets doivent être comptabilisés, affichés, utilisés ou conservés selon les systèmes concernés. Le joueur n’a pas besoin de connaître la structure interne des variables pour jouer, mais chaque interaction doit rester cohérente avec son état réel.

La qualité de cette architecture repose sur la continuité. Une erreur de synchronisation, une ressource mal actualisée ou une transition incorrecte peut remettre en cause la compréhension d’une stratégie entière. Sur une machine aussi dense, la stabilité du software devient donc directement liée à la qualité du ruleset perçu par le joueur.

Dune | Intégration du sound design de Jeff Dodson

La collaboration entre Eric Priepke et Jeff Dodson montre particulièrement bien ce que le code ajoute à une discipline externe. Dodson peut créer un excellent effet sonore, mais le fichier n’acquiert sa fonction de gameplay qu’une fois associé au bon événement et déclenché dans les bonnes conditions.

Les spinners de Dune en donnent un exemple révélateur. Leur réponse sonore doit suivre des activations extrêmement rapides. Priepke et Dodson travaillent sur le retrigger afin que la succession d’impulsions reste perceptible sans transformer le son en masse indistincte. Le comportement final dépend à la fois du design du fichier audio et de la façon dont le code gère sa répétition.

La même logique intervient dans les jackpots, les ressources et les callouts. Certains événements doivent momentanément prendre le dessus dans le mix, d’autres doivent rester secondaires. Le programme ne compose pas le son, mais il établit quand celui-ci intervient et quelle place l’événement occupe dans la hiérarchie de la partie.

Dune | Audio comme interface invisible

L’un des résultats les plus intéressants du travail Priepke / Dodson est l’utilisation du son comme interface. Dune peut confirmer la collecte d’une ressource ou un changement d’état sans obliger le joueur à consulter immédiatement un display.

Cette méthode exige une programmation rigoureuse. Le feedback sonore doit correspondre exactement à l’action enregistrée par le jeu. Une réponse retardée, ambiguë ou déclenchée dans un état incorrect détruirait la confiance que le joueur peut accorder à cette information.

Le logiciel joue donc ici un rôle d’interface sans afficher un seul pixel supplémentaire. L’information existe parce que le code relie l’événement physique, l’état des règles et le fichier sonore correspondant.

Dune | Animation et environnement dynamique

Les animations de Joshua Clay et Trent Armstrong ajoutent une autre couche à cette architecture. Le lower display peut présenter Arrakis, les Harvesters, les Ornithopters ou différentes conditions liées à la progression. Ces contenus ne fonctionnent pas uniquement comme des vidéos lancées depuis un menu.

Leur intérêt dépend du contexte de la partie. Le code doit déterminer quelle animation est pertinente, quand elle peut apparaître, combien de temps elle peut rester visible et ce qui doit l’interrompre si un événement plus important survient.

Cette gestion des priorités est essentielle sur un jeu moderne. Un écran peut simultanément devoir transmettre le score, une règle, un jackpot, un tutoriel, une transition et un élément narratif. Le software doit arbitrer entre ces usages pour éviter qu’une animation spectaculaire masque l’information dont le joueur a besoin.

Dune | Richesse logicielle et charge cognitive

Dune représente probablement le projet le plus dense de Priepke parmi les premières machines Barrels of Fun. Sa richesse constitue une qualité majeure : la machine offre plusieurs axes de progression, beaucoup de possibilités de construction et une quantité importante de découvertes sur le long terme.

Cette densité montre aussi les limites d’une architecture sophistiquée. Le code peut parfaitement savoir ce qui se passe sans que le joueur le comprenne aussi vite. Lorsque plusieurs ressources, cycles, modes et objectifs cohabitent, l’interface doit convertir cette structure interne en information exploitable.

Le travail de Priepke ne peut donc pas être évalué uniquement par la quantité de systèmes implémentés. La réussite dépend également de leur visibilité, de la rapidité avec laquelle le jeu communique ses changements d’état et de la cohérence de leurs interactions. Dune atteint un niveau élevé sur cette architecture, tout en restant plus exigeant à lire que les machines plus immédiates du catalogue.

2025 | Winchester Mystery House | Changer de designer sans changer de colonne vertébrale logicielle

Winchester Mystery House constitue un test important pour l’organisation de Barrels of Fun. Karl DeAngelo remplace David Van Es au game design principal, tandis que Priepke conserve la responsabilité du software. Le fabricant peut ainsi introduire une architecture physique et une sensibilité différentes sans reconstruire entièrement sa culture logicielle autour d’un nouveau programmeur.

Cette continuité joue un rôle structurant. Les outils, systèmes et méthodes développés sur Labyrinth et Dune peuvent servir de base à un troisième produit, même si la machine ne joue pas de la même manière. Le software devient progressivement une infrastructure de studio et plus uniquement le code d’un jeu isolé.

Winchester repose sur une expérience plus atmosphérique et sur une exploration du manoir, avec des zones, événements et interactions qui doivent conserver leur propre identité. Le rôle de Priepke consiste à adapter l’architecture logicielle à cette nouvelle logique sans forcer le jeu à fonctionner comme Dune.

Winchester Mystery House | Programmer une machine moins systémique

La différence avec Dune est importante. Winchester n’a pas besoin d’accumuler la même quantité de ressources ou de cycles parallèles pour exister. Son intérêt vient beaucoup de l’atmosphère, de la progression à travers le manoir et de la manière dont les événements sont mis en scène.

Le software doit donc changer de priorité. Une architecture très dense ne serait pas automatiquement meilleure. La programmation doit soutenir le rythme voulu par Karl DeAngelo et laisser les séquences visuelles et audio installer leur ambiance.

Cette adaptation montre une qualité importante dans le travail de Priepke : le code ne semble pas chercher à imposer une structure unique à tous les jeux Barrels of Fun. Labyrinth, Dune et Winchester utilisent le software avec des ambitions différentes, même si une même logique technique les relie.

Winchester Mystery House | Collaboration avec Jeff Dodson

Winchester donne également plus de place au travail audio de Jeff Dodson, qui signe musique, sound design et direction des voix. Priepke doit intégrer cet ensemble aux différents événements de gameplay.

L’audio est particulièrement important dans une machine construite autour d’un lieu hanté. Les sons d’ambiance, voix et effets peuvent préparer un événement avant même qu’un mécanisme ne bouge. Le code doit donc gérer autre chose qu’une réponse immédiate de type switch / effet.

Certaines séquences nécessitent des transitions, des interruptions ou des priorités différentes selon l’état de la partie. La programmation participe directement à la continuité de l’atmosphère, même si les assets et leur direction sonore restent le travail de Dodson.

Winchester Mystery House | Une machine plus lisible mais plus fragmentée

Le software de Winchester bénéficie d’une structure généralement plus accessible que celle de Dune. Les objectifs sont moins nombreux à suivre simultanément et la machine impose moins de gestion parallèle au joueur.

Le revers vient plutôt de la structure physique et du rythme du game design. Certaines zones et séquences coupent la circulation, tandis que plusieurs interactions fonctionnent davantage comme destinations distinctes que comme éléments d’un grand flow continu.

Le code ne peut pas supprimer cette caractéristique sans modifier le design lui-même. Son rôle consiste à exploiter correctement l’architecture fournie par DeAngelo, synchroniser ses états et maintenir la progression. Winchester illustre donc bien les limites de responsabilité d’un programmeur : le software peut renforcer ou affaiblir un design, mais il ne remplace pas sa géométrie.

2026 | Bon Jovi | Le software comme conducteur d’un concert interactif

Bon Jovi change une nouvelle fois le problème. David Van Es reprend le game design, Phil Grimaldi et Jess DeNardo développent les règles, Eric Priepke assure le coding. Le quatrième jeu Barrels of Fun repose cette fois sur dix-sept chansons et sur une progression organisée autour de la construction d’une setlist et de l’évolution d’un concert.

La musique impose des contraintes de programmation particulières. Une chanson suit sa propre durée, mais la partie ne respecte pas une chorégraphie fixe. Le joueur peut rater un tir, accélérer une progression, déclencher un mécanisme ou démarrer une séquence importante pendant que le morceau continue.

Le software doit donc gérer la relation entre la timeline musicale et une timeline de gameplay imprévisible. Cette coordination devient encore plus complexe lorsque lumière, animation, crowd effects, mécanismes et scoring doivent évoluer en relation avec la chanson.

Bon Jovi | Setlist et architecture de progression

Le ruleset construit par Phil Grimaldi et Jess DeNardo repose sur la sélection et la construction progressive d’une setlist. Priepke doit traduire cette structure en états de jeu, conserver la progression et gérer les transitions entre les différentes phases.

Cette architecture demande une attention particulière à la persistance interne d’une partie. Le jeu doit savoir quels morceaux ont été joués, quelles performances ont été accomplies, quelles récompenses ont été obtenues et quelles possibilités restent ouvertes avant les différents Encore.

La complexité ne vient donc pas nécessairement du même type de systèmes que Dune. Bon Jovi utilise moins l’idée de ressources imbriquées pour organiser une expérience fondée sur la succession et l’évolution d’un spectacle.

Bon Jovi | Lightshows, animations et musique

Joshua Clay et Trent Armstrong travaillent sur les animations, avec des séquences et lightshows associés aux différents morceaux. Leur contenu ne peut pas fonctionner correctement sans une intégration très étroite au code de Priepke.

Chaque chanson peut utiliser une succession d’événements visuels, de changements d’éclairage et d’animations qui doivent rester liés à sa progression tout en laissant au gameplay la possibilité d’intervenir. Certaines séquences sont construites dans After Effects, d’autres utilisent des éléments dynamiques intégrés au moteur du jeu.

Cette différence est importante. Une vidéo pré-rendue peut être jouée comme un bloc relativement fermé. Une animation dynamique peut répondre à l’état du jeu, changer selon une condition ou être interrompue pour afficher une information prioritaire. Le software doit donc gérer plusieurs formes de contenu audiovisuel avec des comportements différents.

Bon Jovi | Godot et animation dynamique

Le développement de Bon Jovi pousse également la collaboration avec Trent Armstrong vers une intégration plus dynamique. Armstrong commence à travailler avec une partie du pipeline Godot afin que certaines animations puissent être construites en couches ou déclenchées selon des événements plutôt que rester entièrement figées dans une vidéo pré-calculée.

Priepke conserve la responsabilité du coding de la machine. Le moteur graphique et les assets produits par l’équipe d’animation doivent donc être reliés aux états du ruleset, aux chansons, au scoring et aux événements physiques.

Cette architecture augmente la flexibilité de la présentation. Elle augmente également le nombre d’interactions possibles entre code et contenu. Plus les animations deviennent réactives, plus la programmation doit gérer les conditions qui déterminent leur apparition, leur interruption et leur évolution.

Bon Jovi | Crowd Engine et réponse dynamique

Le Crowd Engine participe à la simulation d’une performance qui évolue avec le joueur. Jeff Dodson construit la dimension sonore de ce système, tandis que le code doit lui fournir les états de gameplay permettant de faire évoluer l’intensité de la foule et la réaction générale de la machine.

Le public n’est donc pas seulement une ambiance enregistrée jouée derrière une chanson. Il peut participer à la lecture de la progression et à la sensation que la performance change au cours de la partie.

La qualité du résultat dépend directement de la coordination entre rules, coding et audio. Si le ruleset définit une montée en puissance mais que le son reste constant, l’effet disparaît. Si l’audio change sans correspondre à la progression réelle, la machine perd sa cohérence. Le software fournit le lien entre ces deux couches.

Bon Jovi | État actuel du code

Bon Jovi est lancé avec une architecture ambitieuse autour de ses dix-sept chansons, mais tous les morceaux ne disposent pas encore au même niveau de finition de l’ensemble des lightshows et animations envisagés pour la structure finale.

Cette situation doit être intégrée à l’évaluation du software actuel. Les fondations sont présentes, la structure de setlist fonctionne et l’intégration audiovisuelle montre déjà le potentiel du système, mais le package n’a pas encore atteint une uniformité complète sur l’ensemble du catalogue musical.

Le constat rejoint une caractéristique déjà observée sur les productions Barrels of Fun : le logiciel continue à évoluer après le lancement. Cette méthode permet d’enrichir fortement les machines, mais elle signifie également que la première version commerciale ne représente pas toujours l’aboutissement fonctionnel et audiovisuel du programme.

Priorités, interruptions et arbitrage des événements

Une grande partie du travail de Priepke reste invisible lorsqu’elle fonctionne correctement. Un flipper moderne peut recevoir plusieurs événements en quelques fractions de seconde. Une target est touchée, une ressource est accordée, un mécanisme s’active, une animation démarre et un jackpot devient disponible.

Tous ces événements ne peuvent pas recevoir la même priorité. Le logiciel doit décider ce qui peut être empilé, ce qui doit attendre, ce qui doit interrompre une séquence et ce qui peut simplement être enregistré en arrière-plan.

Cette hiérarchie conditionne la fluidité de l’expérience. Un jeu qui bloque constamment son joueur pour présenter chaque événement devient lourd. Un jeu qui laisse tout se produire simultanément risque de rendre ses informations incompréhensibles. Le travail de programmation consiste en partie à maintenir un équilibre entre ces deux extrêmes.

Mécanismes | Du signal logiciel au mouvement réel

Les machines Barrels of Fun utilisent de nombreux systèmes physiques dont le software doit contrôler les états. Aimants, diverters, motors, ball locks, targets, systèmes de capture et mécanismes spécifiques aux licences nécessitent des commandes qui correspondent exactement à la situation réelle de la bille.

Cette interaction introduit une difficulté absente d’un logiciel purement numérique. Le programme peut envoyer une commande correcte sans garantir que la bille réagira exactement comme prévu. Le code doit donc intégrer des capteurs, des confirmations d’état, des délais et parfois des solutions de récupération lorsqu’un mécanisme ou une bille ne suit pas le scénario attendu.

La qualité d’une machine repose beaucoup sur ces comportements de récupération. Un mécanisme spectaculaire lors d’une démonstration ne suffit pas. Il doit également savoir retrouver un état exploitable lorsque la partie produit une situation inhabituelle.

Software et affichage | Montrer la bonne information au bon moment

Barrels of Fun utilise plusieurs surfaces d’affichage, notamment le display principal et le lower display intégré au back panel. La quantité d’espace disponible pourrait encourager la multiplication permanente d’informations, mais la difficulté du software est justement de ne pas tout afficher simultanément.

Le joueur regarde d’abord la bille. Les informations indispensables doivent donc être hiérarchisées selon le moment où elles sont utiles. Une progression à long terme peut attendre, tandis qu’une décision immédiate, un jackpot ou une sélection nécessitent une présentation plus directe.

Dune montre toute la difficulté de cet exercice parce que le ruleset contient beaucoup d’informations simultanées. Winchester réduit cette densité. Bon Jovi ajoute la contrainte de préserver l’expérience du concert. Les trois machines demandent donc des politiques d’affichage différentes malgré une infrastructure technologique commune.

Mises à jour | Une architecture conçue pour évoluer

Les quatre premières machines Barrels of Fun montrent que la mise à jour logicielle fait partie du cycle normal du produit. Labyrinth continue à recevoir des améliorations longtemps après sa sortie, Dune est enrichi après commercialisation, Winchester bénéficie à son tour d’un développement continu et Bon Jovi évolue encore sur ses contenus de chansons.

Cette capacité permet à Priepke et aux équipes de corriger, équilibrer et compléter les jeux sans intervenir sur leur architecture physique. Elle augmente fortement la durée de développement réelle d’une machine au-delà de sa date de livraison.

Le modèle demande néanmoins une discipline importante. Une mise à jour ne doit pas corriger un problème en créant une régression ailleurs. Plus un ruleset devient vaste, plus chaque nouvelle fonction peut toucher des états déjà existants. La maintenance logicielle constitue donc une part croissante du travail à mesure que le catalogue Barrels of Fun s’agrandit.

Quatre machines | Une continuité logicielle devenue identifiable

Eric Priepke est associé au software des quatre premiers titres commerciaux de Barrels of Fun. Cette continuité permet au fabricant de faire évoluer son architecture sans changer de programmeur principal à chaque nouvelle licence.

Labyrinth établit les fondations sur une machine d’aventure riche en mécanismes. Dune augmente fortement la densité des règles, des ressources et des interactions audiovisuelles. Winchester adapte cette infrastructure à une expérience plus atmosphérique avec un autre game designer. Bon Jovi ajoute la synchronisation d’un système musical, de lightshows, d’animations dynamiques et d’une progression de concert.

Cette succession montre une fonction qui dépasse progressivement le coding d’une seule machine. Le travail de Priepke participe à la constitution d’une culture logicielle interne à Barrels of Fun, avec des méthodes, des outils et des systèmes suffisamment flexibles pour accueillir des designs très différents.

Compétences & rôles

Software Development | Pinball Coding | Gameplay Systems | Rules Implementation | State Management | Hardware Integration | Audio Integration | Display Logic | Interactive Systems | Software Maintenance

Machines et crédits

Dates clés et contributions

Eric Priepke | Software Development chez Barrels of Fun

Eric Priepke assure une continuité logicielle sur les quatre premières machines commerciales de Barrels of Fun. Son travail couvre l’implémentation des règles, la gestion des états de jeu, le contrôle des mécanismes, les priorités entre événements et l’intégration des contenus audiovisuels produits par les autres membres des équipes. Cette fonction le place directement entre game design, rules development, engineering, animation et audio sans confondre son crédit avec celui de ces disciplines.

Labyrinth établit cette architecture sur le premier produit du fabricant. Dune en augmente fortement la complexité avec ses systèmes parallèles et son utilisation avancée du feedback audio et visuel. Winchester démontre que la même infrastructure peut servir un autre designer et une expérience moins systémique. Bon Jovi étend encore les contraintes avec dix-sept chansons, une logique de setlist, des lightshows et des contenus dynamiques devant cohabiter avec une partie dont la durée et les événements restent variables.

Le principal apport identifiable de Priepke chez Barrels of Fun tient à cette capacité d’intégration. Les machines du fabricant reposent sur une quantité importante de mécanismes, de règles et de contenus qui n’acquièrent leur cohérence qu’une fois reliés par le software. Le développement post-lancement reste une caractéristique importante du catalogue et signifie que la maturité des programmes continue souvent à progresser après les premières livraisons. Sur les quatre titres actuels, Priepke constitue le point de continuité technique entre des game designers, rules designers et équipes audiovisuelles différents, tout en maintenant une architecture logicielle capable d’évoluer d’une machine à la suivante.