|
Thread Rules
1. This is not a "do my homework for me" thread. If you have specific questions, ask, but don't post an assignment or homework problem and expect an exact solution.
2. No recruiting for your cockamamie projects (you won't replace facebook with 3 dudes you found on the internet and $20)
3. If you can't articulate why a language is bad, don't start slinging shit about it. Just remember that nothing is worse than making CSS IE6 compatible.
4. Use [code] tags to format code blocks. |
On July 04 2014 23:58 Nesserev wrote:Show nested quote +On July 04 2014 22:21 urboss wrote:
So how do you know then when to write a Unit Test?
If you don't do it for every small function you write, what's the point of doing it in the first place?
Are there any scientific studies that compare the gained productivity from doing unit tests vs. doing system tests only? Well, there's a difference between TDD and just writing unit tests. TDD is an ugly process, but the use of unit tests is one of those 'good' parts that came out of it and should be treated as just another tool for the programmer to write the program he/she wants. I personally feel like it's unnecessary to write unit tests for those small functions that I'm confident about, as unit tests are limited and not to be completely relied upon; they're not the proof that your code is bugfree (which is impossible btw). Some agree with my logic, some don't... and some want to shoot me in the face for saying that. To prove my point: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
Some people will want to shoot you in the face no matter what stance you take on anything in programming, so, there isn't a lot of surprise in that.
The only problem that I have with your logic is that its singularly focused on your ability to get the code right. Over the course of a large project, many different programmers will come through and will have varying degrees of knowledge of why the system was formed the way it was. If written well, unit tests can show assumptions that are built into your product and act as a form of documentation as to how you expected for your code to be used. If ran every build, they also have less chances becoming inconsistent like comments.
The rest of what you have to say I agree with, especially on the unit tests do not prove your code is bugfree, only that it acts as the tests prove that they do.
|
On July 04 2014 23:58 Nesserev wrote:Show nested quote +On July 04 2014 22:21 urboss wrote:
So how do you know then when to write a Unit Test?
If you don't do it for every small function you write, what's the point of doing it in the first place?
Are there any scientific studies that compare the gained productivity from doing unit tests vs. doing system tests only? Well, there's a difference between TDD and just writing unit tests. TDD is an ugly process, but the use of unit tests is one of those 'good' parts that came out of it and should be treated as just another tool for the programmer to write the program he/she wants. I personally feel like it's unnecessary to write unit tests for those small functions that I'm confident about, as unit tests are limited and not to be completely relied upon; they're not the proof that your code is bugfree (which is impossible btw). Some agree with my logic, some don't... and some want to shoot me in the face for saying that. To prove my point: http://en.wikipedia.org/wiki/Ariane_5_Flight_501
TDD is a beautiful process. It temporarily produces ugly code which is then turned into beautiful code that is just right for what it is supposed to do.
In TDD you're also not writing unit tests for the small methods that you're confident about, unless they are externally visible features of your module. If you're testing small private methods, you're doing it wrong; you'll bind your implementation to your tests and thus make refactoring impossible.
|
|
|
On July 04 2014 22:21 urboss wrote:
So how do you know then when to write a Unit Test?
If you don't do it for every small function you write, what's the point of doing it in the first place?
Are there any scientific studies that compare the gained productivity from doing unit tests vs. doing system tests only?
If you refer to 'small functions' as private ones, as far as I have understood the topic, you assume they're correct if the public API works as expected. And if they're not tested in the public API, then you don't need them anyway.
As far as the worth of unit testing goes, I'm not consistent in writing unit tests but it's good to know you can rewrite code, and then run the test to see if it works in the intended way as last time.
|
anyone know where i can learn web game development
|
|
|
First time trying something like this...can anybody tell me why the response header is empty? Nothing gets printed in the log. ReadyState of this request stays at 1.
+ Show Spoiler ['JSON/HTTP post request question] +
function update (userid, achievementid, description)
{
console.log("starting http request");
var xmlhttp;
if (window.XMLHttpRequest)
{
xmlhttp=new XMLHttpRequest();
}
else
{
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.open("POST", "/update.php");
xmlhttp.setRequestHeader("Content-type", "application/json");
console.log(xmlhttp.getAllResponseHeaders());
console.log("1");
var JSONObj = { "userId": userid, "achievementId": achievementid, "Description": description } ;
console.log("2");
xmlhttp.send(JSON.stringify(JSONObj));
console.log(JSONObj);
console.log("js update end");
}
|
Don't know if that's the issue, but you are using both XML and JSON in your code.
Stick to either XML or JSON.
|
Yeah...I have somewhat no idea what I am doing.
I'm trying to create a js function that takes 3 parameters, create a JSON object and then submit a HTTP POST request to a page called update.php which would then use that JSON object. But I'm having a lot of difficulty trying to write this request.
|
On July 04 2014 22:21 urboss wrote:
So how do you know then when to write a Unit Test?
If you don't do it for every small function you write, what's the point of doing it in the first place?
Are there any scientific studies that compare the gained productivity from doing unit tests vs. doing system tests only?
Well, if you are asking this question, I can say you should _always_ write unit tests, because you are not (neither do I, for example) experienced enough to decide if it is necessary. I remember, from the presentation a friend of mine made, there indeed are scientific studies that show in the long run unit tests reduce the cost. As far as I remember, writing unit tests increases development time up to 40%, but as the software grows and evolves, it actually reduces the time spent on the project.
Unit tests should be part of your code. It does not matter how small the function is. If you write your own addition operation for example, you never know whether the statement `mySum(2,2)` will always produce `4`. Eventually someone will definitely f... up and you should be prepared.
I have doubts about TDD, but unit tests are a mandatory part of the code. Code should be written for humans, never forget this fact.
|
Ok, so there's an often repeated myth that players living closer geographically to a server (and therefore having a lower ping) have an advantage against those living farther away (here is one example out of many).
However, Starcraft II is a peer-to-peer game where the game states of all participants (players and spectators) are synchronized, and the game server doesn't take an active part.
Let's assume a 1v1 game. After a command is issued (e.g. right click), but before it is carried out (e.g. the unit starts moving), both players' game clients have to agree on the exact frame that the action will happen. If this wasn't enforced, then on one screen you could have a unit barely survive an encounter, and on the other it could be dead – there is no authoritative server that could see "the true state" and resolve such disputes. So, when the two players live 10,000 miles apart, the game slows down for both of them equally – both players' commands are executed not a couple frames from issuing, but several hundred milliseconds later.
Or at least that's how I see it. Am I right by saying that lag in SC2 is always symmetric, or is there something wrong with my understanding?
|
On July 07 2014 03:58 Fawkes wrote:First time trying something like this...can anybody tell me why the response header is empty? Nothing gets printed in the log. ReadyState of this request stays at 1. + Show Spoiler ['JSON/HTTP post request question] +
function update (userid, achievementid, description)
{
console.log("starting http request");
var xmlhttp;
if (window.XMLHttpRequest)
{
xmlhttp=new XMLHttpRequest();
}
else
{
xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");
}
xmlhttp.open("POST", "/update.php");
xmlhttp.setRequestHeader("Content-type", "application/json");
console.log(xmlhttp.getAllResponseHeaders());
console.log("1");
var JSONObj = { "userId": userid, "achievementId": achievementid, "Description": description } ;
console.log("2");
xmlhttp.send(JSON.stringify(JSONObj));
console.log(JSONObj);
console.log("js update end");
}
Response headers are only valid on the response. You are trying to fetch them from the request object, before you even call send.
You don't have seem to have any callbacks on your xmlhttp object, have you not posted some code that is somewhere else?
This post shows an example
You are also using the synchronous call of xmlhttp, might want to be careful with that.
|
On July 03 2014 03:04 RoyGBiv_13 wrote:
I've recently hired a few software devs. I only glanced at their resume's once to see what kind of things to talk about during lunch/dinner.
One candidate in particular had a LaTeX resume, and that was one of the points to talk about. We ended up hiring him. I don't think the LaTeX'ness of the resume made us hire him, but it did add information density to a one page document. If you don't normally use LaTeX, though, I wouldn't hold it against you.
On side projects, the later in your career and life you are, the more they mean. If a 40-year old dev can still make time to fidget with gizmos and gadgets, it's a strong indicator that they like what they do. A 20-something fresh out of college without any side projects or previous experience may have no strong indicator they actually like software development, so it's riskier to invest in them only to find out they'd rather be a history teacher.
That makes sense. Using LaTeX in your resume is a better way of adding LaTeX to your skill summary of some sort, and because it's so prominent it's an easy topic to start talking about, just like any other interesting projects on the resume, or like bringing a sample project (apps) you made to the resume. Great to do to specify you have an interest in it (though I still don't like that some people do it "just to one up others on the interview"), but I guess if the recruiter thinks that LaTeX resumes are better than non-LaTeX resumes I probably don't want to work there.
I guess I just get overly annoyed at some stuff people say, but that's why I asked you guys :d
|
On July 07 2014 05:15 delHospital wrote:Ok, so there's an often repeated myth that players living closer geographically to a server (and therefore having a lower ping) have an advantage against those living farther away ( here is one example out of many). However, Starcraft II is a peer-to-peer game where the game states of all participants (players and spectators) are synchronized, and the game server doesn't take an active part. Let's assume a 1v1 game. After a command is issued (e.g. right click), but before it is carried out (e.g. the unit starts moving), both players' game clients have to agree on the exact frame that the action will happen. If this wasn't enforced, then on one screen you could have a unit barely survive an encounter, and on the other it could be dead – there is no authoritative server that could see "the true state" and resolve such disputes. So, when the two players live 10,000 miles apart, the game slows down for both of them equally – both players' commands are executed not a couple frames from issuing, but several hundred milliseconds later. Or at least that's how I see it. Am I right by saying that lag in SC2 is always symmetric, or is there something wrong with my understanding?
This is how BW worked, this is not how SC2 works.
SC2 does not use a peer to peer system.
|
On July 08 2014 20:23 sluggaslamoo wrote:Show nested quote +On July 07 2014 05:15 delHospital wrote:Ok, so there's an often repeated myth that players living closer geographically to a server (and therefore having a lower ping) have an advantage against those living farther away ( here is one example out of many). However, Starcraft II is a peer-to-peer game where the game states of all participants (players and spectators) are synchronized, and the game server doesn't take an active part. Let's assume a 1v1 game. After a command is issued (e.g. right click), but before it is carried out (e.g. the unit starts moving), both players' game clients have to agree on the exact frame that the action will happen. If this wasn't enforced, then on one screen you could have a unit barely survive an encounter, and on the other it could be dead – there is no authoritative server that could see "the true state" and resolve such disputes. So, when the two players live 10,000 miles apart, the game slows down for both of them equally – both players' commands are executed not a couple frames from issuing, but several hundred milliseconds later. Or at least that's how I see it. Am I right by saying that lag in SC2 is always symmetric, or is there something wrong with my understanding? This is how BW worked, this is not how SC2 works. SC2 does not use a peer to peer system.
[citation needed]
I don't mean to sound like a dick, but if what you said is true, then why do we have lag screens when an observer is on a bad connection?
Or why are maphacks possible?
How are "desync" and "results disagree" errors possible?
If p2p is not how SC2 works, then how does it work?
|
|
|
On July 08 2014 22:10 Nesserev wrote:Show nested quote +On July 08 2014 21:31 delHospital wrote:
[citation needed]
I don't mean to sound like a dick, but if what you said is true, then why do we have lag screens when an observer is on a bad connection?
Or why are maphacks possible?
How are "desync" and "results disagree" errors possible?
If p2p is not how SC2 works, then how does it work? You don't sound like a dick... but you're not sounding logical either  Lag screens, maphacks, etc. are not exclusive to P2P. Lag is a universal problem,
In what client-server games do spectators on a bad connection cause the game to stop? I can't think of any.
and maphacks (in SC2's case) are the results of 'too much data' being on the client's computer, nothing else.
There is nothing that would suggest that the only reason for existence of maphacks is incompetence of Blizzard's developers. And if it was, it would've been fixed a long time ago. We've gotten game resuming, multiplayer replays, changes to the arcade, "global play", etc., why haven't we received a fix to the maphack problem?
"Desync" and "results disagree" could have many possible causes...
Could you give some examples? Because to me they don't make sense outside of a p2p architecture.
If I remember correctly, it was stated that Blizzard uses the typical client-server system, and relays everything through their own servers. Don't have any source though...
They're relaying everything through their servers to eliminate the need for port forwarding.
In custom maps it is possible to alter the game state of only one client. If it's possible, then each player must have "their very own server", i.e. peer-to-peer.
Also, here is R1CH saying that it's p2p. Here's another good post from that thread.
So... does anyone see a way for lag to affect players differently?
|
On July 07 2014 05:53 Blisse wrote:Show nested quote +On July 03 2014 03:04 RoyGBiv_13 wrote:
I've recently hired a few software devs. I only glanced at their resume's once to see what kind of things to talk about during lunch/dinner.
One candidate in particular had a LaTeX resume, and that was one of the points to talk about. We ended up hiring him. I don't think the LaTeX'ness of the resume made us hire him, but it did add information density to a one page document. If you don't normally use LaTeX, though, I wouldn't hold it against you.
On side projects, the later in your career and life you are, the more they mean. If a 40-year old dev can still make time to fidget with gizmos and gadgets, it's a strong indicator that they like what they do. A 20-something fresh out of college without any side projects or previous experience may have no strong indicator they actually like software development, so it's riskier to invest in them only to find out they'd rather be a history teacher. That makes sense. Using LaTeX in your resume is a better way of adding LaTeX to your skill summary of some sort, and because it's so prominent it's an easy topic to start talking about, just like any other interesting projects on the resume, or like bringing a sample project (apps) you made to the resume. Great to do to specify you have an interest in it (though I still don't like that some people do it "just to one up others on the interview"), but I guess if the recruiter thinks that LaTeX resumes are better than non-LaTeX resumes I probably don't want to work there. I guess I just get overly annoyed at some stuff people say, but that's why I asked you guys :d
Meh, I write my resume's in Libre Office and just put LaTeX among other software/computer skills. LaTeX seems like such an overkill for 2 simple pages... There's a tool for everything, and I don't think LaTeX is a tool to write your resume, letter to grandma or some single-page requests at uni/office.
|
You could in theory solve the problem by encrypting all the game state variables.
My guess is that this would:
- be too much of a pain in the ass
- slow down the game noticeably
- assume that this is an actual issue for Blizzard (they can already detect maphacks with Warden)
|
in theory they don't need to shar eall the game state variables, just the one the other guy sees, this was done back in 1996 in subspace.
but solving the maphacking problem by technological innovation is bunk. they should focus on facilitating community effort driven reprisals. maphackers are mostly concentrated around a narrow mmr (sc2 with maphacks is a super simple game for retards), the ppl who give a shit are also concentrated around that same mmr. the maphackers could be policed by something along the lines of the maphacker thread, wherein the mods banned confirmed / blatant hackers.
|
|
|
|
|
|
EPT
