Unreal/Oculus Quest: Vloeistof overgieten, mogelijk/moeilijk

[Rekcor]

We laten een simulatie ontwikkelen in Unreal voor de Oculus Quest 2.

Op een gegeven moment moet de user een vloeistof uit een apparaat (een soort koffiemachine) in een beker kunnen 'schenken'. Idealiter zie je het vloeistofpeil in het apparaat dalen en in de beker stijgen (en daartussen dan een waterstroom).

Nu geeft de app-ontwikkelaar vrij opeens aan dat dit vre-se-lijk moeilijk, zo niet onmogelijk is. M.a.w.: hij wil veel meer tijd (en dus geld). Ook vraagt hij zich af of het überhaupt kan op een Quest 2, vanwege de beperkte rekenkracht. Nu heb ik zelf een Oculus Quest 2, en in een game als Vacation Simulator zie ik ook een koffiemachine. Het lijkt me dus sowieso mogelijk.

Mijn vraag: heeft mijn app-ontwikkelaar gelijk of niet? Hebben jullie wellicht wat pointers op internet hierover? Dit valt ver buiten mijn expertise, dus ik zou niet weten waar te beginnen met zoeken.

[Rmg]

Dat ligt er een beetje aan hoe realistisch/dynamisch je het schenken wilt hebben.

Zoiets als in vacation simulator, dat is vrij makkelijk daar zit geen fluid dynamics in.

Dat zijn een paar losse onderdelen de "koffie" die uit het apparaat komt heeft geen relatie tot de "koffie" in het kopje. Ook de "koffiespetters" zijn losse assets.

Eigenlijk zijn dit 3 losse dingen.
Animatie van koffie die uit de machine stroomt
Niveau van koffie in het koffie kopje die op 0 begint en naar 100% gaat afhankelijk van hoelang de koffie stroomt.
Koffiespetters die verschijnen als het niveau van de koffie layer > 40% procent is en de koffiemachine staat aan.
De bovenkant van de koffie is ook solid en geen vloeistof, het beweegt wat mee met de orientatie van het kopje maar dat is het wel.


Maar wil je dit 'realistisch' hebben. Zal je iets van een koffie particle moeten hebben die zich houd aan zwaartekracht en gedraagt als een vloeistof, zich kan conformen aan containers (koffiemachine, kopje), wat moet er gebeuren als het niet in een kopje zit maar ergens word gemorst etc etc. Dat is hele andere koek.

De vraag ik wil vloeistoffen overschenken en het moet zich gedragen als een vloeistof

of

Ik wil "koffie" mechanics zoals in vacation simulator

Dat zijn 2 hele andere uitersten

[Rekcor]

Ja het is inderdaad het tweede, simpele. Dank voor het opsplitsen van de simulatie in kleine stapjes!

[418O2]

Buiten dat ik me afvraag of je met zulk wantrouwen niet op zoek moet naar een andere partner, heb je aangegeven dat de manier/kwaliteit van "Vacation Simulator" goed genoeg is?

[Rekcor]

Ik heb het niet expliciet aangegeven, maar verwacht dat een dergelijke developer dit soort voorbeelden kent.

YouTube: Vacation Simulator - All Locations Playthrough [No Commentary]

Het lastige is dat de app al 80% af is, en dat een nieuwe dev vinden (naast dat het heel moeilijk is) waarschijnlijk ook betekent dat veel dingen opnieuw moeten.

[Woy]

Het is vanuit hier nogal lastig te redeneren of de developer een punt heeft, want het is nogal afhankelijk van veel factoren. Sowieso is de vraag wat in de originele afspraken staat, en of dit iets is dat is overeengekomen. Het is dan denk ik ook vooral een vraag van hoe de requirements vastgelegd zijn, en hoe de afspraken zijn voor wat betreft hoe dit ingevuld wordt.

Op zich is het niet vreemd dat een developer tijdens het ontwikkel traject problemen tegenkomt, en dat dat meer tijd gaat kosten. Wie daar dan voor op moet draaien is afhankelijk van hoe de afspraken gemaakt zijn. Is het Fixed Price en Fixed Scope, en valt deze feature binnen de bepaalde scope, dan zou dat vanuit de developer moeten komen. Valt het buiten de vooraf bepaalde scope, dan is het logisch dat ze terug komen met een nieuw voorstel hoe dat afgerekend dient te worden.

