Develop Reference

Check the data has updated at server without requesting every frame of the game

I have a game where I have to get data from the server (through REST WebService with JSON) but the problem is I don't know when the data will be available on the server. So, I decided to use such a method that hit Server after specific time or on request on every frame of the game. But certainly this is not the right, scale able and efficient approach. Obviously, hammering is not the right choice.
Now my question is that how do I know that data has arrived at server so that I can use this data to run my game. Or how should I direct the back-end team to design the server in an efficient way that it responds efficiently.
Remember at server side I have Python while client side is C# with unity game-engine.

It is clearly difficult to provide an answer with little details. TL;DR is that it depends on what game you are developing. However, polling is very inefficient for at least three reasons:
The former, as you have already pointed out, it is inefficient because you generate additional workload when there is no need
The latter, because it requires TCP - server-generated updates can be sent using UDP instead, with some pros and cons (like potential loss of packets due to lack of ACK)
You may get the updates too late, particularly in the case of multiplayer games. Imagine that the last update happened right after the previous poll, and your poll is each 5 seconds. The status could be already stale.
The long and the short of it is that if you are developing a turn-based game, poll could be alright. If you are developing (as the use of Unity3D would suggest) a real-time game, then server-generated updates, ideally using UDP, are in my opinion the way to go.
Hope that helps and good luck with your project.

A few Questions about implementing a render loop in Windows Forms

Guten Tag zusammen! (German: Good Day everyone!)
Please excuse my English, it is not my mother tongue. Since I have already found a lot of good answers to my questions here I would like now to ask you some.
In the last few days I have done a little research to the question "What is the best way to implement a game loop in Windows Forms?". And I have found a good explained solution form the SlimDX team, which it is based on the work of Tom Miller.
My Questions are:
First: We I use this solution for an game loop which is the best way to redraw the From after I have rendered a frame? A way I have often found is to call Invalidete(), but this does not look like a good idea to me. Wouldn't this add a message to the message queue and break the while-loop every frame?
Second: To my understanding this loop will consume an entire CPU-Thread (Core). Is there and good way to slow it down to a recommended frame rate that does not consume an entire CPU-Thread?
Third: Is GDI+ capable of render a simply 2D game?. When did Drawing becomes so complex that it is advisable to use a hardware accelerated drawing whit some DirectX or OpenGL wrappers?

A way I have often found is to call Invalidate(), but this does not look like a good idea to me. Wouldn't this add a message to the message queue and break the while-loop every frame?
Yes, that's a bad idea. You don't control the frequency at which the messages are delivered to your window, which means you shouldn't rely on it.
To my understanding this loop will consume an entire CPU-Thread (Core). Is there and good way to slow it down to a recommended frame rate that does not consume an entire CPU-Thread?
You can use the SpinWait structure (NOT Thread.SpinWait) to wait short amount of times. Base the waiting time on the duration of the curret frame and the desired framerate.
But usually the game loop taking an entire core isn't a problem. It may even be desired if you want to maximize your framerate.
Is GDI+ capable of render a simply 2D game?
Yes, although it'd be a really simple game. GDI is slow. I advise you to go with a hardware-accelerated solution right from the start, that way you won't have to rewrite everything if GDI proves to be a bottleneck.

SocketAsyncEventArgs? - simple example

As the progress of my XNA TopDown Shooter game continues, it's time to implement multiplayer functionality.
Because the client and server will have to handle alot of data per second (60 packets per second with position, rotation and other player data) I have to make a stable and fast network system.
My question:
What is the best option to create a very fast, high performance network connection between 1 server and multiple clients?
If the answer is SocketAsyncEventArgs, do you know a simple, clean example somewhere on the internet of how to send and receive data using this advanced class? I can't seem to find a nice example that I understand.
Thanks for your time!
Bas

here's a blog about it
http://socketeering.blogspot.com/
couple youtube videos in the links

What to do if one detects flaw in architecture of the software

Currently our team of 11 people is working on a project on asp.net platform. Timeline for the project is of 8 months and we have already done 4 months. Now working on new functionalities we find that there are some flaws in the architecture of the system due to which we are facing lot of problems. Now whom to look-up for solving this ... the Team Lead or the Project Manager... Have you ever faced this scenario ? What is the best to do then..

