New Blog coming soon...

I wanted to let anyone who follows me know I have a new blog on the way.  This one is being custom developed, because I could find no blogging service that has what I need.

I intend to start sharing a lot more unity samples and proofs.  I want to make this very Unity focused.  The Challenge that I am facing, is that none of the blog sites have a convenient way for me to upload a WebGL package and add it to the site.  The new site I'm having developed is built on that ability.  Now, it takes easily over an hour just to post to the CDN, and reconfigure the HTML example content.  As such, there are only 1 or 2 posts that share this content, but I had started to do one new proof a day to prove out some technology or experiment with a feature.  That's not reasonable.  I could test and produce a PoC in 20 minutes, but then take an hour to share it.

Anyway, I'm working on a few big things that will probably take most of my time until around August 2017.  I'll try to get more in, but it won't be often.  Be assured, its mostly Unity stuff.

A Degree Promises, a Portfolio Demonstrates

I want to share some advice that will help grow your resume to an impressive beast.

I recently came across this image on one of Daniel Doan's LinkedIn posts. The basic idea is that you want things you can show for your abilities.  Its something that I believe is really important.  I'm not saying college isn't important, but you can't depend on college alone to get ahead.

I have a really long resume, as in nine pages long.  I've been told early in my career, that resumes should be no more than one page.  My reasoning: I only add things that are relevant to my career interests.  Earlier in my life, I've worked as a clerk at a gas station, and a sandwich maker at Burger King; you won't find either of those on my resume.

Early on I had to stretch my resume just to get anywhere near a page.  I really wish I had understood this advice back then.  But, if I actually put *everything* that was relevant to my career in my resume, it would be too long; potentially a hundred pages.  I have so many unfinished works, that I have learned from, that I can't even remember them all any more.

But failed projects are the big thing here.  It wasn't until maybe 5 or 6 years ago, that I started dispensing this advice and following it: Complete something small then add to it.  Even if the project is small, as long as it is complete, you can pass it out, show it off, use it as proof.  It's so important to get things complete.  So KISS (Keep It Simple Stupid) and build your resume.

One other thing, when you are working at companies or projects that you already know will become part of your resume, look for buzzwords.  Probably about 8 or 9 years ago, I started doing this.  I would work for a company, and when there were opportunities like leading a small team, working on help files, or anything else that wasn't already part of my work (but related to my goals), I would jump at it.  I was getting paid to make myself more impressive to future employers.

Once you start applying these things, it won't be long before your resume always gets you an interview.

Preparation for THAT Conference Class

While I've been preparing for the presentation I'm going to give on Unity at THAT Conference, anyone who is planning to attend should also be preparing, if you want to try following along.  You should note, that I'm not planning on stopping to help debug issues during the presentation, but I will answer questions at any time in class.  If you plan on attending and just taking notes, use what ever setup you wish.

The game I'll show you how to build is a Chain Reaction game.  It will be easy and can work on a phone or tablet with ease.  

For those planning to follow along, I recommend:
1) a laptop
2) a separate mouse with a middle button.
3) the latest installation of Unity.

 - That's it.

I was considering having some packages, or a starter project already downloaded, but I've worked all that into the presentation now, using no outside content.  We'll be using basic shapes, and getting as far into this as we can.  I would suspect during the class we will get everything up to explosions.

Dependency Injection for Unity Statics

Download it here: https://www.assetstore.unity3d.com/en/#!/content/66012

Back when I worked for InContext Solutions, one thing I was asked to do was make our Unity code fit into a SOLID framework.  But how do you get a system dependent on static method calls to support Dependency Injection and be testable?  Simple, you write a wrapper and interface for all the static methods you want to use.

But since that is a lot of work, and since these methods change between releases, I've written some code to automatically extract the interfaces and wrappers by finding all the static methods and properties.  It wrote most of the code for me, in fact it wrote two hundred and seventy files.   They weren't perfect, I had to fix about 60 minor bugs for special cases I hadn't programmed it to deal with.
But now I have a fully wrapped Unity asset available for free for anyone wanting to get to develop for DI frameworks like Zenject, or get some mocks made up so unit testing doesn't require unity up and running, but can be included as part of a Continuous Build environment via means of NUnit, MS Test or the like.

I've proved out part of it, but there is a lot of code here.  If anyone runs into issues with it, I appreciate the feed back and will complete this.

In-Component Unit Testing

I've also introduced what I think is an interesting concept.  Unit Tests directly associated with the component's Custom Inspectors.  The value, is that the test cases can then use the state as used directly in the game.  Including pausing a live game and triggering a unit test for an object at any given state (accept destruction for obvious reasons).

I think I'll turn that into a separate asset next, and enhance the appearance, as well as making it easier to work apply to any given behaviour.  The current code, as it was a proof for the interfaces and wrappers, is more just a hard coded grouping of test cases.  Plenty of room to improve.

Download the code here.  Full source included.  https://www.assetstore.unity3d.com/en/#!/content/66012

Meetup Retrospectives

I've been trying to create a game development meetup (SDC.Game), and get it popular, but I've faced one problem for a while that I didn't realize was a problem.  Getting help.  I'm often looking up articles and seeking ideas from the group on how to improve it, but I've never had any format to follow.  Its always been ad-hoc.  From now on (or so I believe now), I'll be doing a retrospective after each meetup.  

