Spacing out

Het vorige prototype had pathfinding. Zo konden mannekes hun weg vinden om gebouwen heen. Echter het querien en route berekenen was nogal erg zwaar. Ook was het nog niet mogelijk als je een gebouwtje ging bouwen dat hij zag dat de ruimte op de kaart al bezet was. Dit zijn allemaal probleempjes die ik hoop in dit prototype uit te zoeken. Zo ging ik op een gegeven moment op zoek naar een handige DB functie om distances uit te rekenen tussen elementen. Ik dacht als dit door de db te bepalen is, en ik kan daarop meteen sorteren, mooi!

Tijdens deze zoektocht kwam ik erachter dat MySQL en Postgres allemaal mooie functies hebben om ruimtelijke berekeningen te doen, speciaal toegevoegd voor de zogenaamde GIS applicaties (Geological information systems). Zo kan je dus blijkbaar allerlei points, lines en shapes opslaan in de db en dan querien welke andere elementen ze snijden, raken, overlappen etc!

Ik heb het begin hiervoor nu al geregeld, en ik gebruik nu de geo-ruby plugin en de mysql-spatial-adapter. Ook worden de coordinaten die opgeslagen worden nu als echt POINT type opgeslagen en de paden die worden gelopen als lines. Echte route berekeningen zitten nog niet in dit prototype, omdat units voorlopig door elkaar heen kunnen blijven lopen (later in gameplay testen kijk ik wel of dat echt bevalt of niet) en alleen gebouwen dus echt als obstakel op de kaart moeten zijn. Op dit moment nemen gebouwen nog geen fysieke ruimte in op de kaart, dus daarom zit route berekenen er dus ook nog niet in.

Maar deze spatial tools bieden wel heel veel potentie voor de volgende dingen:

• Snelle controle of er ruimte is om gebouwen te plaatsen
• Hopelijk optimalisering van route berekening
• Proximity detectie voor bijv langslopende mannetjes bij stationaire turrets (sight cirkels en pathing lijnen kruisen)
• Verkenning! het verkende gebied via een polygone vlek op kunnen slaan en steeds via unions stukken verkend gebied kunnen toevoegen!

Nou heb ik de coolste dingen dus nog lang niet in praktijk uit kunnen testen, maar deze set bied wel erg veel mogelijkheden. Ook na implementatie van deze zaken waar ik nog steeds geen grafische client voor nodig heb kan ik al goed server-side performance testen via cucumber scenario's en al performance gaan tunen en kijken of ik bij MySQL blijf of evt overstap naar Postgres.

Komende weken hopelijk mooie updates hierover!

Posted via email from posterous of Matthijs Groen

Harvesting werkt!

Ik heb een best complex script nu werkend gekregen. Het harvesten van resources ala Dune 2.

Dus stel je voor:
een OreField op een lokatie
een OreRefinery op een lokatie
een OreHarvester op een lokatie.

Speler selecteerd harvester, en kiest "Harvest"
het test script doet exact dit:

Background:
Given a new instance
And a new faction named Red
And Red has a primitive base at 100, 100

Scenario: Delving Resources
Given Red selects all OreHarvester
And Red has the following resources:
| amount | type |
| 0 | metal |
When Red issues "harvest"
And wait 1 hour
Then Red should have the following resources:
| amount | type |
| 5000 | metal |

Het "harvest" script doet het volgende:

1. zoek een Orefield in de buurt
2. Rij erheen
3. Start harvesten tot: Harvester vol is; of OreField leeg is.
4. Start return script

en het return script doet vervolgens:
1. zoek een OreRefinery van jezelf in de buurt
2. Rij erheen
3. Dump resources tot Harvester leeg is
4. Start harvest script.

Indien de OreField leeg is transformeert hij zichzelf in een DepletedOreField, en bij de eerst volgende harvest actie wordt hij dus niet meer gevonden en stopt de harvester.

Kortom in bovenstaande testscript had de inhoud van de node 5000 metal, en na uur gametime is de OreField in ieder geval leeg en heeft de harvester alles bezorgt bij de speler.

The game of making a game

De meeste spellen heben het wel, meerdere settings waar je doorheen speelt. Woestijn, Bergen, Water, etc. Ook missies die je voltooid moet hebben om andere missies te unlocken. Of bazen te verslaan voor speciale extra vaardigheden.

Ik heb het gevoel dat het maken van een spel op zich daar ook mee te vergelijken is.


Zo is het maken van een spel als een aantal verschillende werelden die je allemaal kan bezoeken en losse missies voltooien. Echter sommige werelde kan je pas betreden indien deze zijn unlocked en vrijgespeeld. Ook kan je meerdere keren terugkeren naar een missie totdat je alle secrets hebt ontdekt.

