the faster the world knows about it, the faster help can be sent for the victims.
Realistically, no.
Technology has been sufficiently advanced to provide information about natural disasters effectively instantly for about a century. I say "effectively", because it doesn't much matter whether you hear about it 1 minute after it happened, or one day after it happened, if it takes you a minimum of two days to provide any meaningful response.
I'd say response time matters a lot in some situations. I've seen the aftermath of the '99 quake in Turkey, which was of magnitude 7.4 and happened in the middle of the night around 3 AM. The chance of locating and saving people still alive under the rubble of collapsed buildings drops very rapidly with time (reaching almost zero after 48 hours).
In such cases it's the few experienced crews (including trained sniffer dogs and people with knowledge to plan a dig in rubble without further collapsing it) and some sonic / IR equipment to help locate survivors that needs to be shipped to the disaster zone as soon as possible that will make the difference between life and death. Unfortunately the number of such teams around the world is very low, and the sooner a disaster is heard sooner they can be assembled and flown to site. Supplies can start coming a few days later, but each hour counts when you're trapped under and waiting for help.
I'll second that.
Take a look at the best practices/etc. examples that MS puts on the web. They usually have a database access and a business logic layer. If you have a single source of data and a number of application that depend on it (like a visualization, bookkeeping and a numerical numerical analysis app like we had), it is certainly the way to go.
Just be careful when you are using vendor specific features or syntax in your stored procedures, or be prepared to code the differences into your DB layer later if you decide to switch DB vendors. That's why you spent the time coding the DB access layer in the first place!
I think the Spaceball works wonders in 3D modeling and CAD tasks only. It is hard to get used to, and nobody would put much effort to learn it if it's not part of their job. My main gripe is that you expect the ball to move but it does not. It only senses the pressure you apply.
The following part from Wikipedia http://en.wikipedia.org/wiki/F16 is about a similar issue with the F-16 controller, and how they fixed it by allowing a little movement.
This lack of mechanical linkages between the control stick and the flight surfaces led to an unusual characteristic in the design of the control stick: originally, it did not move. The control stick instead detected pressure applied by the pilot and translated that pressure into control of the aircraft. This arrangement proved uncomfortable and difficult for pilots to adjust to, so the control stick was given a small amount (less than a quarter of an inch in any direction) of play.
If there is an existing code base, one of those assignment could be a simple "Present it to me" task. Learn this bit of code, and explain what purpose it has in the system, and bring me a list of questions and concerns about it. Then, after that, do a pair programming task that involves that code. The novice drives, you watch.
... and it doesn't really have to be your own code anyway. Have your partner do the research on using this particular GUI toolkit, connecting to that DBMS, saving and loading object states, message passing, parsing text files, etc. Anything that you can grasp the fundamentals easily but don't know the details by heart will be fine.
Then let her instruct you how to do that specific task. If you don't like the solution, you'll be only dissing "that stupid tutorial writer", and if you like it you'll be praising her work. Hopefully your partner will take ownership of some part of the code, and learn more about how your part of the software system works when she's trying to integrate her part into the final project.
Just don't let the novice get lost trying to find the perfect solution, sometimes "good-enough" is really good enough:)
Anyone remember the mission where Admiral Harkov sends you and your wingmen to inspect an asteroid field (which turns out to be a mine field) to get rid of you, then you had to fight your way out of it alive to report his betrayal. I still remember how angry I felt the moment in mid-flight when I realized the trap. Touches like these really forced you to take part in the storyline and personalize the conflict told in the game.
Oh, and the moment of sweet revenge at the end of the campaign when Darth Vader says "Welcome Admiral Harkov, we have a matter to discuss.". That's what you get for sending me into a death trap sucker!
There is one important difference between software design vs. game design. Although many of us have used numerous pieces of software for years, no of us ever knew about Adapters or Mediators before we had to develop a complex software system and Gamma et. al. published a common language to talk about these issues. On the other hand, anyone who played a few computer games knows personally what a Boss, Level, Power-up, Hi-Score List, etc. is.
I've been having a look at this book for the past few weeks, and it looks like it was written for educating non-players so that they can design games. The question is, do we (as people who enjoy games) really want that to happen?
Exactly. When I have to decide which university to go to, which classes to take, etc.; I like browsing the offered courses to see a detailed sylabbus, past assigments, projects, etc.
How is your idea of Civ. effected by making it a..
on
Ask Sid Meier
·
· Score: 1
game.
Do you feel that you idea of civilization is changed anyway by turning it into a game? Do you compare cultures and civilizations by the number of cities they build, their demographics, etc. in real life too? How much of your definition of civilization as portrayed by the games are a product of designing a fun-to-play game, and how much is it your own thoughts on world history?
I believe that a combination of game design mastery and clever algorithms will in the end decide the fate of physics in games. It really is a challenge, but remember the success of realistic sounds, then of realistic graphics in defining the gameplay of today. I don't understand how or why Mr.Carmack (of all people) can so easily downplay a similar trend.
Although Mr.Carmack says physics in game engines isn't easily scalable for level of detail, there is ongoing research about this producing good results. I remember a video from last years SIGGRAPH that had hundreds of plastic chairs falling from the sky, and bouncing realistically. The important part was it employed a level-of-detail hierarchy for interacting parts (i.e. an object doesn't have much physical detail if you don't touch it), but it will be some time before we can see such techniques in real time games.
Slashdot Mirror
We Muslims consider the mixing of music and words from our Holy Quran deeply offending.
What's this "we" shit?
pure bullshit
Realistically, no.
Technology has been sufficiently advanced to provide information about natural disasters effectively instantly for about a century. I say "effectively", because it doesn't much matter whether you hear about it 1 minute after it happened, or one day after it happened, if it takes you a minimum of two days to provide any meaningful response.
I'd say response time matters a lot in some situations. I've seen the aftermath of the '99 quake in Turkey, which was of magnitude 7.4 and happened in the middle of the night around 3 AM. The chance of locating and saving people still alive under the rubble of collapsed buildings drops very rapidly with time (reaching almost zero after 48 hours).
In such cases it's the few experienced crews (including trained sniffer dogs and people with knowledge to plan a dig in rubble without further collapsing it) and some sonic / IR equipment to help locate survivors that needs to be shipped to the disaster zone as soon as possible that will make the difference between life and death. Unfortunately the number of such teams around the world is very low, and the sooner a disaster is heard sooner they can be assembled and flown to site. Supplies can start coming a few days later, but each hour counts when you're trapped under and waiting for help.
I'll second that. Take a look at the best practices/etc. examples that MS puts on the web. They usually have a database access and a business logic layer. If you have a single source of data and a number of application that depend on it (like a visualization, bookkeeping and a numerical numerical analysis app like we had), it is certainly the way to go. Just be careful when you are using vendor specific features or syntax in your stored procedures, or be prepared to code the differences into your DB layer later if you decide to switch DB vendors. That's why you spent the time coding the DB access layer in the first place!
... and it doesn't really have to be your own code anyway. Have your partner do the research on using this particular GUI toolkit, connecting to that DBMS, saving and loading object states, message passing, parsing text files, etc. Anything that you can grasp the fundamentals easily but don't know the details by heart will be fine.
Then let her instruct you how to do that specific task. If you don't like the solution, you'll be only dissing "that stupid tutorial writer", and if you like it you'll be praising her work. Hopefully your partner will take ownership of some part of the code, and learn more about how your part of the software system works when she's trying to integrate her part into the final project.
Just don't let the novice get lost trying to find the perfect solution, sometimes "good-enough" is really good enough :)
Anyone remember the mission where Admiral Harkov sends you and your wingmen to inspect an asteroid field (which turns out to be a mine field) to get rid of you, then you had to fight your way out of it alive to report his betrayal. I still remember how angry I felt the moment in mid-flight when I realized the trap. Touches like these really forced you to take part in the storyline and personalize the conflict told in the game. Oh, and the moment of sweet revenge at the end of the campaign when Darth Vader says "Welcome Admiral Harkov, we have a matter to discuss.". That's what you get for sending me into a death trap sucker!
There is one important difference between software design vs. game design. Although many of us have used numerous pieces of software for years, no of us ever knew about Adapters or Mediators before we had to develop a complex software system and Gamma et. al. published a common language to talk about these issues. On the other hand, anyone who played a few computer games knows personally what a Boss, Level, Power-up, Hi-Score List, etc. is.
I've been having a look at this book for the past few weeks, and it looks like it was written for educating non-players so that they can design games. The question is, do we (as people who enjoy games) really want that to happen?
Exactly. When I have to decide which university to go to, which classes to take, etc.; I like browsing the offered courses to see a detailed sylabbus, past assigments, projects, etc.
game. Do you feel that you idea of civilization is changed anyway by turning it into a game? Do you compare cultures and civilizations by the number of cities they build, their demographics, etc. in real life too? How much of your definition of civilization as portrayed by the games are a product of designing a fun-to-play game, and how much is it your own thoughts on world history?
I believe that a combination of game design mastery and clever algorithms will in the end decide the fate of physics in games. It really is a challenge, but remember the success of realistic sounds, then of realistic graphics in defining the gameplay of today. I don't understand how or why Mr.Carmack (of all people) can so easily downplay a similar trend.
Although Mr.Carmack says physics in game engines isn't easily scalable for level of detail, there is ongoing research about this producing good results. I remember a video from last years SIGGRAPH that had hundreds of plastic chairs falling from the sky, and bouncing realistically. The important part was it employed a level-of-detail hierarchy for interacting parts (i.e. an object doesn't have much physical detail if you don't touch it), but it will be some time before we can see such techniques in real time games.