So what is a "Retrospective"?  A retrospective is a meeting where we discuss what went well, what went poorly, and what changes we should make.  It should involve the whole team.  In this case, all the RSVP'd members to the meetup.  

But for a meetup group, this will not be in person, nor will it be a group phone call online.  For the time being, I'm using Meetup.com's discussion board, and emailing those who RSVP'd to a meetup.  The discussion will give my initial perspective, but then ask everyone else to chime in and off the same kind of feedback or challenge something I said.  Perhaps what I thought was a difficulty helped others.  

Will this improve things?  Who knows, but I won't find out if I never asked.  We can always decide to change the approach in the future.  Which is exactly what the retrospective is supposed to do.  I'm wondering what else would be good to run a retrospective on.  :)

Before your Next Interview

Interviews are scary.  Doesn't matter if you are are unemployed, or doing the hiring.  It can be nerve racking, finding out if you measure up, or trying to size up a candidate to figure out if they will be able to do what you need.  After reading books and articles on interviewing and psychology, and then through countless interviews from both sides of the table, I had the opportunity to practice and observe everything I studied.  

I'll sum up a useful portion of my interviewing science in this article.  Note: this is focusing on the interviewee.

Two Kinds of Interviewers

This is rather broad statement, but pretty much everybody tends to fit into 1 of two categories.  Either they were trained for it, or not.  Most interviewers were not trained for this.  They have their position because they were promoted into it, or primarily trained as a manager, but not for hiring.  

Those who are not trained, can seldom give a clear answer at the end of an interview as to why they think one candidate is better.  To them, it is usually about the 'fit'.  Which really just boils down to who did they get along with the most.  Their past history and ability to answer questions, play a role, but numerous candidates will typically do well for that.  So to the untrained interviewer, who ever is easiest to get along with, will typically be hired.  

Those who are trained are walk out of the interview with a clear idea of how the candidate did and also how they compare to others.  They have a list of prepared questions, but they aren't just pulled from the net.  There is a specific set of rules applied to the creation of these questions.  These questions have scores tied to them.  While trying to "be their friend" might help a little, it doesn't play heavily here.  Here you need good answers.  They can often smoke out a liar, and there is little you can do about it.

How to tell the Difference

Inexperienced interviewers will often phrase situational questions as "What would you do..." where experienced ones will ask "Tell me about a time..." 

What would you do?  You can honestly and easily say the absolute best thing that comes to mind.  Customers could yell all day and I'll calmly take care of all their needs.  Not that reflects your history, but that's what you believe you could do. 

Experienced interviewers will ask things like "Tell me about a time when..." The difference being that are asking about a specific point where you had to face some issue.  In this case lying will change a variety of verbal and physical queues.  It is easy for a trained interviewer to identify these ticks, and ask trapping questions.  I.e. Don't lie.  You will get caught.

How to react to an Inexperienced Interviewer

1) Don't lie.  

   No matter what the scenario, lying about anything in an interview is a setup for a failed work relationship.  You can get caught, and often the reason to lie is to appear more experienced.  When you take on work above your head, your time will be nothing but stress.

2) Mirror their body language. 

    Mirroring body language sends a signal to the other that in this situation, you act like they would, which implies you understand like they would, which implies you will understand them at a deeper level than someone with different gestures.

3) Use open body language.  

   You should mirror the interviewer, but only as much as they are open.  Stress, and disinterested can close up typical body communication.  Signs of closed body language include crossed arms (if you can't see the palms), crossed legs, closed fist, all things that close the muscle groups, and get you closer to a ball shape.  Additionally lack of attention would show as little eye contact, feet pointing another direction, body pointing another direction, doodling.  Words are about details, body language is typically about trust.  You want to keep your body language open, and closely mirroring them.  

4) Don't mirror their body language.  

   But what about 1 & 2?  After you've mirrored them for a while, try leading the body language conversation.  This is done by some open gesture that is different, such as leaning to one side, hand on the chin as if in thought, correcting a slouched posture.  Still open, but different.  You are testing the water.  If they start to follow your lead, then you have their trust and interest.  It is in human nature that once a positive connection is made to reinforce that connection.  If they start mirroring you, you are doing well.

5) Laughter and Amazement.

  If you can get them laughing, or smiling, or impressed with a solution, these are all great things.  Please note, this is not accomplished by pulling a rabbit out of a hat (unless your interviewing to be a magician)  or by any form of vulgarity.  This is accomplished by observing the interests they lead with.  This part is played more by the hip, and you'll have to gauge how best to read and respond to the room.  

You'll know you did well because at the end of the interview there will be a clear feeling of success, of connection.  Typically smiling, leaning in a bit during the hand shake.  It doesn't mean you got the position, as they might have found someone else who is hard to deny is a better fit or a better skill resource, but you have done well.  

How to react to an Experienced Interviewer

1) Be truthful.  

Above others, these interviewers can often read body language better than most.  You should never lie during an interview, but these interviewers will often ask questions that feel like traps, and if you are insecure, lying might feel like your only option.

2) Bad responses are ok, if you learned from them.  