Dat een andere app het doet betekent natuurlijk niet meteen dat jouw developer ook de specifieke kennis voor dit specifieke probleem heeft, of uberhaupt hoeveel tijd de ontwikkelaar van de andere app erin heeft gestopt.

[ Voor 11% gewijzigd door Woy op 14-09-2021 11:39 ]

[Creepy]

Rekcor schreef op dinsdag 14 september 2021 @ 11:24:
Ik heb het niet expliciet aangegeven, maar verwacht dat een dergelijke developer dit soort voorbeelden kent.

Je doet hier een enorme aanname. Dus als je weet wat je wil, vertel dat dan en laat het dan zien anders blijf je langs elkaar heen praten. Dus laat de developer weten dat je dit bedoelt.

[418O2]

Creepy schreef op dinsdag 14 september 2021 @ 11:55:
[...]

Je doet hier een enorme aanname. Dus als je weet wat je wil, vertel dat dan en laat het dan zien anders blijf je langs elkaar heen praten. Dus laat de developer weten dat ie dit bedoelt.

Ik denk dat dit precies het probleem is. Ik heb inmiddels wel geleerd om door te vragen, maar zo'n vraag kan ontzettend anders worden geinterpreteerd door de dev dan jij het bedoelt.

[ThomasG]

Creepy schreef op dinsdag 14 september 2021 @ 11:55:
[...]

Je doet hier een enorme aanname. Dus als je weet wat je wil, vertel dat dan en laat het dan zien anders blijf je langs elkaar heen praten. Dus laat de developer weten dat je dit bedoelt.

Aannames zijn precies de reden waarom veel software projecten te veel tijd en geld kosten, en uiteindelijk niet gebruikt worden omdat het niet doet wat de klant eigenlijk wilde. Zelfs over iets wat qua uitleg heel eenvoudig en eenduidig lijkt hebben mensen vaak een andere interpretatie.

[Rekcor]

Persoonlijk vind ik dat de 'schuld' altijd bij de developer ligt in dit soort gevallen.

Je kunt niet van een klant verwachten dat hij weet wat hij wil en/of dat hij ideeën heeft hoe e.e.a. geïmplementeerd moet worden.

De developer is de expert.

[aidanl]

Het is een samenwerking die je aangaat. De developer kan niet ruiken wat jij wil (typisch geval van "het werkt niet" koop je niets voor) als je het niet goed duidelijk maakt. Daarentegen zou een developer vanuit zijn technische kennis jouw wensen moeten bevragen en verder uitwerken. Maar het idee zelf blijft van jou. Dus de "schuld" ligt dan niet 100% bij de developer. Was er bijvoorbeeld een uitgedacht plan waar jijzelf mee akkoord bent gegaan voor hij is gaan bouwen?

Overigens hangt het dus ook van de ervaring van de developer af. Ikzelf als developer die al jaren in verschillende projecten mee draai waaronder ook in een PM rol, zou daar zeker op doorvragen. Echter is het puur een developer zonder verdere PM skills, tja dan blijft het de vraag. Ik ken zat developers die zo een knopje voor je in een applicatie bouwen. Dat hij pimpel-paars met een goud randje is geworden, tja je hebt er niet bijgezegd dat hij blauw moest zijn...

Edit:
Zijn er daarnaast ook tussentijdse previews / demo's geweest, of in ieder geval een status overleg?

[ Voor 6% gewijzigd door aidanl op 14-09-2021 14:27 ]

[418O2]

Rekcor schreef op dinsdag 14 september 2021 @ 14:09:
Persoonlijk vind ik dat de 'schuld' altijd bij de developer ligt in dit soort gevallen.

Je kunt niet van een klant verwachten dat hij weet wat hij wil en/of dat hij ideeën heeft hoe e.e.a. geïmplementeerd moet worden.

De developer is de expert.

Je snapt hopelijk wel dat je zoiets "samen" doet. Probeer zelf na te denken bij "hoe zou hij dit interpreteren?". Of "hoe kan ik dit zo omschrijven dat er interpretatie niet nodig is". Tuurlijk kan je heel hard gaan roepen dat de schuld bij hem ligt, maar je maakt het jezelf alleen maar moeilijk.