Game Physics - Momentum & Friction

                One of the natural progressions in game development is going from a locked speed to a momentum based system.  Originally, you might have had code that made your ship move forward by 2 pixels every time someone pressed forward.  It’s easy, done in a line of code, and you can forget it.  But when it comes to upgrading your character, ship or vehicle, you are now faced with a lot of hard coded upgrades.  Instead of moving 2 pixels, now you move 4 pixels.  Etc… 

               

                I remember the idea of adding physics as one of those near-impossible tasks, primarily because I didn’t understand how it worked.  Below, is the basic idea.  To start with, I’ll commonly refer to the word “cycle”, which means that the game makes its decisions/changes, draws the frame, then moves on to the next.  Each game loop is a cycle. 

                During each cycle, I check if the forward key is pressed.  If it is, instead of moving the ships location by two pixels, I add 0.3 to a variable called momentum.  So if I went from still, to pressing the button, the first cycle would move the ship by 0.3 pixels.  During the second cycle, I add another 0.3 to the momentum, increasing it to point 0.6.  That means this ship is moved 0.3, then 0.6, and next it will move 0.9, then 1.2, 1.5, 1.8 etc…   This means that it smoothly increases.  Suppose you are in a car.  You want to be moving 35, but from 0, it doesn’t just happen the instant you touch the gas pedal.  The car gradually accelerates.  First moving only at 3 feet / second, then 6 feet / second, etc…  until you reach 35.

// Game Loop

{

                If UpArrow is Pressed, Momentum = Momentum + 0.3;

                Position = Position + Momentum;           

}

                At this point, in your game, it will increase in speed until you let your finger off of the forward button.  It will coast at that speed.  As with proof of concepts, this brings up another challenge, the ship keeps moving faster when you hold the button.  The speed gets unreasonable pretty quick.  What you need to do is add a top speed variable.  Let’s say TopSpeed = 2.  Every time before you add the momentum to the location, check if the momentum is greater than TopSpeed.  If it is, then set Momentum = TopSpeed.  This way the ship never moves more than 2 pixels per cycle.

//Settings

TopSpeed = 2;

//Game Loop

{

                If UpArrow is Pressed, Momentum = Momentum + 0.3;

                If Momentum > TopSpeed, Momentum = TopSpeed;

                Position = Position + Momentum;

}

                A quick recap so far, you can add a Force variable, and when you press to go forward, it adds that amount to the momentum.  This is now a variable you can set per vehicle, calling it torque, or how fast you accelerate.  Your TopSpeed variable, which is pretty obvious, which is another easily upgradable value for your individual vehicles. 

                So next, lets add Friction.  Friction isn’t necessarily something you need to add, but its excellent for

cars, boats, planes, etc… where you want the vehicle to gradually lose speed when the vehicle isn’t having the gas pedal pressed.  Essentially, you add create a variable called friction, and it’s value will be 1 meaning no friction, or 0 meaning completely blocked.   A good starting friction is probably 0.85.  At the beginning of every cycle, multiply your Momentum by your Friction.  Momentum * 1 = 100% Momentum.  Momentum * 0.85 = 85% Momentum. 

//Settings

TopSpeed = 2;

Friction = 0.85;

//Game Loop

{

                If UpArrow is Pressed, Momentum = Momentum + 0.3;

                Momentum = Momentum * Friction;

                If Momentum > TopSpeed, Momentum = TopSpeed;

                Position = Position + Momentum;

}

                Friction is easily applied as an Aerodynamic feature for each of your vehicles, which is also easily changeable now, for each different vehicle in the game. 

                There are a lot of directions this can be taken, but I wanted to cover some others, like Force/Torque, Vectors and Gravity, in future articles.  This is an article that is meant to be practiced.  The basics are here.