Consider this question, "Tell me about a time when a manager was making things very difficult."  Most of us can think of a story like that.  The trap is when they follow it up with "What did you do to improve the situation."  Suddenly there is the realization that you need to take some responsibility.  Was there anything that you did, or do you just enjoy the opportunity to complain?  If you took no initiative to improve the issues, you can say that at that position, "No, I did not.  However, in future positions, when faced with similar circumstances, I have ..."  And do it.  

You are responsible for your environment.  You can mention a communication breakdown to a manager, or to their boss, if the issue is with your manager.  Once you have exhausted reasonable options, and the problem still exists, you can at least say you took X actions to resolve it, but it did not work.  

The trap questions are not to actually trap you.  They want people who have faced difficult situations and grown from them.  Don't relish in how horrible a past employer was, just be clear about the issues and what you learned from them.  

3) Still follow the advice for the inexperienced interviewer.  

They are using science to read you, but you can still improve the situation with positive body language.  

4) Answer above and beyond the question.

Typically you will get awarded points per question.  Lets say 1-5 points.  5 is usually reserved for something special.  I.e. present the solution, but try to offer some unique insight, or valuable alternative.

Usually there will be extra points for something that stands out.  I.e. not related to a question, just the interviewer wanted to record extra credit.  Perhaps you teach this topic at a college.  Perhaps you have a a valuable connection to an account they want to land.  But the key is to realize you want to go above the expectations of this person to secure those extra points.

-- --- --

Now this has been generalized significantly.  Some interviewers will be in between, developing their skills, or trying something entirely different.  But it seems most often they fall into one of these two areas.  And there is always a candidate more fitting than you.  And some interviews are just off, even with the right candidates.  Don't let any failed interviews get you down.  Learn from them and move on.  

For additional reading, I recommend Victoria A. Hoevemeyer's "High Impact Interview Questions"

Networking Tip: No number on your business cards.

In the book "Networking Like a Pro" by Ivan Misner, (which I highly recommend) it brings up the idea of not including your phone number on your business card.  But how should you give them your phone number?  Write it on the card in front of them.

Why?
Think about the last time someone gave you their card.  Unless there was something super special about the occasion, it typically goes into an imaginary oubliette in your pocket.  I.e. it is pocketed and forgotten.  How does writing the number in front of the person help?  By conveying the message that it really is OK to call.  It personalizes the card in a way to make it more memorable, more connected.

NOTE: It is not the fact that it is written, but the fact it was personalized for them.  I.e. if you just hand write your phone number on all your cards beforehand, it makes it look like you just forgot to add it to the card.  Which appears unprofessional.  You need to do it in front of them, and then it conveys you are providing this additional way to be reached.

Don't Stop There!
Never take a line of advice without considering the psychology behind it.  This isn't about the card, its about the connection.  You are taking a rather mundane transaction and personalizing it to make it more connected.  How else could you accomplish the same thing?

An idea would be to wear something that stands out to your next event.  I'm not talking about wearing a clown suit to your next business convention, but a hook.  Some accessory to get them to ask about it and start a conversation on, especially if it relates to how you can be of service.  Do you sell fishing tackle?  Wear a hat with a fish hook in it.  Sell racing gear?  Have a relatively large gear prominently displayed on your key chain.  Make comics, wear a watch with your favorite character on it, especially if it blinks every now and then.

Another would be match making.  Remember the people you met, how they can help others and what they might need, even if its not for you.  After the meetups, look through your list of people you've met.  Send an email including both parties.  Saying that how you all met, and pointing out the connection.  I.e. such and such place has been having trouble with their email provider, but you know a great IT Technician.  Email them both, and drop the conversation starter on how they can help each other out.  Even though its not directly helping you, they will remember the assistance.  (Please note, if it is an issue like failing email, make sure the technician you are going to suggest is not the source for the broken email) :)

Its up to you and your niche market to figure out what else you can do.  These are just some ideas.  But get networking and make valuable connections today.

Meaningful Decisions - Make your Games more than 1 Dimensional

All games give players choices to make, but how meaningful are they?  If you search Meaningful Decisions in google, you'll see this is actually a very important step in game design.  You could argue that everything a player does is a choice.  Right, left, jump, pick up...   But meaningful decisions will get a player thinking and connecting to the game more.  While you need to make PoC's (proof of concepts) on new technologies, you also need to play test the meaningful decisions, and see if its fun.

So what makes a decision "meaningful?"  Bryce Morrison posted an excellent article on GameSutra.  I'll borrow from a list of what he believes makes a meaningful decision.:

• Awareness - The player must be somewhat aware they are making a choice (perceive options)
• Gameplay Consequences – The choice must have consequences that are both gameplay and aesthetically oriented
• Reminders – The player must be reminded of the choice they made after thay made it
• Permanence - The player cannot go back and undo their choice after exploring the consequences

A while back, when I first started finding out about meaningful decisions, I scoured the internet trying to find better explanations of it, because it felt to vague.  Its like the articles where trying to explain how to ride a bike.  Its hard to portray in text.  

To help get around that, I figured I would give some key examples of meaningful decisions.

Racing Examples

• Do I make a pit stop?  
• The player will lose time, but have a vehicle in better condition less likely to have a tire blowout.
• Should the car be geared for higher speed of faster acceleration? 
• Should I drive through a smoking wreck?
• If I hit another vehicle, I could destroy my own car, but I could also get ahead.  
• Do I use Nitrous on turns to keep up speed?
• At the risk of losing control of the vehicle?

