Open Source Lasergame/Laser Tag

[Phalox]

Ik denk dat protocol 2 nog wel iets verdere toekomst is. Behalve dan de IR, maar dat maakt de interactie tussen spelers onderling mogelijk

Willen deelnemers zich op de wikipagina inschrijven, en hun naam + functies vermelden op deze http://sprite.student.utw...rag/index.php/Medewerkers pagina ?

[Verwijderd]

Mooi, count me in.
Ik kan helpen met de Hardware ontwikkeling. (Proto PCB's maken ed.)
Ik beschik over de nodige tools (tekenkundig als hardwarematig) om PCB layouts te verwekken tot eerste proto's.
Ook met research (op elektronisch gebied) zal ik een handje kunnen toesteken.

De koppeling tussen een gun en de main CPU is me wel niet duidelijk.
Dit is wired toch niet haalbaar ? of vergis ik mij hierin?

Ik stel me ook de vraag hoe je de nauwkeurigheid van de (IR) gun beam doelgericht kan afstellen.
Direct zonlicht gaat toch invloed hebben om de reikwijdte van deze beam ?

[ Voor 17% gewijzigd door Verwijderd op 17-03-2007 20:09 ]

[Phalox]

Zou je jezelf willen inschrijven op de wiki aub ? dan kan je je op de medewerkers pagina zetten (link 2 posts hierboven)

De koppeling is wired ja, waarom zou dit niet haalbaar zijn ? Ik verwacht toch niet dat je met je gun gaat smijten. En de nauwkeurigheid wordt bepaald door een lenzensysteem dat van een diffuse IR led iets meer gerichter maakt.

[shorttracker]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:04:
Ik stel me ook de vraag hoe je de nauwkeurigheid van de (IR) gun beam doelgericht kan afstellen.
Direct zonlicht gaat toch invloed hebben om de reikwijdte van deze beam ?

ja, als je om 2uur 's middags speelt of om 10uur 's avonds, zal je idd een verschillende reikwijdte hebben. Dit is met elk licht zo, ook met lasers.

Ik ben alleen nog wel benieuwd hoever dat IR licht komt, en hoe breed die straal is.
Is de straal net zo breed als de lens?, of loopt hij iets uit?
Hheeft dit niet als gevolg dat je op verschillende plekken geraakt kan worden, bijv. borst en hoofd, of zelfs zo erg dat je verschillende spelers tegelijk kan raken?

[Verwijderd]

shorttracker schreef op zaterdag 17 maart 2007 @ 20:28:
[...]

Ik ben alleen nog wel benieuwd hoever dat IR licht komt, en hoe breed die straal is.
Is de straal net zo breed als de lens?, of loopt hij iets uit?
Hheeft dit niet als gevolg dat je op verschillende plekken geraakt kan worden, bijv. borst en hoofd, of zelfs zo erg dat je verschillende spelers tegelijk kan raken?

Idd, dit zal je enkel kunnen weten adhv testen vrees ik.

[Verwijderd]

tokesnugerd schreef op zaterdag 17 maart 2007 @ 20:11:
De koppeling is wired ja, waarom zou dit niet haalbaar zijn ? Ik verwacht toch niet dat je met je gun gaat smijten.

Het blijft vervelend, is dit ook zo in de commerciele games ?

[mithras]

Verwijderd schreef op zaterdag 17 maart 2007 @ 20:34:
[...]


Het blijft vervelend, is dit ook zo in de commerciele games ?

Zelfs het Nederlandse leger gebruikt een wired versie volgens mij

[Verwijderd]

tsja je kan ook bluetooth versies maken van gun+backpack, maar dat gedeelte laat ik dan maar effe aan jullie over denk ik zo...

Mss dat Naftebakje wel een ideetje heeft over zigbee?

Shht!! ok we gingen het dus nog even simpel houden

@ Sprite, ik begrijp het al wat beter, maar het effectief implementeren ervan blijft me echt heel wazig. Heb je soms een paar links ofzo?
Ik zie er echt alleen een soort van subroutines in die door een aanpasbare 'main' (dat script dan) aangeroepen worden, can't seem to get out of the box..

[gerre22]

Een ideetje eventueel, gebruik labview voor het uitlezen op pc. Valt redelijk snel mee uit te lezen, ondersteuning van usb en de hele rataplan. En programmeren gaat op zich simpeler als in C of java.

[Phalox]

Alleen is labview niet gratis.. gedaan met de open source. En het is veel te uigebreid voor wat we nodig hebben.
In andere gevallen zou het een goed programma zijn denk ik:)

[Sprite_tm]

Gerre22: Nah, dedicated programma's ervoor zitten zo inelkaar en zijn niet zo heel moeilijk om te schrijven als je kan proggen. Labview = overkill hiervoor.

Scud_racer: Als we de protocollen en evt. een VM hebben liggen, kunnen daarna eventueel verbindingen draadloos gemaakt worden jah, maar het lijkt me het handigst als we in de eerste instantie iets werkbaars maken. Draden zijn dan het meest obvious.

Slopert: We hebben er zelfs 3, als je ook een rf-verbinding wilt leggen: eentje voor de IR-guns, eentje voor de draden tussen onderdelen en eentje voor de RF-verbindingen. Verder is het hele idee van die VM dat de programma's die erop draaien configureerbaar zijn: friendly fire is een onderdeel van de 'spelregels' die op de VM draaien en als je die vergeten bent kan je desnoods nog in-the-field de mensen bijelkaarroepen om ze via IR even de nieuwe regels door te stralen.

[slopert]

Rf had ik ook al aan gedacht voor bv mijnen en gas wolken die rond moeten stralen. Dat is met IR moeilijker te bereiken, maar betekend wel weer een extra module. RF verbindingen zou je ook kunnen in een mesh network kunnen gebruiken om match info real time naar de game master te kunnen versturen. Ik kan me zo voorstellen dat in de gemiddelde match het bereik van IR te klein is om die afstanden te overbruggen. Zoals ik al gezegd heb, ik kan niet programmeren, maar nadenk over een model kan ik wel. Miscchien wel dat ik daar enigzins goed in ben +). Solderen kan ik ook en gestructureerd nadenken ook.

Over het bereik van de IR guns: Ik heb snel bekeken en de IR-diode kan een PIEK hebben van 1,5 A. Ik denk dat je daar ik de volle zon wel een eind mee moet komen, alleen zal dan het aantal schoten per seconde iets terug zal moeten om de diode niet te verbranden. Op dat moment zou de diode grofweg 1,5V x 1.5A = 2.25Watt verstoken.

[Martijn13]

Ik en mijn vrienden zijn bezig met het ontwerpen van een dergelijk systeem, waarbij er wél herladen moet worden tussendoor, dat is wel zo realistisch. Onderdelen zijn aangeschaft, er moet enkel nog een printplaatje ontworpen worden, maar het programmeerwerk is allemaal gedaan. Zal hier nog eens langs komen als het af is (~2 weken).

[gerre22]

Mja, student fysica hier eh. Studentenversie kost 50euries en wij gaan het hier veel nodig hebben op school vandaar dat het in me opkwam, was maar een gedacht.
Ik weet niet of ik kan helpen, meeste skills van me zijn theoretisch van aard. Maar werp me wel naar voor als test/ proef persoon.

[Sprite_tm]

Ik heb het geheel van de VM nog eens uitgebreid op de wiki gezet: http://sprite.student.utw...index.php/Virtual_Machine . Als je het nog niet snapt, dump je vragen in de talkpage ervan; ik snap dat het lastige stof is maar ik wil wel het idee zo goed mogelijk duidelijk maken.

