Closed buzzdead closed 4 years ago
Det blir nevnt
SRP
flere ganger, med dette mener du "Single responsibility principle"?
Ja, enhver klasse skal alltid forholde seg til en oppgave og forholde seg til et singulært prinsipp i forhold til funksjonalitet.
Anngånde kontroll i spill vs debug: er gjort en del her:
Men tenker du å ha med alle de funksjonene, er nesten hele tastaturet man bruker for å debugge er det ikke, og mange av de fungerer ikke som de skal lenger i forhold til andre ting. Mange spill har muligheten til å "aktivere debug mode" on the fly.
Flyttet til nye issues som er nice to have.
Ting som kanskje ikke er nødvendig å gjøre til presentasjonen, men som alikevel bør gjøres frem til innleveringen!
continueGameLoop()
i Game til en Round Event, gjøre det mye mer oversiktlig og lesbart med metoder.Menu
#188 #211this.
og getters metoder bruker ikkethis.
TiledTranslator
#220 blir laget 50 ganger av spillet og alle instansene er helt like. (kan f.eks opprettes statisk i settingsutil)GameView
klassen Hovedsakelig render metoden, helst ha den til å være på 5-10 linjer.Refaktorere med hensyn på SRP
ProgramCardsView
UIElements
#209 flere veier å gå, enkeltvis legge opp en klasse til å konstruere elementene, en klasse til å utføre funksjonene, eventuelt en klasse for hver "del" av uielements, f.eks en for helse og reboots, en for knappene..Til vurdering
[x]
KeyboardInput
#193 Når jobben er gjort, hva slags funksjoner er det fornuftig å etterlate programmet, og hvilken plass skal denne klassen ha i programmet?[x]
AssetManagerUtil
til et SRP (Hente ting fra -filer-), #94 Vurdere hva vi skal gjøre med robotene i denne klassen. (Brukes flere steder, men det er ikke et hinder).