FPS Examples

• Should I take the longer safer route, or the faster more dangerous route?
• Do I use a bigger weapon and risk running out of ammo, or a smaller weapon with lots of weaker ammo?
• Do I shoot from a distance where it is safer for me, but risk missing and alerting the enemy to my presence?
• Do I evade a higher level enemy or take a risk in battle?

You'll notice its not "Should I move left or right" or "Should I jump over pits?"  Those are immediate mechanical operations.  Instead this focuses on decisions a player makes in the game, that alter how the game is played.  For instance, in the racing example, a player who recently had a pit stop would be more apt to make it through a wreck and have their vehicle survive an impact.  A decision the player would have made potentially 6 laps ago is still affecting their options now.

In that example, Awareness could be a damage counter on the vehicle.  Not just gas and tire wear, but vehicle damage.  Awareness would be a pit boss telling you to come in, you need to get fixed up.  Consequences would be getting a flat or running out of fuel, possibly even a drop in speed or acceleration.  Reminders would be a pit boss yelling at you, to get fixed, or warn you that your vehicles to damages to risk taking a hit in a car wreck.  Permanence, means the player can't easily redo the decision.  Typically damage, or destruction to a player's vehicle will result losing the level, or at least waiting to get towed to the pit.

All games will have basic mechanics, but the better ones will give the player decisions that weigh in on future options and game play.  When designing a proof of concept it is important for the proofs to focus on these meaningful decisions.  This is where the game play becomes more memorable.

Dev Tip: Play Tests should be Incomplete

If you want to get better feed back from your play testers, consider adding an element that is obvious and incomplete.  If the game looks closer to done, they might reserve feed back to only apply to things that look easier to fix.  

Most people, when attending a restaurant, and the food taste in general is mediocre, the customer is not apt to say anything, but simply not return and possible leave a bad review.  But if the plate has something clearly wrong with it, like there is no burger in the bun, or the bacon is charred black. The customer is more likely to assume the food *could* be good, but has a mistake and ask for it to be fixed.

Play testers are often the same way.  If they think the game sucks over all, they'll be less apt to say that.  But if its clear that it is incomplete, that it is a work in progress, they will be more open about criticisms.

Unity Presentation at THAT Conference, WI

I'm presenting an Intro to Unity 3D:

THAT Conference, held annually in the Wisconsin Dells, is all about geeking out, particularly in technology.  I'll be hosting a presentation, that introduces Unity 3D.

This is a 3 day event, from Monday, August 8th to Wednesday, August 10th, at the Kalahari Resort, featuring technology speakers, hands on practices and open rooms.

My presentation is designed to take you from no experience in Unity 3D, to enough to be dangerous.  I'll show you how the environment works, how to tie in C# (or Java Script if you prefer) to start creating your own games in 3D on nearly any platform.

I've given similar presentations in the past, which focused on a remake of Jenga, the popular table top block game.  This presentation will focus on a more mobile friendly game, a chain reaction game featuring both 2D and 3D elements.  Below is a video of the initial proof for that.

This is a 3 day conference with adult only sessions, but many sessions that are intended for kids as well, making this an event for the whole family as well.  Sign Up Now!

Unity Certification : Prep Day 1/14

So I just found out that Unity announced official certifications at GDC this year, and not only that, but they will be here in Chicago on the 20th.  I'm already signed up.  You can too, if you feel ready, which I don't.  Hence I've got 2 weeks to practice on all areas I'm missing.

Fortunately, Unity released a PDF containing most of the important details of what is covered in the test, and the granularity is pretty fine, making it easier to focus my training, and I'm basically going down a check list of topics.  At this point, I'm working on animation, which is an area I really haven't touched before.

I developed a proof with models found free in the asset store.  I'm not trying to polish these.  I just want PoC's that try to give a realistic game experience example.  In this case, I'm having a player swim up to a wall, climb it, hop over the top, crouch, peak around a corner and then stand.

I'll be doing more proofs over the next 2 weeks, until the Cert happens.  Awesomely, Omni Resources, the company I work for now, is letting me expense the certification.  :)

Alt Review: GDC: Side Scrolling Cameras