Going Pro to Cut the Stress

                I’m going to take a stab in the dark here.  You commonly face stress, because you don’t have enough time to complete the tasks before you.  People, red tape, unclear definitions and even the environment around you create constant issues that prevent you from being able to meet all your commitments.  This is one area that tends to separate professionals from the aspiring.  (Please note: this is one aspect of being professional, as I see it, there are many)

                I came up with the focus for this article from speaking with a friend who was having a lot of stress, and constantly finding themselves trying to do more than they could.  Once it became clear to me what was causing this, I spoke with him about it and hopefully, helped him out.  (Time will tell) 

                The first issue is that we don’t pay attention to the issues that block or interrupt us.  When we look back at how long a task took to build, we ignore little things that interrupted or blocked us, because in an ideal world, those things would not stably be part of that task.  Perhaps while trying to complete the documentation on something, we had to wait 30 minutes for an email verifying something, perhaps we were pulled away from our desk to answer a few questions for someone, who knows.  The point is, that despite the fact the task itself was not responsible for the extra time needed, it was a stable part of the environment; you will always be interrupted by questions, you will always have to wait on emails, you will always have to [Insert random thing]. 

                The first solution is to start realize that nothing is ideal.  Every task you take on will have interruptions from delayed resources, unrelated requirements, unanswered questions, and more.  Figure how long it will take you to do a task, then once done, look back and figure out how much time you spent focused on the task, and how much time the interruptions took.  You’ll start to notice sizable differences.  You’ll start to notice trends, 25% (or some other %) of your time gets taken by interruptions. 

                The second solution is to learn from your past.  Until you pay attention to your past, your doomed to suffer from it.  Your past gives you clues to help you realize how things will play out in the future.  If you start seeing a trend of about 25% of your time is taken by things that are not important to the task at hand, then you can start applying more appropriate time lines.  You could say this task will take me 1 hour to complete, but I estimate 15 minutes will be lost to environment issues.  My total estimate is one hour and fifteen minutes.         

                Another source of stress deals with us wanting more.  We want more and more and more.  At home, we want to do all these things to improve our houses, our family lives, our health, our entertainment, our stuff, and our “fun” things to do.  We find ourselves cutting it really close when driving, trying to shave off 5 minutes here and 2 minutes there, pressuring our vehicles and the traffic around us to get us there as fast as possible without getting pulled over. 

                The whole time, any interruption that creeps in, like traffic from rush hour, car accidents, unsure drivers, holiday traffic, and construction we find ourselves unhappy, stressed, and angry.  But, we always know that things like this will happen.  We tend to take the fastest time we went from point A as point B as the standard, while anything more is cause to raise your frustration.

                Once you start realizing that chaos will always be there, you will start to see that a lot of your time is wasted in frustration, particularly relating to unimportant things.  As you start to realize how long these things take, you will be able to apply a better standard in defining what you can fit into your day.  You will have less stress and be more trust worthy, as people will know that when you say it will take you an hour to do something, you mean it, unless something highly unlikely creeps into view, and will more often be early, giving more time for reflection and relaxation.

                Also, when you start applying seasoned experience like this to the work place, you will find that you will be able to identify time lines better, identify weaknesses better and provide clear reasons for success or failure.  You will be more respected at work. 

Often relating to our jobs, when we take on a task, we might think that it will only take X time, but once into it, we realize that there are issues we didn’t know going in.  Perhaps it’s how large the learning curve is, or how slow the requirements are getting produced, or constant issues with the hardware we have to work with.  Whatever the case, because we don’t pay attention to those as having real impact on our tasks, we keep getting stressed that our timeline is closing in, thinking *maybe* we could finish it in time.  The whole time, we get closer, the possibility of completing it gets smaller and smaller, and the questionable area gets larger and larger, but we only focus on that possibility of success. 

The 3^rd Solution is to keep others notified and be clear about changes.  Whenever I take on a task, I always identify my confidence in completing it and try to have a small list of key areas I think might cause issues.  I never go higher than 90% confidence unless it is a regularly occurring task, that does not have a history that varies much, if at all.   By making your managers and coworkers aware of your confidence level, it opens up the possibility that that portion you are not prepared for will be more work than expected and provides a valuable safety net when things go wrong. 

If you face issues about something changing, you can say you are going from 75% confidence to 50% confidence that it will be completed on time, because of X issues.  Most people are afraid of looking like they don’t know something or can’t handle something at work, and will take on more than they should.  Remember this, quite often the original numbers for a project or task were created by looking at a one or two line description and assigning a number off the top of some one’s head.  Remember that when you agree to them, and apply the confidence level, you are being clear about your knowledge, making it better known whether you can finish something or not. 

Answer me this, which is better, an employee who takes on a lot, gets most of it done, but often causes delay because they didn’t get it done in time (for [insert random excuses]), or someone who says it will take longer, who always gets the tasks done on time, baring something catastrophic.  Sometimes, it’s nice to get the hacked work out faster, but most companies want people who know there limits, so management can really figure out what is needed, and what is possible.