I want to tell... (story) (world)

Part 1: The basic idea
Mission: Overal storyline
Mission: Mission setting(s)

Part 2: Refinement (locked: must finish part 1 first)
Mission: Goals
Mission: Character design

Part 3: Finishing touches (locked: must finish part 2 first)
Mission: Sub-plots

That's logic (gameplay-logic) (world)

Part 1: Basic building blocks
Mission: Game asset technical modelling
Mission: Resource management
Mission: Scripting (special bonus: upon mastering unlocks great AI)

Part 2: It's alive! (locked: must finish part 1 first)
Mission: Overarching scripting and level objectives
Mission: Unit upgrades
Mission: "Tech" tiers

Part 3: Algorithmatic (locked: must finish part 1 first)
Mission: Occupying space and routing
Mission: Combat (special bonus: upon mastering unlocks great Gameplay)

Making it look cool (client design) (world)

Part 1: Make it click
Mission: Design code architecture
Mission: Data streaming/pushing
Mission: Rendering items
Mission: Showing some buttons to push

Part 2: Painting the borders (locked: Must finish part 1 and story pt 1 first)
Mission: UI design
Mission: Menu structures

Part 3: Welcome to the game! (locked: Must finish part 2 and gameplay-logic first)
Mission: Tutorial design

And a drop of (content creation) (world)

Part 1: Mastering the process
Mission: Determine design style
Mission: Select the tools
Mission: Create proces for different colorsets of same unit
Mission: Mission / campaign creation tools

Part 2: Doing the actual work (locked: must finish story and gameplay-logic)
Mission: Model your ass off
Mission: Mission / Campaign design

Part 3: It's all in the details (locked: must finish part 2, client-design pt 1, gameplay-logic first)
Mission: Balancing
Mission: Beta test

De bedoeling is natuurlijk erg succesvol al deze missies te voltooien, en enkele natuurlijk te masteren. Als resultaat kan je dan een mooie game krijgen :-)

Ik ben nu her en der missies aan het doen, maar mij voornamelijk door "That's Logic" aan het ploegen, in part 1 met de missies resources management en scripting.

2 jaar terugblik

Even een korte terugblik voor mijzelf. Hoe veel er toch is veranderd voor mij qua ontwikkelen van apps/games/meuk.

Source code management:
Toen: CVS/Subversion
Nu: Git

Taal: PHP -> Ruby
Framework: Custom made -> Rails
Database: MySQL -> MySQL, SQLite
Javascript: Geen framework -> JQuery
Testing: Geen tools -> Cucumber
OS: Windows -> GNU/Linux (Ubuntu)

Cucumber gebruik ik nog maar een paar weken sinds de nieuwe start van game prototype, ik zal daar zeer binnenkort nog een post over doen. Op dit moment ben ik mij aan het verdiepen in de SPATIAL functies van MySQL, en daar hoop ik binnenkort ook (positieve) ervaringen over te kunnen delen.

Metaprogramming spel eenheden

In mijn eerste prototype waarbij ik 'echt' wilde programmeren (dus serverside, geen JS display prototype). Liep ik tegen een aantal problemen aan:

1. Ik heb geen uitgebreide ervaringen met het maken van spellen
2. Je moet items hebben die met elkaar interactief kunnen zijn.

bij punt 2 moet je denken aan soldaatjes die kunnen rondlopen en schieten. Hoe hard lopen die? hoe krachtig en ver schieten die? Dit is meta data die geld voor alle soldaatjes (upgrades daargelaten).

Ga ik die in een database opslaan en er voor querien? Ga ik die in XML of yaml definieren en inlezen bij het opstarten?
Nadelen bij deze approaches zijn dat het niet alleen om getalwaarden ofzo gaat. Als je echt eenheden wil definieren, dan hebben die ook verschillende vaardigheden. Zo kan een helicopter vliegen, raketten afvuren en bommen gooien, een buggy kan wellicht mijnen leggen en mannetjes vervoeren. Dit zijn vaardigheden, die toch een soort uniek zijn per soort eenheid. Als je dat allemaal in XML moet omschrijven is punt 1, maar bij het uitlezen moet je ook een object hebben programmatisch in je systeem die hiermee om kan gaan.

De oplossing: Metaprogramming.

Stel ik zou gewoon een Marine klasse maken? en daarin methodes toevoegen voor zijn vaardigheden? en daarin vertellen wat zijn stats (health, armor, range, speed) zijn?

Dankzij Single Table Inheritance in Rails is dit verdomd makkelijk. Definieer een standaard eenheid. Ik heb deze 'Asset' genoemd. Alles in het spel wat op het speelbord zich bevind is een asset. Dit kan een boom zijn, een gebouw, maar ook meer interactief zoals een soldaat.