[Alt Reviews is a review of some topic but with my own spin on it.  I.e. I learn from the topic, and mix my own experience and ideas into it.  I do this mentally on all learning content, but I'm sharing it for others benefit as well.]

At GDC 2016, Itay Keren gave a presentation called "Scroll Back: The Theory and Practice of Cameras in Side Scrollers."

Physics Base

2D camera movement is more important that typically realized.  For instance, in many games, a camera is simply affixed to a focal point and never moves off.  An upgrade, is adding minor physics to so that the movement is smoothed out with tethers and springs.  Another upgrade is leading the view, where if you are in a vehicle and picking up speed, the camera might move out to let you see farther ahead, while keeping the vehicle far behind.  Itay's presentation talks about the importance, value and methods of implementing deeper layers of leading and controlling the camera for players.

Itay starts out talking about how the eye works and how the brain recieves images.  First pointing out that the center of our vision and the edge of our vision have different response systems.  The center is very clear, focused, and lower speed.  While the outer/edges is faster, but less attuned to specifics.  It makes assumptions about what it sees.

He brings up 3 topics that are intertwined

• Attention - Make sure the camera shows all things that are important.
• Interaction - Make background movement tightly bound to controls. (Paralax BG's for instance)
• Comfort - Ease of contextualizing background changes.

Issue: How to eliminate unpredictable bumps?  Below is ordered from earlier/lighter methods to newer/more exact methods.  (Its not that one method is better than the other, but that each can have practical value depending on your game design.)

• None.  The camera is locked to the unit.
• Vertical or horizontal snapping.  I.e. the camera freely follows the character along 1 axis, but the other is locked.
• Camera Window. I.e. the camera stays put until the player moves just outside of the camera window.  The window is smaller than the screen.
• With Lock: This forces elements to move with the camera when needed.  Like Street Fighter.
• Works best with Zoom To Fit
• Platform Snapping.  I.e. The camera remains locks when there is nothing for it to do.  Once the player jumps and lands on another platform, the camera quickly (not instantly) moves vertically to that next section.

Next he talks about using the physics to smooth the production.  I tend to use Impulse (small measurable unit of speed) and Velocity (direction * speed).  I.e. as you move, the unit is the target.  As you move, the camera first moves slowly, then picks up speed every frame until it catches up to the target.  (Turns out he talks about this a moment later, as Lerp Smoothing.  :) )

• Forward Focus.  I.e. the camera will show more ahead of the player.
• Dual Forward Focus.  I.e. if the player turns around, the camera switches to provide more space in front of the the direction they are facing.
• Threshold triggered.  I.e. The character can move back a little before triggering camera movement.
• 2D Forward focus.  Any direction the player moves.  the camera moves a little ahead of the player.  Requires smoothing physics for the player control and the camera with Lerp based velocity.
• Target Based focus.  I.e. giving some camera shift based on targets.  such as are the targets in view and important?  Is the mouse over a target?
• Position Averaging.  I.e. focus on multiple players on the screen who both always show up in the same view.  like gauntlet
• Shake.  I.e. Lack of control, something emphasizing the player's lack, or the impact something just had, because the whole world shakes.

The Directors Chair

Next Itay moves on to Directed Paths.  Everything so far has been based on game play focused camera movements.  I personally have provided very little direction in my game development.  A major distinction, is that (typically) the game play focused camera controls are all code based.  A programmers makes them happen as expected.  While a Director's perspective puts more control in front of a level designer.

Note that with the Director's perspective, your still coding all the camera movements, but you are providing tools for the designer to make changes to that mid game.

• Region Based Anchors
• Level or areas in a game change how the camera focus works.  
• If a portion of the game is mostly vertical, then the camera option changes to focus on vertical assist.
• Zoom To fit.  
• zoom in/out to show/focus on key elements in a scene.  
• Example for boss levels
• Cue Focus
• Attractors found in levels that try to shift the camera to it based on its distance from the player.  
• Center Region/Camera
• Focuses on player, but takes an value between the target and the center of the region.
• This gives a sense of where you are in the region, because the camera movement compared to the unit position helps express your location.
• Camera Track
• The camera follows a set track in the game, and moves to keeps its closest position along that track to the player.
• Gives feeling of control of the camera, while allowing the designer complete freedom to setup each angle, zoom/pan, etc...
• Gesture Cues
• Focuses either on actions, or elements in the game, where the camera perspective changes to better show something.  For instance as you hang on an edge, the camera focus might switch from side scroller, to emphasize downward fall more.
• This may also focus on player events, like picking up an object to temporarily highlight the object over their head, or a particular attack, that if it catches, will run several slow motion hits.
• Cinematic Paths
• Predefined set of paths, outside any player control, that shows things happening, 
• This might emphasize an even just off scene event, that helps the story along.  You don't control it, but its very important for story/emphasis.
• This stops actually cut scenes and allows the game to move on without scene loading.

Italy then goes on to talk about Mushroom 11, and all the camera modes that went into it.  I strongly recommend reviewing it.  I'm planning on organizing these thoughts a little further, and write up some code examples, perhaps a Lynda or Udemy class to show it.

So here is another link to "Scroll Back: The Theory and Practice of Cameras in Side Scrollers." I strongly recommend watching it, as Itay goes into far more detail and explanation on each area.

Knock Out PoC Update 1

I took on a new proof of concept, similar to match 3, except that you blow up anything you click on, and all connected pieces of a similar color.  Everything here represents about 6 hours of work.

The ball prefab is just a sphere with a rigid body, with the Z constrained.  I had initially tried placing an empty quad in front and behind but found this was better for performance & visuals.  The first PoC was just to get a bunch of them filling up a screen, and as the video above shows, that was completed well.  Because its physics based, and not defined slots, there is some variance in how they line up.

Next I added click to destroy.  Easy enough, using OnMouseEnter/OnMousExit to set a bool and if that is set, onclick, destroy(gameObject).  But destroy wasn't visual enough, so I added a simple explosion.  A while ago, I picked up the asset FX Mega Pack from the asset store, and I'm using modified version of one of their explosions.

Next I daisy chained all the touching (or close to touching) items of similar color and separated the destruction by a fraction of a second each, so you can see the chain effect.

Lastly, I added a bunch more block types and a score system.  You get 1 point for each block, but each daisy chained item gets you the number of points as its position in the destruction.  so 1 block = 1 point.  2 blocks = 2 points (1 + 2) and so on.  

Truck Ride PoC Retrospective

Reminder, Trick Ride PoC was just a Proof of Concept.  It was intended to end and not be base code.  Here were some of the good and bad's along the way:

Good:

• Unity's 2D Wheel components (Wheel Joint 2D) were easy to implement and get a wheel started.

Bad:

• Terrain modulation was tough.  I didn't come up with a full solution for this as the proof turned to pixelation, but trying to smooth out the terrain like hill climber was tough to do.  I have ideas, but not that include handling the pixelation.

• Unity's 2D Wheel Components had no natural way to separate them.  Each wheel is connected to a separate script.  Each script has to be connected to the rigid body of the vehicle.  So if you have a script that's going to control front and rear wheel separately, then you have to base it off position, which doesn't work if you start the vehicle upside down or tilted greatly. Unity's drag/drop solution won't work.  
• The Joint was a little too hard to use.  it didn't seem to have a "flex range".  Something to stop it from moving too far from the wheel well.  I had it move over 50 away from a vehicle that was only 3 long.  Made no sense, and was hard to control.

Fun:

• The game peaked in fun for me as I was climbing steep terrain, with awkward grip that worked really well to reach around to the other side of a block and then pull me over.  It felt like something was there, but I couldn't enhance it any more.  I think I was a little too focused on getting the physics to work better for speed, and could have gotten more out of the climber if I let it focus on slow movement with challenging terrain.

In the end, I'm glad I tried this, but its time to try another proof.  Something quick and easy to expand on, until I get caught up in something insanely fun.

Create your own 3D RTS in Unity

Its LIVE!  There is a course on Lynda.com now called "Unity 5: Build a Real-Time Strategy Course" that you can attend.   If you don't have an account there, you can get a free trial here.

I could have done multiplayer, but I decided to go with an AI instead. I've shown ways to add new AI capabilities with ease, using a relatively straight forward AI system.  You can control how easy or hard it is by a making the AI slower or have it make poor decisions.  

Its a playable RTS, where you can battle an AI player, (or multiple if you add more enemies), define AI starting points and resources, control the camera movement, hide enemies on the mini map, add actions to units, use actions to control the technology tree, determine safe points to build, navigation and a lot more.

Try it out now! ~ Unity 5: Build a Real-Time Strategy Course

Truck Ride PoC - Update 6 - BG and more Pixelly crashes. (Slow motion wreck)

I've added a background, and more pixels for the crashes.  Below is a slow motion explosion.  Perhaps I'll mess with the time on this, so slow motion explosions are part of the game, not the recording process.

Truck Ride PoC - Update 5 - Crumble Physics

As the 'Pixel' transformation is gaining more traction, I've been thinking about how I can take more advantage of it.  Crashing is a great concept, when the pixels all become separated from their base, and scattered with the velocity of the vehicle just before it crashed.

While I don't have the Crash Event wired into the physics, (so I'm using [space] for now) I do have the transfer of physics from the body to the pixels working great!