Creative Story Tips

                It would be easy for most experienced writers and designers to come up with 1,001 tips for creating a plot, applying emotional attachments and filling in the content to make it work.  But starting from the ground up, we are all different.  We approach problems differently, and we've learned different things along the way. 

                So my first tip is to not take every tip you read as important, as something that is valuable to follow.  Besides, a lot of people who like to give tips wouldn't even use it themselves.  They suggest something that seems logical to them, but when it comes down to it, they don't actually apply it.

                Always determine what works best for you.  What do you feel helps you the most.  What are you looking for?

                So to continue on with a few more odd tips to consider, we get to used to summarizing things that we think we understand, even pushing a book down to a few sentences.  Harry potter can be summarized as "Evil wizard thinks boy will defeat him, tries to kill him, and fails.  Boy grows up, learns to survive in magical world, and destroys evil wizard." 

                Tip #2) Try writing a book you already know.  Take Harry Potter for instance.  I pick that because it is a popular book and uses a lot of well-known styles for making it an easy, engaging and fun read.  Take any story where you know the plot really well and write it from the top of your head.  Plot is often easy, but doesn't matter if your characters don't make your readers want to find out what happens next. 

                It’s a great way to test your abilities.  Is it interesting?  Are your characters engaging?  Do other people find it an interesting read?  If you have friends who like Harry Potter (or the story you choose) are they enjoying your alternative perspective on the story?

                Tip #3) At many points you may find that you have written so many words, that the purpose you were originally trying to convey, may not be getting across very well because you wrote so many words to try to explain it clearly, especially when the same message is repeated, or importance of the added detail is unimportant. 

               

                PLEASE note that the previous paragraph was ONLY one sentence.  Perhaps it would have been easier to say, "Don't use more words than needed to convey something."  But I wanted to make a point.  Often, we feel the urge to add more words.  I use that as a sign that I haven't found the right words, and consider re-writing the paragraph, or omitting it. 

                Tip #4) everything has to flow.  Directors often remove lots of great content from movies.  Lord of the Rings for instance; Watch the normal movie, then watch the extended edition.  It covers more, but you'll also notice that it doesn't flow as well, and you start getting a little more bored with it.  It makes it not quite as engaging to continue. 

                You should re-read the chapters and pages regularly as you are writing, and seriously consider getting rid of any part that seems to flow a little slowly. 

                Tip #5) Readers of your story are smart, very smart.  You miss something and they'll see it.  But, if you over explain something; it is easy to risk boring them with details.  When reading Harry Potter, I find myself often annoyed with little sections that say "And harry knew this because, in a previous book, blah blah blah."  In most cases, repeating content is a poor choice. 

                Tip #6) Reconsider everything you hear, no matter from what source.  Urban Legends start because someone suggested something that somewhere along the line someone else took literally and spread it as truth.  The whole thing about "humans eat an average of 7 spiders a year when sleeping" was just a hoax made up to see if it would catch, and sure enough, lots of people took (and take) it as truth.  Just because I say something doesn't mean it’s true.  Most things are never universally true.  Read with your own eyes.  Don't just use my goggles, or anyone else’s, or you'll see no more in life, stories, creation or chaos.

Technical Interviews...

                So you need to hire a developer?  You are either a competent developer yourself, or not.  Either way, this may help you with some ideas about what to ask for.  First off, I recommend a great book called High-Impact Interview Questions by Victoria A. Hoevemeyer.  It gives an overview of different styles of interviewing, and teaches the CBBI (Competency Based Behavioral Interviewing) approach.  I found that that bulk of the information needed is within the first few chapters.  (at least enough to get you started, but I still recommend you read the whole thing)

                To briefly go over the CBBI interviewing practice, I’ll give a couple examples.  Imagine yourself in an interview, and the person asks, “How would you approach a really irate customer?”  You would think of the most optimal way it should be handled, and speak along those lines.  But what about this question, “Tell me about a time that you had to deal with a very irate customer.”  It’s not a question, it’s a demand.  And it’s not giving leeway for you to think of the most optimal solution.  Instead, you have to describe what really happened.

                Most of us can easily cite what the most optimal reaction might be to something, but when you are actually in the moment you need it, what really happens?  CBBI gets the person to tell us about real scenarios in a person’s background.  Follow up questions like, “how was it resolved?” or “What did you do at X point?” can help you get the answers you’re looking for when the initial response isn't satisfactory, or questionably false.  (as the follow up questions may also get a person caught for lying)

                So the next part is figuring out what is important to you?  Obviously there are technical skills, but not so obvious is that the person needs to communicate their knowledge to less experienced people, or that they need to work independently a lot.  You need to figure out what areas are important to you.  (the book has a LONG chapter dedicated to different topics for questions, with example questions, like Communication, Empathy, Speed, Stress, etc…)

                Now, hopefully, you've got a brief idea of how to ask some of these questions, but I still highly recommend the book, as it has a lot more content than my few paragraphs, and there really is a lot more value to it than I just provided.  The next part I’m splitting into Skilled and Unskilled questions…  Skilled covers questions and issues for interviewers who are already skilled as developers, while Unskilled means that the interviewer is not greatly knowledgeable in development work.