If you've realised this and no one else has, and you want the project to succeed, then it's up to you to put a few extra hours in and figure out a plan, and then sell it to the people who are nominally responsible for the decision making.
Real projects do have "restarts". It doesn't mean that you throw away all your existing work. It means you find a new shell to fit pieces of that work into. This is a lot easier if your work-so-far consists of well-understood self-cohesive little components, loosely coupled with each other. This is why people work that way - because they know from experience that they're going to have to rearrange things. Almost all features added to programming languages over the decades are due to the fact that we know each chunk of code we write may be in for a choppy voyage - it may survive, but will probably have to cope with a lot of unfamiliar environments on the journey to release.
So you've noticed that relevant information emerges continuously, throughout a project. It doesn't conveniently all show up in a single burst right before you start typing code. Writing a specification document doesn't solve this problem at all. So you need to change the way you work so that the project draws in new information all the time - new emerging information from outside is the food that drives your project forward. Try to look forward to each new surprising revelation and greet it as a friend!
What does this mean? It means that the "architecture" parts of a project are no more stable than the "little details". You have to be able to change the architecture. You don't have enough information at the start to make a permanent decision about anything.
The underlying problem may be the fact that you have an eight month project in the first place. Real eight month projects (ones that succeed on time) are actually, if you look closely, a lot of shorter projects: 16 two week projects is ideal.
You need to put all the project's aims (so far) into a big list in priority order. Write each feature requirement from the user's perspective. "The user must be able to blah blah blah", that kind of thing. Avoid talking about the technical issues of the current design. Think about how a user would deal with having no product at all (or whatever they currently use) and talk about how their experience would be improved by a particular feature.
The important thing is the priority order. The aim is to be able to say: we only have time to ship with the first 10 items done. That's better than 9 items, which in turn is better than 8, and so on. But even with 8 items it would be better than nothing, because each item is a feature that by itself would improve the user's experience.
The list is called the backlog.
If you compare your work so far with the backlog, you'll typically find that you've been working on low priority stuff, because you imagine you'll need it later. Try not to do that from now on. The low priority stuff is... low priority. What if some new higher priority requests emerge between now and ship date? They almost certainly will! Despite what some people will claim ("It will be totally useless without feature A!"), you could probably ship with neither feature A nor feature B. But if you had to pick one, you'd go with feature A. And you may well have to ship without feature B, due to lack of time. So don't jeopardise A for the sake of being "ready" for adding B later. Only prepare in advance if it costs you next-to-nothing - leave places where you can add things, make everything extensible, but not if it slows you down right now.
Then start working on a new version of the product (cannibalising the work done so far where it makes sense) that takes care of the first few items on the list - the bare minimum. Spend no more than a week on this. A week is 6.25% of your remaining time, so it's actually pretty expensive. But at the end of this you have a picture of what you're ready to ship so far. That is the only way to measure your progress from now on.
The rest of your project consists of:
Repeatedly cranking out new working versions of the product, each time adding a few more features from the priority list. Get a small community of users to work with each version and give direct feedback to your team. Aim to do a new version every couple of weeks.
Turning the user feedback into new "stories" to go "on the backlog". This of course involves prioritising them.
You do this over and over, in short iterations, until you run out of time (you probably have time to do six to eight iterations). At the end of each iteration you have something to ship that is "better" (has more high-priority features, incorporates more feedback) than what you had at the end of the previous iteration. This is progress.
Each end-of-iteration release has two purposes: to show progress and make the user community a bit happier, of course, but also to elicit more feedback, to find out new information. Every version is both a solution and a probe. This dual nature continues after the first public release. A public release is a deep space probe that you send out into the solar system to send back pictures of strange new worlds (in the form of exception stack traces).
The whole thing is scientific and rational. You make decisions about order of work based on order of priority. You get constant feedback based on a working version of your product, instead of having to guess the feedback you'd receive from an imaginary version of your product.
People will respond to this approach by saying that it will be horribly "inefficient". Efficiency is a relative term. Projects that don't work this way always end up working this way in the end. But "in the end" is very late. Usually there's a mad panic for an extra N months after the original deadline, where the project keeps producing repeated versions of the product that are all "nearly right" or "nearly done", in a crazy self-deluded parody of iterative development.
Fortunately, you can start thinking and working this way at any time. Better to start halfway to the original deadline than shortly after it.

Just put up your issues in the team meeting that involves both the team lead and the project manager. Put forward all your views frankly and effectively. This would in turn help the future of the project and give a new insight to the PM.
Further all the 11 team members too can discuss this among themselves and share one another views.. not just about the problem... but also about the possible solution. In the end share all the valid solutions to the TL and PM. This whole process would eventually help to recover the project from this mid-development issues.
A good link for what to do is this