Truck Ride PoC - Update 4 - Pixel Climber

So in this version, I got rid of the polygon collider for the frame, and the circular colliders on the wheels.  Then I placed 2D Box Colliders on all the "Pixels".  This allowed them to operate like squares and gain unique abilities that round tires don't have.

Around 18 seconds in, you'll see it pull itself over a hill, by allowing a front pixel to sink past the end and pull the back end over.  A grip the round tires could not make.  This is opening a lot more options in the Blocky realm of casual game play.  I'll see about expanding on those.

* Another update, is the terrain is all based on the pixels as well.  I spent about 2 minutes creating a simple "pixel" square, and now EVERYTHING in the game uses it. 

*Another update is that the ground is complete now.  A top layer of grass (made of 1 pixel) atop a depth of dirt (made of 10 pixels) 

* Another update is that the vehicle control is now in the player's hands.  So far stopping/slowing are very *slow*, but I'll improve that. 

Truck Ride - PoC Update 3 - Blocks.

So I'm testing out a new perspective on the game play.  Taking hill climber and adding an 8Bit feel to it.

I slowed it down, so the tire movement stands out more.  I attached square textures all over the tires and frame of the body, and then created a really simple script that locks the rotation in place:

Finally, I stopped rendering the original textures and colored the squares to what I want.  I think I'll keep up on this proof for a bit.  It's starting to feel fun.  I'll chase that.  :)

SDC.Game: March 2016

Tuesday, March 8th, at the Warrenville Public Library.  

http://www.meetup.com/SoftDev/events/228083927/

There will be a few larger things to discuss this time.  

• I'll be proposing a new time/day of the month for the Meetup.  
• I'm planning on it being roughly in between the SDC Meetups so perhaps 3rd Tuesday, instead of the first of the the month.  (SDC is technology in general, SDC.Game focuses on gaming tech.

• Running a Game Jam
• I'd like to start a Game Jam for the group. 
• Debating on a 4 hour live, or 1 week online.  
• General Discussion on what they are.

