Should I include code in my research paper?

Depends on the field and journal - check other papers in the same journal on how they do it. In my field (Bioinformatics) we usually do not put code into the paper but provide the full source code via the department web-page and/or git.

As mentioned in the answer by lordy, it is going to depend heavily on your field and journal. But to expand on things, here are a couple thoughts about including code directly in the content of the paper:

• Programming language: You're code is going to be in just one of the many available programming languages out there. That might limit its usefulness or make it more difficult for people that are not familiar with that language.
• Line lengths: Often it is hard to write readable code that fits into the line length of a single printed page. You have to resort to things like shorter, potentially less useful variable names, splitting lines, etc. Also, different journals might use different fonts that change how many characters fit on a line, so you might have to spend a lot of time just reformatting the code for different submissions. It's worse if it has to be in a single column of a two-column layout.
• Conciseness: there might be a lot of things that people don't need to see to understand the actual application of your paper, like initializing variables, unrolling loops, etc. This is just wasted space that may count toward word limits.
• Future-proofness: Ideally, you don't want any part of the main content of your paper to become obsolete in the future. Technology changes, standards change, etc. Eventually your code could become unrunnable. It's probably impossible to avoid altogether, but including it in the main body of the paper just makes it more prominent if it does happen.

With that, here are some alternatives, some of which have already been mentioned in other answers/comments:

• Pseudocode: basically the same as including code, but negates/offsets most or all of the negatives outlined above.
• Supplementary info (SI): Many journals allow the inclusion of supplementary material. You could potentially include your code here. This has the advantage that no matter what, there will always be an archival record of your code associated with your paper that you don't have to spend time managing.
• External repositories (e.g., Github): This makes you responsible for ensuring the code continues to be available for readers, and also depends on the service's continued existence, but has the upside that you can fix mistakes, add features, etc.

There's nothing stopping you from including all three options. Pseudocode provides permanency for describing an algorithm, supplementary info provides a combination of permanency and utility for an example implementation, and an external repository provides utility and future-proofness for actual mainstream use.

Your topic sounds like the paper would benefit from having the core algorithms as code in the paper, but you should probably use pseudo code with explicit declarations and everything.
Read a few other papers and look at the corresponding LaTeX packages, to get a rough impression how a good pseudo code listing should look like.

Do NOT:

int random_element(std::vector<int> mylist) {
  std::random_shuffle(mylist.begin(), mylist.end());
  return mylist.at(0);
}

Do:

Input:  A non-empty list of integers "mylist", a "shuffle" function that
        creates a random permutation of a list
Output: A random element of the list
-------------------------------------------------------------------------
shuffled_list ← shuffle(mylist)
result ← shuffled_list[0]
return result

Your reader should not need to understand the details of your programming language and many of them are implementation specific and have nothing to do with the algorithm itself. Your reader needs to understand the abstract method and is in general not interested in if you use smart pointers and other technical details.

The same applies for your screencaps. Are you sure, they are needed for the paper? Keep it at a minimum, if you're not explicitely writing about user interface guidelines. There are many ways to implement an UI for a specific application and when describing the method, it does not matter how you arranged the buttons.

Such things may be put into supplementary material, for example by putting your code online for others to read and try (possibly with a documentation including the screencaps and compiled binaries with the UI for easy testing).