Van deze standaard Asset maak ik overervingen. Omdat je in Ruby mooi op klasse en instantie niveau methodes kan definieren, heb ik in de asset basis een klasse methode waarin ik een willekeurig aantal eigenschappen kan definieren van de assets.

class Asset::Base < ActiveRecord::Base
 info \
  :build_time,   # building info
  :build_costs,
  # movement info
  :movement_speed # etc.. meer leuke stats dingetjes
end

In een Marine overgeërfde klasse kan ik vervolgens standaard waarde voor deze attributen opgeven:

class Terran::Unit::Marine < Asset::Base
  # building info
  build_time 10.seconds
  build_costs 75.metal
  # movement
  movement_speed 30.kmph

end

Zoals je ziet zijn in de bassis via kleine opsomming wat attributen verzonnen, en via de klasse van de specifieke unit kan je ze dan "inkleuring" geven. Zo gaat een marine klasse omschrijving eruit zien als een magic the gathering of pokemon (wat je wil) speelkaartje :-) Dit mooie mechanisme heb ik uit "Why's (poignant) guid to Ruby" Echter is deze site nu down, maar met googlen kom je er ook. Dit stuk wordt beschreven in hoofdstuk 6.3 "A Sponsored Dragon-Slaying"
Voordelen van deze approach:

1. Een marine klasse beschrijft een marine in een aantal regels, en is zeer leesbare code
2. Een instantie van deze klasse is ook echt een marine op het speelveld met zijn eigen vaardigheden
3. Door STI (Single Table Inheritance) is elke Asset type direct in de database op te slaan
4. Validatie model van active record is te gebruiken voor minimale eisen en uit te breiden met eigen validatie soorten. Bijv: Om een marine te maken hebben we barakken nodig.

Zo we gaan weer eens aan de gang

Laat ik maar eens deze blog in leven roepen... Ik heb vaak zin om wat dingen gewoon van me af te schrijven van de dingen die ik doe, echter op facebook zelf kan je niet echt lekkere verhalen kwijt. Dus dan maar deze blog die zichzelf weer deelt met Facebook!

Deze blog gaat gewoon over MIJN interesses, dus ik zal natuurlijk niet voor iedereen interessant zijn :P het is dan ook een 'weblog' dus soort dagboek dingetje van mijzelf.

Ik ben nu al een behoorlijke tijd geleden (lees: ruim 2 jaar) begonnen met een eigen webbased game, waar ik met vlagen aan gewerkt heb. Ik neem er rustig de tijd voor, omdat het voor mij ook heel veel spelen met verschillende technieken is. Ik ben zo ooit begonnen met verschillende prototypes in javascript, waaronder een terrein rendering demo waarmee je over een flink stuk terrein kon scrollen waar verscheidende mannetjes en boomjes in stonden. Ook bewogen deze mannetjes af en toe (beetje verveeld rondkijken) om het een levendig geheel te laten vormen.

Ik was daarna ooit begonnen met een soort level editor in Java, maar dat had geen lang leven beschoren. De ontwikkeling ging te langzaam en ik ging daarna eigenlijk terug naar diverse prototypes in javascript. Zo heb ik onder andere nog een combat prototypje gemaakt waarin 2 partijen elkaar flink overhoop aan het schieten waren en een prototype om pathfinding te doen door een doolhof.


Omdat ik Ruby on Rails aan het leren en me dat erg beviel wilde ik daarin graag beginnen om een prototype te maken waarin ik ook met de serverkant aan de slag ging. Hierin was ik ook aardig in geslaagd (voor een prototype dan!). Je kon een unit selecteren. hij kon rondlopen, om gebouwen heenlopen, er zat animatie in gebouwtjes, en je kon opdrachten geven zoals 'creer een gebouw' of patrouilleer tussen deze 2 punten. Echter echt visuele combat en verkenning heeft er nooit ingezeten.

Omdat mijn kennis in Ruby al flink vooruit is gegaan wil ik dat prototype opnieuw bouwen. Met hopelijk een leuk speelbaar spel als eindresultaat. Gameplay eerst, graphics en levels/scenario's later. Ohja, als doel is het om het volledig PUUR webbased te doen, dus zonder plugins. (Geen flash, applets, etc) Puur technieken die de browser native bied, dus HTML, CSS en Javascript. En misschien later wat canvas dingen mocht HTML 5 echt wat worden.

Kortom in deze blog zal ik het onder andere hebben over voortgang van dit nieuwe prototype. En ohja, het zal ook technische dingen bevatten zoals wat sourcecode snippets etc :-)