• Format Change:
• Currently, the meetups are more ad-hoc discussion.  
• I'd like to start each meetup with a presentation on something game related.  
• 15-45 minutes long, relating to game programming, engines, art, music, marketing, design, ai, etc...
• I'd like to get different people to present.  
• Do you commonly generate textured models in Blender?  Show us how.
• Have you developed game samples with RpgMaker?  Show us how.
• I can do some presentations to begin with, but I'd like to get more people in on it.
• After the presentation, 
• it will be open to Q&A, 
• then open for announcements, sharing project updates, etc
• and finally stay in open for discussion.  

Join us on Tuesday, March 8th from 6 to 8:45.

Review: The Game Jam Survival Guide: Part 1

I'm still in the middle of reading The Game Jam Survival Guide, but I felt like posting an update on it.  How I feel inspired, and stopped working on games (for a moment).  :)

First, if you have any interest in game development, I recommend getting this book.  (so far. :) )

I've found it very inspiring.  While I've been part of very few game jams, I find my interests in attending in a game jam peeking again.  At first, I started working on another game concept, the 2D truck physics game, but after getting into hours 13-24, on a part for "Motivation techniques" (page 51) it brought up to share the work in progress and some reasons why.

Sharing the progress reminded me of what Codivore.com has been becoming in my head.  While I want Codivore to be an open community of training, where the community helps shape and define the training, the first feature I'm aiming for, is a quick way to post an article with a functioning Unity 3D WebGL game attached.  Its proven a pain within blogger.

I feel like getting Codivore to take over for the blogs before I jump into a 48 hour game jam.  I hope you enjoy it.  The book is inspiring my to finish more than just a game.

Truck Ride - PoC Update 2

I've decided to give the project a code name, "Truck Ride" which is intended to be changed prior to release, as a title might emerge from the product.

Updates:

• Custom Art.  Terrible Custom Art, but its my temporary place holder that I built in gimp after a few minutes.
• Camera Script for following the truck  It has an offset that I'm not using, 
• Later is intended to alter the view range based on the speed.
• Shrunk the terrain prefab.
• Terrain Script that recycles the terrain, and adjusts the height.
• Will need to improve this drastically, to include angling the terrain, and potentially curving it along a changing spline/bezier curve.  
• There are still *no* scripts controlling the vehicle.  I have the default wheel scripts set to 1000 RPMs.

Codivore.com Update 2:

Codivore.com is a site I've been working towards for a while.  A video training site, since there clearly aren't enough.  (snark)  I'm hoping for it to stand out in a particular way.  Like Stack Over Flow, multiple people can cover the same topic, and different answers get up voted.  Community members can add training they created.  If we don't have it covered already, then you'll show up.  If we do cover it already, it will be available as an alternative, and enough people review both and like the new one, yours will swap out as the primary.  Kind of a videopedia.

Its not ready, but it has been improving in the capabilities and will go live, hopefully soon, and replace this blog.  I.e. I'm bringing out its blog focused features now, and plan to make it easy to add Unity demos in articles.  A feature which is not convenient here.

I'm trying to do everything as cleanly is possible.  MVC5, C# 6, Ninject (& Ninject.MVC), AngularJS, Web API's, etc.

I hope to have it up for blogging at least very soon.

POC: 2D Car Physics

I'm considering creating a 2D Car game, similar to Hill Climber.  This is a proof of concept, just testing the features.  The art is only a place holder, as I borrowed it from RC-Niews.nl for this test.  The point is to make sure I can control general physics and vehicle creation.  Additionally will come custom graphics, upgrades, terrains, power-ups, high scores, and hopefully a fun & engaging system of play.

Unity Review: Sweater Stitch Shader (5 Stars)

Sweater Stitch Shader works incredibly well and was a breeze to add.  Installation is 1) import, 2) add stitch script to the camera, and 3) set background color alpha to 255.  That's it.  You can activate it and deactivate it in game.  (click the image to see a higher res copy)

I took an RTS I'm working on for Lynda.com and dragged it in as a test and this is the effect.  Below is an image where I increased the stitch size.

I give this a 5/5 for what it advertises.  However, there are 2 upgrades I would like to see.
1) have the script's start up edit the background color's alpha channel.  Additionally just add a bool called "SetAlphaOnStart" so the designer can turn that off if they wish.  And 2) I wish the gauge would take into account screen size.  I.e. keep the size the same no matter what screen size it is on.  This would help so that the tablet and the phone apps could appear the same.

Of course we can write our own scripts or mod the existing ones, so its really quite a minor concern.

Update -- Below is a recording of the system in real time, adjusting stitch sizes and turning it off, without affecting the game, and still seeing animations live.

EdTech Article on Helping Kids get Started in Programming

Back in September 2016, I was giving a presentation on Unity 3D at Veredus.  A content strategist from CDW asked if I'd do an article for them.  The article is online, and can be found in the January release of the EdTech K-12 magazine.  You can also read the article online here: http://www.edtechmagazine.com/k12/article/2015/12/get-kids-involved-coding-games

The article is about kids learning to make there own video games, particularly when their parents, teaches or classes might not be able to help.  This is a topic that came up during the last Board of Advisors meeting at the Technology Center of Dupage.  It addresses some real potential for kids to accomplish their game development goals.  

This was also my first magazine article, and I look forward to writing more.  

Video Game Testing as a Career...

Game Testing is a real career option.  According to google, the average salary for a US Game Tester, is about forty eight thousand a year.  It is a chance to take experience many of us already have and turn it into a future.  But what do you need to know?  Where do you find them?  And is it really worth while?

