GUI block probleem

[Verwijderd]

Hallo,

Al een hele tijd kom ik niet op een ideale oplossing voor een probleem in de architectuur van typische roll playing games zoals Monopoly, Risk,...

Het is duidelijk dat dit soort games zeer grafisch zijn en updates naar de GUI heel frequent gebeuren. Meestal maak ik gebruik van een MVC-structuur.
Wanneer het model een code aan het uitvoeren is die een lange verwerkingstijd eist doet het zich in een single-threaded applicatie zich vaak voor dat de gebruiker daardoor ook niets meer in de GUI kan doen. In een extreem geval bijvoorbeeld als er een aantal of enkel AI spelers in het spel zitten kan de gebruiker zelfs niet meer het scorebord bekijken vooraleer hij weer aan de beurt is of het spel gedaan is.

Dit kan natuurlijk verholpen door de applicatie op te bouwen met meerdere threads. Maar welke verwerking kan dan best in eenzelfde thread gebeuren. De volledige GUI kan bijvoorbeeld in 1 thread zitten en het Model in een andere thread wat bij dit soort grafische applicaties als gevolg heeft dat er continue gesynchroniseerd moet worden. Het hele model in 1 thread laten draaien geeft ook nog niet een volledige oplossing want als een AI speler aan zijn zet bezig is en de gebruiker vraagt bijvoorbeeld het scorebord op dan zal bij deze actie ook weer data van het model nodig zijn waardoor er toch nog gewacht moet worden totdat de AI speler gedaan heeft. Tevens zal na een zet volgens mij de uitvoering van een thread beëindigen en bij elke actie of start van een beurt weer een nieuwe thread aangemaakt moeten worden?

Ik heb al een aantal van dit soort applicaties gemaakt maar nooit was er een ideale oplossing die gemakkelijk te onderhouden is of uitbreidbaar is omwille van dit probleem. Daarom vraag ik jullie mening over het implementeren van dit soort applicaties.

[RobIII]

Verwijderd schreef op donderdag 30 september 2010 @ 21:05:
Het is duidelijk dat dit soort games zeer grafisch zijn en updates naar de GUI heel frequent gebeuren.

Bij een Monopoly of Risk? Wat versta je onder frequent? Frequent is honderden keren per seconde; niet iedere paar secondes 1 update...

Verwijderd schreef op donderdag 30 september 2010 @ 21:05:
De volledige GUI kan bijvoorbeeld in 1 thread zitten en het Model in een andere thread wat bij dit soort grafische applicaties als gevolg heeft dat er continue gesynchroniseerd moet worden.

Nogmaals: Dit zie ik even niet. Als je GUI 5x per seconde update is dat toch al meer dan genoeg voor een Risk/Monopoly? Dat je bij een "Crysis" of weet ik het wat 30~70 fps nodig hebt begrijp ik maar voor een bordspelleke?

Verwijderd schreef op donderdag 30 september 2010 @ 21:05:
Het hele model in 1 thread laten draaien geeft ook nog niet een volledige oplossing want als een AI speler aan zijn zet bezig is en de gebruiker vraagt bijvoorbeeld het scorebord op dan zal bij deze actie ook weer data van het model nodig zijn waardoor er toch nog gewacht moet worden totdat de AI speler gedaan heeft.

Wat heeft het scorebord daar mee te schaften? Ik neem aan dat dat na een move bijgewerkt wordt? En dus niet in de "denk thread" hoeft te zitten? Je hoeft toch niet je héle "model" in 1 thread te mikken? Je kunt toch puur het rekenintensieve deel een eigen thread geven? Laat 'm lekker rekenen en als 'ie er uit is maakt 'ie z'n move en werk je je game-state/scorebord bij etc.

Verwijderd schreef op donderdag 30 september 2010 @ 21:05:
Tevens zal na een zet volgens mij de uitvoering van een thread beëindigen en bij elke actie of start van een beurt weer een nieuwe thread aangemaakt moeten worden?

En dus...? Wat zou daar het probleem mee zijn? Je kunt een shitload aan threads (lees: honderden) per seconde starten. Even aangenomen dat een zet berekenen in jouw AI 1 seconde duurt (en dat zou al lang zijn IMHO?) dan is dat toch 0 probleem?

Verwar je een thread niet met een proces ofzo?

[ Voor 5% gewijzigd door RobIII op 01-10-2010 02:11 ]

[Verwijderd]

Nogmaals: Dit zie ik even niet. Als je GUI 5x per seconde update is dat toch al meer dan genoeg voor een Risk/Monopoly? Dat je bij een "Crysis" of weet ik het wat 30~70 fps nodig hebt begrijp ik maar voor een bordspelleke?

Stel je steekt alles in 1 thread. Wanneer de AI aan zet is en hij doet bijvoorbeeld in monopoly een aantal stappen. Natuurlijk wil je dat elke stap duidelijk weergeven wordt en hij niet onmiddellijk verder gaat met zijn volgende stap dus zal je toch een "Wait" moeten gebruiken om de uitvoering een aantal sec te stoppen en de gebruiker de kans te geven de zet van de AI waar te nemen en dan verder te gaan met de volgende zet van de AI. Gedurende die periode zal de gebruiker ook niets meer met het programma kunnen doen want de volledige thread ligt stil. Daarom dus het multithreaded principe. Misschien dat voor dit wachten iets anders gebruikt kan worden? timers ofz maar ik weet niet of dat een ideale en betere oplossing is?

[pedorus]

Volgens mij kan een monopoly-applicatie prima in slechts 1 UI-thread met timers, of je moet een nogal ingewikkelde AI hebben. Het voordeel is dan gelijk dat je geen synchronisatieproblemen tussen verschillende threads hebt.

[epic007]

Ik neem aan dat je AI continue bezig is met zetten vooruit te denken (Minimax algorithme o.i.d). Wat je kan doen (multithreaded of singlethreaded) is nadat een aantal zetten is berekend de rest van de app ook wat cpu tijd geven (GUI, scorebord etc).
Je moet je AI algoritme zo ontwerpen dat je hem kan stoppen en later weer kan hervatten. Meet na elke zet bv het aantal ms dat het algoritme bezig is geweest, is dat hoger dan bv 200ms dan moet de rest van de game zich even kunnen updaten.

[Vinnienerd]

Alles wat rekenintensief is in een eigen thread gooien, prioriteit op laagst zetten zodat er ook nog met de GUI te werken valt. Gooi er eventueel een thread.sleep van 5 ms in ofzo in als de rekenthread teveel CPU-tijd opeist.