Raise the matter to your project manager. Present a list of options with as best an estimate as possible for time to complete each with an objective list of pros and cons.
Offer your advice as best you can, but at the end of the day it's probably not your call to make on which way it will be resolved.

For what you say it seems you have a Technical Debt.
That's a problem that every project faces, mainly because now yo have much more knowledge of the domain than 4 months before.
It's a tradeoff, if the changes are not very brutal you might pull them off. If they are radical, you might reach the deadline with some of the features and then schedule time for refactoring.
Remember, as real debt it will keep growing interests until you pay it off.
Good luck!

I'd start by getting a consensus across the team of what the issues are, and how they might be resolved. Ask yourselves: What's the overall impact? Is it a complete roadblock? Are there ways around the issues without having to make major changes? It might not be too serious, and by discussing the issues you might be able to agree an quick resolution.

determining your location using ONLY wifi signals?

i will be working on a project that tries to determine your position using the wifi signal strength from a few access points. i was wondering if anyone knew of any similiar projects or any articles on that topic
if anyone cares: its a research project in at my university. the app is written is used as a playing ground to develop new wifi antenna that are better suited for this type of usage. i only work on the coding part of the project though. oh and its written using c# which is not optional
clarification:
its ONLY wifi. no GPS goodnes for us becaus its supposed to work indoors
the software is supposed to determine your location by using the known locations of the access points and their signal strenghts to tell you where you are. its currently at around 4-5 meters of accuracy
aside from that i already have a working prototype and was just wondering if anything similiar has been done before or if anyone has any tips or ideas for/about the project

Discarding the first 2 answers, where they need to use GPS and A-GPS in the first and a known WiFi network in the second, my answer is:
it sounds easy, but you need to do some homework first, a Survey.
you will need to measure up and create a oval shape (in a paper) with points and percentages of all wifi routers in the camp.
when, lets imagine that you compile 2 routers information, you are ready to go.
get the current wifi points and signal strengths from the user laptop/device and query the database using those values.
give the user their current location.
Example:
in the campus bar you measured that to be in that place you need to have around 55% strength of the signal provided from WiFi Router 1 and 25% of the WiFi Router 2.
To use all this in C#, you should start in this Code Project article to get the signal strengths. Then is just use those returned values with your data that you measured before when doing the first survey.
Hope it helps :) At least, that was what I would do in order to approach this problem.

We did this on a project already determining distance from Access Points, but without the signal triangulation (already covered on other answers here).
I do have a recommendation from the "man, I wish I didn't have to go back and do this" department - it would be to spend extra time on 2 areas:
An easy and repeatable method of calibration using Multiple Data Points. For example, the dropoff from being "very close" to "kinda close" will be a lot more than "really far away" to "really really far" away. It's not going to be a linear slope.
Data Smoothing. As you move, the signal strength will vary unproportionally to your movement (due to obstacles in the path). It will make your results much more accurate if you take a rolling average of the last 5-10 samples of the signal strength rather than just taking the last sample.

You might like to look at the Google Gears Geolocation API. I don't know how easy it is to use from C#, but it may be useful/relevant.
(Disclaimer: I work for Google, but haven't had anything to do with the Geolocation API.)

I wouldn't have thought that signal strength would work well: too many things interfere with it (like walls). But you might try measuring ping times, especially if you threw a hundred pings at the AP and took the average. Most of the time will be the AP digesting the ping and generating the pong, but there will also be a time-of-flight component for the signals. If the AP response time is consistent then you should be able to subtract it and hence compute the distance to the AP. By well-known hyperbolic maths you can then find your position from 3 or 4 APs.
Paul.

Skyhook springs to mind. It depends on people registering the llocation of their APs though.

Goto Wifi in positioning System(WPS), where we use multiple Wifi AP to track a location..
this is implemented by many systems like Google, horizon etc by providing extra security 4 privacy..
I too without knowing this tried on immplimenting this sort of technique..
All d best, we can simplify its complexity by various methods there-by achieving INNOVATIVE to existing infrastructure.
I recommend u to go to the wifi router add-in management & usage before pursing this.

you can try FIND3 project, here's a documentation https://www.internalpositioning.com/doc/, it's API can be used for that purpose and use learning algorithm to constantly learn your position with accuracy. They also have mobile apps (for android only). I'm looking to do something of the same nature.