I want my game to give a certain amount of coins as gift to the player on a daily basis so he can buy whatever he likes. What's the best way to achieve this so the system will be immune to stuff like setting the time forwards and re-starting the game , etc. It would be nice to have this working without the need to access the Internet.
Client is in the hands of the enemy. Whatever system you design on client side to be secure, it will be broken. If you want to have control over the player's data, you have to do it on the server.
Related
I'm looking for the simplest way to create AS3 multiplayer game. I've made few as3 games, so I basically know the language and its limits.
I've never been into server-like coding.
I want to create a simple game, just like my previous ones, but this time with multiplayer connections. I don't want p2p connection, more likely I'm looking for server/room hosting.
About the game: Something similiar to hybrid of casual mugen game and a 2d-platform shooters (watch TeeWorlds, Soldat). I don't need large database, eventually I could use some xml saved files for that purpose (no need to keep real-time data management). In the first throw I don't need accounts for that game, more like open access, same for everyone.
What are your suggestions? Which engine/enviroment/modules could I use to bring AS3 to multiplayer game? And any tutorials how to start?
Most ready made servers for multiplayer games are commercial and you'll eventually have to pay a monthly fee or so. For now, you could try AppWarp that has some tutorials here http://appwarp.shephertz.com/game-development-center/basic-concepts/
Others options you can explore are SmartFoxServer or Yahoo Games Network (former Player.IO). But all these options have costs. But if the game is simple enough you might be better suited with a Java server written from scratch, or PHP.
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'd like to build a 2-player turn based game with an authoritative server to manage the game state/logic. The flow I have in mind is something like:
Players are subscribed to a unique game channel (via pubnub/pusher/something similar)
Players submit their turns over HTTP directly to the game server
The server runs the game logic and publishes the result to the game's channel (which both players are subscribed to)
The client handles the response and renders the outcome
matchmaking kind of confuses me though. Any suggestions?
Is that the "right" way of using a pub/sub service in this scenraio? Is there a better approach (something other than polling the server constantly)?
This is a heated topic at our office! I've been using PubNub as an authoritative game server using creative choice of channel names. It works like this:
Run a node.js server (doesn't have to be node; can be anything) that serves your content, and also acts as an authoritative entity.
When a client connects, generate a UUID (can be done either server-side or client-side) and have both the client and server listen on that channel (something like "my_game_[UUID]").
Because no other clients know this channel name, the client and server can communicate freely on this channel.
The server can talk to everyone, and clients can perform secure actions through the server and communicate with each other using an "unsecure" vanilla pubnub channel.
Your proposal sounds great and is the "right" way. The challenge you face is shared from the beginning of the computer epoch, where synchronizing data is a requirement between multiple devices such as a mobile smartphone. Polling is SLOW and expensive (and does not make sense for a large number of players). Multiplayer games is a great example need to pair players and provide game rooms. Your solution is to:
Create a Game Lobby, where players can create game rooms and join game rooms.
Create an Auto-Pair of players (Quick Join) [Recommended]
You may solve this technical challenge with products such as Socket.IO and some other open source options. However you want to just build your game rather than focus on deploying a Node.JS server and hooking it up to Express.
Instead use a Cloud Service like PubNub, PusherApp or Beacon Push. Utilize the Pub/Sub API to synchronize users in a multiplayer environment easily.
I've created a simple game where 2 players make a simultaneous choice in each round, and the winner of the round is determined by a set of rules specific to the game. Sort of like how Rock Paper Scissors works.
I'd like to be able to offer this game online where 2 players can find and play against each other. There would be some central server to arbitrate the game, and then each player would interact with the game using some game client of his choice that we would provide (i.e. web-based, mobile-based, Flash, etc).
Obviously, a player could also play against a computer opponent that we could provide. I'd also like to have the capability to allow programmers to submit computer programs that they've written to act as players and play against other programs in some sort of tournament.
I realize that the specifics of my game would certainly need to be written from scratch, but it seems that all of the work that the servers would have to do to communicate with the clients and maintain the state of the game has probably been done many times before. This is probably the bulk of the work.
Does anyone have any ideas for how this could be done quickly and easily? Are there servers available with some sort of standard interface to drop new games into? Is there some sort of open source game server? How would you go about doing this?
Seeing as the clients only communicate with the game server occasionally (as opposed to continuously), a web framework should be able to serve as your "basic game server". While web frameworks may be made for providing "web pages", they can certainly be (ab)used to serve as request handlers.
This certainly doesn't force you to make the game a browser game; standalone game clients can be made easily, and they can communicate with your game server using basic http. I also heard this thing called Ajax is pretty nifty for such things.
Not only will you find a lot of ready-made http-based servers, as an added bonus, there is a lot more documentation on how to work with Web 2.0®©™ than "game servers". You just need to know that you want a web framework that lets you easily manage sessions and receive/respond to requests and a client library that does likewise.
As an added aside, "maintaining the state of the game", as you put it, falls 100% within the domain of the actual game logic. But many web frameworks come with good database support, and will surely be useful for this kind of thing.
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.