I am building a small cards game for Windows Store using HTML/JS as my programming languages. One of the features that I would like to add is multiplayer capability. My game it's based on a 1 versus 1 player (unlike Hearts where you need 4 players), so an ad-hoc peer-to-peer connection is enough. Also, keep in mind that I am only considering local network multiplayer, without internet support (meaning that "privateNetworkClientServer" capability is required on that app manifest).
So I am imagining, when a player want to start a multiplayer game, the app will periodically broadcast a message to find any candidates. Meanwhile he will also have to listen for those same messages (in case of another player is broadcasting them also). When they find which other we transmit the game state back and forward to perform the required games changes.
My question is, does WinRT provide any functionality out of the box to do something like this? If no, do you have any suggestion for my problem?
Thanks
Look at the documentation for the PeerFinder class. Proximity can use either NFC or by browsing on the same subnet. Note, in the case of WiFi, not all WiFI cards support the browsing model, so some older PCs may not be able to use this solution.
The proximity sample application on msdn should help you with this.
Related
i need to create an application that is capable of detecting a person entering and leaving the area in front of a big screen.
since sensors like infrared and ultrasound can easily be fooled by multiple persons i was thinking of using face / person recognition.
one option would be to use the kinekt sensor.
my questions: is this system reliable? is there another good option?
Thanks a bundle!
I've already used kinect for this kind of projects in actionscript and unity with c# and i can say that's your best and only solution to detect person and mantain a low cost.
You have 2 possibilities to use kinect with as3:
First is to use AIR with a ANE (adobe native extension) and interface c++/c# dll with your application.
Second one is to use the old trick of the socket communication. You have 2 application as3 and c#/c++ and you put them in communication with a tcp/udp connection on the loopback interface.
IMHO the best solution is the first one, you don't have to write a good protocol to communicate but you just call methods and receive events as a normal API.
I'm creating a game with HTML5 and javascript, but am having trouble finding a way to get networking working.
What I want is for one instance of the game to listen on a Websockets/http stack, while the other instances connect to it.
So far, I'm yet to find any way of doing it that doesn't require additional plugins or online services. (ie: Flash or silver light opening the socket and pumping messages back - Something that isn't acceptable for mobile, or an online server like Player.IO, which while much better than Flash, wouldn't work for Wifi networks that are disconnected from the Internet)
While the latter option is a compromise I'm willing to make, I was wondering if it's one I need to make, or if I could survive without it.
Well, if I understand what you are trying to, hope to be right.
Client One:
Plays game, listens to incoming data from Client Two
Client Two:
Plays game, connects to Client One
I'm guessing it's a P2P game? If this is the case, I think you want to look at WebRTC.
Otherwise, peer-to-peer is not really possible unless you run a mediator service that both clients connect to and handle it as a dispatcher.
I'm planning to realize the following project and would be thankful if somebody could verfy my approach!
I want to establish a fully bidirectional wireless realtime communication between a smartphone (cross platform) and a embedded microcontroller running a webserver.
The webserver should provide data of the connected hardware in realtime e.g. temerature.
The smartphone should render these on screen and you should be able to configure the hardware e.g led color with the smartphone and save the config to the embedded webserver.
My first guess was to use HTML5 websockets but they aren't available on all platforms so I got inspired by XBMC, which uses JSON-RPC.
Just imagine a car stero system with bluetooth connected to a µC with webserver and wifi dongle.
My plan is to implement a webapp on the webserver which lets serves the purpose mentioned above. But the tricky part is to get the user to establish a bluetooth connection to the stereosystem because i looked up similar questions which say you can't access stuff like bluetooth on the smartphone with HTML5.
long story short, this is the current idea:
hardware -> µC -> webserver -> HTML5 Webapp-> WIFI -> Smartphone
communication via JSON RCP.
I would be highly thankful if somesone could give a statement to said idea and planned implementation because I never done this before!
Thanks guys!
We at muzzley, have developed a framework to simplify this process. We provide a way for your browser applications to communicate with smartphones. In the side of the smartphone you have widgets that are already done (gamepad, drawpad, switch, swipe, others) or you can build your own html based widget.
(disclaimer: i work for this project)
Most of the work is already done for what you want to do :)
Quick start here:
http://www.muzzley.com/documentation/quick-start.html
You can pull from github several examples here:
https://github.com/muzzley/muzzley-demos/
Lib for browser:
http://www.muzzley.com/documentation/libraries/javascript.html
I hope it helps.
Best
I think your first instinct was probably right. Have you looked at socket.io for node? It's essentially a shiv which ensures that you can use websocket functionality in virtually any combination of device and browser (see list of supported transport mechanisms and browsers here).
It should allow you to avoid bluetooth altogether.
What is a good framework to build a multiplayer game in Actionscript?
I want to create a multiplayer 2D shooter like Asteroids on the Blackberry Playbook; my main concern is latency - a shooter wouldn't be fun if the bullets are super-jerky and unexpectedly hit people.
I'm guessing that a UDP-based framework would be the best. Can anyone point me to the right direction?
There are many things you can use off the shelf but the basic setup is very simple but you have a few options.
The most common is server push, things like Flash Media Server, LiveCycle Data Services from Adobe or other tools like SmartFoxServer can do this. With this setup the server saves the connections to everyone that connects to the server and passes or "pushes" applications state to the people connected every time the data changes in the application.
Another option is called long pulling, this can be done with any web server really. How this works is the data stores the state of the application, when the application starts it calls the server, when it responds the client calls the server again.
There are a few other ways to do it but these are the most common. But this has nothing to do with protocol like HTTP, UDP, AMF, XMPP, or whatever else. The protocol is the format that the data is sent. With these out of the box servers they normally output a few of these but the fastest formats are binary like AMF but not always the best, there are advantages to each, because each gives you different features for keeping track of things.
If you are talking about have a game that takes over the world that has millions of users then you need to think about scaling and what happens when you need two or 100 servers and how do they talk to each other. But for now keep in mind that the more the server does the slower it will get, if you are sending small amounts of data it will be able to handle more users. Stick with making one efficient server and worry about that later if you get there.
You also need to thing about what server side programming language you want to mess with if any. Some services don't let you do anything, these normally cost money and don't do as much. Adobe likes Java but there are servers that output all of these protocols in most every language. My favorit lately has been Node.js a super fast way to run JavaScript on the server. Node.js has a built in HTTP server but it is just as easy to create a simple server that sends basic text through a Socket or XMLSocket. A server like this will easily handle many thousands of users. There are many games that use Socket.IO and if you want to see a simple example of what I'm talking about you can check out this.
Assuming you want to use Flash/Flex and not Java (Blackberry/Android) or native SDKs for Playbook -
There is a book as an inspiration: http://www.packtpub.com/flash-10-multiplayer-game-essentials/book it uses Pulse SDK at the server side. But you could use an own sockets-program on the server side. I use Perl as TCP-sockets server (sends gzipped XML around) in a small card game but this wouldn't work for your shooter.
Flash does not support UDP out of the box
But there is peer-to-peer networking protocol RTMFP in the upcoming Flash Media Server Enterprise 4 (price is out of reach for mere mortals)
So your best bet is to buy an Amazon-service for RTMFP then you can pay-per-use and stay scalable...
You can either do a constant post/get request with the server to get data for the game, but for a multiplayer shooter i'd surgest SmartFoxServer: http://www.smartfoxserver.com/
Out of the box, Adobe AIR supports UDP through datagram packets.
http://help.adobe.com/en_US/air/reference/html/flash/net/DatagramSocket.html
I couldn't find a particular networking API for flash, but perhaps you can build one. Libgren is open source and you can use that for reference.
You can also look into RTMFP though it's focus is on transmitting audio/video and some messages (through TCP I think).
If you were tasked with operating a commercial DVD player from a computer program, how would you do it?
My company sells a product that does exactly that. We have a couple of different approaches, and they both have major issues:
Get an IR Transmitter, Pretend To Be a Remote Control
Pros: Works with pretty much every commercial DVD player in existence.
Cons: The IR transmitter is another moving part that can (and too frequently does) go wrong. Only allows one-way communication; you can talk to the DVD player, but it can't talk back; you can only tell if it's on or off by seeing if it's putting out a video signal.
Get a DVD Player With an RS-232 Serial Port
Pros: Everything that's "con" with the IR transmitter approach simply goes away. The direct connection is more reliable and allows the code to understand just what the machine is doing.
Cons: Niche market; very few machines actually have an RS-232 port. So, when a manufacturer discontinues a model you've been using, you're left scrambling to find a replacement.
And I suppose for the sake of completeness, I should mention....
Just Use the DVD Drive In the PC
Cons: Boss doesn't like it.
What other approaches are available? I've seen DVD players with USB ports, but the last time I researched the subject, it seemed that was just for playing media stored on an iPhone or the like and not actually a potential control mechanism.
I'm really hoping somebody will say something like "Silly boy, don't you know about the ridiculously common FOO port that allows a home theater system to control the DVD directly? Just get a USB -> FOO converter and you're all set!" But I'm grateful for any options I haven't already considered.
The DVD drive is the way to go.
But if he does not like that, I'd go ahead and get a PIC microcontroller, one with USB built in (forget which part number this is). I'd write code to control this, having the IO lines go out on lead wires that attach to the inside of the front panel buttons. You'd need less than a dozen.
If a model is obseleted, it only changes where the lead wires attach. A hole can be punched out of the back of the commercial DVD player, and one of those little rubber gaskets can seal the USB cable to it. It looks like a regular player with a USB A cable coming out of the back.
The cable itself would be rather cool, I'd buy a few if someone sold them. My "USB betamax VCR" would be hilarious.
Bonus points if you integrate it with Front Row, complete with another icon/menu entry.
Many Blue-Ray players can be controlled via the HDMI port. The protocol is probably proprietary and different for each vendor...
I am am a big fan of optical media but it is a dying form of media.
Have you considered building a small windows or linux computer with an SD card slot (Raspberry Pi) and placing a DVD disc image on the SD card? From there you could write software to playback the DVD from the image and interact with it. You could even use something like Adobe Director as a framework for playing and interacting with the DVD content.
Or you can bypass the DVD image idea altogether and build an interactive framework in Flash, HTML/CSS or Adobe Director which allows you to draw menus on the fly and playback audio/video when a link/button is selected. This would have the added benefit of being more flexible than a multiplexed DVD. You could program the menus to build from an XML file for easy language localization, typo corrections, etc. And you could support playback of video with multiple audio streams, subtitles, etc.
It depends... are you being tasked with controlling (almost) any dvd player, or do you get to decide the model? If you're trying to control whatever AV setup a customer may have, then you're basically required to go the IR transmitter route. And there will still be things you won't be able to handle (like a PS3) without additional hardware.
Most AV devices don't put out any input about their current state short of power draw and video/audio output, and the ones that do usually use proprietary rf (sony is big on this in the near future) or localized standards (like scart in europe). A handful will send/recognize command signals over coax, but that went out of style in the 90s.