Open Source Lasertag project

[Tp21]

Misschien zullen sommigen onder ons het spel lasergamen wel kennen.
Voor dezen die het niet kennen, lasergamen is rondlopen met een speciaal geweer in een arena. Het geweer schiet onschuldige onzichtbare lichtstralen (infrarood, net zoals in je afstandsbediening).

Nou zijn de meeste lasergame arena's binnen en arcade-achtig. Er zijn ook enkele outdoor lasergame arena's die meer op een real-life FPS lijken.

---

Nou lijkt het mij zeer gaaf om een meer real-life FPS achtige versie van lasertag te ontwikkelen. Er zijn verschillende bestaande open source projecten maar deze zijn of technisch heel gelimiteerd of niet langer in ontwikkeling.
Een bekend voorbeeld hiervan is milestag (http://lasertagparts.com/mtdesign.htm)
en openlaserfrag (http://gathering.tweakers.net/forum/list_messages/1205402).

Bij openlaserfrag is al enige tijd geen leven meer te bekennen en bij milestag zit alles in de gun.

---

Hierom open ik nu dit topic. Ik wil een open source, modulair laser-tag systeem, wat lijkt op openlaserfrag.
Het systeem is niet zoals bijvoorbeeld milestag alles in 1 gun maar een verzameling verschillende modulaire onderdelen. Alle verschillende onderdelen zijn verbonden middels een bus.

De bus zorgt ervoor dat het systeem zeer modulair is en ook dingen als dual-wielding, of meerdere zones mogelijk zijn. Ook is het hierdoor mogelijk om in het veld wapens en andere dingen uit te wisselen.

Iedere speler heeft een 'personal controller' waar een VM op draait met de spelregels. Hierdoor is het mogelijk en zelfs makkelijk om later de regels uit te wisselen voor nieuwe regels. De personal controller houdt de health en andere speler-zaken bij en representeert de speler.

---

Er zijn nog veel onbekenden en dingen die nog uitgezocht moeten worden. Zelf ben ik redelijk onervaren met hardware, ik ben zelf meer een software-persoon. Maar ook software kan ik alle hulp bij gebruiken die ik kan krijgen!

Ik heb alvast een wiki gemaakt om mijn ideeën wat makkelijker te delen. Hier staat al enige informatie op maar het is nog in zijn beginselen. Lees deze toch door als je geïnteresseerd bent!
Deze is te vinden op: http://github.com/Darksecond/Landmine.

Ik hoop jullie hiermee geïnteresseerd te hebben gemaakt en ik hoor jullie ideeën graag!

[memphis]

In een ver verleden heb ik ooit een extra item ontwikkelt voor een lasergame, door een breuk tussen de gamehal en de opdrachtnemer is het nooit tot een product gekomen dan een half gesoldeerde print.

Ik heb wel in die tijd samples genomen van alle signalen, de laser op die guns waren puur voor het licht maar in werkelijkheid werd er met gebundeld IR licht geschoten welke makkelijk te sampelen was. Zo kon ik iedere gun van ieder team simuleren en ook een groepsbom.Ik moest de groepsbom een nieuwe dimensie geven door na een triggering (met een bewegingsmelder) 3x op een klein doel te schieten om de bom onschadelijk te maken ipv gewoon dom afgaan.

Maar het signaal bestond uit niets anders dan een teamcode en een spelernummer. Naast teamcodes hadden bommen ed ook een soort van teamcode waardoor achteraf het allemaal uitleesbaar was door wie je geraakt was.

[Tp21]

memphis schreef op zondag 22 juli 2012 @ 23:37:
In een ver verleden heb ik ooit een extra item ontwikkelt voor een lasergame, door een breuk tussen de gamehal en de opdrachtnemer is het nooit tot een product gekomen dan een half gesoldeerde print.

Ik heb wel in die tijd samples genomen van alle signalen, de laser op die guns waren puur voor het licht maar in werkelijkheid werd er met gebundeld IR licht geschoten welke makkelijk te sampelen was. Zo kon ik iedere gun van ieder team simuleren en ook een groepsbom.Ik moest de groepsbom een nieuwe dimensie geven door na een triggering (met een bewegingsmelder) 3x op een klein doel te schieten om de bom onschadelijk te maken ipv gewoon dom afgaan.

Maar het signaal bestond uit niets anders dan een teamcode en een spelernummer. Naast teamcodes hadden bommen ed ook een soort van teamcode waardoor achteraf het allemaal uitleesbaar was door wie je geraakt was.

Dit idee is dus iets uitgebreider en heeft veel meer opties en mogelijkheden. Dit lijkt me juist het leuke eraan!

[Sphere-]

OpenLaserFrag is niet helemaal dood maar ik moet toegeven dat de ontwikkeling ook niet echt snel gaat.
Voornamelijk omdat ik zo ongeveer de enige ben die flink bijgedraagt heeft aan de eerste implementatie (en Sprite's VM, maar die route hebben we niet genomen) en ik momenteel niet super gemotiveerd ben.

Er is een werkend basissysteem ( http://www.sphere.ws/openlaserfrag/images/base_system.png http://www.sphere.ws/open..._batch_01/asembled_01.jpg ) en de firmwares zijn ook zo goed als af voor basic taggen maar het moet nog opgekuist worden.

[ Voor 26% gewijzigd door Sphere- op 23-07-2012 00:41 ]

[Tp21]

Sphere- schreef op maandag 23 juli 2012 @ 00:38:
OpenLaserFrag is niet helemaal dood maar ik moet toegeven dat de ontwikkeling ook niet echt snel gaat.
Voornamelijk omdat ik zo ongeveer de enige ben die flink bijgedraagt heeft aan de eerste implementatie (en Sprite's VM, maar die route hebben we niet genomen) en ik momenteel niet super gemotiveerd ben.

Er is een werkend basissysteem ( http://www.sphere.ws/blog...s/2009/12/base_system.jpg ) en de firmwares zijn ook zo goed als af voor basic taggen maar het moet nog opgekuist worden.

Ik denk dat het belangrijkste ding aan een modulair lasertag systeem de bus is. De bus moet hot-plugable zijn en het moet in allerlei configuraties te gebruiken zijn (alle devices zitten aan de PC, devices verdelen zelf weer ,etc)

Zelf had ik RS-485 op het oog, maar ik ben niet echt gespecialiseerd in hardware zaken dus ik hoor graag alternatieven als die er zijn.

Ook vind ik het VM een belangrijke toevoeging aangezien die de modulariteit afmaakt en het mogelijk maakt dat mensen zelf personal controller en andere devices gaan maken.

[ Voor 8% gewijzigd door Tp21 op 23-07-2012 00:42 ]

[Sphere-]

Absoluut. OLF maakt ook gebruik van RS-485.

ps. ik heb mijn reply hierboven geupdatet.

Heb je een achtergrond in embedded systems en programmeren?

[ Voor 26% gewijzigd door Sphere- op 23-07-2012 00:44 ]

[Tp21]

Sphere- schreef op maandag 23 juli 2012 @ 00:43:
Absoluut. OLF maakt ook gebruik van RS-485.

ps. ik heb mijn reply hierboven geupdatet.

Heb je een achtergrond in embedded systems en programmeren?

Nee, ik volg een opleiding informatica en zit zelf meer in de high-level talen zoals ruby. Maar ik heb een lasertag project wel altijd interessant gevonden.

Is er trouwens een IRC kanaal ofzo, waar dit soort slow chat niet beter op terecht kan?

[Sphere-]

#openlaserfrag op irc.tweakers.net zaten we altijd maar ik zit er al sinds een half jaartje niet meer omdat ik afgelopen half jaar totaal niet meer gebruik heb gemaakt van IRC. Kzal morgen mijn irssi client eens aanslingeren aangezien ik toch ook weer aanwezig wil zijn op een aantal andere channels.

[Tp21]

Maar toch, als ik kijk naar sommige beslissingen die genomen zijn bij openlaserfrag weet ik niet of het wel de goede richting is om het project weer leven in te blazen. Sommige beslissengen die ik zelf zeer interessant vind en waarvan ik denk dat ze belangrijk zijn, zoals de VM. is er bij openlaserfrag voor gekozen om voor een alternatieve route te gaan.

Tevens zien de prints er nodeloos groot uit, maar dit is natuurlijk in een tweede revisie wel op te lossen indien nodig.

In ieder geval ben ik blij dat RS-485 een degelijke oplossing is voor de bus.

[ Voor 7% gewijzigd door Tp21 op 23-07-2012 00:56 ]

[Sphere-]

Het enige voordeel wat ik zo zie van een VM (emulator eigenlijk) is indien je de game logic (firmware) at runtime zou kunnen laden en dat je "game logic modules" uitwisselbaar zou zijn tussen verschillende hardware platformen.

Echter een aantal aandachtspunten:

1. De VM zal een abstractie moeten vormen tussen de firmware draaiend onder de VM en de hardware. Te denken valt aan UART, Timers en PWM. Deze delen van de code zullen net zo goed geport moeten worden voor elk hardware platform omdat ze platform-specifiek zijn.
2. Ik geloof dat de huidige implementatie van Sprite nog geen interrupts ondersteunt, dat kan wel wenselijk zijn.
3. Het emuleren van een processor is minder efficient dan het draaien van native code. Je zal denk ik rekening moeten houden dat het minimaal 10 keer langzamer uitvoert. Behalve dat gebruikt een VM ook geheugen (flash en sram) waardoor het de prijs van de microcontroller kan omhoog drijven (een microcontroller met 128 Bytes SRAM (bijvoorbeeld Atmel ATtiny2313) heeft misschien niet genoeg resources). Het stroomverbruik ligt ook hoger doordat je een hogere kloksnelheid nodig hebt maar dat hoeft niet perse een probleem te zijn met een redelijke batterypack.
4. Een VM is geen garantie dat je firmware overal hetzelfde gedraagt of uberhaupt werkt. De ene microcontroller heeft 128 bytes RAM en 1KB Flash, de andere heeft 8KB RAM en 128KB Flash. Verder voert de ene microcontroller een instructie uit in 1uS en de andere in 100nS.
5. Een VM met een custom instructieset is leuk maar dan zal je de code die draait op de VM wel moeten schrijven in Assembly of een eigen compiler maken of porten.
6. Een VM voegt een extra complexiteitslaag toe. "Als het niet werkt" kan het nu liggen aan de hardware, de VM of de firmware die op de VM draait waar je anders alleen naar de hardware of firmware hoeft te kijken.

Ik schrijf bovenstaande vanuit mijn persoonlijke doel om een systeem te maken dat portable is naar verschillende hardware platformen. Dit is wellicht niet een doel van jou,

Verder zou ik willen toevoegen dat het leuk is om na te denken over het perfecte systeem maar dat het uiteindelijk ook geimplementeerd moet worden door iemand of een groep.

Ik kan de printjes zo klein maken als het moet, maar dat is niet bepaald comfortabel om even snel je oscilloscoop of logic analyzer eraan te hangen

[ Voor 3% gewijzigd door Sphere- op 23-07-2012 01:50 ]

[Tp21]

Sphere- schreef op maandag 23 juli 2012 @ 01:46:
Het enige voordeel wat ik zo zie van een VM (emulator eigenlijk) is indien je de game logic (firmware) at runtime zou kunnen laden en dat je "game logic modules" uitwisselbaar zou zijn tussen verschillende hardware platformen.

Echter een aantal aandachtspunten:

...
[/list]

Ik schrijf bovenstaande vanuit mijn persoonlijke doel om een systeem te maken dat portable is naar verschillende hardware platformen. Dit is wellicht niet een doel van jou,

Verder zou ik willen toevoegen dat het leuk is om na te denken over het perfecte systeem maar dat het uiteindelijk ook geimplementeerd moet worden door iemand of een groep.

Ik kan de printjes zo klein maken als het moet, maar dat is niet bepaald comfortabel om even snel je oscilloscoop of logic analyzer eraan te hangen

Ik ben het hier niet zo mee eens, de spellogica is niet super tijdsafhankelijk en of dus de instructies sneller of langzamer uitvoeren maakt niet zo uit. Alleen de personal controller zal een VM krijgen (in een standaard set, PC, Gun en Zone).
In mijn ogen zal de personal controller zowiezo een wat zwaardere uC krijgen dan bijvoorbeeld de gun of een zone.

Dingen zoals PWM en UART kan je in je firmware afhandelen, het VM programma zal hier puur een abstractie van zien indien nodig. (Daarnaast weet ik niet of de gamelogic uberhaupt wel moet kunnen PWM'en)

De firmware mag totaal anders zijn, zolang de VM maar hetzelfde programma snapt en uiteindelijk dezelfde spelregels gelden. Als je je VM een beetje goed schrijft (in C bijvoorbeeld) is het porten van je VM naar een ander platform ook niet zo moeilijk meer.

Interrupts inbouwen in een VM is zo gedaan en niet zozeer moeilijk. Hier moet wel even goed over na worden gedacht wanneer interrupts worden aangeroepen en zo, maar dit maakt het niet zozeer ingewikkelder.

Ja, voor een VM zal er een assembler en programma's moeten worden gemaakt, maar ik denk dat dit het zeker waard is, en minder moeilijk dan je misschien denkt.

Al met al denk ik dat een VM en een toolchain ervoor maken minder moeilijk is dan jij misschien denkt. Het maken van een VM en toolchain iets dat ik prima kan.

[ Voor 40% gewijzigd door Tp21 op 23-07-2012 02:25 ]

[Sissors]

Als je met die openlaserfrag verder gaat zou ik lekker bij RS485 blijven, maar als je iets nieuws begint, is I2C dan geen makkelijkere optie? Uiteraard zolang je de afstanden kort houdt, maar dat is wel het geval in een gun, en zoveel haast is er niet bij die communicatie.

Voordeel is iig dat elke uC rechtstreekse ondersteuning heeft voor I2C, voor RS485 heb je weer een extra converter IC nodig en die moet je weer een enable signaal meegeven.

Qua VM, ben je dan niet gewoon Arduino aan het nabouwen? Vraag me ook een beetje af wat het nut ervan is, maar goed.

[Tp21]

furby-killer schreef op maandag 23 juli 2012 @ 09:11:
Als je met die openlaserfrag verder gaat zou ik lekker bij RS485 blijven, maar als je iets nieuws begint, is I2C dan geen makkelijkere optie? Uiteraard zolang je de afstanden kort houdt, maar dat is wel het geval in een gun, en zoveel haast is er niet bij die communicatie.

Voordeel is iig dat elke uC rechtstreekse ondersteuning heeft voor I2C, voor RS485 heb je weer een extra converter IC nodig en die moet je weer een enable signaal meegeven.

Qua VM, ben je dan niet gewoon Arduino aan het nabouwen? Vraag me ook een beetje af wat het nut ervan is, maar goed.

Ik heb zelf wat onderzoek gedaan naar I2C en RS-485 en ik had een aantal eisen aan mijn bus:

1. De bus moet multi-master mode ondersteunen, zowel RS-485 als I2C doen dit.
2. De bus moet geen ingebouwde addressering hebben, dit omdat mijn protocol geen expliciete adressen voor apparaten heeft. RS-485 heeft geen addressering, I2C wel
3. De bus moet langere afstanden aan kunnen (3 meter max). RS-485 doet dit zonder moeite, I2C officieel niet (er zijn blijkbaar wel oplossingen voor)

Tevens heb ik I2C afgekeurd omdat bijvoorbeeld de ammo clips met behulp van I2C met de gun praten, als we vervolgens dezelfde bus gaan gebruiken voor ander verkeer kan er hier misschien iets mis gaan.

Het leek mij makkelijker om RS-485 te maken. Nou ben ik absoluut geen expert, en ik hoor dus graag dat mijn redenen niet kloppen en dat I2C wel ideaal is


Over de VM zijn genoeg dingen te vertellen, om een AVR normaal te programmeren moet de chip in bootloader-mode staan, tevens werkt de firmware die je upload dan alleen op dat soort chips, dus als jij bijvoorbeeld een ARM chip zou gebruiken moet jij de firmware opnieuw ontwikkelen. Arduino heeft geen VM maar compileerd naar machinecode voor het apparaat (firmware)

Bij een VM kan het programma ter alle tijden worden geupload zolang de chip een goede VM heeft. Daarnaast is de omgeving binnen het VM-programma gelijk, waardoor 1 programma op allerlei soorten chips werkt.

Hierdoor kan je heel flexibel gamelogica ontwikkelen.

[Sissors]

2.De bus moet geen ingebouwde addressering hebben, dit omdat mijn protocol geen expliciete adressen voor apparaten heeft. RS-485 heeft geen addressering, I2C wel

Je kan alles naar general call adres sturen, en het lijkt mij ook wel voordelen hebben dat je ingebouwde adressen hebt, maar klopt in principe ja.

3.De bus moet langere afstanden aan kunnen (3 meter max). RS-485 doet dit zonder moeite, I2C officieel niet (er zijn blijkbaar wel oplossingen voor)

Ik denk in de praktijk dat zolang je niet al teveel haast hebt (beetje redelijke datarate dus) I2C het ook wel lukt, al moet ik wel zeggen dat als je het echt over zulke afstanden gaat hebben RS485 wel betrouwbaarder zal zijn.

Tevens heb ik I2C afgekeurd omdat bijvoorbeeld de ammo clips met behulp van I2C met de gun praten, als we vervolgens dezelfde bus gaan gebruiken voor ander verkeer kan er hier misschien iets mis gaan.

Met RS485 heb je toch exact hetzelfde probleem?

Over VMs, zover ik weet kan je een zelfgeschreven bootloader vanuit standaard prog van atmel aanroepen (alleen de bootloader moet bij nieuwere atmel chips in een bepaald gedeelte van het geheugen zitten). Wel waar dat je voor elke chip aparte firmware nodig hebt, maar wat is het doel van andere chips (bijvoorbeeld ARMs) te gebruiken als je toch dezelfde firmware erop wilt hebben? Het lijkt mij iig geen bijzonder hoge prioriteit om een complete VM te schrijven, maar goed niet mijn keuze uiteraard.

[Tp21]

furby-killer schreef op maandag 23 juli 2012 @ 16:42:
[...]

Je kan alles naar general call adres sturen, en het lijkt mij ook wel voordelen hebben dat je ingebouwde adressen hebt, maar klopt in principe ja.


[...]

Ik denk in de praktijk dat zolang je niet al teveel haast hebt (beetje redelijke datarate dus) I2C het ook wel lukt, al moet ik wel zeggen dat als je het echt over zulke afstanden gaat hebben RS485 wel betrouwbaarder zal zijn.


[...]

Met RS485 heb je toch exact hetzelfde probleem?

Over VMs, zover ik weet kan je een zelfgeschreven bootloader vanuit standaard prog van atmel aanroepen (alleen de bootloader moet bij nieuwere atmel chips in een bepaald gedeelte van het geheugen zitten). Wel waar dat je voor elke chip aparte firmware nodig hebt, maar wat is het doel van andere chips (bijvoorbeeld ARMs) te gebruiken als je toch dezelfde firmware erop wilt hebben? Het lijkt mij iig geen bijzonder hoge prioriteit om een complete VM te schrijven, maar goed niet mijn keuze uiteraard.

Met RS-485 heb je dat probleem niet omdat je je ammo clip via I2C kan benaderen (ammo clip kan een simpele I2C EEPROM zijn), waar je de UART gebruikt voor bus communicatie.

Ik heb er expres voor gekozen dat apparaten geen adres hebben. Dit om hot-plugging makkelijker te maken en dynamic addressing onnodig te maken. Hierdoor word het uiteindelijke bus-systeem simpeler.

Als iemand ervoor kiest een personal controller op basis van ARM te bouwen zal diegene nieuwe firmware moeten schrijven, of op z'n mist porten, maar een VM programma zal nog steeds werken.

[Stoney3K]

RS-485 is ook nog een heel stuk robuuster dan I2C. I2C is in eerste instantie bedoeld om op één print tussen bepaalde IC's verbinding te maken, niet om met apparaten buiten de (EMC-veilige) behuizing te kletsen.

Met RS485 heb je dat probleem niet omdat je met gebalanceerde signalen en bekabeling werkt. Alle storing en ruis van buitenaf zal een device op RS485 (bijna) geen last van hebben.

Je VM kun je inderdaad redelijk simpel houden en juist concentreren op het afhandelen van de spelregels, niet in het afhandelen van bijvoorbeeld Team/Player IDs of andere berichten. Zo gauw het voor het spel relevant is kun je je VM een signaal geven dat ie wat moet doen.

Sterker nog, je kan je hele in-game event loop gewoon netjes in je uC houden en de VM-'taal' alleen defniëren in termen van spelbeslissingen. Dan wordt je instructieset en aantal geheugenplaatsen/registers wat je voor je VM nodig hebt ook nog eens een stuk beperkter en dus makkelijker te implementeren. De daadwerkelijke uitvoeringscode van je VM kan dan bestaan uit een set branches die uitvoeren als gevolg van een bepaald bericht-ID dat je ontvangt.

Dat de printplaten groot zijn is geen nadeel, zelfs een voordeel in dit geval. Niet alleen is het makkelijker (alleen through-hole) solderen, maar in een potje lasertaggen wil het er nogal eens ruw aan toe gaan en dan heb je liever wat grotere, lompe, zware behuizingen die je aan een vest, beenholster of koppelriem kan bevestigen, in plaats van een kleine gadget van formaat mobieltje. Als je met je Personal Unit per ongeluk ergens tegenaan stoot dan wil je niet dat ie bij het eerste de beste deukje de geest geeft.

Als je mensen hun eigen VM laat implementeren moet je natuurlijk wel een mechanisme hebben om te controleren dat "hun implementatie" van jouw spel-VM klopt, en ze niet in de onderliggende laag nog ander spelgedrag uit gaan voeren. Want dan zet je de deur open tot cheaten via een simpele man-in-the-middle aanval.

[Tp21]

RS-485 is ook nog een heel stuk robuuster dan I2C. I2C is in eerste instantie bedoeld om op één print tussen bepaalde IC's verbinding te maken, niet om met apparaten buiten de (EMC-veilige) behuizing te kletsen.

Met RS485 heb je dat probleem niet omdat je met gebalanceerde signalen en bekabeling werkt. Alle storing en ruis van buitenaf zal een device op RS485 (bijna) geen last van hebben.

Klopt, hierom leek RS-485 mij een goede optie voor de bus.

Je VM kun je inderdaad redelijk simpel houden en juist concentreren op het afhandelen van de spelregels, niet in het afhandelen van bijvoorbeeld Team/Player IDs of andere berichten. Zo gauw het voor het spel relevant is kun je je VM een signaal geven dat ie wat moet doen.

Sterker nog, je kan je hele in-game event loop gewoon netjes in je uC houden en de VM-'taal' alleen defniëren in termen van spelbeslissingen. Dan wordt je instructieset en aantal geheugenplaatsen/registers wat je voor je VM nodig hebt ook nog eens een stuk beperkter en dus makkelijker te implementeren. De daadwerkelijke uitvoeringscode van je VM kan dan bestaan uit een set branches die uitvoeren als gevolg van een bepaald bericht-ID dat je ontvangt.

Precies, een VM-programma zal puur de gamelogica afhandelen, hierdoor blijft een VM-programma simpel en toch krachtig.

Dat de printplaten groot zijn is geen nadeel, zelfs een voordeel in dit geval. Niet alleen is het makkelijker (alleen through-hole) solderen, maar in een potje lasertaggen wil het er nogal eens ruw aan toe gaan en dan heb je liever wat grotere, lompe, zware behuizingen die je aan een vest, beenholster of koppelriem kan bevestigen, in plaats van een kleine gadget van formaat mobieltje. Als je met je Personal Unit per ongeluk ergens tegenaan stoot dan wil je niet dat ie bij het eerste de beste deukje de geest geeft.

De behuizing van een print en de grootte van een print staan los van elkaar. Ik zou juist zeggen dat een kleinere print, en dus een kleinere behuizing juist steviger zijn, lichter, en makkelijker mee te nemen.

Als je mensen hun eigen VM laat implementeren moet je natuurlijk wel een mechanisme hebben om te controleren dat "hun implementatie" van jouw spel-VM klopt, en ze niet in de onderliggende laag nog ander spelgedrag uit gaan voeren. Want dan zet je de deur open tot cheaten via een simpele man-in-the-middle aanval.

Mensen kunnen altijd cheaten, dit lijkt me, zeker in dit stadium, nogal vergezocht. Een VM zou het zelfs moeilijker maken omdat je dan in het programma moet kunnen (bij de VM registers, en zo)

[Stoney3K]

Tp21 schreef op maandag 23 juli 2012 @ 22:45:
[...]
De behuizing van een print en de grootte van een print staan los van elkaar. Ik zou juist zeggen dat een kleinere print, en dus een kleinere behuizing juist steviger zijn, lichter, en makkelijker mee te nemen.
[...]

Een kleinere footprint levert in dit geval ook kleinere onderdelen, kleinere bekabeling en kleinere connectoren op. Als een stuk bekabeling van 5mm dik met een XLR-stekker ergens tussen komt overleeft ie het wel, maar als je een USB/CAT5/Molex kabel hebt die in de verdrukking komt, bijvoorbeeld tussen een speler en een muur waar ie tegenaan dekking zoekt, dan kan het nog wel eens heel snel afgelopen zijn.

In de behuizing zelf kun je natuurlijk wel alles miniatuur maken, maar dan moet de behuizing zelf wel tegen een flink stootje kunnen om te zorgen dat de print niet beschadigt of zelfs schokken oploopt. Met grotere componenten heb je daar minder snel last van.

Bot gezegd: Als ik een oude ghettoblaster uit de jaren 80, met grote prints en transistoren, al spelend over mijn balkonhek smijt, dan kan ik hem beneden gewoon oprapen zonder dat de muziek gestopt is. (Nee, hij zal vast niet meer erg mooi zijn, maar er komt nog wel geluid uit ). Doe je dat met een mobieltje, dan mag je gelijk een nieuw mobieltje kopen.

Mensen kunnen altijd cheaten, dit lijkt me, zeker in dit stadium, nogal vergezocht. Een VM zou het zelfs moeilijker maken omdat je dan in het programma moet kunnen (bij de VM registers, en zo)

Het gaat er dus juist om, als mensen hun eigen VM maken die jouw VM-code kan uitvoeren, dan kan daar tussendoor nog ander gedrag geprogrammeerd worden. Niet in de VM-code dus, maar in de uitvoering van die code.

Simpel voorbeeld: VM heeft een routine waardoor er een spelbeslissing gemaakt wordt als je door een andere speler wordt geraakt. In jouw controller (die de feitelijke VM uitvoert) zal er eerst een vergelijking gemaakt moeten worden tussen het ontvangen 'hit' signaal en jouw player/team ID (bijvoorbeeld, voor het afvangen van friendly fire) waarna de betreffende routine in de VM wordt uitgevoerd.

Een simpele hack is natuurlijk om die hele routine uit te commenten en te zorgen dat dat stukje VM-code nooit wordt aangeroepen. Resultaat: Speler is onkwetsbaar, omdat de hits niet binnen komen en hij dus eigenlijk softwarematig zijn sensor heeft uitgeplugd. De code die je in je VM stopt is nog altijd 100% legitiem net zoals bij alle andere spelers, maar het gedrag dat uit diezelfde code volgt is anders omdat een hobbyist besloot om zijn eigen gedrag ervoor in de plaats te schrijven.

Nu verwacht ik ook niet dat mensen zo hard doelbewust eigen code gaan knutselen om maar spelvoordeel te halen, maar als je het protocol en je VM-indeling op straat gooit heb je die kans natuurlijk wel.

[Tp21]

Stoney3K schreef op dinsdag 24 juli 2012 @ 00:17:
[...]

In mijn ogen zou het verbergen van het protocol en VM-indeling meer obscurity zijn dan security. Maar je hebt wel gelijk, en in de toekomst zou hier zeker aandacht aan moeten worden besteed.

Aangezien dit een software probleem is, is dit probleem prima in een later stadium op te lossen en kunnen we ons eerst richten op het werkend krijgen van een systeem. anti-cheat kan dan later altijd nog.

Over de behuizing. De bekabeling en algemene casing kan je natuurlijk zo stevig maken als je zelf wilt, en het lijkt me verstandig voor de kabels en connectoren van de bus ook een goede stevige plug te kiezen.

[Scout77]

Ik heb ook nog altijd een grote legerkist vol met spullen voor OLF staan hier, helaas kom ik daar de komende tijd ook niet aan toe. Ik heb het nog wel altijd op mijn verlanglijstje staan en heb ook de protoprints voorzien van de nodige onderdelen maar nog nooit helemaal afgemaakt.

Als er ontwikkelaars zijn die bepaalde onderdelen nodig hebben, ik ben niet te beroerd om zaken te doneren voor de goede zaak.

Toen ik laatst die Raspberry Pi's zag, zag ik daar ook wel mogelijkheden voor met OLF, wel een overkill maar wat betreft programmeren en de vraag of de hardware het wel trekt hoef je je helemaal geen zorgen te maken.

[Sprite_tm]

Ik heb inderdaad een VM geschreven voor de game logic toendertijd, maar we zijn al weer een tijdje verder.... ik heb ondertussen gezien dat er andere VMs voor al wel bestaande taaltjes bestaan, bijvoorbeeld Megapython die een Python-interpreter maakt. Misschien is het nuttiger om zoiets te pakken: er zijn dan al mensen die er ervaring mee hebben (en zo niet zijn er zat tutorials) en er is al een mooie set aan tools die gebruikt kunnen worden.

[Phalox]

Ik heb ook nog een reeks aan componenten liggen! En zoals iedereen hier, wil ik er ook ooit verder aan werken :-) Ik ben een PIC microcontroller fan, dus ik zou daarmee developen

Wat ik tot op heden geleerd heb, is dat je zoveel mogelijk moet hergebruiken! Zoals Sprite zegt, als er tools beschikbaar zijn, moet je die proberen gebruiken.

[Tp21]

Phalox schreef op woensdag 25 juli 2012 @ 10:04:
PIC microcontroller

Zelf ben ik hier niet zo voor, ik ben zelf helemaal niet bekend met PIC en bekender met AVR. Ook (in ieder geval de laatste keer dat ik keek) is er geen goede open source C compiler voor de PIC en wel voor AVR.

Scout77 schreef op dinsdag 24 juli 2012 @ 22:12:
Toen ik laatst die Raspberry Pi's zag, zag ik daar ook wel mogelijkheden voor met OLF, wel een overkill maar wat betreft programmeren en de vraag of de hardware het wel trekt hoef je je helemaal geen zorgen te maken.

Ik denk dat het een goed idee is om de 'reference implementation hardware' vrij low-cost te houden. Dit betekend in mijn ogen atmega en niet raspberry. Als we ervanuit gaan dat iedereen toegang heeft tot de kracht van een raspberry zal dat de minimumeis worden (willig of niet) en het bemoeilijken om minder krachtige hardware in te zetten.

Het mooie aan zo'n modulair systeem is dat iedereen zijn eigen implementatie kan maken als ze dat willen. Zolang de VM en bus interface maar hetzelfde is zal het gewoon moeten werken.

Sprite_tm schreef op dinsdag 24 juli 2012 @ 22:32:
Ik heb inderdaad een VM geschreven voor de game logic toendertijd, maar we zijn al weer een tijdje verder.... ik heb ondertussen gezien dat er andere VMs voor al wel bestaande taaltjes bestaan, bijvoorbeeld Megapython die een Python-interpreter maakt. Misschien is het nuttiger om zoiets te pakken: er zijn dan al mensen die er ervaring mee hebben (en zo niet zijn er zat tutorials) en er is al een mooie set aan tools die gebruikt kunnen worden.

Ik heb zelf nog niet echt naar alternatieve bestaande implementaties gekeken, maar het heeft in mijn ogen zowel voor- als nadelen. De voordelen zijn dat er dan een bestaande pc compiler suite voor is. De nadelen is dat je een stukje controle over je VM verliest. Ook heeft een bestaande VM mogelijkerwijs hogere resource eisen, maar hier weet ik niet genoeg van.

Persoonlijk zou ik gaan voor een custom VM. Ik wil mij best inzetten om de compiler-suite enigsinds gebruiksvriendelijk te maken.
Maar op zich ben ik niet tegen het gebruik van een bestaande VM, mits deze niet teveel nadelen heeft.
De bestaande tooling bij een bestaande VM is wel een aanlokkelijk punt ja.

Over de python compiler, ik wil in ieder geval geen dingen als een garbage collector op de personal controller laten draaien, dit moet absoluut onnodig zijn voor de VM.

[Phalox]

Deze aanpak is misschien ook wel nuttig: http://hackaday.com/2012/...and-building-custom-guns/

Zo vertrek je niet vanaf 0...

[Scout77]

Dan is deze nog makkelijker: http://www.lasertagparts.com/arduino.htm, heeft nog meer mogelijkheden.

Helaas is deze setup nogal beperkt in de mogelijkheden, daarom zijn we er ooit mee begonnen, helaas gaat de ontwikkeling nog niet zo snel.