Becoming a Game Tester

Anyone who is comfortable with playing Video Games has a chance to work as a game tester.  But it is not likely that will get you in the door with so many other's interested in the same position and with more potential skill than you.  So what skills can make you stand out more?

• Playing a wide array of game genres.  
• You may be most interested in racing games, or first person shooters, but that doesn't mean their clients happen to have any of those games to test.  If you have no skill in strategy games, or basket ball, you will be somewhat limited in your usefulness.
• Reducing challenges to the lowest common denominator
• You are playing a game, when you find that after 12 actions, a bug happens that makes you lose  a life.  You could report this as is, and then the developers have to assume the bug is caused by some combination of all those actions.  Or you could try repeating the 12th action before the bug in a simpler way, and deliver a report that only takes 1 step.
• Your job is to reduce the work of the developers trying to repair these bugs
• Being Professional.
• This will not be playing at home with your buddies, acting however you want.  You need to be able to conduct yourself professionally. 
• Most Game Testing positions will be more laid back and lax, but that is per company, per position.  It is your job to be professional first, and then relax as the company allows.
• So what are some features of professionalism?
• Competence:  Don't say you can do something if you are not sure how.
• Reliability: Show up to work on time (and your interview)
• Positive Attitude: You can't just walk away from a game, like you might at home.  You need to be fun to work with, and your job is to test these games.  You also can't tell people you work with they are idiots.  That's a fighting word.  You need to be able to remain positive even in frustrations.
• Clarity: You can't just say this game sucks, or enter a bug that says this level is terrible.  You need to be clear.  "Awesome", "Terrible" and "Incredible" are useless words.  Explain why it is that way.  Explain that "falling through the floor at seemingly random intervals is very frustrating."
• Honesty: It is often difficult to tell a manager that you don't think you'll be able to complete something in time.  So you might say things like "It will be done" and when it does start going over in time, you might be saying, "I've almost got it done" even if it isn't and you have no idea how much longer it will take.  Managers's often aren't worried about occasional break downs in ability.  none of us are perfect.  They want to know if something is going to take longer, so they can mitigate it.  To help them, you must be honest.
• There are a lot of professional guides/tips/sites out there.  Read some.
• Step out of the game play.
• We usually play for fun.  But your are not technically "playing" the game.  You are helping prepare the game.  Granted, part of your job is to make sure the game play is great.  
• You need to start looking for bugs.  For instance walls that don't quite line up, allowing a line of pixels.  Perhaps picking up a weapon only works when you are standing directly over it, and not when it is right in front of you and easier to see.  It doesn't make as much sense, but it's easy to get used to.  You should still bring it up as a bug.
• Once you start doing this, you'll start noticing lots of bugs in almost all major video games.  Part of the question will be how easy is it for the bugs to be over looked.
• Sign up for Beta Testing games online.  
• Report any bugs you find.  Research different types of bugs in games.
• Get used to the bug submission tools they use.
• Start building a resume.  
• Include everything game related you can think of.  I.e. list the genre's you've played, list major achievements.  
• List games you beta tested, and particularly some of the better bugs you'e discovered
• List the tools you used for bug submission, if it was more than just a simple text box on their site.
• Pick up a programming language, 3D modelling or Art.
• While you don't need these things, they will help you understand what you are looking at better.  If you get into 3D modelling, you might better understand that you can see that certain edges aren't seamed properly.  If you get into art, you might recognize that pre-shading in the art is making the lighting in the game seem off.  If you get into programming, you might better understand the reason that you can't jump on certain blocks, is because only the X is being checked, and not the Y.  

Finding a Job

These positions are more common in areas with a lot of Game Development, such as LA and Seattle.  Considering moving out there might be a good idea.  Do you have any friends or family in that area you can stay with while doing this?  

You can search for "Game Tester" or "QA" positions on Dice.com, Monster.com and other technology or game boards.  Even if you can't find a position directly relating to games, start out with other QA/Testing positions.  Getting a few months contract done will give you substantial experience and better chances for the positions you do want.  

Expand your connections, and get noticed online.  If you don't have one, create a LinkedIn.com profile.  Much of technology jobs today come from there now.  You can post your resume, get involved in groups of professionals talking about topics, and make a name for yourself.  I've been getting setup to be flown out for interviews with major companies that haven't even seen a resume yet, because of some of my statements on forums.

Is it Worth it?

While you can make a career out of Game Testing, and when you are starting out, 50k average salary can sound quite nice, it is often considered a gateway career for most.  Don't get me wrong, some stay in testing their whole lives, and its all about making games better.  That is a noble point of view, and our games a greatly improved by it.  

But it is a job.  It is serious.  There is a lot of work.  Even if you spend most of your time playing games you really enjoy, much it will be coming back every day and repeating the same level, with slightly changing glitches.  The exact things that would make you throw out a game at home are what you might find yourself doing day in and day out.  If you can't handle that, taking it up as a career, might make you lose your passion for video games.  

If you view it as a gateway, this puts you in contact with Game Developers, Designers, Artists, Managers, and other big names in the game industry.  While you develop your other skills, you'll find doors opening around you for Junior Developers, or Automation, which is a bridge position from Testing to Programming.  Or be able to talk with designers, and get tips and advice, and start learning things that will help you out greatly.