Research and Development 1/^Archief/2009-2010/07/Pilot/Verslag
Inhoud
HiberNations Pilot 2010
Onderzoeksvragen
Hoofdvraag:
- Hoe kan je een voornamelijk cooperatieve RTS maken die ook nog leuk is?
Deelvragen:
- Hoe bouwen we een user interface voor ons spel?
- Hoe kunnen we de GameObjecten het beste balanceren voor leuke/spannende gameplay?
Concept
Het idee van ons spel staat uitgelegd op deze pagina: https://lab.cs.ru.nl/algemeen/Research_and_Development_1/Projecten/07/Pilot/Concept
Hoe we te werk zijn gegaan
In den beginne zijn wij gaan brainstormen, en hebben hier een Wiki-pagina over aangemaakt. Dit werd later het "Concept". Al snel waren we tot de beslissing gekomen om Java als onze programmeertaal te gebruiken, omdat dit enerzijds aansluit op de cursus Object Oriëntatie, en anderzijds om de reden dat de standaard-bibliotheek van Java nu eenmaal zeer uitgebreid is. Op de Wiki-site is er, deels uit noodzaak, een klassenpagina opgesteld waarin staat wat elke klasse moet weten en kunnen. Dit hebben wij geleerd van Object Oriëntatie. Zo werd de code een stuk overzichtelijker. Week na week hebben we stapsgewijs voortgebouwd op de broncode. Dit was mogelijk omdat er veel communicatie plaatsvond tussen ons. Als tool hebben we Subversion (SVN) via SourceForge.com gebruikt. Dit stelde ons in staat om de code te synchroniseren tussen onze werkplekken. Dit versnelde het programmeren behoorlijk. Ook waren wij in staat direct feedback te geven op elkaars werk. We hebben wekelijks een logboek bijgehouden met onze vorderingen. Hierin staat onder meer wat wij hebben gedaan, maar ook waarom. Ook staan eventuele conclusies die wij getrokken hebben, concreet vermeld.
Hoe bouwen we een user interface voor ons spel?
Om antwoord te geven op deze vraag hebben wij vaak en lang overlegd over het ontwerp van het spel. Dit leidde uiteindelijk tot een ontwerp van klassen waar op deze pagina een overzicht van te vinden is: https://lab.cs.ru.nl/algemeen/Research_and_Development_1/Projecten/07/Pilot/Klassen
Hieronder hebben wij enige uitleg gegeven met betrekking tot de klassen:
Commando interpreteren
Aangezien de interactie met de gebruiker voornamelijk gebeurt via getypte commando's, moesten we iets hebben om ingetypte zinnen te ontleden. Uit C komt de functie sscanf die een willekeurige zin kan opdelen in stukken en opslaan in variabelen, van verschillende typen. Na wat onderzoek bleek dat Java gaan sscanf-functie of iets wat er op lijkt bevat, dus hebben we gekozen om het interpreteren te doen met hulp van de StringTokenizer-klasse, die een String in stukjes knipt met whitespace ertussen. Dit hebben we dan gecombineerd met Integer.parseInt, die een getal uit een String haalt, en zo een soort lichte versie van sscanf gemaakt. We hebben gekozen om alle mogelijke commando's in een textbestandje op te slaan, zodat veranderingen snel toegepast kunnen worden. De CommandInterpreter-klasse leest eerst dit bestand helemaal uit, en kijkt dan naar het eerste woord van de ingetypte zin (Het eigenlijke commando dus) en vergelijkt dit met alle bekende commando's om het correcte formaat (bv: kill <naam> <aantal>) te verkrijgen. Daarna worden alle parameters uit de zin geknipt, al dan niet geconverteerd naar Int, en kunnen dan bereikt worden door andere klassen.
Map representeren
Het spel heeft natuurlijk een speelveld nodig. We hebben gekozen om speelvelden waarop gespeeld kan worden afzonderlijk op te slaan in tekstbestandjes, zodat iedereen nieuwe kan toevoegen, verwijderen en makkelijk kopiëren. De Map-klasse gebruikt een MapReader-klasse om een gegeven mapnaam te zoeken. Als deze wordt gevonden wordt de inhoud naar de Map gestuurd, die dit dan ontcijfert in een breedte, hoogte en de inhoud van de map. Aangezien er minder dan 26 verschillende types van grond op het speelveld waren, hebben we elk vakje van de map als 1 letter in het bestand gezet. Dit zorgt ervoor dat we met een simpele switch-case elk vakje uit de inhoud kunnen lezen.
De klasse Canvas gebruikt een instantie van Map om het speelveld te tekenen. Daarom moest Map ook informatie bevatten over wat waar staat. Een complicatie was dat er maar 1 object (gebouw, leger) per vak op de grid getekend konden worden. Legers en gebouwen kunnen op hetzelfde vak bestaan, dus moesten we kiezen of een gebouw of een leger in zo'n geval bovenop komt te staan. We hebben gekozen voor gebouw, omdat die over het algemeen groter moeten overkomen dan legers en omdat ze niet mobiel zijn, dus moet duidelijk zijn waar ze staan. De Map controleert dus, bij het toevoegen van een object op de kaart, wat er al dan niet op het bestemmingsvak en het originele vak staat.
Map afbeelden
Om de map af te beelden wordt een JFrame gebruikt waar een 2D representatie van de map in te zien is. Zo kunnen de spelers gemakkelijk de voortgang van het spel zien:
Het venster telkens geüpdate nadat de speler correct een commando heeft ingevoerd. Dit wordt geregeld door een klasse Canvas, die een instantie van de klasse Map meekrijgt. Die Map bevat 2 matrices. De velden uit die matrices worden door Canvas op het scherm gezet als vierkanten.
Canvas doorloopt eerst de ene matrix. Die is voor de achtergrond. De achtergrond bestaat kan bestaan uit Resources, Obstakels en een gebied dat aan het begin van het spel gereserveerd is voor het Blauwe team en het Rode team.
Als canvas die matrix heeft doorlopen dan tekent hij de andere matrix die GameObjecten bevat. GameObjecten kunnen eenheden zijn die bij een team horen, zoals legers, voertuigen en gebouwen.
Zo is de Canvas dus eigenlijk opgebouwd uit twee lagen die na elkaar afgebeeld worden. Hierdoor zijn we in staat makkelijk GameObjecten op achtergrond te tekenen met dezelfde (x,y) coördinaten.
Stats van eenheden
Net als met commando's hebben we besloten alle verschillende stats van eenheden (maximale levenskracht, sterkte, etc) ook in een textbestandje op te slaan. De klasse ObjectManager leest deze bestanden in en creëert instanties van de eenheden en gebouwen zodat deze gekopieerd kunnen worden om een nieuwe eenheid of gebouw te maken. We hebben hiervoor gekozen, omdat het hard-coden van de stats ervoor zou zorgen dat het lastig wordt deze on-the-fly te veranderen, en omdat we makkelijk dingen kunnen veranderen om bijvoorbeeld de balans te testen. Aangezien alle eenheden dezelfde typen stats hebben en gebouwen ook dezelfde parameters, hebben we deze niet in aparte klassen gezet. Dit zou ook leiden tot een gigantisch klassenbestand en tot verminderde flexibiliteit. Elke eenheid en elk gebouw draagt een naam mee, waardoor ze makkelijk te identificeren zijn.
Code
De laatste versie van de code voor Hibernations kan altijd hier gevonden worden: https://sourceforge.net/projects/hibernations/
Plan voor volgende Fases
Ons doel voor de pilot was om in ieder geval een werkend prototype van het spel te maken. Echter, onderzoeken hoe je het beste zo’n interface moet maken en hem daarna ook daadwerkelijk maken kostte meer tijd dan we eerst gedacht hadden. We zijn een heel eind gekomen, maar hij is nog niet af. Daarom hebben we dit plan nu doorgeschoven naar Fase 1.
Voor fase 1 hebben we dus gepland dat het prototype alle functionaliteit bevat om echt een geloofwaardig hot-seat multiplayer spel te kunnen spelen met 2 teams. Voor fase 1 kunnen we ook experimenteren met verschillende sterktes van eenheden en gebouwen en we willen proberen om het spel te balanceren tot een leuk spel. Hierbij zullen we ook veel testen en het spel moeten spelen. Ook zullen playtests met andere mensen moeten doen, want wat in de ogen van de ontwikkelaar helemaal geweldig lijkt, kan bij de gebruikers nog wel eens tegenvallen. We hopen dan de vraag "Hoe kunnen we de GameObjecten het beste balanceren voor leuke/spannende gameplay?" beantwoord te hebben.
In de laatste fase kunnen we de code optimaliseren en finaliseren. Dan wordt de netcode toegevoegd en alle optionele dingen als we daarvoor nog tijd over hebben. De hoofdvraag is dan beantwoord.
- 1. Interface afmaken
- 2. Gamemechanics basis maken
- 3. Gamemechanics invullen
- 4. (Laten) testen
- 5. Eventuele veranderingen bedenken. Ga naar 3 indien veranderingen nodig.
Logboek
https://lab.cs.ru.nl/algemeen/Research_and_Development_1/Projecten/07/Logboek
Gemaakt door: Marco Jonkers, Stein Keijzers en Peter Maandag
April 2010
