Toon posts:

GUI block probleem

Pagina: 1
Acties:

  • alcon
  • Registratie: september 2010
  • Laatst online: 01-10-2010
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
  • Registratie: december 2001
  • Laatst online: 21:41

RobIII

Admin Devschuur®

^ Romeinse Ⅲ ja!

alcon 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...
alcon 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?
alcon 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.
alcon 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]

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery.

Roses are red Violets are blue, Unexpected ‘{‘ on line 32.

Over mij


  • alcon
  • Registratie: september 2010
  • Laatst online: 01-10-2010
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
  • Registratie: januari 2008
  • Niet online
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. :p

Vitamine D tekorten in Nederland | Middelen tegen corona


  • epic007
  • Registratie: februari 2004
  • Laatst online: 16-09 12:32
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
  • Registratie: juli 2000
  • Nu online
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.
Pagina: 1


Nintendo Switch (OLED model) Apple iPhone 13 LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S21 5G Apple iPad Pro (2021) 11" Wi-Fi, 8GB ram Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True

Tweakers maakt gebruik van cookies

Bij het bezoeken van het forum plaatst Tweakers alleen functionele en analytische cookies voor optimalisatie en analyse om de website-ervaring te verbeteren. Op het forum worden geen trackingcookies geplaatst. Voor het bekijken van video's en grafieken van derden vragen we je toestemming, we gebruiken daarvoor externe tooling die mogelijk cookies kunnen plaatsen.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Forum cookie-instellingen

Bekijk de onderstaande instellingen en maak je keuze. Meer informatie vind je in ons cookiebeleid.

Functionele en analytische cookies

Deze cookies helpen de website zijn functies uit te voeren en zijn verplicht. Meer details

janee

    Cookies van derden

    Deze cookies kunnen geplaatst worden door derde partijen via ingesloten content en om de gebruikerservaring van de website te verbeteren. Meer details

    janee