Slopert: Bij nader inzien: RF is leuk, maar ik stel voor dat we die nog even uitstellen. Als we een intra-pak-communicatie-protocol hebben kunnen we die er nog altijd later aanknopen, en met een VM is het slechts een extra randapparaat. Het lijkt me practischer om eerst de ideeen hier uit te werken tot protocollen en uiteindelijk slechts een rudimentaur pak (sensoren, ir, that's it) aan de praat te krijgen. Daarna kunnen we fijn gaan uitbreiden, maar dan hebben we iig iets zichtbaars (en betatestbaars )

[gerre22]

Aha, na wat opzoek werk over IR remote controls ben ik erachter dat door de frequentie en de golflengte zo te kiezen bij infrarood licht je de invloeden van zonlicht en andere stralingsbronnen kan uitschakelen. Frequentie staat er niet op maar ik heb wel een golflengte gevonden van 980nm. Het nadeel is hier wel dat op de zender en ontvanger filters moeten staan.

edit: slechts een max afstand van 10m? kan iemand dit bevestigen? nvm

[ Voor 9% gewijzigd door gerre22 op 17-03-2007 22:39 ]

[slopert]

Ik ben met je eens dat er eerst een idee en een minimale (werkende) hardware configuratie moet zijn. Ik weet de complexiteit niet van RF. De 433MHz band is vrij voor gebruik, maar met lage vermogens.
Voor het pak stel ik voor om te gaan voor een bergbeklimmers gear, de electronica kan in een langwerpige behuizing op de rug gemaakt worden. Er zijn best wel klimmuren die (voor hun doel) afgekeurde sets hebben. Eventueel zou de accu seperaat op een andere plek gemonteerd kunnen worden (zak, voorkant + display)

[slopert]

@Gerre22 volgens mij zou dat 940nm moeten zijn. Check http://www.lasertagparts.com/order.htm . ik zeg niet dat deze hardware gebruikt zou moeten worden, maar voor hun heeft het duidelijk gewerkt. Waarom zou je daarvan afwijken? Maar dat zal dus in de HW specs moeten komen staan.

[gerre22]

Op de site van milesTag staat dus al heel de uitleg over hoe best een lenzensysteem op te zetten en welke ir leds te gebruiken. Dat valt dan gewoon zo te gebruiken.

Uitleg over de optiek

Enige verschil was dat ik nieuwere versie van de ledjes gevonden had.

[brinkdinges]

gerre22 schreef op zaterdag 17 maart 2007 @ 22:36:
Op de site van milesTag staat dus al heel de uitleg over hoe best een lenzensysteem op te zetten en welke ir leds te gebruiken. Dat valt dan gewoon zo te gebruiken.

Uitleg over de optiek

Enige verschil was dat ik nieuwere versie van de ledjes gevonden had.

Er komen heel vaak nieuwe leds uit. De leds die op lasertagparts staan zijn ook wel erg duur Via Corbin van world-led.com zijn alle soorten te regelen als je er genoeg af neemt, en ook een actie op samenkopen.net is erg goedkoop.

[gerre22]

Jah, ik was aan het zoeken geweest op leds met een behoorlijke range van zichzelf uit. Aangezien ik niet direct overtuigd was van lenzen. Hierbij kwam ik dan uit op IR lampen met een bereik van max 200 m via een 20tal leds. Daar opgezocht welke leds en zo voorts, prijs was dacht ik 0,65 euro. Wat dus 3 maal zo hoog is als op world-led.com, loopt blijkbaar een actie.

[brinkdinges]

Als je leds per 1000 of 10.000 aankoopt kun je flink wat met de prijzen doen. Samen inkopen kan dus wel lonen.

[Phalox]

Mjah.. 1 probleem, als je ontwikkelt heb je er nog niet zoveel nodig (omdat ze misschien niet goed zijn).

Als het project eenmaal "af" is zou dit wel handig kunnen zijn...

[Sprite_tm]

Gerre22: Lenzen zul je toch moeten gebruiken, anders ben je een heleboel licht kwijt: de beam die uit je barrel moet komen moet bijna evenwijdig zijn, of iig erg smal, en dan ben je veel efficienter met een lens dan dat je veel leds pakt en dan 99% blokkeert omdat het de verkeerde kant opgaat.

Edit: Kalibreren van zo'n lenssysteem is ook nog wel te doen: koop 3 (of meer) van die TSOP-dingen en knoop er rechtstreeks een ledje aan en je kan dat gebruiken als een soort ijkbank.

Is het trouwens een idee om een paar linkjes naar de wiki e.d. in de startpost op te nemen? Die zaken zijn atm nogal verscholen in de thread hier.

[ Voor 37% gewijzigd door Sprite_tm op 17-03-2007 23:19 ]

[Phalox]

jij bent de mod jij kan dat doen als meneertje poststarter nog eens langskomt, kan hij het ook doen.
Ik moet zeggen, de wiki heeft succes.. alleen is het nogal ingewikkeld om een forum na te bootsen.

[JanPaul123]

Een VM systeem klink handig maar is naar mijn idee overkill. Wat je volgens mij veel beter kunt doen, is alle game opties die je maar wil inbouwen in OpenLaserFrag, wat makkelijk kan aangezien het open source is. Zo kun je ook je eigen idee implementeren. Alle systemen worden vervolgens door middel van een bootloader via USB geprogrammeerd, zowel de versie van OpenLaserFrag, ofwel de nieuwste ofwel een eigen versie, en de settings per gun worden in het EEPROM geprogd (herlaadtijd, etc.)

Zo weet je zeker dat iedereen dezelfde versie van het spel heeft, maar heb je niet de lasten van het programmeren van een toch wel complex systeem als VM.

[Phalox]

VM kan handig zijn, maar dat valt te zien hoe ver je wilt gaan. Als je crossplatform gaat werken, dan is dat zeker een must (of je moet alles opnieuw ontwikkelen voor een platform)
Die EEPROM zit dan in het gun zelf ? En wat als er ooit aanpassingen komen aan de gun (of als er meer specs moeten toegevoegd worden ?)

[brinkdinges]

Gluggie schreef op zondag 18 maart 2007 @ 09:24:
Een VM systeem klink handig maar is naar mijn idee overkill. Wat je volgens mij veel beter kunt doen, is alle game opties die je maar wil inbouwen in OpenLaserFrag, wat makkelijk kan aangezien het open source is. Zo kun je ook je eigen idee implementeren. Alle systemen worden vervolgens door middel van een bootloader via USB geprogrammeerd, zowel de versie van OpenLaserFrag, ofwel de nieuwste ofwel een eigen versie, en de settings per gun worden in het EEPROM geprogd (herlaadtijd, etc.)

Zo weet je zeker dat iedereen dezelfde versie van het spel heeft, maar heb je niet de lasten van het programmeren van een toch wel complex systeem als VM.

Bij een bootloader laat je toch een klein stukje extra software in je pic? Dan zul je dus de spelregels enzo doorsturen. Ik vraag me alleen af of je een connector op je set wilt, of dat je de spelregels via IR wilt versturen.
Wat ik ervan begrepen heb is VM hardwareonafhankelijk, wat me wel erg makkelijk lijkt zolang dit soort spullen niet in massa's gemaakt worden, maar door iedereen thuis.

En zet even alle linkjes (van het forum en de wiki) in je topicstart

[ Voor 9% gewijzigd door brinkdinges op 18-03-2007 10:22 ]

[Phalox]

Forum heb ik terug uitgeschakeld dus die moet er niet op..

Als er later behoefte naar is, zal ik hem terug inschakelen.

[Borgoth]

ik lees net de spel modes op de wiki door. nu zie ik dat deathmatch en onderaan bij algemeen de eerste "algemene mode" bijde hetzelfe beschreven staat. Is dit bewust gedaan?

[Sprite_tm]

Dat soort wiki-specifieke dingen kan je imo beter op de talk-page van die pagina vragen is handiger dan hier naar de wiki refereren.

Is het trouwens een idee om wat knopen door te hakken?

* Welke proc gaan we gebruiken? Als we het geheel open-source willen maken lijkt me C het beste, er is namelijk voor de meeste uCs wel een C-variant te krijgen. De mogelijkheden van de C-varianten verschillen echter: gcc is bijvoorbeeld naar AVR en ARM geport, dus dat zit wel goed, maar de laatste keer dat ik checkte was de C-support voor PICs niet gratis en/of wat brakker dan GCC. Is dit nog steeds zo, en zoja, is het een idee om een AVR (of zelfs ARM) te pakken als hoofdproc? (Imo kunnen we de individuele randapparatuur alsnog wel op PICs uitvoeren, maar van de game-logic wil je zeker weten dat het overal hetzelfde draait)

* Pakken we een VM of pakken we geen VM? Ik ben zelf nogal voor, maar dat had je vast al door Argumenten voor zijn hier te vinden, check ook de talkpagina en vraag als je iets niet snapt.

* Gaan we voor het eerste ontwerp RF-communicatie wel of niet meenemen? Als we het niet doen kunnen we een aantal speltypen niet spelen, als we het wel doen zijn we langer bezig met ontwikkelen.

Stemmen zou hier kunnen, met een poll, maar het lijkt me practischer om het op de wiki te doen; dan kunnen alleen de ingeschreven mensen stemmen, en meteen de bezwaren erbij zetten:
http://sprite.student.utw...ag/index.php/KnopenHakken

[ Voor 8% gewijzigd door Sprite_tm op 18-03-2007 14:15 ]

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 14:09:
Dat soort wiki-specifieke dingen kan je imo beter op de talk-page van die pagina vragen is handiger dan hier naar de wiki refereren.

Is het trouwens een idee om wat knopen door te hakken?

* Welke proc gaan we gebruiken? Als we het geheel open-source willen maken lijkt me C het beste, er is namelijk voor de meeste uCs wel een C-variant te krijgen. De mogelijkheden van de C-varianten verschillen echter: gcc is bijvoorbeeld naar AVR en ARM geport, dus dat zit wel goed, maar de laatste keer dat ik checkte was de C-support voor PICs niet gratis en/of wat brakker dan GCC. Is dit nog steeds zo, en zoja, is het een idee om een AVR (of zelfs ARM) te pakken als hoofdproc? (Imo kunnen we de individuele randapparatuur alsnog wel op PICs uitvoeren, maar van de game-logic wil je zeker weten dat het overal hetzelfde draait)

* Pakken we een VM of pakken we geen VM? Ik ben zelf nogal voor, maar dat had je vast al door Argumenten voor zijn hier te vinden, check ook de talkpagina en vraag als je iets niet snapt.

* Gaan we voor het eerste ontwerp RF-communicatie wel of niet meenemen? Als we het niet doen kunnen we een aantal speltypen niet spelen, als we het wel doen zijn we langer bezig met ontwikkelen.

Sprite, ik wil niet vervelend doen, zeker niet tegen een moderator, maar als je de hele thread had gelezen had je gezien dat ik een prototype gemaakt heb op basis van de PIC18F2550, met software compatible met het milestag protocol. Het is lastig een open source project te beginnen zonder een beginnetje te hebben. Ik zal binnenkort alle details posten, maar het is erg overhaast om nu gelijk een VM-systeem met RF functionaliteit en meerdere guns, etc. te gaan maken dus laten we eerst vanuit dit beginnetje werken. OpenLaserFrag.org is bijna operationeel.

[Vuikie]

Ik heb mij ook ingeschreven op de wiki omdat mij dit een leuk project lijkt. Ik heb vroeger veel met vrienden lasergames gedaan, zelf zo'n gun maken lijkt mij wel wat.

Nu heb ik gelezen dat jullie met PIC's willen gaan werken, daar heb ik alleen geen ervaring mee, daarom lijkt mij zo'n VM wel heel handig om mee te werken.

Maar goed just my €0,02

[Sprite_tm]

Gluggie schreef op zondag 18 maart 2007 @ 14:19:
[...]

Sprite, ik wil niet vervelend doen, zeker niet tegen een moderator,

In deze thread ben ik gewoon een user hoor. Pas als je vervelend doet op een manier die tegen de regels ingaat kom je de moderator-Sprite tegen

maar als je de hele thread had gelezen had je gezien dat ik een prototype gemaakt heb op basis van de PIC18F2550, met software compatible met het milestag protocol. Het is lastig een open source project te beginnen zonder een beginnetje te hebben. Ik zal binnenkort alle details posten, maar het is erg overhaast om nu gelijk een VM-systeem met RF functionaliteit en meerdere guns, etc. te gaan maken dus laten we eerst vanuit dit beginnetje werken. OpenLaserFrag.org is bijna operationeel.

Klopt, en geloof me, ik heb er een hekel aan om al gemaakte keuzes en geschreven code in twijfel te trekken, ik weet hoe het aanvoelt. Ik heb echter het idee dat dit project kan uitgroeien dan meer dan nog een manier om met een bepaalde firmware een bepaald spel te spelen (dus gewoon net zoiets als milestag etc), naar een extendible iets waar in principe iedereen nieuwe spelregels voor kan verzinnen en nieuwe randapparatuur voor kan maken, hoe gek het ook inelkaarzit. Ik ben alleen bang dat als we dat doel willen halen, we eerst naar het uiteindelijke doel moeten kijken, en vanuit daar een klein beginnetje maken, ipv meteen al iets inelkaar willen zetten en daarbij misschien een aantal keuzes maken die later, als iedereen de hard- en software al inelkaar heeft zitten, ondoordacht blijken.

Misschien ben ik met het hele Vm-erin-en-portable-en-extendible-protocollen-overal-verhaal wat te ver doorgeschoten. In dat geval moet je me het gewoon zeggen en dan zul je me in deze thread ook een stuk minder zien: jij bent begonnen met het idee en om de groep nou nu al in tweeen te splitsen kan helemaal de doodslag voor zo'n jong project zijn. Zegt u het maar

[ Voor 4% gewijzigd door Sprite_tm op 18-03-2007 14:35 ]

[shorttracker]

Gluggie schreef op zondag 18 maart 2007 @ 14:19:
[...]

Sprite, ik wil niet vervelend doen, zeker niet tegen een moderator, maar als je de hele thread had gelezen had je gezien dat ik een prototype gemaakt heb op basis van de PIC18F2550, met software compatible met het milestag protocol. Het is lastig een open source project te beginnen zonder een beginnetje te hebben. Ik zal binnenkort alle details posten, maar het is erg overhaast om nu gelijk een VM-systeem met RF functionaliteit en meerdere guns, etc. te gaan maken dus laten we eerst vanuit dit beginnetje werken. OpenLaserFrag.org is bijna operationeel.

Ik denk dat dat VM-systeem wel een goed idee is. Ik heb geen idee hoe uitvoerbaar het is, maar ik geloof Sprite_tm wel..
Als je met dat VM-systeem gaat werken, moet je daarmee beginnen, dat kan je later niet toevoegen. RF en meerdere wapens enzo wel. (zover als ik de poll zie in de wiki denk ik dat RF nog even geduld moet hebben..)

Verder moet er al wel nagedacht worden welke functies je later allemaal wilt gaan toevoegen. Het protocol moet namelijk al wel gemaakt worden, dat is in een later stadium een stuk lastiger om nog te veranderen

[Vuikie]

Ehm gewoon even een brainwave van mij, ik zie dat veel mensen een VM te moeilijk vinden of eigenlijk stiekum niet gewoon niet snappen Maar is het mss wat makkelijker om in plaats van een VM een soort script taal te maken waarmee je bepaalde functies kan aanroepen die je dan via een interpreter kan draaien op je gun (uC). Hier kan je natuurlijk ook inbouwen dat als een gun een functie niet heeft die gewoon negeert, maar wel kan mee doen aan het spel type.


Al met al denk ik dat daar de echte uitdaging in zit, een systeem maken wat eigenlijk alles aan kan of in elk geval snel kan leren/upgraden.

[ Voor 3% gewijzigd door Vuikie op 18-03-2007 15:08 ]

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 14:33:
[...]

In deze thread ben ik gewoon een user hoor. Pas als je vervelend doet op een manier die tegen de regels ingaat kom je de moderator-Sprite tegen

[...]

Klopt, en geloof me, ik heb er een hekel aan om al gemaakte keuzes en geschreven code in twijfel te trekken, ik weet hoe het aanvoelt. Ik heb echter het idee dat dit project kan uitgroeien dan meer dan nog een manier om met een bepaalde firmware een bepaald spel te spelen (dus gewoon net zoiets als milestag etc), naar een extendible iets waar in principe iedereen nieuwe spelregels voor kan verzinnen en nieuwe randapparatuur voor kan maken, hoe gek het ook inelkaarzit. Ik ben alleen bang dat als we dat doel willen halen, we eerst naar het uiteindelijke doel moeten kijken, en vanuit daar een klein beginnetje maken, ipv meteen al iets inelkaar willen zetten en daarbij misschien een aantal keuzes maken die later, als iedereen de hard- en software al inelkaar heeft zitten, ondoordacht blijken.

Misschien ben ik met het hele Vm-erin-en-portable-en-extendible-protocollen-overal-verhaal wat te ver doorgeschoten. In dat geval moet je me het gewoon zeggen en dan zul je me in deze thread ook een stuk minder zien: jij bent begonnen met het idee en om de groep nou nu al in tweeen te splitsen kan helemaal de doodslag voor zo'n jong project zijn. Zegt u het maar

Kijk, ik vraag me gewoon af in hoeverre we een VM nodig hebben? We kunnen toch gewoon alle denkbare bouwstenen voor een spelmodus in de firmware inbouwen, zoals grootte van teams, wat er gebeurt als je geschoten wordt, etc. Vervolgens kun je deze opties zelf selecteren in een PC programma, waarna deze gebundeld wordt met de laatste firmware en naar het systeem wordt geupload. Hier nog even een plaatje van mijn idee.

[Verwijderd]

Sprite_tm schreef op zondag 18 maart 2007 @ 14:09:
* Pakken we een VM of pakken we geen VM? Ik ben zelf nogal voor, maar dat had je vast al door

Sprite, is een VM niet nogal overkill als je eigenlijk alleen maar een tokenized interpreter wilt implementeren?

[Sprite_tm]

Afterlife: Wat is uiteindelijk het verschil?

Gluggie: Het kan wel, maar dan ga je ervanuit dat iedereen precies dezelfde firmware/apparatuur/... heeft, en dat is iets waarvan ik vind dat je d'r in de praktijk niet vanuit mag gaan. Bovendien: als je echt alle mogelijke gametypes in je uC wilt bouwen, heb je te maken met redelijk veel ruimte om je code in te gooien, plus je moet een nette manier verzinnen om het te configgen, ... Verder is het zo dat op deze manier mensen sneller een nieuw gametype inelkaar kunnen zetten: in een VM kan je minder snel dingen stuk maken en kan je makkelijker debuggen dan in de echte firmware; ook mensen die verder niets met het project te maken hebben kunnen zo snel een game-idee realiseren.
Verder: sorry hoor, maar dat mooie diagram wat hierboven staat is iets waar ik verrekte weinig echt info uit kan halen...

Iedereen lijkt trouwens te denken dat een VM enorm veel codeerwerk is. Dat is het niet. VM-code bestaat eigenlijk alleen maar uit een redelijk grote statemachine, die voor 99% te implementeren is als een groot SELECT-statement en dus niet veel bytes programmaruimte of ram inneemt. Verder moet het interfacen met de randapparatuur, maar subroutines die je daarvoor nodig hebt zul je toch moeten schrijven, of je het nu aan een VM knoopt of niet.

[ Voor 110% gewijzigd door Sprite_tm op 18-03-2007 16:02 ]

[Standeman]

w00t. Wat een gaaf project!. Ik heb nog nooit stil gestaan dat er hier ook opensource projecten van konden zijn. Ik moet het hele draadje nog doorlezen, maar dat doe ik vanavond wel op mijn gemak.

Ik heb jaren lang ge-lasergamed (was in scheveningen, bestaat niet meer volgens mij) en ik vind het echt een super spel (leuker als paintballen).

Dus ik wil wel solliceteren

Mijn pros:
- Java (en een beetje C) development kennis
- Lasergame enthoustiast.
- Beetje electro kennis (Ben bezig met mijn Asuro Robotje ))

con's:
- Zo nu en dan weinig tijd


Maar goed, mijn interesse is gewekt en als ik mijn steentje kan bijdragen, lijkt me fantastisch!

[Verwijderd]

Sprite_tm schreef op zondag 18 maart 2007 @ 15:55:
Afterlife: Wat is uiteindelijk het verschil?

De drempel. Een VM klinkt moeilijk en ingewikkeld, terwijl een OpenLaserFrag interpreter toegankelijker overkomt. En face it, het is helemaal geen virtual machine.

Iedereen lijkt trouwens te denken dat een VM enorm veel codeerwerk is. Dat is het niet.

Natuurlijk is 't dat niet, maar in dit geval valt er niet zoveel te virtualiseren. De processor ligt vast, de gun ligt vast en de sensoren liggen vast. Een tokenized interpreter met wat loadable modules om bv diverse displays aan te sturen is dan een stuk lichter.

[ Voor 36% gewijzigd door Verwijderd op 18-03-2007 16:12 ]

[Sprite_tm]

Verwijderd schreef op zondag 18 maart 2007 @ 16:01:
[...]
De drempel. Een VM klinkt moeilijk en ingewikkeld, terwijl een OpenLaserFrag interpreter toegankelijker overkomt. En face it, het is helemaal geen virtual machine.

Dat hangt ervanaf hoe je het interpreteert; uiteindelijk komen de meeste (kleine) interpreters toch neer op een emulatie van een virtuele microprocessor, wat dus basically een virtual machine is. Kan jij anders een voorbeeld geven van hetgene wat jij bedoelt? Ik wil even weten of we hier elkaar puur en alleen semantisch niet snappen, of of ik iets over het hoofd gezien heb

Ik ben het wel met je eens dat 'scripttaal' wat minder imposant klinkt dan 'virtual machine', terwijl het uiteindelijk ongeveer hetzelfde is.

[Verwijderd]

Zie m'n edit hierboven.
Maar als jij de (tokenized) Basic interpreter van een ZX81 (mijn eerste computer) een VM vindt, dan is ons interpretatieverschil uitsluitend semantisch.

[ Voor 80% gewijzigd door Verwijderd op 18-03-2007 16:24 ]

[Loy]

wat gaat dat snle hier op GoT, ik ben 2 dagen weg, en er zijn weer 3 pagina's bijgekomen!

Persoonlijk ben ik heel erg voor het gebruiken van een VM, of inieder geval voor het eenvoudig game-types maken, wat snel kan met een VM+scripttaaltje.

Voor één van de protocollen zat ik te denken aan een serie bitjes die gestuurd worden, waarvan dan de eerste paar bits zijn gereserveerd voor een code met het soort gebeurtenis, gevolgd door een rits bits met de code van de afzender.
Dan krijg je op je pak dus binnen iets als dit:
<schiet><pietje>
<health><dokter1>
<schiet><mijn1>
etc. Via de centrale server (waar ik dus ook voor ben), kun je dan opzoeken of het friendly fire of niet was enzo.
Op deze manier weet je meteen dat je beschoten bent, en door wie, en iets later komt er bij dat het friendly fire of niet was.

Misschien kun je dit tussen het pak en de gun ook nog doen, zodat je gun een signaal geeft waarin je aangeeft dat ie moet schieten, op commando van iemand. Is die iemand ook degene in het bijbehorden pak, dan word er geschoten.
Je kunt het dan nog zo maken dat je gun ook op anderen gaat reageren, als ware je gun stuk ofzo.

<edit>
Op de wiki stond al wat over het protocol, maar denk hier asjeblieft eens over na. Dit lijkt me flexibeler, maar das mijn mening over een idee van mezelf

[ Voor 8% gewijzigd door Loy op 18-03-2007 16:38 ]

[Sprite_tm]

Ok, fair nuf. Ik denk dat een VM echter practischer is: deze kan gemiddeld kleiner geimplementeerd worden dan een tokenized interpreter. Je moet uiteindelijk meer moeite doen om je code naar iets wat de engine kent om te zetten, maar itt het tijdperk van de Z81 hebben we nu PCs die dat prima kunnen. Het zijn en blijven echter implementatiedetails: de vraag is op dit moment of we de spelregels in een uitgebreid, maar vast firmwareprogramma willen hebben of in een configurabel scripttaaltje.

Verder beweer je dat een VM overbodig is omdat er veel vastligt qua hardware: Ik denk juist dat de kracht van dit project kan wezen dat het zo open is dat iemand desnoods een implementatie op een andere proc of zelfs een PDA of een iPod kan schrijven, en alsnog vrolijk compatible kan blijven met iedereen anders zonder dat de gameregels opnieuw geschreven moeten worden of dat er verschillen in implementatie optreden. Ook heb je het voordeel dat de firmware zelf op een gegeven moment 'af' is: als de VM/scriptengine en de I/O-routines klaar zijn, kunnen extra sensoren en andere zaken in de VM/scriptcode afgehandeld worden. Op deze manier hoef je niet aan het begin van elk spelletje iedereen z'n apparatuur laten flashen, en word het ook voor minder die-hard computermensen toegankelijk.

[ Voor 26% gewijzigd door Sprite_tm op 18-03-2007 16:44 ]

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 16:37:
Ok, fair nuf. Ik denk dat een VM echter practischer is: deze kan gemiddeld kleiner geimplementeerd worden dan een tokenized interpreter. Het zijn en blijven echter implementatiedetails: de vraag is op dit moment of we de spelregels in een uitgebreid, maar vast firmwareprogramma willen hebben of in een configurabel scripttaaltje.

Verder beweer je dat een VM overbodig is omdat er veel vastligt qua hardware: Ik denk juist dat de kracht van dit project kan wezen dat het zo open is dat iemand desnoods een implementatie op een andere proc of zelfs een PDA of een iPod kan schrijven, en alsnog vrolijk compatible kan blijven met iedereen anders zonder dat de gameregels opnieuw geschreven moeten worden of dat er verschillen in implementatie optreden.

Maar de firmware hoeft dus niet vast te zijn. We kunnen het gewoon laden via een bootloader. Daarbij kun je zo ook de firmware als ons 'scripttaaltje' zien. Vervolgens kan de user heel makkelijk vanuit een programma aanvinken welke opties hij wil en daarmee een gamemode maken. En C is ook gewoon te compilen voor bijv. een PDA, alleen moet je andere interface modules maken.

Edit: en de wiki kan worden overgedragen als je wil

[shorttracker]

Loy schreef op zondag 18 maart 2007 @ 16:34:
Voor één van de protocollen zat ik te denken aan een serie bitjes die gestuurd worden, waarvan dan de eerste paar bits zijn gereserveerd voor een code met het soort gebeurtenis, gevolgd door een rits bits met de code van de afzender.
Dan krijg je op je pak dus binnen iets als dit:
<schiet><pietje>
<health><dokter1>
<schiet><mijn1>
etc. Via de centrale server (waar ik dus ook voor ben), kun je dan opzoeken of het friendly fire of niet was enzo.
Op deze manier weet je meteen dat je beschoten bent, en door wie, en iets later komt er bij dat het friendly fire of niet was.

<edit>
Op de wiki stond al wat over het protocol, maar denk hier asjeblieft eens over na. Dit lijkt me flexibeler, maar das mijn mening over een idee van mezelf

Een bericht dat binnenkomt, begint altijd met een teamID, vervolgens het spelerID. dat is byte 1
in byte 2 staat hoeveel schade er aangericht, hoeveel health erbij komt, ammo, enz..
een binnengekomen bericht ziet er dus zo uit:
011 01101 10100 1
team 3, speler 13. schade20, pariteit.

Het Milestag protocol is echt al goed uitgedacht hoor, ik zoek ook heeltijd wat er vergeten is, maar heb nog niets kunnen ontdekken

[Sprite_tm]

Gluggie schreef op zondag 18 maart 2007 @ 16:42:
[...]


Maar de firmware hoeft dus niet vast te zijn. We kunnen het gewoon laden via een bootloader. Daarbij kun je zo ook de firmware als ons 'scripttaaltje' zien. Vervolgens kan de user heel makkelijk vanuit een programma aanvinken welke opties hij wil en daarmee een gamemode maken. En C is ook gewoon te compilen voor bijv. een PDA, alleen moet je andere interface modules maken.

Edit: en de wiki kan worden overgedragen als je wil

Klopt, maar dat zou betekenen dat in het geval van flexibelere hardware iedereen aan het begin van een spel de firmware die bij zijn hardware hoort zelf in z'n apparatuur zou moeten flashen; je hebt namelijk niet 1 codebase die overal op draait. Kan wel maar lijkt mij een hoop gedoe. Een VM is ook veel gedoe, maar slechts eenmalig, tijdens het ontwikkelen. We kunnen natuurlijk besluiten dat dat geen probleem is of dat we standaardiseren op slechts 1 type uC/..., maar dan schiet je wel een stukkie van de openheid van alles weg imo. Desalniettemin is het een valide optie, natuurlijk.

Je hebt trouwens een DM over die wiki.

[Verwijderd]

Is Klikmij (E-bay link) niets iets om in het geweer te bowen ?
5watt IR licht lijkt me wel wat, de prijs even buiten beschouwing gelaten.

Als je dat proper kan bundelen heb je een mooie sniper

De A850-SB IR led kan ook 4 ampere piek verdragen, maar ik heb geen idee wat de beschikbaarheid van deze dingen zijn.
Bron

En om een visueel onderscheid tussen de verschillende team te maken is het misschien mogelijk om SMD RGB leds aan het pak te maken, alleen vrees ik dat de intensiteit van deze leds in daglicht zwaar zal tegenvallen.

[ Voor 34% gewijzigd door Verwijderd op 18-03-2007 17:09 ]

[mithras]

Met mijn gering kennis en de discussie die hier gevoerd wordt lijkt me een VM-achtige methode wel het makkelijkste. Echter kost het meer tijd, en misschien is dat ook de vraag: als "we" doorgaan op het vm-idee, hoeveel moeite kost het schrijven van de VM tov de rest van het programmeerwerk: de feitelijke aansturing van guns en sensoren etc.

Hoewel het natuurlijk een prachtig idee is, moet je ook in je achterhoofd houden dat wanneer je eerst 5 jaar bezig bent met de virtual machine en daarna in een week de rest schrijft, de moeite voor de vm niet echt opweegt tegen de tijd die het heeft gekost

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 16:50:
[...]


Klopt, maar dat zou betekenen dat in het geval van flexibelere hardware iedereen aan het begin van een spel de firmware die bij zijn hardware hoort zelf in z'n apparatuur zou moeten flashen; je hebt namelijk niet 1 codebase die overal op draait. Kan wel maar lijkt mij een hoop gedoe. Een VM is ook veel gedoe, maar slechts eenmalig, tijdens het ontwikkelen. We kunnen natuurlijk besluiten dat dat geen probleem is of dat we standaardiseren op slechts 1 type uC/..., maar dan schiet je wel een stukkie van de openheid van alles weg imo. Desalniettemin is het een valide optie, natuurlijk.

Je hebt trouwens een DM over die wiki.

De scripts zul je ook altijd op een of andere manier aan het begin van een spel erin moeten flashen, dat maakt helemaal geen verschil uit of je nou een script erin flasht of code die de uC gelijk kan draaien. Alleen is een script stukken minder efficient omdat die nog geparst moet worden. Voordeel is inderdaad dat het wel werkt op een andere processor, maar directe code kun je ook zo voor een ander systeem compileren, moet je alleen andere header bestanden gebruiken.

[Sprite_tm]

Klopt, maar dan moet je het wel compileren, en dus een laptop bij je hebben met een compiler etc.

Verder is het voordeel van een VM juist dat de logica voor 99% generiek in de (echte) firmware kan blijven: als je op de wiki bijvoorbeeld mijn voorbeeld-spelregel-script ziet en dan bedenkt dat dat naar <100bytes encodeert, snap je ws wel dat een VM-script makkelijk via infrarood overgezapped kan worden. Scheelt meteen weer firmware-update-kabels enzo: gewoon een stel IR-leds en een laptop (of ander storage-device) en je kan iedereen van de spelregels voorzien, welke hardware ze ook bij zich mogen hebben.

Edit: Ik heb de wiki-info trouwens net overgedaan aan Gluggie, de wiki zit dus tijdelijk ff dicht.

[ Voor 7% gewijzigd door Sprite_tm op 18-03-2007 17:11 ]

[wimjongil]

Leuk lijkt mij! Ik kan niet heel erg nuttig helpen, maar voor de geweren: ik heb een legergeweren encyclopedie Dan kan je daar wat uitkiezen (heb ook een pistolen encyclopedie).

[shorttracker]

whow die infrarood led is wel HEEEL ERG overkill denk ik...
Maar je heb gelijk, je kan daarmee een geweldige sniper maken, moet je hem wel goed af kunnen stellen.

Maar ik denk dat het nutteloos is zo'n sterke led, die led komt zo vreselijk ver, dat je neit eens meer zo precies kan richten.

[Phalox]

Nop, geweren mogen niet lijken op de echte.. anders kan je nog problemen krijgen met de politie.

En het is hier een aardige discussie.. de initiatiefnemer tegen 3/4 van andere 'deelnemers'. Dat wordt hier nog moeilijk! Maar, wie kan er eigenlijk met zo'n VM dinges werken ?
Alles moet nog haalbaar zijn om ineen te steken.

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 17:07:
Klopt, maar dan moet je het wel compileren, en dus een laptop bij je hebben met een compiler etc.

Verder is het voordeel van een VM juist dat de logica voor 99% generiek in de (echte) firmware kan blijven: als je op de wiki bijvoorbeeld mijn voorbeeld-spelregel-script ziet en dan bedenkt dat dat naar <100bytes encodeert, snap je ws wel dat een VM-script makkelijk via infrarood overgezapped kan worden. Scheelt meteen weer firmware-update-kabels enzo: gewoon een stel IR-leds en een laptop (of ander storage-device) en je kan iedereen van de spelregels voorzien, welke hardware ze ook bij zich mogen hebben.

Edit: Ik heb de wiki-info trouwens net overgedaan aan Gluggie, de wiki zit dus tijdelijk ff dicht.

Nee, bij mijn idee hoef je het niet ter plekke te compileren! Ik moet het misschien nog wat helderder uitleggen. We maken 'firmware': dat wil zeggen C code die je moet compileren voor PIC, AVR, whatever. In deze C code hebben we allerlei opties geïmplementeerd waarmee je een game mode kunt samenstellen. Bijvoorbeeld: gebruik x bits van de PlayerID als TeamID (bij milestag standaard 3), of herladen duurt x seconden, of als je datapakket x binnenkrijgt word je geheald, etc. etc. Dit zijn allemaal opties die je aan de 'firmware' kan toevoegen in de laatste bytes (EEPROM) gedeelte. Dit kan een laptop doen, maar ook een willekeurige andere device. Je bakt dus als het ware je custom firmware. Bijkomend voordeel is dat je zo zeker weet dat iedereen dezelfde firmware draait. Als je een interpreter/VM gebruikt, kunnen mensen hun eigen interpreter aanpassen dat ze bijvoorbeeld nooit hun health decreasen. Maar dit terzijde. Vervolgens wordt de custom firmware aan het begin van de ronde in de geweren geladen. Dit kan via USB/IR/whatever. PIC's hebben namelijk een zelfprogrammerend vermogen. Je kunt dus een bootloader schrijven die laden via IR accepteert.
(En het is niet zo dat je de bootloader zodanig kunt programmeren dat die stiekem zo'n health dingetje gaat veranderen, omdat de bootloader zichzelf moet uitlezen voor controle, en je kunt een beperkt aantal geheugenbytes voor de bootloader reserveren, zodat er niet genoeg ruimte kan zijn om dit controle proces te gaan corrupten.)

Edit: wiki op http://www.openlaserfrag.org

[Sprite_tm]

Ten eerste: Cheaten kan altijd. Met het VM-idee zelfs nog wat lastiger: omdat de health gewoon een variabele in het VM-programma is, kan de firmware niet zo 123 uitvogelen welke variabele, if any, het precies is; daarvoor zou je heuristics ofzo moeten bouwen. On the other hand: als je je bootloader wilt corrumperen kan dat altijd: 'checksum de data en geef dat door' zal altijd meer bytes innemen dan 'geef deze vaste data door'. Imo zou je zowiezo ervanuit moeten gaan dat mensen niet cheaten; het is maar een spel en als je kinderachtig genoeg bent om te cheaten, verlink je jezelf toch wel op een gegeven moment.

Het probleem wat ik heb is met het uploaden van 'de firmware'. Als je aan het begin van een spel slechts een aantal vaste configuratieopties mee zou geven (shot-damage, of friendly fire mag, speltype, ...) zou het niet zo'n ramp zijn; als mensen eigen hardware meenemen moeten ze gewoon zorgen dat die opties ondersteund zijn. Is een manier, maar het nadeel is dat iedereens firmware up-to-date moet zijn en de opties van het spel moet ondersteunen. Als iemand achterloopt met het implementeren van de nieuwste gamecore op zijn hardware, heeft 'ie per default pech.

De andere optie is dat je een complete firmware overzapped aan het begin van een spel. Kan ook wel, maar dat betekent dus dat je voor elke implementatievariant drivers moet hebben, plus een compiler voor de proc die erinzit etc. Dat betekent ook dat als iemand een randapparaat verzint waar een custom driver bijhoort, hij die driver dus eerst in de main code moet zien te krijgen voor 'ie het kan gebruiken. Het laatste probleem is dat de firmware op die manier snel boven de tientallen Ks kan uitkomen, wat betekent dat het een stuk slechter over een IR-verbinding te sturen is.

[ Voor 3% gewijzigd door Sprite_tm op 18-03-2007 17:46 ]

[Loy]

Het idee van Gluggies systeem is wel het zelfde, maar wil je iets veranderen, bijvoorbeeld de actie die ondernomen moet worden bij healen, is hetnadeel dat je dan voor alle verschillende deelnemende uC's apart dit moet hardcoden in C, en voor alle uC's moet compilen, en apart uploaden en in het programmageheugen oid moet zetten.
Als je daarentegen één keer voor alle uC's een VM maakt, die voor iedere uC potentieel wat anders is in code, kun je daar altijd mee vooruit, en per spelletje alleen een x aantal kopieën van het zelfde script doorzenden is genoeg om meteen weer aan de gang te gaan.

Voordeel van Gluggies systeemdat het ongetwijfeld sneller is, qua uitvoering en qua programmeerwerk.

Voor zover ik kan zien, met mijn kennis, zit de afweging hem puur in de tijd:

• de VM kost toch wel meer tijd om te maken dan een enkel programma voor een enkele gametype.
  Die extra tijd is tijdens het ontwikkelen.
• tijdens het wisselen van spel voor alle deelnemende uC's apart het nieuwe spel compileren en in de uC zetten. Dit is uiteraard net nadat je enthousiast aan het schieten en rennen was.

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 17:45:
Ten eerste: Cheaten kan altijd. Met het VM-idee zelfs nog wat lastiger: omdat de health gewoon een variabele in het VM-programma is, kan de firmware niet zo 123 uitvogelen welke variabele, if any, het precies is; daarvoor zou je heuristics ofzo moeten bouwen. On the other hand: als je je bootloader wilt corrumperen kan dat altijd: 'checksum de data en geef dat door' zal altijd meer bytes innemen dan 'geef deze vaste data door'. Imo zou je zowiezo ervanuit moeten gaan dat mensen niet cheaten; het is maar een spel en als je kinderachtig genoeg bent om te cheaten, verlink je jezelf toch wel op een gegeven moment.

Checksummen duurt langer, maar uitlezen niet. Als je eerst de hele firmware overzendt en daarna weer terug kun je het controleren. (Is wel minder praktisch trouwens als je het via IR doet...) En als ie niet terug wordt gezonden heb je sowieso te maken met een corrupt bootloader. Maar laten we ons hier inderdaad even niet op concentreren.

Sprite_tm schreef op zondag 18 maart 2007 @ 17:45:
Het probleem wat ik heb is met het uploaden van 'de firmware'. Als je aan het begin van een spel slechts een aantal vaste configuratieopties mee zou geven (shot-damage, of friendly fire mag, speltype, ...) zou het niet zo'n ramp zijn; als mensen eigen hardware meenemen moeten ze gewoon zorgen dat die opties ondersteund zijn. Is een manier, maar het nadeel is dat iedereens firmware up-to-date moet zijn en de opties van het spel moet ondersteunen. Als iemand achterloopt met het implementeren van de nieuwste gamecore op zijn hardware, heeft 'ie per default pech.

Nee, dat is natuurlijk totaal niet praktisch. Was ook niet mijn idee .

Sprite_tm schreef op zondag 18 maart 2007 @ 17:45:
De andere optie is dat je een complete firmware overzapped aan het begin van een spel. Kan ook wel, maar dat betekent dus dat je voor elke implementatievariant drivers moet hebben, plus een compiler voor de proc die erinzit etc. Dat betekent ook dat als iemand een randapparaat verzint waar een custom driver bijhoort, hij die driver dus eerst in de main code moet zien te krijgen voor 'ie het kan gebruiken. Het laatste probleem is dat de firmware op die manier snel boven de tientallen Ks kan uitkomen, wat betekent dat het een stuk slechter over een IR-verbinding te sturen is.

Maar alle implementatievarianten lijken ongelovelijk op elkaar. Het is allemaal schieten, herladen, enzovoorts.

Ik denk dat het dan zelfs makkelijker is om alle ideeën in één stuk code te houden, die dan misschien lastiger op bugs te controleren is, maar die ALS het goed werkt, het ook gelijk goed doet met alle gameplay modes. Als je voor elke gameplay mode echter een los script gaat schrijven, en je gaat verbeteringen in een core feature maken, dan moet dat met ALLE scripts! Het lijkt mij een stuk onoverzichtlijker.

Bovendien, er zijn maar een aantal uC's die voor ons idee in aanmerking komen (PIC, Atmel, Basic Stamp), dus het compileren van 2 of 3 verschillende 'edities' lijkt me niet echt een punt.

Loy schreef op zondag 18 maart 2007 @ 17:52:
Het idee van Gluggies systeem is wel het zelfde, maar wil je iets veranderen, bijvoorbeeld de actie die ondernomen moet worden bij healen, is hetnadeel dat je dan voor alle verschillende deelnemende uC's apart dit moet hardcoden in C, en voor alle uC's moet compilen, en apart uploaden en in het programmageheugen oid moet zetten.
Als je daarentegen één keer voor alle uC's een VM maakt, die voor iedere uC potentieel wat anders is in code, kun je daar altijd mee vooruit, en per spelletje alleen een x aantal kopieën van het zelfde script doorzenden is genoeg om meteen weer aan de gang te gaan.

Voordeel van Gluggies systeemdat het ongetwijfeld sneller is, qua uitvoering en qua programmeerwerk.

Voor zover ik kan zien, met mijn kennis, zit de afweging hem puur in de tijd:

• de VM kost toch wel meer tijd om te maken dan een enkel programma voor een enkele gametype.
  Die extra tijd is tijdens het ontwikkelen.
• tijdens het wisselen van spel voor alle deelnemende uC's apart het nieuwe spel compileren en in de uC zetten. Dit is uiteraard net nadat je enthousiast aan het schieten en rennen was.

Er hoeft niet een heel spel opnieuw gecompileerd te worden! Het uploaden van een andere spelvariant is gewoon te vergelijken met dat van een script zoals Sprite voorstelt. Instellen van parameters en uploaden maar. De firmware wordt dan samengevoegd met deze parameters en geupload. Daar hoeft niet opnieuw voor gecompileerd te worden!

[MrNGm]

Leuk topic. Ik ga het zeker volgen.... Eventueel wil ik nog wel meedoen met het een en ander

[Sprite_tm]

Gluggie schreef op zondag 18 maart 2007 @ 18:22:
Maar alle implementatievarianten lijken ongelovelijk op elkaar. Het is allemaal schieten, herladen, enzovoorts.

Ik denk dat het dan zelfs makkelijker is om alle ideeën in één stuk code te houden, die dan misschien lastiger op bugs te controleren is, maar die ALS het goed werkt, het ook gelijk goed doet met alle gameplay modes. Als je voor elke gameplay mode echter een los script gaat schrijven, en je gaat verbeteringen in een core feature maken, dan moet dat met ALLE scripts! Het lijkt mij een stuk onoverzichtlijker.

Bovendien, er zijn maar een aantal uC's die voor ons idee in aanmerking komen (PIC, Atmel, Basic Stamp), dus het compileren van 2 of 3 verschillende 'edities' lijkt me niet echt een punt.

Ten eerste vraag ik me dat af... ik denk dat ik bijvoorbeeld van een GP2X of een iPaq een prima en (als je 'm al hebt) goedkope console kan maken. Heb je alweer 2 platforms erbij. Ten tweede kan je met 1 firmware slechts 1 set hardware ondersteunen. Als ik bijvoorbeeld een geweer heb met daarop iets ingewikkelds als een vingerscanner of zelfs iets simpels als een sensor op het geweer ipv via de bus aangesloten, zorgt de firmware die je upload naar mijn geweer als het spel begint ervoor dat die niet meer werken, en misschien zelfs mijn custom hardware stuk maken of meer niet meer laten functioneren.

Er hoeft niet een heel spel opnieuw gecompileerd te worden! Het uploaden van een andere spelvariant is gewoon te vergelijken met dat van een script zoals Sprite voorstelt. Instellen van parameters en uploaden maar. De firmware wordt dan samengevoegd met deze parameters en geupload. Daar hoeft niet opnieuw voor gecompileerd te worden!

Juist wel. Hetzij je ziet de firmware als een 'blob' waar je een stel regel-instellingen als datageheugen achteraankleit, waarbij we bij de 1e optie uitgekomen zijn die ik noemde, hetzij je gooit de spelregels dynamisch in de firmware, waardoor je alsnog een compile- of op z'n minst een linkactie zou moeten doen, die voor elke proc dus weer anders is.

[JanPaul123]

Sprite_tm schreef op zondag 18 maart 2007 @ 19:14:
[...]

Juist wel. Hetzij je ziet de firmware als een 'blob' waar je een stel regel-instellingen als datageheugen achteraankleit, waarbij we bij de 1e optie uitgekomen zijn die ik noemde, hetzij je gooit de spelregels dynamisch in de firmware, waardoor je alsnog een compile- of op z'n minst een linkactie zou moeten doen, die voor elke proc dus weer anders is.

Ik zie het als een blob waar je regel-instellingen achteraankleit, maar dat betekent niet dat mensen met oude firmware een probleem hebben. Sterker nog, de firmware (nieuwste!) + de regel-instellingen worden samen geüpload.

[Sprite_tm]

Gluggie schreef op zondag 18 maart 2007 @ 19:24:
[...]

Ik zie het als een blob waar je regel-instellingen achteraankleit, maar dat betekent niet dat mensen met oude firmware een probleem hebben. Sterker nog, de firmware (nieuwste!) + de regel-instellingen worden samen geüpload.

Ok, maar daarmee besluit je dus nog steeds dat iedereen precies dezelfde hardware moet hebben (of iig alleen maar hardware die ook daadwerkelijk door de firmware ondersteund is en niets anders.) Is dat wat je wilt? Imo ben je dan gewoon weer een variant op het MilesTag-systeem aan het maken, maar dan met een net iets makkelijker te krijgen source.

[ Voor 10% gewijzigd door Sprite_tm op 18-03-2007 19:27 ]

[ShadowLord]

Ik heb wat op de Wiki gezet (KopenHakken pagina). Dat hoef ik hier niet meer te herhalen denk ik

Uiteraard ben ik -voor- RF
Oh, iemand snapte mijn bewoording van 'server' niet. Ik bedoelde niet een PC als RF server, maar gewoon een uC met (groter) LCD display en RF unit. Deze uC kan dan game master zijn, bijhouden wie er speelt (en dat ook communiceren). Ook kan de server centrale commando's geven en gebruikt worden om game rulesets te uploaden naar de spelers. Dan hoef je helemaal geen laptop/PC te hebben om te gaan gamen.

Gewoon een VM package uitkiezen voor je spelsoort en dan iedereen laten aanmelden bij de game. Dan kan de server de gamecode gelijk uploaden.
En iedereen kan gelijk iedereen aan het scorebord kan worden toegevoegd. Ook kan de server als het nodig is teamindeling bepalen (door de beheerder of random bijvoorbeeld).

Ook game start & end kan gesynchroniseerd worden.

[Verwijderd]

shorttracker schreef op zondag 18 maart 2007 @ 17:14:
whow die infrarood led is wel HEEEL ERG overkill denk ik...
Maar je heb gelijk, je kan daarmee een geweldige sniper maken, moet je hem wel goed af kunnen stellen.

Maar ik denk dat het nutteloos is zo'n sterke led, die led komt zo vreselijk ver, dat je neit eens meer zo precies kan richten.

Zo een zaken kan je alleen maar weten door ze te testen.

Moesten we toch power tekort komen zijn deze 2 'leds' een hele stevige backup lijkt me zo

[Kek]

Verwijderd schreef op zondag 18 maart 2007 @ 19:46:
[...]


Zo een zaken kan je alleen maar weten door ze te testen.

Moesten we toch power tekort komen zijn deze 2 'leds' een hele stevige backup lijkt me zo

mag je ook wel een lekkere lood accu menemen, anders is je battery pack zo leeg maar ik denk niet dat we die led ooit nodig moeten hebben

[Verwijderd]

Kek schreef op zondag 18 maart 2007 @ 19:58:
[...]


mag je ook wel een lekkere lood accu menemen, anders is je battery pack zo leeg maar ik denk niet dat we die led ooit nodig moeten hebben

We monteren dat gewoon op zo een jeep met geweer op dak

[Phalox]

Jah wadde, hoe groot verwacht jij dat het domein gaat zijn?! Stoormvoorziening is een zorg voor later. De onderdelen moeten gewoon een beetje spaarzaam zijn.

Daarom een rugzak, kanje hem volstauwen !!

[Zsub]

Verwijderd schreef op zondag 18 maart 2007 @ 20:09:
[...]


We monteren dat gewoon op zo een jeep met geweer op dak

Warthogs ftw =P

Anyhow.

Als je zo'n VM schrijft, met een script-achtige gamemode interface, dan kan je die toch dusdanig construeren dat je niet telkens je scripts aan hoeft te passen? Ik denk bijvoorbeeld aan GTA: SA Multiplayer met PAWN... Dat script wel heerlijk makkelijk in C-stijl... En als je één core-VM hebt kan je zorgen dat iedereen die mee wil spelen zoiets thuis al in z'n geweer kan laden, of wat voor apparaat dan ook. Zoiets moet alleen wel gecompiled worden voor die specifieke architectuur natuurlijk, waardoor weer alleen de wat 'nerderigere' types zouden kunnen meedoen...

Imho (en ja ik weet dat ik me niet aangemeld heb en ja ik weet dat ik bepaald geen programming-guru ben) zou het handig zijn als je een VM schrijft in C, met een compiler voor één bepaalde hardware set waarvan je dan schema's op je site zet, of die je kant en klaar of als bouwpakket verkoopt. Als iemand dan zelf dingen wil bouwen zal die persoon ook wel slim genoeg zijn de VM naar die hardware te compilen...

[Verwijderd]

tokesnugerd schreef op zondag 18 maart 2007 @ 20:17:
Jah wadde, hoe groot verwacht jij dat het domein gaat zijn?! S

Relax, het was een grap

[Scout77]

Toch nog even over VM, het is me nog niet helemaal duidelijk

Zelf ben ik beter thuis in php en mysql enzo, dus ik probeer het daar even mee te vergelijken.

Is VM nu hetzelfde als een soort DB abstraction zoals je met Pear voor php kan doen. Dus dat je eigenlijk standaard commando's hebt voor verschillende functies en dat dan de VM de codes vertaald naar hardware specieke "taal"? Zoals dus pear de db commandos kan vertalen naar mysql, oracle of sql?

Als dat zo is ben ik zeker voor, alhoewel ik niet zou weten hoe dat zou moeten worden geimplementeerd.

[ Voor 10% gewijzigd door Scout77 op 18-03-2007 20:38 ]

[BrennuS]

Mensen wat een super idee.

Ik volg deze thread sinds enkele dagen en ben reuze geintresseerd!!!

Mijn ervaring ligt op het webgebied php/sql/*nix en heb weinig/een beetje ervaring met solderen dus kan jullie niet echt steunen.

ik hoop wel dat ik mijn ideeen mag geven...

MBT RF is het mogelijk om hier een soort van p2p op te maken. op die manier kunnen gegevens per suit naar uitgewisseld worden op het moment dat deze in range is. deze gegevens kun je dan door sturen naar een team leader of server points. idee is dus niet continuee uitwisselen maar een verbinding op het moment dat teamgenoten in bereik zijn. denk aan bv:

• time sync
• ammo check ivm speciale wapens (granaten die over zijn)
• team stats

[Kek]

p2p RF had ik ook aan gedacht, en zou uiteindelijk een mooie optie zijn, maar wel heel erg meoilijk te realiseren, je krijgt dan een soort tcp/ip achtige protocol.

[Borgoth]

offtopic:
@Sprite_tm: de wiki op je site ligt er uit.

[Phalox]

http://www.openlaserfrag.org/wiki/ -> een volledig dedicated site

[ShadowLord]

Kek schreef op zondag 18 maart 2007 @ 20:59:
p2p RF had ik ook aan gedacht, en zou uiteindelijk een mooie optie zijn, maar wel heel erg meoilijk te realiseren, je krijgt dan een soort tcp/ip achtige protocol.

Protocol is het makkelijkste. Daar zijn er al 100-en van waar je er zo een van kan kiezen. Het ethernet is bijvoorbeeld een voorbeeld om met tegelijk sprekende apparaten om moet gaan (en ja, dat werkt niet goed voor RF, maar er zijn dus best goede mogelijkheden die zo 'op de plank' liggen).

[Verwijderd]

Persoonlijk vind ik P2P een beetje erover.. als je dan toch RF gaat werken kan je beter met 1 centrale werken die alle data ontvangt en ze eventueel doorzend naar desbetreffende spelers, zo kan je op een centraal punt ook de data aanpassen en weet iedereen in 1 team evenveel, zonder dat ze vlak naast elkaar moeten staan bij wijze van spreken.

[shorttracker]

Verwijderd schreef op maandag 19 maart 2007 @ 10:57:
Persoonlijk vind ik P2P een beetje erover.. als je dan toch RF gaat werken kan je beter met 1 centrale werken die alle data ontvangt en ze eventueel doorzend naar desbetreffende spelers, zo kan je op een centraal punt ook de data aanpassen en weet iedereen in 1 team evenveel, zonder dat ze vlak naast elkaar moeten staan bij wijze van spreken.

Daar ben ik het ook mee eens. Bovendien moet je voor P2P een heleboel schakelaars? gaan plaatsen ergens op je pak.
Minimaal een stuk of 8, bovendien moet je een telefoonboek mee nemen voor dat ene getalletje van die persoon waar je een berichtje naartoe wil sturen..

[Sprite_tm]

Errm, volgens mij zit je verkeerd te denken, shorttracker. Met p2p word bedoeld dat je een netwerk hebt van alle spelers, en dat een pakketje van a naar het basisstation bijvoorbeeld eerst langs spelers b, c, d en e hopt en zo uitkomt op het basisstation. Het voordeel is dat je zelfs als een directe jij->basisstation-verbinding niet bestaat, je toch kan communiceren. Het nadeel is idd dat je protocol lastiger word.
Wat er in die berichten staat is verder niet zo belangrijk, maar dat zal toch in de eerste instantie gamedata zijn, en pas later SMS-achtige data. Voice moet je imo helemaal niet aan denken; dat gaat je veel te veel bandbreedte kosten waardoor de prijs van de modules enorm op kan lopen. Misschien dat dat er later bijingezet kan worden, maar omdat het zo weinig met de spellogica zelf te maken heeft, denk ik dat het practischer is om dat met walkietalkies ofzo te doen.

[ShadowLord]

Ik denk dat je ene cmbi zal hebben van P2P en server comms. Ligt er maar helemaal aan wat voor communicatie het is. Je wil niet een stukje informatie wat 2 spelers moeten uitwisselen over een server laten lopen. Maar het gros van de communicatie zal idd client/server zijn. P2P zal meer voor team messages e.d. zijn denk ik.

Edit: Over voice: voice wil je sowieso niet digitaal gaan doen, tenzij je geld wil uitgeven aan zwaardere processors en transcievers. Maar analoge voice, (maar kanaal bepaald door de Uc) is zeker een mogelijkheid. Ben het sowieso met Sprite eens dat we in het begin zeker nog niet over onze eigen voice units moeten denken. Daar zijn walkietalkies nu zeker geschikt voor.

[ Voor 36% gewijzigd door ShadowLord op 19-03-2007 12:10 ]

[JanPaul123]

Hoe gaan we geluid eigenlijk realiseren?

[Sprite_tm]

Mmm, da's een leuke. Ik denk dat het het practischst is om daar ook weer een randapparaat van te maken. De hoofdcontroller gooit er een commando als 'speel het gunshot-geluid af' en afhankelijk van de uitvoering ontstaat er een bliepje, een ruisig gunshot-iets of een in flac opgenomen en met digitale synthesese van een SD-kaart afgespeeld in een studio opgenomen gunshot-geluid Je zou er zelfs voor dove mensen een stel leds voor kunnen laten branden of een vibrator aan kunnen hangen; zolang het weggeabstraheerd is hoe het geluid uiteindelijk gemaakt word niet belangrijk.

[shorttracker]

ahh, wordt het zo bedoeld:P Maar zelfs dan denk ik dat die centrale server beter is;) En voice denk ik ook hoor dat dat nog even moet wachten, walkietalkie's zijn daar erg geschikt daarvoor.

[shorttracker]

Milestag gebruikt ook een apparte geluidmodule:
http://www.lasertagparts.com/mtsounds.htm

(oeps, had edit moeten doen)

[ Voor 15% gewijzigd door shorttracker op 19-03-2007 12:21 ]

[Loy]

wat, maken lasers niet zelf een gaaf geluid?
In beginsel kunnen we er een simple piezo-speakertje opzetten, dat een simpel geluid maakt.
Iets van geluid als je schiet of geraakt word is wel een vereiste, vind ik.

misschien kunnen we later iets als dit of wat uit deze lijst gebruiken

[JanPaul123]

shorttracker schreef op maandag 19 maart 2007 @ 12:20:
Milestag gebruikt ook een apparte geluidmodule:
http://www.lasertagparts.com/mtsounds.htm

Die chip wordt niet meer geproduceerd...

En het lijkt me natuurlijk het beste dit niet als losse module te doen maar gelijk te integreren

[ Voor 16% gewijzigd door JanPaul123 op 19-03-2007 12:21 ]

[shorttracker]

Gluggie schreef op maandag 19 maart 2007 @ 12:21:
[...]


Die chip wordt niet meer geproduceerd...

En het lijkt me natuurlijk het beste dit niet als losse module te doen maar gelijk te integreren

als die niet meer gemaakt worden moet er dus een beter alternatief zijn...
ff een kwestie van goed zoeken, maar de opzet van dat bordje is goed denk ik?

[BrennuS]

[lol]
kunnen we er meteen een vibrator/schok per bodypart aanhangen?

is wel realistisch geraakt worden en iemand horen kermen....
[/lol]

[shorttracker]

BrennuS schreef op maandag 19 maart 2007 @ 12:26:
[lol]
kunnen we er meteen een vibrator/schok per bodypart aanhangen?

is wel realistisch geraakt worden en iemand horen kermen....
[/lol]

ghehe, zoeits als dit?
Klik voor Force-feedbackjasje-laat-gamers-pijn-lijden

[Standeman]

Ik moet eerlijk zeggen dat ik ook wel gecharmeerd ben van de "VM oplossing" van sprite. Zeker in Java is zoiets ontzettend makkelijk te maken nu v6 uit is. Daaraan kan je nu ook met scripting talen tegen aan praten (ECMA / Python) en is dus super makkelijk te leren.
Ik denk alleen dat PIC's die java snappen wat duur zijn (geen flauw idee eigenlijk wat die dingen kosten)

Ik ga me denk ik even verdiepen in het milestag protocol om te zien wat dat nou inhoud. Als ik ideeen heb, zal ik ze wel spuien.

[Scout77]

Als geluidmodules gebruiken ze bij milestag en fragtag, ISD modules. Zijn te vinden bij riechelt.de maar zijn niet goedkoop.

ISD 2560 P Voice Record, 60 sec, DIL-28 12.80 €
ISD 2590 P Voice Record, 90 sec, DIL-28 18.35 €

Dacht ooit eens begrepen te hebben dat die 90sec dingen eigenlijk dezelfde opslag capaciteit hebben en het geluid dus op een mindere kwaliteit opslaan.

[JanPaul123]

Scout77 schreef op maandag 19 maart 2007 @ 12:40:
Als geluidmodules gebruiken ze bij milestag en fragtag, ISD modules. Zijn te vinden bij riechelt.de maar zijn niet goedkoop.

ISD 2560 P Voice Record, 60 sec, DIL-28 12.80 €
ISD 2590 P Voice Record, 90 sec, DIL-28 18.35 €

Dacht ooit eens begrepen te hebben dat die 90sec dingen eigenlijk dezelfde opslag capaciteit hebben en het geluid dus op een mindere kwaliteit opslaan.

Maar die chips zijn gemarkeerd als End Of Life, ze worden niet meer ondersteund en binnenkort niet meer gemaakt e.d. Geen goede keus dus. Maar die andere chips van Winbond kan ik nergens vinden waar je die een beetje goedkoop kunt krijgen.

[Sprite_tm]

Met de huidige uCs en een beetje leuke adpcm-compressie is geluid op zich ook wel te maken met een 24c512 ofzo (voor opslag) en een kleine uC die een beetje rap draait. Worst case hang je er een oud MMC/SD-kaartje aan en sla je je geluiden gewoon als 16bit, 48KHz WAV op. Ook dit is echter iets wat we later kunnen uitbreiden: in de eerste instantie zouden bliebbliep-geluidjes voldoende moeten wezen om het idee over te brengen, later kunnen we altijd nog complete sample-processors e.d. toevoegen.

Gluggie: In principe kunnen we beide wel doen: in de eerste instantie laten we geluid aan de hoofdprocessor over, maar zodra er een betere oplossing is kan die evt. ook extern aangesloten worden.

Ik heb trouwens een stel requirements neergezet. Als we het erover eens zijn wat de requirements voor de eerste mijlpaal zijn en hoe we die gaan bereiken, kunnen we denk ik aan het coden en hardware ontwerpen gaan Ze staan hier

[ Voor 5% gewijzigd door Sprite_tm op 19-03-2007 12:58 ]

[Scout77]

Opzich hebben ze bij winbond nog meer chips die niet EOL zijn volgens mij http://www.winbond-usa.com/mambo/content/view/36/140/
geen idee of ze een beetje verkrijgbaar zijn en wat de kosten zijn.

[Jazzper]

Net even alle 4 paginas met interesse gelezen. Vooral mooi die 1e opmerking van sprite dat hij geen tijd heeft en vervolgens paginas lang theorie uittypt haha. Hulde sprite!

iets heel fysieks. Bij lasergamen heb ik er altijd een hekel aan dat die simpele zielen zo oervervelend zijn met hun hand de sensoren af te schermen. Zou je in de sensoren niet een soort 2e set sensoren kunnen maken die merken als een object de sensor blokkert (still with me? ).

edit: een lasergame tent in groningen heeft ook allemaal al extra dingen zoals bommen die zo nu en dan afgaan of mensen die ineens godmode zijn (alhoewel dat laatste ook een bug kan zijn trouwens met die troep van ze ).

[ Voor 19% gewijzigd door Jazzper op 19-03-2007 13:01 ]

[Verwijderd]

Die ISD's zijn niets meer of minder dan een EEPROM met wat logica in (zodat je het juiste eepromcelletje kan oproepen) en een DAC + versterker. Moet je dus heus niet gaan zitten zoeken achter een moeilijk verkrijgbare /dure chip als je hetzelfde effe kan namaken.. zoals Sprite zegt, WAV is al vrij eenvoudig door een simpele pic met een paar weerstanden als DAC af te spelen.

Op zich is dat idd al toekomstmuziek, maar ik zou er toch rekening mee houden van dit mee 'in den beginne' te ontwikkelen, uiteraard ook als een aparte module.

Weet echter niet in hoeverre je kan FAT16 implementeren op low-level software gebied, dat laat ik dan wel ff over aan de C fanaten

[Sprite_tm]

@Jazzper: Mja, ik weet het, maar ik heb nu even veel tijd, geen idee hoe het verderop gaat zijn; kans is groot dat ik het dan ineens erg druk krijg. Sensoren afdekken is niet echt te detecteren: als je voor een boom staat oid worden ze ook 'afgedekt'. Ik denk dat je gewoon van de eerlijkheid van de mensen (die per slot van rekening zelf de apparatuur gebouwd hebben) uit mag gaan, en anders gewoon meer dan 2 sensoren fixen. Bommen e.d.: is aan gedacht

Mag ik trouwens de suggestie neerleggen om over nuttigere dingen dan de geluidschip te gaan discussieren? Allemaal leuk en wel, daar niet van, maar het is niet iets wat een onoverkomelijk probleem gaat vormen. Iets anders: Hoe gaan we het regelen met dingen als basisstationnen/granaten/health-bronnen/tijdbommen/...? Vele ervan zit qua hardware hetzelfde inelkaar en dus lijkt het me practisch om ze gewoon hetzelfde te maken en ze dmv een instelmanier een functie te geven. Hoe gaan we die instelmanier doen? Laten we alle bronnen gewoon een ID uitzenden en de logica in de pakken uit laten vogelen of er health bij, health eraf, kogels bij, of nog iets heel anders moet? Of doen we het net zoals milestag en configgen we de basisstations aan het begin van elk spel voor de bedoelde functie?

Scud_racer: Dat is wel te implementeren, maar ik zou zelf eerder alle data rechtstreeks, zonder FS, op de MMC/SD/...-kaart dumpen. Dat scheelt je een berg logica en is uiteindelijk ws. even makkelijk.

[ Voor 7% gewijzigd door Sprite_tm op 19-03-2007 13:12 ]

[Loy]

mooie requirements, Sprite!

Even over de acties die er kunnen zijn, en wat daarmee moet gebeuren. Op de wiki heb ik er een stukkie over gemaakt.

Bij de events kunnen we aangeven hoeveel prioriteit ze hebben, die met de minste prioriteit zijn minder nodig om een basisvariant van het spel te kunnen spelen.

Even een brainwave, pas later belangrijk: op je rugzak een rits ledjes die aangeven hoeveel health je nog over hebt.

[slopert]

Gluggie, misschien is het handig om iets van code dat je al gemaakt heb openbaar te maken? Ben zelf geen coder, maar er zullen best wel mensen met genoeg kennis/interesse zijn op er naar te kijken.
Je zegt zelf al dat je bijna klaar bent, dat zou een goede basis kunnen zijn om vanaf te beginnen.

[Verwijderd]

Loy schreef op maandag 19 maart 2007 @ 13:27:
Even een brainwave, pas later belangrijk: op je rugzak een rits ledjes die aangeven hoeveel health je nog over hebt.

Wat is er mis met een polsbandje met LCD schermpje ?

En het geluid zal zeker geen probleem zijn, opties genoeg.

1
2
3 < lijkt me wel iets handig.

[ Voor 31% gewijzigd door Verwijderd op 19-03-2007 13:54 ]