
After my last post regarding what Students might do to increase their chances of getting into the industry, I have had discussions with those on the teaching side and what I think Colleges & Universities could do to help better prepare students.
Version Control
One key part is that there are a number of tools that any respectable (and long lasting!) development team or studio use, and most students I encounter are either not aware these exist, or are almost “afraid” of trying to utilise them, citing them as “too hard” to understand.
The first in this list is version control.
Anything like Subversion, Git, Mercurial, Plastic, Perforce… it doesn’t matter which tool they use or learn, as different studios use different ones, but knowing what they are, how they work, how to update the versions of their projects – all of this is paramount!
Especially when they collaborate on a team project!! If they are all working together with version control then:
- There is none of the “so-and-so has it on a memory stick.”
- Everyone can see when everyone else is working and what they worked on.
- Everyone can see who made what changes, so if someone breaks the game, then it’s clear to see who did what, where and why it’s breaking (or it can at least elude to why).
They can also get exposed to automation tooling, such as Continuous Integration, Auto Deployment and testing… but this might be a third-year item or maybe something they at least need to be aware of, not necessarily use?
Experimentation & Development
In my earlier article, I noted about the troubles with “Blank Page Syndrome” and in a similar context, I’ve encountered an almost “unwillingness” from students to try to put their game ideas/designs into something technical like Unreal Engine or Unity.
It’s easy for me to say now with my years in the industry, but both programming and maths are not difficult! The hard part is being able to understand how to put ones thoughts into the context of programming (or maths). Outlining and teaching some basic programming principles in a way that can highlight and link back to game design would, in my opinion, bridge the gap between the creative elements of design and at the very least, experimentation on the technical side.
With regards to teaching methodologies, there are threshold concepts to teaching and learning any subject that unlock the next leaps in their learning… and always relating it through context back to game design or how it works in the game, should help.
Production & Project Management
There are many other areas that I feel Academia could improve when preparing students, but the last big one is Production and Project Management.
The games industry cannot operate on the “Waterfall” development methodology and teaching it in relation to a digital project would be a negative.
That’s not to say that Waterfall doesn’t have any place in production, that’s not true! It works great for building a house where one must do things in a specific order. Or having parts fabricated for a board game. But in video games, Agile methodologies win out. It’s also key to note that Agile does not mean “do what you want.” If anything, it’s got more rules than Waterfall, but because the direction of the product can be steered every sprint (usually every 2 weeks), it’s easier to correct the direction of the game at an earlier stage, with less of an impact to the final product. And a major part is that the game is always playable at the end of each sprint!
Following on from this, the use of proper project management tools, like Jira, Monday or even a physical Kanban board are paramount. Spreadsheets are not an appropriate PM tool! There is a post-mortem on the first Shenmue game where the developers lamented that they used spreadsheets with thousands of rows, whereas they felt they should have built their own PM suite and that would have taken less time than fixing the broken documents (or rewriting them every few months, when they would inevitably become unusable or inaccurate).
Those are my key elements that I feel Colleges & Universities should be tackling when preparing students for the industry. I’d be interested to know other developers thoughts, is there anything you think is more important? Just as important? Areas within the sections I’ve mentioned that need special attention?

Once we have configured our Input controls, sorted the bindings (in our Player Controller) and passed them through to the controlled character, we can simply call the
In Kirby, the developers called it “Fuzzy Landing” and it clearly explains the issue stated above – when you think the character is just on the ground, but they aren’t. We implemented a distance check with the ground and if you were within a tolerance of the ground, then we now call the Unreal node
Most characters in video games are represented by a Capsule that surrounds the actual player geometry. This capsule is what is moved around in the world, with the mesh updating the animations based on the velocity of the capsule. In the above image, you can see the capsule around the front portion of the Dog and the hind paws are just leaving the rocks surface. However because the capsule has started to fall, then the dog enters the appropriate animation state.
To get around this, we added a simple Timer and a jump override. If you press Jump before the Timer, we call
The first step is to make two simple projections both ahead of the dog and down from the shoulders. We only trigger this check when the dog is jumping and if a valid surface is detected between the two projections, then we can initiate a scramble.
Here you can see the “Real” shadow of the dog (bottom right) but also the ground target shadow (in the red circle). This moves directly below the Dog and fades in/out to always give you a point to aim at.
Anyone who has used Unreal Engine’s foliage tool within the editor will know just how incredibly powerful it is and how easy we can populate some terrain or a map with trees, bushes and the like.
You can also change these at runtime in Development or Debug builds via console commands such as sg.FoliageQuality with values ranging from 0 to 3.
When in Foliage Mode, select the mesh that is disappearing, then scroll down until you find the Scalability area. Make sure you untick “Enable Density Scaling” on the meshes you want to keep. Of course, keep in mind this line from the tooltip text: