Open Source Lasergame/Laser Tag

[JanPaul123]

De meesten van ons kennen wel het spel Lasergamen of Laser Tagging maar ik zal het nog even kort beschrijven. Wat het globaal inhoudt is dat je met een geweer rondloopt in een arena, waarbij je met het geweer infraroodpulsen kunt uitzenden. Vaak zit er voor de sier ook nog een laserpointer bij, maar dit is slechts voor de show! Ook heb je een pak aan met infrarood-gevoelige sensoren. Door dat de infraroodstraling gepulseerd uitgezonden wordt, kan ieder geweer een unieke code uitzenden, waarmee deze door de ontvanger geïdentificeerd kan worden. Zo kun je zien door wie je bent neergeschoten. Er zijn verschillende manieren waarop het gespeeld kan worden. Het meest voorkomend is dat er twee teams zijn, waarbij je alleen op de tegenstanders kan schieten, er geen sprake is van een eindig aantal 'kogels' en je dus ook niet hoeft te herladen, en waarbij je enkele seconden nadat je wordt neergeschoten weer verder kunt spelen. Soms zijn er ook objecten in de omgeving die een rol spelen, waar je bijvoorbeeld power-ups van kunt krijgen zoals onkwetsbaarheid of onzichtbaarheid (dan gaan alle lampjes op je pak uit). Er zijn echter ook meer realistische varianten bekend, waarbij je echt moet herladen, af bent voor de hele ronde, of terug moet naar een basis als je wordt neergeschoten, er echt sprake is van health en verschillende soorten geweren die elk meer of minder schade geven. Het is dus te vergelijken met een soort real-life FPS, waarbij je de ene speelvariant kunt vergelijken met bijvoorbeeld Unreal Tournament, en de andere met Counter-Strike. Zoals je kunt verwachten zijn er liefhebbers van de ene en van de andere variant. Echter, in de meeste Lasergame centra in Nederland is alleen de eerste, niet-realistische variant te spelen.

Nu leek het me leuk om als tweaker zelf zo'n systeem te maken.
Er zijn een aantal amateur projecten met hetzelfde doel waar van te leren is.

• De bekendste is Milestag, een voormalig open-source project, maar wat eigenlijk alleen door 1 persoon werd gerund en die de source nu niet zo snel meer vrijgeeft, omdat het naar eigen zeggen commercieel gebruikt werd. Op de site staat een mooi protocol dat veel functies omvat. Ook kun je er schema's voor printplaten downloaden of bestellen.
  
  Ik heb de auteur gemaild voor de broncode, en deze gekregen. Echter, deze is geschreven in Basic, lastig te volgen en erg rommelig.
• Ook bekend is FragTag, een commercieel en closed-source systeem, maar wel met veel documentatie en gebaseerd op het MilesTag protocol.
• Dan was er nog RealTag, TagTek, en nog wat andere projectjes, maar deze zijn zeer verouderd en sommige sites bestaan niet meer of worden niet meer onderhouden
• Andere nuttige sites zijn LaserForums waar de makers van MilesTag en FragTag perminent aanwezig zijn, en DeltaForceLaserTag, de site van enkele Nederlanders die zich hier ook mee bezig houden.

Wat gelijk opvalt is dat er op het moment geen volwaardig Open Source project aanwezig is, met meerdere mensen die een bijdrage leveren. Nu ben ik zelf een paar maanden geleden begonnen met een eigen ontwerp, en heb nu een prototype die al goed kan zenden en ontvangen met het MilesTag protocol, op basis van een PIC18F2550, met USB 2.0 bootloader, display, en dergelijke. Nu zat ik er aan te denken om er een Open Source project van te maken, de code die ik tot nu toe heb is al heel goed gedocumenteerd.

Nu vroeg ik me af of er hier misschien mensen zouden zijn die geïnteresseerd zijn in een dergelijk project, ofwel om actief mee te helpen met ontwerp van elektronica en software, ofwel geïnteresseerd zijn in het spelletje, en zelf een set willen maken en/of testen wanneer het in een later stadium is.

Als begin zouden we dan hebben wat ik tot nu toe ontwikkeld heb, maar dat is natuurlijk totaal geen richtlijn. Als iemand bijvoorbeeld een beter voorstel heeft dan het MilesTag protocol, dan gaan we dat natuurlijk overwegen.

Je zou je kunnen afvragen: wat wil je hiermee bereiken? Je kunt het toch net zo goed voor jezelf houden en als het af is verkopen. Dat klopt, maar ten eerste hoop ik dat het systeem hiervan beter wordt, als er genoeg mensen zijn die actief meewerken, en ten tweede hoop ik dat het systeem hierdoor populairder is. Je zou als je wil dan ook geassembleerde printplaten of geweren kunnen verkopen. En wat is nou mooier dan waar je maar wil gratis zodra je dit hebt 's nachts in de bossen een real-life potje UT te doen!

http://www.openlaserfrag.org

[bazzzzzz]

als je eenmaal begint met de code dan denk ik dat er wel veel mensen zijn die je verder willen helpen. Waarom je persee met een protocol wil beginnen snap ik niet. Als je stand allone gaat werken en 2 types infrarood pulsen: enemy en teammate. Dat kan je dan uitbereiden naar allerlei leuke trucjes. Dus bijvoorbeeld de leds die uitgaan als je geraakt wordt. Een paar leds zodat je kan zien of je niet door je teammate gekilled bent enzovoort.

Zelf lijkt het me een leuk idee maar de behuizingen van de guns gaat een probleem worden. Dat moet lekker aanvoelen en niet in bouwvakkerstijl gemaakt zijn. En dat is vaak zelf moeilijk te maken.

[mithras]

bazzzzzz schreef op woensdag 14 maart 2007 @ 18:07:
als je eenmaal begint met de code dan denk ik dat er wel veel mensen zijn die je verder willen helpen. Waarom je persee met een protocol wil beginnen snap ik niet. Als je stand allone gaat werken en 2 types infrarood pulsen: enemy en teammate. Dat kan je dan uitbereiden naar allerlei leuke trucjes. Dus bijvoorbeeld de leds die uitgaan als je geraakt wordt. Een paar leds zodat je kan zien of je niet door je teammate gekilled bent enzovoort.

Ik denk dat je het beter wel op de manier van de TS kan doen, want dan heb je legio mogelijkheden. Je kan dan elke spelvariant spelen die je wil: per persoon, en in teams waarvan de aantallen ook weer variabel zijn.

Door het vast te leggen ben je erg beperkt, want achteraf controleren wie een bepaald persoon een aantal keer geraakt heeft kan dan al niet meer

Verder @TS: super idee! Ik kan er alleen helemaal niets van, dus helaas moet je het zonder mijn hulp stellen

[warcow]

Voor die guns moet je es kijken op www.psxshop.nl daar hebben ze lightguns voor de psx in de verkoop vanaf al 1 euro ofzo dacht ik. (en die zullen wel goed zijn)

[Phalox]

Mooi initiatief!! Ik ben eigenlijk wel zeer geinteresseerd !! Ik kan alleen niet echt veel helpen.. brainstormen zal nog lukken, maar soft en hardware is nog niet voor mij weggelegd.

Ik ga het opvolgen, als er iets anders is waarmee ik kan helpen.. Een website rond dit project zou misschien nog passend zijn ?

[bazzzzzz]

de software lijkt mij nogal lastig worden als je je aan protocollen moet houden. De hardware daarentegen wordt niet zo ingewikkeld. Paar hele gevoelige IR-sensoren a/d converter van de pic gebruiken. De leds op je armen in 2 groepen verdelen zodat je half stealth/stealth bent. De leds laten knipperen als je dood bent. Dat is allemaal het probleem niet:P

trouwens 1 euro voor zown gun is wel heel goedkoop. Op die manier zou je voor minder dan 10 euro een gun kunnen hebben.

[JanPaul123]

tokesnugerd schreef op woensdag 14 maart 2007 @ 18:40:
Ik ga het opvolgen, als er iets anders is waarmee ik kan helpen.. Een website rond dit project zou misschien nog passend zijn ?

Ik wil eerst kijken hoeveel mensen mee willen doen. Als er genoeg animo is kunnen we ons aanmelden op bijvoorbeeld sourceforge en een website maken.

bazzzzzz schreef op woensdag 14 maart 2007 @ 18:56:
de software lijkt mij nogal lastig worden als je je aan protocollen moet houden. De hardware daarentegen wordt niet zo ingewikkeld. Paar hele gevoelige IR-sensoren a/d converter van de pic gebruiken. De leds op je armen in 2 groepen verdelen zodat je half stealth/stealth bent. De leds laten knipperen als je dood bent. Dat is allemaal het probleem niet:P

trouwens 1 euro voor zown gun is wel heel goedkoop. Op die manier zou je voor minder dan 10 euro een gun kunnen hebben.

Op het moment gebruik ik TSOP digitale sensoren, die ontvangen behoorlijk goed. De software werkt vooralsnog prima met het MilesTag protocol, zeker in C is het goed te doen dit te programmeren en het werkt ook snel genoeg. Ik kan nu al schieten en geraakt worden tegelijk (ook door jezelf maar dat is te herkennen aangezien je dan je eigen PlayerID ontvangt)

En 10 euro is wel heel optimistisch hoor, vergeet niet dat je redelijk wat meer geld kwijt bent als je alle kleine onderdelen bij elkaar optelt zoals LCD scherm, IR ontvangers, batterijen/accu... Maar het hoeft inderdaad zeker niet duur te worden!

[ Voor 0% gewijzigd door JanPaul123 op 14-03-2007 19:36 . Reden: TSOP digitale sensoren, niet TSAL, dat zijn de ledjes... ]

[Phalox]

De software in modules maken zou ook handig zijn, kan je achteraf nog iets toevoegen..

BTW: NO WAY to sourceforge, die rommel is veeel te traag Het idee achter SF is goed, maar de servers zijn te traag

Als dit gaat lukken (als er wat meer mensen zijn) dan kan ik misschien eindelijk wat electronica oefenen/leren

[ShadowLord]

Heb je al nagedacht hoe je de centrale communicatie gaat doen (dus met een 'server' die alle scores bij houd)? Hievoor zou ik eens kijken naar RF units in de (vervuilde) 325 MHz band of iets schonere 2.4 GHz band.

2.4 GHz heeft als voordeel dat het een stuk sneller is, maar het bereik is niet altijd even goed (zeker als je in het bos gaat spelen).

De 325 MHz band is langzamer (maar snel genoeg lijkt me), alleen behoorlijk vervuild wat problemen kan geven in bebouwde gebieden. Ook zijn de meeste 325 MHz onderdelen een stuk simpeler waradoor je zelf veel meer werk hebt om het te maken (en je PIC het hele protocol zal moeten afhandelen).

[sebastius]

Waarom zou je continu terugrapporteren? Dat is wel leuk maar eigenlijk niet nodig. Enkel een ontvanger in de backpacks voor 'game start/end' en de rest gewoon aan het einde downloaden

[mithras]

Ik denk dat je best wat mensen bij elkaar kan krijgen om dit (beter) op te zetten. Echter moet je wel naast het idee wat je geopperd hebt even wat kernpunten formuleren:
[list]• Wat heb je gedaan
• Wat moet je nog doen
• Welke dingen moet je daarvoor kunnen
• Wat is je doel
Nu is het eerste en laatste punt wel duidelijk, maar die middelste twee nog niet. Heb je nog programmeurs nodig, testers, hardware designers (of hoe dat ook heet)? Het zijn verschillende taken die niet iedereen kan vervullen

offtopic:
Sf.net is opzich prima hoor. Een eigen startpagina waar je php en mysql kan gebruiken, lekker veel bestanden kan posten. Nieuws berichten posten met rss feeds, statistieken, documentatie. Dan nog de mogelijkheid voor bugs reporting, feature requests en support requests. Ik vind het persoonlijk stukken beter dan bijvoorbeeld code.google.com.

[Alm4riC]

Ik zou ook wel mee willen werken aan dit project, alleen denk ik dat ik net als tokesnugerd niet heel erg thuis op het gebied van elektronica.

Verder zal ik dit op de voet blijven volgen. Erg leuk innitiatief.

[JanPaul123]

mithras schreef op woensdag 14 maart 2007 @ 19:42:
Ik denk dat je best wat mensen bij elkaar kan krijgen om dit (beter) op te zetten. Echter moet je wel naast het idee wat je geopperd hebt even wat kernpunten formuleren:
(...)
Nu is het eerste en laatste punt wel duidelijk, maar die middelste twee nog niet. Heb je nog programmeurs nodig, testers, hardware designers (of hoe dat ook heet)? Het zijn verschillende taken die niet iedereen kan vervullen

Goed idee.
Wat ik nu heb is een prototype dat kan zenden en ontvangen volgens het milestag protocol en wat andere kleine dingetjes kan. Dit is wel in gemoduleerd en goed gedocumenteerd C.

Er moet dus nog veel code geschreven worden (dit is het meeste werk).
Ook is de hardware nog niet optimaal, en moet er ook nog gezocht worden naar eventueel goedkopere onderdelen of die er zijn.
Ook moet veel worden getest.
En goede ideeën zijn altijd welkom!

Je kan helpen als je

• goede ideeën hebt;
• of kunt programmeren in C;
• of de hardware kunt ontwerpen (ofwel schema tekenen, ofwel printplaat ontwerpen);
• kunt solderen en wil testen en/of exemplaren wil maken voor programmeurs die niet kunnen solderen ;
• op andere maner nuttig denkt te kunnen zijn

[Phalox]

Hier ben ik weer
Eigenlijk kan je hier een heeeel uitgebreid project van maken, granaten, bommen.. ga zo maar door. Het is allemaal mogelijk. Misschien moet er eerst een primair doel opgesteld worden ?
De basiselectronica = een paar wapens en een paar sensoren moeten mekaar kunnen raken
Dan kan je verder bouwen.

SF heeft zeer veel mogelijkheden, daar ben ik me bewust van! maar de site is vaak irritant traag, en dat is niet zo tof als je er vaak op zit... achja 'tis nog eventjes vooraleer het zover is.

//EDIT: Ik wil wel solderen dan oefen ik dat wat!! maar, dan moeten de onderdelen zoals je zegt zeer goedkoop zijn, of ik zou er nog wel eens een paar 10-tallen eurootjes door kunnen jagen

//EDIT2: als je wil kan ik tijdelijk voor hosting zorgen (ik heb er nog ergens), tis dan wel 2 subfolders verder in de link, en maar 1 mysql DB.. maar voor derest TOPPIE

[ Voor 26% gewijzigd door Phalox op 14-03-2007 19:59 ]

[Anoniem: 118825]

Count me in... ik moet er wel ff bijzeggen dat ik zelf met een groep vrienden al heel lang over dit concept bezig ben en zelf ook al heel wat code heb geschreven die ik dan ook liever niet openbaar maak, aangezien we het uiteindelijk in een licht commerciele versie zouden gebruiken..

Maar ik wil je zeker en vast steunen in dit concept, wat dan ook compleet anders kan uitdraaien :-)

Persoonlijk ben ik wel een assembly programmeur, hoewel ik C aan het leren ben (embedded dan, heb er wel wat ervaring mee maar niet zo veel)

Hardware kan ik ook wel wat helpen denk ik... soit, point me in the right direction and i'll help where i can

/lichte edit; ik ben niet zo'n fan van mickeychip, maar heb er wel ervaring mee, alleen niet in de 18f reeks... nu goed, wsl maakt het niet veel verschil in C maar toch maar ff meedelen

[ Voor 12% gewijzigd door Anoniem: 118825 op 14-03-2007 20:15 ]

[JanPaul123]

Leuk dat er zo veel positieve reacties zijn!
Wat me ook te binnen schiet is dat je ook kunt helpen als je ervaring hebt met Open Source-projecten, ik weet namelijk niet of ik anders alles in goede banen kan leiden.

[Phalox]

Eigenlijk al een naam verzonnen ? zonder naam kan je geen SF project maken he (of eendert welk ander)
Iets met laser tag ?

[JanPaul123]

tokesnugerd schreef op woensdag 14 maart 2007 @ 20:29:
Eigenlijk al een naam verzonnen ? zonder naam kan je geen SF project maken he (of eendert welk ander)
Iets met laser tag ?

Open Source Laser Tag?

[bazzzzzz]

De tsop1736 is er ook in smd he! Dat is mischien ook wel handig! Het type nummer is dan TFMM5380. Kheb die dingen nog eens gekocht voor 2 cent per stuk bij een of andere SK waarbij die gast ervan af moest. Mischien idee om na te vragen of hij er nog wat heeft? Als het goed is heeft hij er nog 230 stuks:P(volgens sk dan.)

EDIT: de tsop heeft mischien wel een te groot bereik:P Kdenk dat je het afstellen van de a/d omzetters wel lastig gaat worden(lees:kritisch)

[ Voor 18% gewijzigd door bazzzzzz op 14-03-2007 21:00 ]

[Phalox]

d8 ik ook al aan, maar is nogal lang.... ochja, het kan er nog nét mee door Maken da SF project!! Dat is een goede manier om gedachten en ideeen te ordenen

[JanPaul123]

tokesnugerd schreef op woensdag 14 maart 2007 @ 20:50:
d8 ik ook al aan, maar is nogal lang.... ochja, het kan er nog nét mee door Maken da SF project!! Dat is een goede manier om gedachten en ideeen te ordenen

Welke licence moet ik dan opgeven? GPL?

[mithras]

Als je open-source kenmerk in je naam wil hebben: laat het 'source' lekker weg OpenLaserTag, OpenFrag (want fraggen: it's in the name) e.d. Het maakt niet veel uit, je kan eigenlijk wel alles zo'n beetje verzinnen.

Daarnaast: ik kan geen C, heb weinig met hardware en elektronica, maar mocht je organisatorisch (en website technisch voor een cms oid) in de problemen komen kan je me wel DM'en

Gluggie schreef op woensdag 14 maart 2007 @ 20:54:
[...]


Welke licence moet ik dan opgeven? GPL?

De GPL is zo'n beetje de grote standaard voor open source ja. Je hebt wel veel mogelijkheden hoor. Hier heb je eigenlijk alle open source licenties die er zo ongeveer zijn (op de zelf aangepaste versies na). Ik zou eerder voor een MIT of vergelijkbare licentie gaan eigenlijk:

Copyright (c) <year> <copyright holders>

Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

[ Voor 66% gewijzigd door mithras op 14-03-2007 21:04 ]

[Phalox]

Euhm, gpl.. dan mogen mensen het verkopen maar ze moeten broncode meeleveren. Misschien toch iets anders ? even op zoek

[Mc.Boldy]

tokesnugerd schreef op woensdag 14 maart 2007 @ 19:56:

...
SF heeft zeer veel mogelijkheden, daar ben ik me bewust van! maar de site is vaak irritant traag, en dat is niet zo tof als je er vaak op zit... achja 'tis nog eventjes vooraleer het zover is.
...

Download op www.vmware.com de kant-en-klare linux distributie incl. SF installatie. 2,5 GB groot na uitpakken en binnen 15 minuten up-and-running. Niks geen problemen meer met traagheid (en de rest ook niet als je upload behoorlijk is). Regel iemand in je team die een lekker abbo-tje heeft.

[sebastius]

Ik heb er eigenlijk geen tijd voor maar als je een hardware ontwerper (printplaatjes etc) kan gebruiken... wil ik best wel meedenken Ik heb voor bedrijven microcontroller systemen met zeer creatieve mogelijkheden gemaakt in het recente verleden.

[ Voor 29% gewijzigd door sebastius op 14-03-2007 21:12 ]

[Flapp]

Zelf ben ik maar een beginneling in de electronica.

Maar ik ben wel bereid hosting hiervoor op te geven, Ik heb toch nog een host waar ik nog een half jaar aan vast zit.
't is best een snelle server, en als je minder dan 30Gb aan bandbreedte verstookt in de maand vind ik t goed.


Kunnen jullie een directe domeinnaam (flapietoetoe.nl) krijgen of een subdomein naam onder flapp.nl
DM me maar als je interesse hebt.

[warcow]

Als het zover is zal ik hier misschien ook wel gebruik van willen maken. (het idee is uiteraard nog wel vet.)
Ik heb momenteel 2 van die light guns hier liggen, misschien dat ik er nog een paar bijbestel, die dan als voorbeeld kunnen worden gebruikt. (ik denk echter niet dat die zaak er nog veel heeft liggen... )
Ik zal ze morgen eens mailen hoeveel ze hebben.

[MBV]

tokesnugerd schreef op woensdag 14 maart 2007 @ 21:03:
Euhm, gpl.. dan mogen mensen het verkopen maar ze moeten broncode meeleveren. Misschien toch iets anders ? even op zoek

what's the problem? Je zet je projectje op Sourceforge, dus als mensen het gratis willen hebben kunnen ze het gratis krijgen. Als ik een bedrijfje wil opzetten dat complete sets wil verkopen, en daarvoor aanpassingen aan de software doe, ben ik verplicht om die aanpassingen door de communiceren naar mijn klanten. Lijkt mij prima toch? Ik verdien geld aan de verkoop van de hardware, en jouw projectje wordt daardoor beter

MIT hoeven ze die terugkoppeling niet eens te doen, LGPL mogen ze er dingen aan vast hangen zonder dat terug te koppelen,

Terugkoppelen hoeft trouwens niet rechtstreeks: je moet erop vertrouwen dat de klanten van 'mij' dat doen.

sebastius schreef op woensdag 14 maart 2007 @ 19:42:
Waarom zou je continu terugrapporteren? Dat is wel leuk maar eigenlijk niet nodig. Enkel een ontvanger in de backpacks voor 'game start/end' en de rest gewoon aan het einde downloaden

Is leuk voor een scorebord ofzo en als je toch al dingen heen en weer stuurt voor begin/eind...

[ Voor 18% gewijzigd door MBV op 14-03-2007 21:29 ]

[JanPaul123]

Project aangemaakt op SF onder de naam OpenLaserFrag (openfrag bestaat al, google maar..)
Nu maar wachten op toestemming.

[Phalox]

Wel.. die zal er wel komen zeker maar, dat is wachten tot morgen..

Nu mag jij es zeggen wie jij denkt nog nodig te hebben.

[JanPaul123]

tokesnugerd schreef op woensdag 14 maart 2007 @ 21:37:
Wel.. die zal er wel komen zeker maar, dat is wachten tot morgen..

Nu mag jij es zeggen wie jij denkt nog nodig te hebben.

Alles op z'n tijd. Laten we eerst afwachten of er nog meer mensen zich aanmelden.

[Phalox]

• tokesnugerd: Wat hij/ik kan
• Alm4riC: idem
• Scud_racer: ervaren met het onderwerp
• mithras: is bereid wat mee te organiseren
• sebastius: wil helpen als hij kan/tijd heeft
• Flapietoetoe: hosting
• Loy: kan programmeren en heeft materiaal in huis
• Scout77: meedenker
• roelke: aangemeld (geen idee met wat )

Een voorlopige tussenstand 6 'medewerkers' is toch nog niet slecht voor 1 avond.

[ Voor 15% gewijzigd door Phalox op 15-03-2007 21:28 ]

[kluyze]

Er zullen er nog wel passief aan mee werken, ik wil ook wel wat helpen, maar dan heel passief. Daarmee bedoel ik hier langs het forum.

Ik heb wel wat programmeer ervaring via school, C/C++/java/... ook C voor op een atmel moest dat nodig zijn, en dan heel klein beetje asm.

Ook voor een schema te maken wil ik wel wat helpen/opzoeken of zo.

Ik weet niet wat de bedoeling gaat zijn, maar via het forum wil ik mijn steentje wel bijdragen. Ik heb het voor de rest ook redelijk druk met mijn laatste jaar (masterproef en zo neemt nogal wat tijd in beslag).

[Stoney3K]

Hee, ik dacht dat ik de eerste was met het idee!

Ik heb hier nog 4 printjes van prototype RSCombat systeem liggen, en we hebben met de clan 6 guns van Lazer Tag Team Ops. Ik kan wel aardig wat in het ontwerpen van elektronica maarr in het programmeren van uC's ben ik voorlopig nog een leek.

Ben al actief op LaserForums.com, en ik had zelf een systeem in gedachten dat de sensoren en de guns los houdt, dus dat je bijvoorbeeld ook zonder gun (als hostage/technician) aan een game mee kan doen. Pak je dan een gun dan prik je die gewoon in je Sensor Controller module.

Zoals MilesTag werkt is een goed beginpunt, één bordje met een TSAL6200 en TSOP4840's als sensor. Simpel te maken en redelijk veelzijdig, alleen moet je aan andere oplossingen denken als je echt realistisch wil spelen (en bv. een vervanger wil worden voor airsoft wat in NL verboden is). Denk bijvoorbeeld aan EPROM's in de magazijnen voor realistische reloads (je kan een leeg magazijn er immers niet terug in stoppen en hopen dat hij schiet )

[Scout77]

Tijden terug eens een keer een topic over gelezen op hackaday.com toen ook eens een beetje rondgekeken, lid van laserforum.com enzo. Helaas binnen mijn vriendenclub niemand die tijd/zin enzo had om die guns ook te gaan klussen.
Ergens in Den Helder (dacht ik) waren er ook mensen mee bezig (naam iets met Deltaforce) maar dat was te ver weg.

Helaas nog niet heel bedreven in de electronica maar wil best meedenken en wil in de toekomst ook met PIC's aan de slag.

[Anoniem: 118825]

Ff voor de zekerheid, welk protocol wil je nu net gebruiken ?

[Loy]

Zo, dit is wel interessant! Ik zou graag meewerken, heb alleen niet zoveel voorkennis op de gevraagde gebieden.
Ideeën heb ik altijd wel, ik heb wat ervaring met C-programmeren voor de SAB80515 uC, en studeer nu werktuigbouwkunde, maar volgend jaar mechatronica. De juiste kennis komt er dus aan.

Idee:
Voor de 2 of meer teams op de pakken en de gun nog een 2e kleur LEDs maken, naast de eigen teamkleur, Geel bijvoorbeeld.
Hierdoor kan je een soort Bombing-run als in Unreal Tournament doen. Iemand die de bal heeft, heeft alleen gele LEDjes branden op z'n pak en gun, en kan door met die gele gun te schieten iemand anders de bal ofwel gele kleur geven, of dat nou vijand of vriend is.

Ik wil wel meehelpen, weet alleen niet zo goed hoe. Ik wil best een gave gun ontwerpen en maken, ik weet allleen nie tof dat binnen het project valt. Wat valt er binnen het project? De software? Ook de elektronica? Of zelfs ook eigen guns?

[ Voor 14% gewijzigd door Loy op 15-03-2007 10:50 ]

[Stoney3K]

Ik denk dat zo'n beetje alles van elektronica, software tot het mechanisch design van de guns eronder gaat vallen.

Ik zou zelf de guns graag willen maken uit fiberglas/epoxy, dat is licht en het best geschikt voor hol materiaal als guncasings, maar ik heb niet echt een werkplaats waar ik veel kan doen. Als we een prototype met een CNC machine konden laten maken en daar moldings van trekken zijn we al aardig op weg

[Phalox]

De hoofdprocessor van het geheel zou beter in een soort jasje verwerkt worden ipv in het wapen. zo kan zoals een paar posts hierboven gezegd is, iemand meerdere functies hebben.. Maarja, het Idee moet nog vorm krijgen.
Dit zou een project moeten worden wat te maken valt zonder al téveel ervaring, veronderstel ik. (dus, nadat de ontwikkeling voltooid is)

[Loy]

Beschikking tot een CNC-draai- en freesbank heb ik, en programmeren kan ik ook.
Binnenkort eens een ontwerpje maken

[Phalox]

List updated -> 8 'medewerkers'

[uppie8374]

Grappig... ik ben ook al een hele tijd aan het brainstormen. Moet alleen nog steeds echt gaan beginnen. Heb wel al een hoop ideeën bij elkaar gescharreld. Voor de echte geïnteresseerden heb ik nog een leuk forum: http://www.laserforums.com/

Anyway veel succes eenieder. Ik bouw namelijk liever alles geheel zelf om er van te leren.

[Stoney3K]

uppie8374 schreef op donderdag 15 maart 2007 @ 19:28:
Grappig... ik ben ook al een hele tijd aan het brainstormen. Moet alleen nog steeds echt gaan beginnen. Heb wel al een hoop ideeën bij elkaar gescharreld. Voor de echte geïnteresseerden heb ik nog een leuk forum: http://www.laserforums.com/

Anyway veel succes eenieder. Ik bouw namelijk liever alles geheel zelf om er van te leren.

Bovenstaand forum ben ik al regular poster, we zijn daar zelfs voorzien van een apart Nederlandstalig subforum

Programmeren in C/C++ is voor mij geen enkel probleem, alleen het programmeren in Assembly voor bv. microcontrollers wordt wat lastiger. Maar wat niet is valt te leren

Waar je overigens wel even over moet nadenken is dat je je taggers niet te realistisch maakt, anders krijg je zware zeik met de Nederlandse wapenwet, sinds het dan voor de wet nepwapens worden. En het geel of groen schilderen van je taggers maakt er niks aan uit, alleen de basisvorm. Zorg dat die genoeg van bestaande vuurwapens afwijkt, ik heb zelf op LaserForums een paar ideeën gepost, wapens uit games zijn een redelijk goed startpunt.

[Phalox]

Kheb eventjes mijn idee uitgetekent..


Lijkt me makkelijker dan alles vanuit het wapen te laten vertrekken. Je moet dan wel een soort van uitrusting aandoen, waarin de hoofdunit zit, of in een rugzak ofzo.

[Stoney3K]

tokesnugerd schreef op donderdag 15 maart 2007 @ 20:49:
Kheb eventjes mijn idee uitgetekent..
[afbeelding]

Lijkt me makkelijker dan alles vanuit het wapen te laten vertrekken. Je moet dan wel een soort van uitrusting aandoen, waarin de hoofdunit zit, of in een rugzak ofzo.

My idea exactly! Mijn idee was (met OLCS - Open Laser Combat System) om een MCU te hebben in het sensorvest/uitrusting die alleen maar hitpoints en hits bijhoudt, en van daaraf eventueel aangekoppelde guns aan of uitschakelt, en misschien nog andere dingen kan doen (bv. IrDA communicatie op sensors).
De communicatie tussen gun en sensor controller verloopt dan via I2C wat zo'n beetje elke microcontroller aan boord heeft, met een 3-polige XLR verbinding (sensor side) voor de aansluiting. Dus geen problemen meer met kabels die er onverhoopt uit vallen

Voordeel is dat je met zo'n schema ook onbeperkt guns en add-on modules aan kan sluiten, wat je bij MilesTag bijvoorbeeld niet kan omdat het niet echt goed schaalt. Wat is immers vetter dan met TWEE guns te kunnen lopen in plaats van één?

[roelke]

overgens zal ik hier ff melden dat ik me via msn ook heb aangemeld voor dit project

[Phalox]

Ja, dit heeft zowat onbeperkte mogelijkheden Maar wat jij daar allemaal zegt is half chinees voor mij ik kan er nog nét aan uit, maar snap het niet allemaal.. daarom zijn schema's handig !!

Ik denk dat er nog veeeeel zo'n schema's gemaakt zullen worden

EDIT: @ roelke: Toegevoegd aan de lijst, maar ik heb wel geen functie kunnen opgeven

[ Voor 14% gewijzigd door Phalox op 15-03-2007 21:28 ]

[JanPaul123]

Dat ziet er goed uit als ontwerp. In het prototype is de microcontroller in de gun geïntegreerd, maar dat hoeft uiteraard niet zo te blijven.

Kan iedereen zich vinden in de naam OpenLaserFrag?

We hebben trouwens de sponsoring van Sanbax webhosting voor paar honderd MB ofzo ruimte + domeinnaam.

[Phalox]

Jahwadde da gaat hier nogal vooruit!
Dit topic bestaat van gisteren, en er is nu zelfs al sponsering !! De naam vind ik wel gepast, dus voor mij part mag die zeker blijven !!

ps: ik wil me wel amuseren met schemaatjes maken

[Tp21]

ikzelf ben ook bezig met een lasergame achtig systeem, alleen het meine word een stuk minder geavanceerd, en is gebaseerd op het milestag v3 syteem. (source-code van maker gekregen).

[Stoney3K]

Gluggie schreef op donderdag 15 maart 2007 @ 22:03:
Dat ziet er goed uit als ontwerp. In het prototype is de microcontroller in de gun geïntegreerd, maar dat hoeft uiteraard niet zo te blijven.

Kan iedereen zich vinden in de naam OpenLaserFrag?

We hebben trouwens de sponsoring van Sanbax webhosting voor paar honderd MB ofzo ruimte + domeinnaam.

Klinkt al ontzettend goed!

Ik denk dat we in zo'n meermans project een duidelijke rolverdeling moeten hebben:
* Gameplay / spelopzet
* Promotie / PR
* Guncasings / Mechanics / Optics
* Elektronica hardware
* Elektronica software
* evt. overige uitrusting

Als we het goed opzetten krijgen we misschien wel een zootje Airsofters mee uit het noorden en westen des lands die niet elke keer in België willen spelen

[Anoniem: 118825]

Ik ga hier in mee, een duidelijke rolverdeling, gevolgd door een duidelijk 'lastenboek' eg. vorm vh protocol, welke nibbles/bytes worden waarvoor gebruikt, draaggolven, interfaces etc etc.

Btw wat betreft de wapens, glasvezel ed is heel leuk, maar waarom geen vacform.. als je dan toch CNC gaat mallen frezen kan je op deze manier veel sneller (en veeeeeeeeeeeel goedkoper) een aantal wapens maken. Ik zou de glasvezel varianten houden voor prototypes of "one-off special editions" ofzow.

Idee van een backpack zou ik ook zeker voor gaan, het geeft je meer ruimte om te "spelen" met plaatsing v componenten ed en je kan sensoren op het lichaam plaatsen zonder velcro of weetikveelwat..

Dan rijst de vraag, enkele microcontroller of een combinatie van bv 1 controller voor het wapen en 1 controller voor ontvangers/interactie met bv pc ed..

[mithras]

Anoniem: 118825 schreef op vrijdag 16 maart 2007 @ 09:48:
Dan rijst de vraag, enkele microcontroller of een combinatie van bv 1 controller voor het wapen en 1 controller voor ontvangers/interactie met bv pc ed..

Ik heb totaal geen verstand van microcontrollers, maar ik zou het zo modulair mogelijk opzetten. Dat je dus een centrale controller hebt die de invoer/uitvoer regelt (start spel, opslaan van een hit e.d.). Hierop kan je een vest aansluiten waar sensorten opzitten: zoveel als je wil (nou, niet oneindig, maar een variabel aantal). En datzelfde met wapens, dan kan je dus zelf een, twee of zelfs drie wapens bijvoorbeeld aansluiten.

Het moet allemaal aangekoppeld en allemaal losgekoppeld kunnen worden. Hoe je dit moet doen en of het op deze manier nog simpel blijft weet ik niet, maar zo kan je dus spelen met hostages (geen wapens), lichte wapens en zwaardere wapens

[StefSybo]

Afgelopen zomer heb ik hier met een vriend ook al over zitten denken en we waren er toen al erg enthousiast over. Helaas is dat nooit van de grond gekomen, maar ik vind dit zeker een interessant idee.

Ik kan wel helpen met programmeren, hoewel ik nog niet zoveel ervaring met C heb, maar dat moet binnen afzienbare tijd toch wel te leren zijn. Ik heb ook wat ervaring met assembly als dat nodig is, ook voor de PIC18F-serie.

Ik zou dan voor een modulaire opzet zijn met ook andere gamemodes dan (team) deathmatch en bijvoorbeeld in een later stadium verschillende wapens die zich ook verschillend gedragen.

[MBV]

Een modulaire opzet lijkt mij ook erg verstandig. Wees wel zo slim om te bepalen in welke richting je systeem flexibel moet worden: als je oneindige flexibiliteit wilt hebben, krijg je oneindig moeilijke code

Verschillende wapens lijkt me wel een must, net als verschillende sensors en verschillende games.

Maareh, is het niet verstandig om compatible te zijn met bestaande hardware? Dan kan je beginnen met de software voor de game-aansturing, en daarna pas de hardware maken . Lijkt mij een voordelige manier van ontwikkelen

* MBV zou wel zin hebben in wat C/C++ proggen, maar weinig ervaring en nog minder tijd

[Stoney3K]

Anoniem: 118825 schreef op vrijdag 16 maart 2007 @ 09:48:
Ik ga hier in mee, een duidelijke rolverdeling, gevolgd door een duidelijk 'lastenboek' eg. vorm vh protocol, welke nibbles/bytes worden waarvoor gebruikt, draaggolven, interfaces etc etc.

Btw wat betreft de wapens, glasvezel ed is heel leuk, maar waarom geen vacform.. als je dan toch CNC gaat mallen frezen kan je op deze manier veel sneller (en veeeeeeeeeeeel goedkoper) een aantal wapens maken. Ik zou de glasvezel varianten houden voor prototypes of "one-off special editions" ofzow.

Idee van een backpack zou ik ook zeker voor gaan, het geeft je meer ruimte om te "spelen" met plaatsing v componenten ed en je kan sensoren op het lichaam plaatsen zonder velcro of weetikveelwat..

Dan rijst de vraag, enkele microcontroller of een combinatie van bv 1 controller voor het wapen en 1 controller voor ontvangers/interactie met bv pc ed..

Vacform werkt op zich wel maar glasvezel is veeeeel steviger. Als je een gun laat vallen wil je niet dat er dan een stuk uit is. Het liefst zou je voor grote productie-runs zo'n ding uit ABS of PVC spuitgieten, maar op zo'n schaal wil ik nog niet echt gaan denken

Backpacks werken wel maar komen redelijk lomp over, misschien voor één of twee mensen die een speciale rol hebben kan het wel. Maar als je gaat taggen heb je vaak toch al militaire gear aan zoals een koppelriem en een vest, waar met gemak een controller-doosje aan te bevestigen is (we hebben het hier niet over PC's/laptops maar over een doosje met één printje, een accupack en een drietal connectoren). Voor civilians die geen militaire kleren dragen kun je altijd iets verzinnen zoals een heuptasje (fannypack) of iets dergelijks.

[ShadowLord]

sebastius schreef op woensdag 14 maart 2007 @ 19:42:
Waarom zou je continu terugrapporteren? Dat is wel leuk maar eigenlijk niet nodig. Enkel een ontvanger in de backpacks voor 'game start/end' en de rest gewoon aan het einde downloaden

Team scores. Controle van hits (aangepaste guns kun je dan detecteren). Realtime scorelijst. Game start en game end? Referee controle over guns. Team interactie (bijvoorbeeld een team powerup of powerdown). CTF tracking. Team messages (beetje SMS achtig). Etc, etc. Alle niet line-of-sight communicatie die je zou willen kun je met RF doen.

Een RF unit is niet zo duur. Het belangrijkste aspect vind ik persoonlijk de detectie van aangepaste guns. Bij iedere hit en iedere kill rapporteren beide spelers aan de server. Is hier een verschil tussen dan speelt er iemand vals.

Overigens kan ik dus ook een handje helpen met dir project. Ik ben zowel coder (PC en MCU) en ik kan printjes ontwerpen. Dus ik kan eigenlijk het volle spectrum van dit project wel aan
Zelf ben ik nu bezig met een ambi/moodlight projectje waarbij ik RF units (ga) gebruik(en) om tussen de verschillende lampen te communiceren. Ik heb hier dus al wat research in zitten.

[mithras]

ShadowLord schreef op vrijdag 16 maart 2007 @ 13:19:
[...]

Een RF unit is niet zo duur. Het belangrijkste aspect vind ik persoonlijk de detectie van aangepaste guns. Bij iedere hit en iedere kill rapporteren beide spelers aan de server. Is hier een verschil tussen dan speelt er iemand vals.

Volgens mij ga je enorm veel load genereren als je elk schot gaat rapporteren.

Geen idee welk percentage schoten raak zal zijn, maar het lijkt me wel handig om in iedergeval tussentijdse rapportage mogelijk te maken. Je kan dan bijvoorbeeld wel de kills terug rapporteren, zodat je centraal kan bekijken wie er wanneer (en waar als je ook gps koppelt ) dood gaat. Maar van elk schot er communicatie laten plaatsvinden lijkt me wat overbodig

[StefSybo]

mithras schreef op vrijdag 16 maart 2007 @ 13:27:
[...]
Volgens mij ga je enorm veel load genereren als je elk schot gaat rapporteren.

Geen idee welk percentage schoten raak zal zijn, maar het lijkt me wel handig om in iedergeval tussentijdse rapportage mogelijk te maken. Je kan dan bijvoorbeeld wel de kills terug rapporteren, zodat je centraal kan bekijken wie er wanneer (en waar als je ook gps koppelt ) dood gaat. Maar van elk schot er communicatie laten plaatsvinden lijkt me wat overbodig

Mee eens, ik denk dat er zo veel gerapporteerd moet worden dat het verloop van het spel door iedereen gevolgd kan worden, dus wel kills, respawns en specifieke dingen voor dat spel (denk aan of iemand de vlag heeft bij CTF), maar het lijkt me overbodig om elk schot te rapporteren.
Ik denk ook dat je je om aangepaste guns niet zo druk hoeft te maken, dat moet ook wel op een andere manier uit te vinden zijn dan elk schot rapporteren. Daarnaast moet je denk ik een zekere mate van vertrouwen hebben dat iedereen eerlijk speelt en niet met een aangepaste gun gaat rondlopen.

Daarnaast moet er denk ik iets zijn om met je team te overleggen, maar daar kan je misschien ook gewoon een set portofoons of iets dergelijks voor gebruiken om dat datanetwerk wat te ontlasten.

[Stoney3K]

ShadowLord schreef op vrijdag 16 maart 2007 @ 13:19:
[...]

Team scores. Controle van hits (aangepaste guns kun je dan detecteren). Realtime scorelijst. Game start en game end? Referee controle over guns. Team interactie (bijvoorbeeld een team powerup of powerdown). CTF tracking. Team messages (beetje SMS achtig). Etc, etc. Alle niet line-of-sight communicatie die je zou willen kun je met RF doen.

Die SMS messages dacht ik ook aan, maar mijn idee was om ze asynchroon af te leveren via infrarfood communicatie. Als je elke gun van een RF module moet voorzien moet je daar aardig geld in steken, en hou er ook rekening mee dat RF modules op de PMR band (443 MHz) maar 8 kanalen hebben waarvan er al minstens 2 gebruikt worden voor voice van de spelers zelf.

Voor de SMS messages en andere sturing had ik het idee om vanaf de controllermodule een losse LCD module te maken (HD44780 of grafisch) die je bv. wristmounted kan dragen. Met keys onder het display kun je dan opties aanpassen, een beetje zoals een G15 LCD of de meeste FMC's in vliegtuigen.

Bovendien, wil je real-time een server gaan bijhouden als je outdoor speelt? Dat betekent ook weer ergens een PC neerzetten, dus je gaat stroom nodig hebben (een laptop haalt het echt niet voor de hele periode).

Mijn idee is om eerst een 'basis' systeem in elkaar te zetten met een universele bus (ik zeg I2C) waarop je later add-ons aan kan sluiten. Eerst een systeem bouwen waarmee je gewoon hits kan registreren zodat we kunnen spelen en er mensen mee trekken, daarna kun je 'bells and whistles' toevoegen.

[Kek]

Ik heb in een grijs verleden ( ongeveer 2 jaar) me enigzins verdiept in verschillende lazergame technieken/tactieken, en watvoor systemen er allemaal te maken zijn of dingen die je zo van internet kan plukken, het bleef toen bij de research, ik ben niet daadwerkelijk aan een systeem begonnen, maar het interreseert me nog steeds.

Wat ik hier nu zie is opzich heel mooi. Prachtige dromen over meesterlijke systemen met GPS voicechat, aflezen van allerhande informatie. Dit is allemaal leuk, maar straks zie je door de bomen het bos niet meer.

Wat ik sterk aan raad is, en wat ook al eerder gezegt was, is eerst een simpel systeem te maken, waar je later plugins op/in kan steken.

[Falcon]

Gluggie schreef op woensdag 14 maart 2007 @ 21:33:
Project aangemaakt op SF onder de naam OpenLaserFrag (openfrag bestaat al, google maar..)
Nu maar wachten op toestemming.

Klopt... OpenFRAG is een project die hier gestart is op GoT en nu een internationaal project is geworden. www.openfrag.org

Succes!

[Anoniem: 118825]

Goed, dus ik som ff op, correct me if i'm wrong:

• Centraal systeem dmv heuppack oid
• Koppeling DMV I2C (zou ik persoonlijk ook voor gaan eerlijk gezegd)
• Mogelijkheid om onbepaald aantal sensoren te gebruiken (binnen de mate van het mogelijke)
• Door de heuppack/koppeling wordt het nagenoeg onmogelijk om met slechts 1 controller te werken, dus 2 controllers

Dan rest me de vraag, heeft er iemand de beschikking over enkele TSOP's en een scoop, die es kan kijken of het mogelijk is deze parallel te zetten, in enkele verschillende richtingen, en dan is een afstandsbediening ofzo op richten om te kijken in welke mate het signaal consistent blijft zodat we slechts 1 ingang moeten gebruiken voor een "oneindig" aantal TSOPs

/Edit; het is idd al mooi om te dromen maar ik zou het momenteel nog even houden op het effectieve shoot/hit gedeelte, al de rest komt nadien wel

[ Voor 9% gewijzigd door Anoniem: 118825 op 16-03-2007 15:35 ]

[Sprite_tm]

Klinkt als een gaaf project, ik heb iets te veel andere zaken lopen om mee te doen, maar ik kijk met veel interesse mee

Het lijkt me idd een goed idee om alles zo modulair mogelijk te maken. Microcontrollers kosten toch geen tiet meer, en het is alleen maar handig om overal dezelfde kabel etc tussen te hebben; daar verdien je de kosten van de paar uCs wel mee terug. Ik vraag me echter af of i2c nou zo'n goede keuze is: doordat dat van open-drain-verbindingen die mbv een simpel pull-upje omhoog getrokken word, kan het nogal storingsgevoelig zijn. Je kan misschien beter de UART van alle uCs pakken en daarvan de transmit- en receive-pinnetjes aanelkaar knopen en op een RS232-ish manier communicatie opzetten: normaal praat alleen de master en heeft de rest de Tx-pin in tristate staan, als een slave wil antwoorden schakelt 'ie z'n Tx-pin aan en antwoord de master. Omdat UARTs steviger gebouwd zijn qua storingsgevoeligheid en ook bijvoorbeeld hardware paritycheck ondersteunen, ben je zekerder dat je netwerk up blijft dan bij i2c. Voordeel 2 is dat je ook je power door je XLR-jack kan laten lopen: gnd, comms en power en je hebt 3 pinnen.

Scud_racer: Afaik hadden die TSOP-units een open-drain-uitgang, dus kan je ze vrolijk parallel schakelen.

En nog meer ideeen: Design eerst eens het communicatieprotocol tussen alle units, het liefst incl. automatische detectering wat er allemaal aan de lijn hangt (zodat je zonder iets in te stellen bijv. een extra gun aan kan klikken, je pak kan re-initten en spelen.) Dat is je basis van het systeem, als je dat goed hebt kan je de sub-protocollen van je individuele apparaten (laser, sensor, ...) bekijken en specificeren. Als je die hebt kunnen mensen namelijk al beginnen met het inelkaardraaien van de firmware daarvoor. Pak daarna een standaardspel (free4all bijvoorbeeld) en ga daarvoor de backpack-sw ontwikkelen. Anderen kunnen ondertussen bezig met de casing e.d., en als je het goed aanpakt kan je binnen no-time je eerste spelletje al spelen.

Ahrg, ik blijf ideeen krijgen: Misschien is het een idee om de spelregels als een soort script op te bouwen? Als je dat doet kan je namelijk gewoon een compleet nieuw spel ontwikkelen zonder dat iedereen de firmware in z'n pak hoeft te upgraden. Gewoon via IR of RF het nieuwe script erinzetten en gaan met die banaan. Heeft meteen als extra voordeel dat iedereen desnoods z'n eigen hardware en firmware kan ontwikkelen; zolang het de scripttaal ondersteunt, draait het wel. Je zou zoiets btw gewoon als een virtuele machine kunnen inrichten, dan past het bijvoorbeeld makkelijk in een ATMega8 of een stevige PIC.
Mochten jullie besluiten dat dat een goed idee is, wil ik wel aan het design van de scripttaal en -interpreter meewerken; ik heb al vaker met dat bijltje gehakt.

[ Voor 42% gewijzigd door Sprite_tm op 16-03-2007 16:11 ]

[Phalox]

Sourceforge doet het ook op z'n gemak precies.. nog altijd nix te vinden

Twordt me nu al allemaal te moeilijk, ik versta er wel wat van, maar niet veel meer... Er zullen dus beslissingen gemaakt moeten worden. Wat wordt gebruikt als hoofdplatform ? wat om de communicatie te voorzien tussen 2 modules (het hoofdmodule, en een "uitbereideingsset" )

Maar daar zijn jullie veeeel beter in dan ik

[Anoniem: 118825]

@ Sprite, thanks,kunnen we daar al verder op gaan.

Vraagje ivm die scripting, lijkt me echt wel heel interessant trouwens, maar ik heb absoluut in de verste verte geen idee wat je nu eigenlijk bedoelt kan je dat es wat verduidelijken ivm koppeling tss firmware/script? Als firmware heb je dan een aantal standaard subroutines die je scripts aanroepen ofzo?

@ the rest, Sprite heeft idd wel een punt ivm de comm's, RS-232 is zowel bijna standaard ingebakken in elke controller, plus storingsongevoeliger.Any comments?

Wat betreft de sensoren, daar maakt niet zoveel uit dat je kan detecteren hoeveel er aangesloten zijn lijkt me, wat wapens of extra items betreft kan je bij "bootup" er bv van uit gaan dat de hoofdunit bv via 255 adressen een "call" doet, waarop de aangesloten items dan een reply geven met eventuele verdere informatie. Een standaard wapen heeft dan bv adres1, een shotgun adres2. Of een wapen heeft zowieso adres1, met nog een extra byte die het type wapen aangeeft.
Enkel probleem is dan dat je bv geen twee wapens kan toevoegen, tenzij de adressen instelbaar zijn.

[Phalox]

Nog maar eventjes wat uitgetekent, handig om gedchten te ordenen



Dit is dus wat ik er zover van begrepen heb, en da script krijg ik niet in dit schema verwerkt


Owja: als er een website komt, ben ik wel bereid om vertaal werk te doen. Ik denk wel dat het handig is als je een site in engels en nederlands hebt. Ehm, die lijst van deelnemers bijhouden is ook niet makkelijk, ik moet altijd terugzoeken naar waar ik die gepost had

[ Voor 35% gewijzigd door Phalox op 16-03-2007 18:41 ]

[JanPaul123]

Er is veel gepost zie ik. Veel goede ideeën over meerdere guns, sensoren, backpacks, communicatie protocollen! Zoals ik het nu heb is alles geïntegreerd in de gun, met 4 lijnen naar sensoren (power, gnd, ontvangst en leds aan/uit) Je kunt dus nog niet meerdere geweren aansluiten of zelfs detecteren waar je geraakt bent. Mijn voorstel is om dit te vervolmaken alvorens we complexere systemen gaan bouwen. Wel moeten we alles vanaf het begin abstract maken, dat wil zeggen een aparte software module voor functies van de gun, zoals bijhouden van ammo, schieten, enzovoort, en ook niet meer dan bij de gun hoort, zodat het later makkelijker is om dit in een aparte microcontroller te stoppen.

Het is uitstekend om nu over alle mogelijkheden te brainstormen, later kunnen we beslissen welke ideeën we in welke volgorde zullen implementeren, maar het is goed om allerlei invalshoeken belicht te hebben.

Ik zal binnenkort mijn huidige ontwerp publiceren, maar ik wil toch eerst iets hebben om mee te beginnen, een open source project is niets waard als je geen aanknopingspunt hebt, geen software waarvan je kunt uitgaan.

Verder zou het mooi zijn als een (ervaren) websitebouwer een Joomla site zou willen inrichten. Post maar even een portfolio ofzo, dan zal ik details sturen zodra men vindt wie het meest geschikt hiervoor is.

In ieder geval is het geweldig dat jullie zo enthousiast zijn. Waarschijnlijk zullen in een later stadium ook Engelstaligen zich aansluiten, maar vooralsnog is het mooi om met taalgenoten te beginnen.

[Kek]

oww ik kan niet wachten om hier aan mee te werken mijn kennis op het gebied van controllers/electronica en programeren is dan wel niet zo groot, maar ik sta vooraan om zelf dingen te maken en te testen.

Schrijf mij ook maar in voor goede ideeen, solderen, testen en in een later stadium, prototype guns te maken.

en idd een site met een forumpje zou erg handig zijn.

[ Voor 17% gewijzigd door Kek op 16-03-2007 20:07 ]

[Phalox]

Ik ben eens aan het zien naar dat Joomla gedoe, ziet er mij toch niet al te moeilijk uit hoor

Ik heb beetje ervaring met php en mysql, forums beheren, website beheren (zie www.5wwe.co.nr)
De handleiding kan je gemakkelijk volgen, en ik heb toch eventjes tijd genoeg

[brinkdinges]

Ik heb er ook wel eens over nagedacht om zoiets te maken, maar dat is er natuurlijk nooit van gekomen Ik zou best wel mee willen werken. Ik weet wel wat van electronica, en een beetje logisch nadenken wil ik ook wel aan mee doen

offtopic:
Google's advertenties doen het ook weer goed

[Phalox]

Eventjes snel een installatie gedaan, hier bij mij thuis.. 't is toch nét iets moeilijker dan ik dacht. Het systeem steekt niet zo intuitief in elkaar..
http://213.219.145.54:111...table-Full_Package_dutch/

Niet teveel traffic genereren aub wij zitten maar achter een pover internet connectie-tje, en er valt toch niet veel op te zien. 'tis gewoon handig om eens uit te proberen

[shorttracker]

Ik zou ook graag willen meewerken, ik ben nu eerstejaars student elektrotechniek, en ik denk dat ik een hoop kan leren van dit project. Ik kan een beetje c proggen, knutselen, en logisch nadenken

[JanPaul123]

tokesnugerd schreef op vrijdag 16 maart 2007 @ 21:11:
't is toch nét iets moeilijker dan ik dacht. Het systeem steekt niet zo intuitief in elkaar..

Klopt, maar als je het eenmaal door hebt is het wel heel leuk

[Phalox]

Hoe zit dat eigenlijk met die hosting ? daar kan je toch makkelijk een forum op zetten ? da's snel gedaan hoor 15 minuten en het staat erop, volledig actief.

[mithras]

Als je een wat snellere hosting wil: ik heb ff een subdomein aangezet en een ftp account daarvoor opgezet. http://openlaserfrag.juriansluiman.nl.
Ftp username: [e-mail]
Ftp wachtwoord: henk
Database naam: juriansl_openlaserfrag
Db username: juriansl_laser
Db pass: henk

Maak het niet te bond, maar met 500MB diskspace / 30BG bandwith moet ik er niet al te snel doorheen zitten

offtopic:
En als je nog even de tijd hebt, binnenkort is de nieuwe versie van mn cms beschikbaar wat snel en lekker draait.

[ Voor 13% gewijzigd door mithras op 17-03-2007 00:39 ]

[Phalox]

Voila, forum is gemaakt http://openlaserfrag.juriansluiman.nl/Forum/index.php

Ik ga even een paar admin accounts maken, zodat jullie er ook op kunnen. (mithras al zeker )

EDIT: @ Mithras & Gluggie: ik heb jullie paswoorden doorgemaild naar de adressen die op deze site staan..

offtopic:
Wat is die cms?? ik heb eens gezocht op google, leek me wel interessant

[ Voor 16% gewijzigd door Phalox op 17-03-2007 01:25 ]

[trigger808]

Ik zou wel mee willen helpen maar ik kan helaas niks wat jullie nodig hebben, maar ik wil best wel als alpha/beta tester met wat anderen een weekend op de hei/bos gaan liggen (maar dat gaat nog wel even duren)

Het idee vind ik wel super, ik heb er toevallig ook al vaker aan gedacht (niet om zelf te maken want daar mis ik veel kennis voor) wat ik er van zou maken en wat er allemaal bij komt kijken.

Hoeveel sensoren willen jullie op een speler plakken? Want dat zullen er nogal wat wijn (hoofd, lichaam armen en benen en dan aan minstens voor- en achterkant, dat zijn al 8 sensoren die met kabeltjes aan elkaar zitten)

[Martkrui]

Ik las dat jullie (iemand?) liever geen backpack gebruikt voor dit project maar is het dan niet mogelijk het spel te beinvloeden door de sensoren "goed" te plaatsen ?

Sensoren op de juiste plek op de borstkast zijn bv af te dekken met armen/wapen.

Ik zou daarom toch eens nadenken over een soort harnas. Zeg maar de banden van een rugzak, zonder de zak .
Voorbeeld, een climbers harness:

Hier zitten dan de std. sensoren vast die je zoiezo nodig hebt en geen problemen met valsspelen, sensoren die verschuiven of vallen.

[mithras]

tokesnugerd schreef op zaterdag 17 maart 2007 @ 01:16:

offtopic:
Wat is die cms?? ik heb eens gezocht op google, leek me wel interessant

offtopic:
Mijn cms is nog niet te vinden op Google, maar mn site draait erop en een site site waarmee ik bezig ben. Het is nog ook alpha software en bijvoorbeeld een installatie is nog niet geschreven. Echter gaat het niet zo vlot deze week aangezien ik pas mijn site ben kwijtgeraakt en dus met een oude versie opnieuw moest beginnen

[Phalox]

Nog niemand op het forum geweest ? het is zeer licht, en ook vrij eenvoudig. Iet minder grafisch, dus je moet de bbcode wel kennen

http://openlaserfrag.juriansluiman.nl/Forum/help.php#bbcode -> hier wat meer informatie

[Anoniem: 118825]

Dr.DNA schreef op zaterdag 17 maart 2007 @ 04:47:
Ik zou daarom toch eens nadenken over een soort harnas. Zeg maar de banden van een rugzak, zonder de zak .
Voorbeeld, een climbers harness: [afbeelding]

Hier zitten dan de std. sensoren vast die je zoiezo nodig hebt en geen problemen met valsspelen, sensoren die verschuiven of vallen.

Dacht ook aan zo'n systeem, maar persoonlijk had ik eerder een soort motorcross harnas in gedachten, hoewel dat pakken duurder zal zijn dan dit mooi idee!

[Phalox]

Jaja, we lazen het 2 posts hierboven ook al wel.

[ Voor 79% gewijzigd door Sprite_tm op 17-03-2007 13:57 ]

[vanThijs]

Anoniem: 118825 schreef op zaterdag 17 maart 2007 @ 12:05:
[...]


Dacht ook aan zo'n systeem, maar persoonlijk had ik eerder een soort motorcross harnas in gedachten, hoewel dat pakken duurder zal zijn dan dit mooi idee!

Waarom geen overall? Goedkoop, stevig en sensoren kunnen gemakkelijk geplaatst worden over heel het lichaam.

Ik wil voor de rest ook wel wat helpen met brainstormen/proggen van micoC.

[ Voor 11% gewijzigd door vanThijs op 17-03-2007 14:07 ]

[Sprite_tm]

Is het trouwens een idee om een wiki inelkaar te zetten om het protocol kan ontwikkelen? Kan iedereen daar z'n ideen in kwijt en kunnen die ws wat makkelijker per-stuk afgeschoten en uitgewerkt worden dan als je het in een forum doet. Het is niet nuttig om ideeen als spelregels e.d. in uit te werken, daar is een forum veel handiger voor, maar specs die echt 100% vast moeten komen te liggen (protocol, scriptlanguage, connectoren, ...) komen imo sneller en beter tot ontwikkeling in een wiki.

Verder: Is het misschien een idee om de discussie gewoon in dit topic te houden ipv een apart forum? Niet zozeer omdat ik daar waarschijnlijk geen modrechten heb en GoT gewoon rulet maar je hebt hier een heleboel mensen die meelezen en als ze iets leuks tegenkomen een post doen. Als ze daarvoor naar een apart forum moeten zul je zien dat 75% afhaakt en je een veel kleinere groep overhoudt. Laat je vooral niet tegenhouden om toch naar een eigen forum te verhuizen, maar 't is misschien iets om mee te nemen.

[Phalox]

Wiki komt eraan

*sorry voor "dubbel post" ik wou even wat meer mensen lokken, niet zo'n goed idee vn mij :p*

offtopic:
btw: als je mod wilt zijn, moetje gewoon vragen tis maar een kleine moeite, en als je hier al mod bent, dan ben je zeker te vertrouwen!

Je kan wel gelijk hebben, maar ordelijk is het zeker niet! alles in 1 post maakt 1 grote puinhoop, en dat is wel wat moelijker als je met meerdere mensen aan een project moet werken

*zucht* http://openlaserfrag.juriansluiman.nl/Wiki/ -> we have an error, en ik kan er niets aan doen! Toch geen wiki dus..

[ Voor 72% gewijzigd door Phalox op 17-03-2007 14:28 ]

[Sprite_tm]

Temp wiki. Deze draait op mijn server en kan wel het eea hebben. Als er een eigen domein + hosting is en het moet die kant opgemoved worden moet er maar een gil gegeven worden, exporteer ik de databases ff.
Wiki-addr: http://sprite.student.utw...rfrag/index.php/Main_Page

[mithras]

Organisatorisch ben ik het er wel mee eens om lekker de discussie op een forum (dus ook: hier) te houden. Om de ideeën wat vastere vormen te geven heb je een wiki, en pas als er over een (lange) tijd echt wat te presenteren is kan je een site opzetten met wat tekstuele, statische, pagina's.

Helaas dat ik niet kan met elektronica en (pic)programmeren, dus inhoudelijk zal ik minder ondersteuning kunnen geven

[slopert]

Ik denk dat het beter is om eerst een protocol te verzinnen (rekening houdend met de hardware), misschien is het goed om als basis het milestag protocol te gebruiken. Eventueel zou daar nog uitbreidingen/aanpassingen to maken nodig zijn.

Ben zelf niet echt goed in proggen, weet wel wat van electronica, maar kan wel redelijk goed logisch nadenken en rekening houden met onvoorziene dingen.

Edit:

Zit net te denken, misschien zou er ook alvast rekening gehouden moeten worden om wat voor voor spel modi's er gebruikt kunnen worden.

[ Voor 15% gewijzigd door slopert op 17-03-2007 16:06 . Reden: nieuwe idee ]

[mithras]

Wat wordt er eigenlijk bedoeld met "protocol"? De interne communicatie tussen centrale chip en elementen als sensoren en guns? Of bedoel je het signaal wat je zendt met je gun? Of wat je verstuurd tussen centrale server en persoon (met RF)? * mithras snapt er niet veel van

Daarnaast: over die spelmodi, ik zou het zo houden dat je een centrale chip hebt die alle "equipment" kan starten en stoppen, en daarnaast signalen ontvangen (sensoren), uitsturen (guns) en nog een extra signaal (voor CTF of iets anders: breed inzetbaar).

Dan kan je op dat fundament hardware aansluiten (een of meerdere sensoren, een of meerdere guns en een of meerdere "overigen").
Hoe het spel in elkaar zit maakt niet uit, dat kan je met een 2e chip ofzo regelen. Als de programmeercode die eerder als is genoemd: je hoeft alleen je programma aan te passen, en je hebt een compleet ander spel. Je hebt dan je spelregels losgekoppeld van het systeem zelf, waardoor het breed inzetbaar wordt

[Phalox]

Ja, ik zou ook eerst beginnen aan een systeem dat vanuit een centraal punt geregeld wordt. Dan zijn later alle mogelijkheden nog open.
Als je nu al gaat "beperken" door alles in je gun te steken, moet je later alles misschien terug opnieuw doen.

[Anoniem: 118825]

Makkelijkste is mss om alles in subroutines te schrijven, waarbij dan enkel en alleen het soort game de verschillende oproepen doet naar alle subroutines. Zo kan iedereen nadien zijn "eigen" games nog vrij makkelijk schrijven, plus wordt het eenvoudiger om alles op te splitsen (een team voor guncode, een team voor hoofdcontrollercode, enz enz)

Qua protocol zou ik het ook bij Milestag houden, eenvoudig, we hebben al alle info die er nodig is, alleen de system messages bv zou ik nog aanpassen naar eigen wens. 7 teams met 32 spelers per team.. kwijl

[shorttracker]

dat milestag protocol zit inderdaad wel goed in elkaar, maar geeft niet echt mogelijkheden voor verschillende speltypen...
het is alleen geschikt voor Team-Deathmatch, en gewoon Deathmatch.
(Deathmatch kan dan wel max. gespeeld worden met 32mensen...)

[ Voor 179% gewijzigd door shorttracker op 17-03-2007 18:00 ]

[Sprite_tm]

De spelregels die ik voorstelde is dus hetgene wat in een scriptingtaal geschreven zou kunnen worden. Ik zal es proberen uit te leggen wat ik daarmee bedoel. * Sprite_tm gaat er eens goed voor zitten.

Kijk naar een taal als Java of Flash. Dat zijn talen die gecompileerd worden naar een soort van virtuele processor, en als je een programma daarvoor geschreven uitvoert, emuleert de runtime library feitelijk die processor. Dat is handig: ten eerste kan je de processor fijn optimaliseren voor je taak (met 1 assembly-instructie veel gespecialiseerde dingen doen) maar ten tweede is het ook nog eens cross-platform-compatible. Dat is practisch, want als je later je apparatuur op goedkopere/uitgebreidere/... hardware wilt draaien, ben je alsnog automatisch compatible met de bestaande hardware, zolang je er de virtual machine maar op implementeert.

De virtuele machine die ik voorstel heeft als bedoeling om het hele pak te abstraheren naar een stel randapparaten. Vanuit de virtuele machine zou je dus bijvoorbeeld de sensorstatus gewoon uit een register uitlezen: het hele verhaal van berichten over de bus sturen en terugkrijgen word door de emulator geregeld. Ook verschillen in de hardware kunnen weggeabstraheerd worden: als het programma draaiende op de VM naar een display wil versturen 'Je bent geraakt door Pietje in je nek met een M50' kan dat afhankelijk van de hardware in een knipperend ledje, een getal op een LED-display of zelfs de complete text op een PDA ofzo omgezet worden. Je hoeft dus als programmeur geen rekening te houden met dat soort verschillen, en als je een eigen display oid aan je pak wilt klussen kan dat ook.

Nog een voordeel is dat je elk spel in principe als een programma met daarin geencodeerd de spelregels kan versturen. CtF, tag, deathmatch, teams, ..., het kan allemaal uitgevoerd worden als een VM-programma. Ook geintjes als oplaadstationnen e.d. kunnen dmv de VM-code makkelijk een andere betekenis krijgen (ipv ammo erbij bijvoorbeeld helth erbij) zonder dat aan de firmware van de hardware zelf gesleuteld dient te worden.

Het distribueren van de code zou trouwens ook via IR kunnen gebeuren: denk aan een IR-schijnwerper die naar alle ontvangers in de pakken de code 'beamt'. Omdat je instructies zwaar gespecialiseerd zijn kan je met weinig bytes al een goed programma maken, de tijd die het duurt moet dus geen probleem wezen.

Ook compatibiliteit met andere systemen zou, als je direct de IR-sensor en -zender kan accessen vanuit de VM, in een VM-programma gestopt kunnen worden: beam even het juiste progje over en je kan met MilesTag-mensen spelen. Ander protocol? Ander VM-programma en gaan met die banaan. Voordeel is wederom dat je aangesloten hardware automatisch goed werkt: of je nu een ledje of een VGA-display aan je pak gehangen hebt, hij displayt de hoeveelheid info die het aankan.

Het nadeel is wel dat we een stel kundige programmeurs moeten hebben om de verschillende speltypen om te zetten in VM-code, maar daar dat code is die zowiezo one way or another wel geschreven moet worden zie ik er geen probleem in Ook de VM zelf moet gecoded worden, maar uit ervaring weet ik dat dat meer een kwestie van goed designen dan van echt coden is, en ik denk dat er meer mensen kunnen helpen met het eerste dan met het laatste.

[Phalox]

Impressive Idea , ik snap het wel ongeveer. en je hebt gelijk, zo'n "VM" heeft sterke kracht in z'n crossplatform. Zo kan je vrij gemakkelijk nieuwe hardware toevoegen/maken..

Maar ik heb nog niet door hoe je dit praktisch moet realiseren (niet dat ik er veel verstand van heb )
Als de andere mensjes hier dat wel kunnen, go 4 it!! ik zal me nuttig maken als jullie dat nodig vinden, want ik heb er niet genoeg / geen verstand van.

offtopic:
Ik heb 2 pagina's aangemaakt op de wiki, maar ik weet niet direct iets om er op te zetten!

[ Voor 10% gewijzigd door Phalox op 17-03-2007 18:43 ]

[slopert]

Anoniem: 118825 schreef op zaterdag 17 maart 2007 @ 16:52:
Makkelijkste is mss om alles in subroutines te schrijven, waarbij dan enkel en alleen het soort game de verschillende oproepen doet naar alle subroutines. Zo kan iedereen nadien zijn "eigen" games nog vrij makkelijk schrijven, plus wordt het eenvoudiger om alles op te splitsen (een team voor guncode, een team voor hoofdcontrollercode, enz enz)

Qua protocol zou ik het ook bij Milestag houden, eenvoudig, we hebben al alle info die er nodig is, alleen de system messages bv zou ik nog aanpassen naar eigen wens. 7 teams met 32 spelers per team.. kwijl

Ik ben het helemaal met je eens, weet ook niet waarom eigenlijk. Maar het idee met een VM lijkt me ingewikkeld op de een of andere manier. In BV de system code zijn de volgende undefined:
00011000 Undefined
00011001 Undefined
00011010 Undefined
00011011 Undefined
00011100 Undefined
00011101 Undefined
00011110 Undefined
00011111 Undefined
Deze zou je kunnen definieren de verschillende game modes.
Team tegen team (7x32 pers)
Caputre the flag (7x32 pers)
Tag team (112 x 2 pers)
en nog veel meer

In de data code zou je dan de team verdeling oid kunnen zetten.

[Sprite_tm]

Als je een voorbeeld wilt, kijk dan eens naar de sourcecode van een Chip8-emulator. Dat is een game-platform van heeeeeel vroegah, wat op ongeveer dezelfde manier opgezet is: de spelletjes zijn ook code die op een virtuele machine uitgevoerd word. Dat runde op hardware met paar K aan RAM, waarvan 99% voor het spel zelf was, en een 8-bits proc van nauwelijks een MHz. Zoiets is dus ook prima in een PIC of AVR te zetten.

En ik ben het met ^^ eens dat VMs ingewikkeld klinken. In de praktijk valt het allemaal mee: je schrijft gewoon een stel specs voor wat de VM-emulator moet kunnen en gaat dat domweg implementeren. De core is gewoon een stel if (opcode==0xbla) then reg1=reg1+1;-regeltjes, en de rest van de 'hardware' zijn dezelfde subroutines die je bij een normaal programma ook zou krijgen.

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

[slopert]

Mij zou het niet uitmaken hoe het geimplementeerd zou worden, ik kan niet proggen anyway.
Maar als je nou vergeten bent om (ik noem maar wat) friendly fire te implementeren, zou je dan de hele VM opnieuw moeten compileren? Of om de vraag anders te stellen heeft 1 van de 2 ideeen voordelen voor uitbreidbaarheid, behalve voor hardware dan?

[Borgoth]

Lasergamen. Ik heb zeker intresse in dit onderwerp. Moet nog even wachten voor ik me er echt in kan verdiepen Heb deze week niet de gelegenheid om veel te internetten.

Ik schrijf me wel alvast in voor solderen en testen (ik denk dat testen mischien iets te globaal is aangezien er nog heel veel moet gebeuren) Ik ga volgende week beginnen met programeren. Mischien zet ik me er later in dit project nog voor beschikbaar. Ook wil ik helpen mee denken met het ontwerpen van de plaatsing van de sensoren en te gebruiken materiaalen.

edit:
Mischien is het een idee om capture-the-flag te maken. Dat je een kastje heb in de ene basis waar de tegenstander op schiet en dan weer naar z'n eigen basis moet komen. Word hij neergeschoten gaat de vlag automatisch weer naar het "kastje". moeten we alleen nog kijken hoe we duidelijk maken dat je ziet dat hij de vlag heeft, mischien met een blauwe led?
(ik bedenk het expres met een kastje waar je op moet schieten omdat je anders met het probleem zit dat je de vlag ook terug naar zijn eige basis moet krijgen. Dit kan niet zoals in UT ofzo )

[ Voor 34% gewijzigd door Borgoth op 17-03-2007 19:15 ]

[slopert]

togesnugerd, ik heb een paar links in de wiki gezet.

Misschien is het ook duidelijker om te stellen dat er twee verschillende soorten protocollen in dit project zijn. De ene is tussen de hadware op 1 speler en het tweede protocol is de communicatie tussen de spelers en de game master.
Protocol 1 zou dus I2C, RS232, PCI of AGP kunnen zijn. De laatste 2 zijn meer voorbleed dan realistisch.
Protocol 2 zou dus RC5, WiFi of IR kunnen zijn. Zeg maar de taal die over het verbindings medium gesproken wordt.