Skilled Interviewer:

                To begin with, you should be aware of 2 key directions of developers.  Both are highly valuable, but both may fail horribly if questioned in the wrong way.  For instance, C# is a powerful, flexible modern language.  It has roots in Visual Basic, .NET itself, and C++/Java.  Naturally, your developers come from varying backgrounds.  If the persons background came from VB for instance, they don’t often know the term “Hash Table” in VB, they used Dictionaries.

                Many people have plenty of experience developing, but don’t necessarily understand the best word (according to you) for that scenario.  I, for instance, was concatenating strings for over a decade before I realized it was called that.  I remember being in an interview where the interviewer asked me about that, and I said I didn't know what it was.  Instead of asking me about my experience with string manipulation, he marked me down as being incredibly unskilled.

                You may inadvertently discard a candidate who may be 10 times more qualified for the position, because your choice of words were not the same that they would use.  Always follow up your keyword based questions, with a request for them to explain the mechanics.  It is better to understand the process than the words.  While words are pretty, the process is what really gets the job done.  A skilled interviewer with strong symbolic memory, and a mental dictionary of keywords would excel over a person who actually does this stuff all the time.

                Back to CBBI, remember to request that the person tell about real experience.  This also helps you get off the resume.  Sometimes a person has experience that they don’t bring up so boldly, because it isn't attached to a shiny business name, but it was part of a failed personal project.  Despite that, the skill is there.   It is your job as the interviewer to find the best you can get. 

It doesn't really matter if you get the impression that the person will work out well.  Any skilled interviewee can give you a great “impression”.  That usually only says that they were good in the interview.  Remember, as Charismatic as that person was, when it comes down to crunch time and not a hypothetical interview, you are depending on this person to reflect well on you, and help reduce the overall stress with their skill at getting things done.

Unskilled Interviewer:

                First, you have to determine why you are hiring.  If it is a larger company, and you are responsible for filling in a position that you know nothing about, that is a problem.  Any skilled interviewee who recognizes that you know very little, can rattle off some strand of answers that are right, or wrong, and as long as they sound confident, you’ll most likely believe them. 

                If you've determined that you have to be in charge of it, then you NEED to find technical help.  The same questions you look up online, are likely the same ones a skilled interviewee will find.  If you don’t have someone immediately available, ask friends with these skills.  Or, expanding farther, ask a company with some vested interest in your success, if they could get a little assistance in finding a person.  Obviously, this won’t be a competitor, but perhaps a business client or a vendor.   Getting in touch with sources like this, can actually help promote stronger bonds with your 2 companies, and help you get a better person for the job.   This person could possibly just do a simple technical phone screen, spending 10 minutes per client, and possibly assist in a sit down interview for a few of them.

                If your still stuck, talk to a recruiter.  Have them do the technical screenings.  Make sure the person’s resume shows that they have skills in the areas you are looking for.  Call their past managers, and ask them how well they work on their own.  (after all, if you don’t have resources to understand what they do, they could just sit around and make things up, with you none the wiser) 

                Next, ask them to explain things to you.  If this person will work with databases, ask them to explain how databases work.  Then ask them to explain how they get might be able to get it to work with your product.  At a certain point, you can request, “Tell me about a recent time you had to do this, that you got stuck on an error and had to spend some time debugging it.  What did you do?”  naturally following up with other questions. 

                Since you’re asking them to explain something in the first place, ask yourself.  Do you feel that you understand it better because of them?  Remember to use a sliding scale on these things.  Your first interview, you will understand the least, and as you interview more people, you will gain more theoretical knowledge.  Remember to give each person that same initial question of “Explain [X] to me.”  Though your follow up questions might be more in depth.

                A skilled person should be able to explain how it works quickly, easily and clearly.  Given how they are being hired, you need someone who can explain what is happening to you in the same manner.  Whether or not you get help on it, if you won’t have qualified technical resources who can review and explain the issues available to you, you should still ask these questions to make sure the person will be able to convey the issue. 

                If a person passes the technical aspect completely, but can’t help you understand how a database works, or how a website gets built, then once they are hired, you can’t expect to be well updated by this person.