I have requirement of developing an Quiz Game but real time. I have read a little about it and went through some tutorials and documentations.
I have a queries in my mind regarding making it real time and effective.
I want to ask that
Whether I should use Game Center or Socket Programming where server is made in PHP/Asp.net or Python.
As, the architecture which I am thinking to make is looks like as below...
Architect…..
Download All Categories.
Select Subject, or Category/topic, every category can have many subjects.
After selecting, you will press button, Play now, it will send query to server, that you want to play., server will choose any one who also want to play and searching for some opponent
After both opponents are selected, it will send data to both, means in response of previous request, a user along with data of questions will be send.
As every question has fixed time, fixed score, so locally it will be shown and calculated and score will be sent to server and server will also show score to both players. means another data will be send, but very small data, say one string or two.
As time will be over, another request will be sent and final result will be displayed.
Thanks
Proper guidance will be appreciated.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I'm learning how to parse JSON from web APIs. I have read that I need to asynchronously return my parsed data from the API for my application, as opposed to synchronously. I'm not sure why it has to be asynchronously. I know it has something to do with threading, but that doesn't clarify it for me.
Why do network requests have to be performed asynchronously?
The fact that you should to do this asynchonously has nothing to do with the nature of the response (JSON or otherwise). It’s just that you’re requesting data from an API on a remote server and you don’t know how long it will take (subject to the nature of the network the device is on, how busy the web server is, etc.).
Bottom line, any task that takes more than a few milliseconds should generally be performed asynchronously to ensure a responsive UI, and this API call will take much more time than that.
Analogy time
Imagine that you're employed in the information booth of a train station to manually update a board with trains' statuses. You read off an old-fashioned ticker tape and move models of the trains around so that passengers can see what's going on. You also answer questions about schedules and such directly, when passengers ask you.
You realize that for one particular portion of the board, some information is missing from your tape. Your colleague has the info, but she isn't in the station. So you leave the board, go over to the phone, and call her. You dial, and wait for her to pick up, and then explain what you need. She doesn't have what you need immediately to hand, so she asks you to wait a moment while she gets it.
Meanwhile, the tape doesn't stop. Information about trains continues to come in. but because you're sitting there on the phone waiting, you're not doing anything with it. The people who are watching the board get frustrated, and the people who have questions for you can't ask them either.
Finally, your colleage comes back and gives you what you asked for. You thank her and return to the board. You realize the board is in very bad shape, not reflecting the current state of the world at all. And the passengers with questions have stormed out and left you a one-star review on the App, I mean Train, Store.
Next day, the same situation comes up. You need information you don't have. Instead of stepping away from the board for several minutes, you quickly fire off a text message, and get right back to talking to passengers and moving things around on the board.
In about the same amount of time that you spent waiting on the phone yesterday, you get a text back from your colleague with the information. You incorporate it into your workflow, and nobody even notices that you spend a couple of seconds reading from your phone instead of the ticker tape. Victory!
The first day, you made a synchronous network request. You initiated a conversation with a remote service and waited until you got the response. When that happened, your UI was locked up, neither taking input from the user nor refreshing its own state.
The second day, you made an asynchronous request. You kept working normally until the response came back, allowing you to continue with all your other tasks.
I'm working on a little WebVR game using Hayden Lee's library, Networked AFrame and I'd like to place the users on a specific position as soon as they arrive in the networked room.
I've tried using the 'onConnect' callback, but when it's called the NAF object connectList is empty, so I cannot know if I'm the first one in the room or if other clients are already connected.
What would be the best way to get this kind of information, I can't find information about it in the docs.
Thanks for your help!
Currently in Networked-Aframe you can only control the position of entities that you have created and there is not a mechanism for determining how many people are in the room.
The only way to do what you're suggesting with NAF 0.2.3 is to set an arbitrary wait period after the onConnect callback, say 10 seconds, in which you hope that all the other users connect to the room. If there are anomalies that take longer and you end up with a collision of two people choosing the same position you react to that collision (which is also hard given there isn't events for users connecting yet). NAF 0.3.0 will at least have events for other users joining.
I’m attempting to build a multi peer network app and I’ve got everything working for a single conversation between two users however the intention was to build a master- -> detail app like whatsapp where you have a list of conversations and tapping one takes you to the conversation. The problem I’m having is all the housekeeping in maintain multiple sessions.
My structure is that I have a ‘conversation manager’ which has an array of ‘conversations’ which are wrappers for an MCSession that have an array of messages. When a conversation is started (either by inviting a recipient or by accepting an invitation) the conversation object(session) is added to the array, which is the data source for the master table view. When a conversation is selected from the list, in prepare for segue I pass the conversation object to the detail view controller and it’s array of messages become the data source for the detail screen.
I’m having numerous issues trying to get this working, such as messages not being delivered in conversations currently not on screen, keeping all the sessions active, not allowing multiple separate conversations between the same two people etc.
My specific question is that, most of the examples and tutorials, including Apples sample app focus around one conversation, one active session at a time. Am I wasting my time trying to get this working. Ie. Was the framework only designed to accommodate a single active session at a time?
I ran into this curious about the same thing!
I realize this is nearly 3 years old but here's a thought:
If you're using MPCF then you're accepting that these chats are within wifi/bluetooth range. Well, you could accept the limitation of one session at a time and the limitation of up to 7 active chats at any time. You and seven others? 1:1 Then you can just pair those chats up. Each peer could have 7 threads. We can assume that only 8 people have your app open and are within range? I realize this doesn't -completely- solve your problem but it hopefully it gives some direction since I'm not sure another option is possible.
And no answer/help for three years kinda stinks so I'm hoping to pitch in!
If you did find a better answer I'd love to know what you found!
Im in the need of changing a client's browser location on a certain time X. It has to be solid even if a user reloads page it should redirect to location X
Below is my current (imperfect) implementation of this:
Im in the need to a way to make this solution solid OR an alternative solution if that would fit better. ITs to complex to share code snippets so I would like to reframe from that and discuss the concept instead and discuss how to code wise implement the missing gaps to keep this question overseen able.
Current solution:
Im currently using redis and faye to send data to a subscribed channel (at the client) at time X
This means that a jquery event (redirect of url ) will be triggered when the redis background scheduler pushes/sends this data at a certain time X ( which is always in future)
The problem is this is not solid, since on a page reload the pushed/send data is never received and rendered useless.
Even if it would be possible to save the last 10 sends/pushes in lets call it a "history" one could read it but say a user drops connection the excecution of this data would be useless since it will be to late and not in time.
*How could I overcome this problem? I prefer to keep the load server side and not use a client polling the server every 1 seconds to check if there is data received. that would not scale at all and would become a big problem if usage of the app grows.*
What ideas on this concept to make it solid or use another method to get a solid implementation of this idea? any comments ideas suggestions welcome thanks in advanche!
I'm writing a FPS XNA game. It gonna be multiplayer so I came up with following:
I'm making two different assemblies — one for the game logic and the second for drawing it and the game irrelevant stuff (like rocket trails).
The type of the connection is client-server (not peer-to-peer), so every client at first connects to the server and then the game begins.
I'm completly decided to use XNA.Framework.Game class for the clients to run their game in window (or fullscreen) and the GameComponent/DrawableGameComponent classes to store the game objects and update&draw them on each frame.
Next, I want to get the answer to the question:
What should I do on the server side? I got few options:
Create my own Game class on the server, which will process all the game logic (only, no graphics). The reason why I am not using the standart Game class is when I call Game.Run() the white window appears and I cant figure out how to get rid of it.
Use somehow the original XNA's Game class, which is already has the GameComponent collection and Update event (60 times per second, just what I need).
UPDATE:
I got more questions:
First, what socket mode should I use? TCP or UDP? And how to actually let the client know that this packet is meant to be processed after that one?
Second, if I is going to use exacly GameComponent class for the game objects which is stored and processed on the server, how to make them to be drawn on the client? Inherit them (while they are combined to an assembly)? Something else?
First of all, your game logic should be on the server.. Not only does that prevent cheating, but it also garantees consistency, especially over random operations. The clients should only be sending their inputs to the server
I'd recommend your keep the server's window visible to make it a debug console, you'll need it, to know what your server is doing exactly.
For a FPS, UDP is recommended. You'll be sending a lot of data and you don't really care if your packets are all received or ordered. While the packets are not garanteed to arrive ordered, you don't really have to worry about it. Most of the time, they will arrive in order anyway. Let's say you send 60 frames per second to your clients and one of your packet arrives in the wrong order: Your client will have erroneous information for 1/60th of a second, which is barely visible.
Finally, you should send a serialized representation of your game state multiple times per second to your clients. They should be able to retrieve that information and draw it the same way as your server. You could even serialize your gamecomponent and send it if you think that's appropriate. It's really up to you to decide.
Hope this helps!