How to be “Ready” for the Games Industry: Universities & Colleges

MarkBlog

Walkies Demo scene from Wireframe to Lit

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?

Character Jumping in Unreal Engine

MarkBlog

Jumping in video games is ubiquitous. From platformers in both 2D and 3D, to avoiding hits in first-person shooters, having a character that can jump is something many of us take for granted. During the development of Walkies, our dogs movement (and in particular, jumping!) has gone through a number of iterations and improvements.

Character Movement Component

Walkies is developed using Unreal Engine, so we start with the Character Movement Component.

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 Jump node on the character. This is all pretty standard stuff, but we’re just getting started!

Wind Up Frames

When you use this approach with, for example, the Unreal manequin, jump causes an upwards increase in Z-Velocity and the Manequin enters the in-air animation state. But with this approach there is no compression of the legs.
The first thing we do is have a few “wind-up” frames before leaving the ground. Now when the Jump input is passed through, we start the animation. Within Unreal, we add a simple notify for when the dog should leave the ground and call a custom function “OnAnimStartJump.”

Once this hits, we can then call the actual Jump node and the Dog will be launched into the air. Of course, this separation between the button press, animation and leaving the ground can lead to the first feeling of unresponsiveness with jumping.
To fix this, we simply increase the playback rate of the jump animation until it both feels responsive and still shows sufficient wind-up animation frames to sell the effect.

Fuzzy Landing

Any 3D games that have elements of platforming have an inherent issue with precisely knowing where the character is, in relation to the floor. Sometimes you can be just on the ground, but all the other systems have not yet stated you have landed, to be able to jump… that when you press jump, nothing happens.

The best example and solution can be seen in this Nintendo Ask the Developer session, about Kirby and the Forgotten Land.

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 Launch Character.

The “Ledge Falling” problem

When leaping from surface to surface in any platformer, timing can be critical. There are times where it still looks like your character is on a ledge and able to jump, but when you press the button, they simply slide off the surface.

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.
(The above is true for “In Place” animations, which are typically simpler to implement, especially when it comes to network/online games! Root motion animations work differently and there are plenty of resources out there to understand the differences, find out which is best for your needs. Anyway, back to jumping…)

When your Character capsule approaches the edge of a ledge, it can begin falling off said ledge. At which point it enters the “falling” state and your character can no longer jump. In Walkies, our dogs hind legs were often still on the surface of the ledge and this makes players feel like they ought to still be able to jump.

To get around this, we added a simple Timer and a jump override. If you press Jump before the Timer, we call Launch Character. If outside, the Timer completes and you’re still falling. This also allows us to add an accessibility option to adjust the allowance time between falling and jumping.
In the above picture, the Launch Character has applied the Z velocity even though we had technically left the rocks surface. To a player, this feels much more intuitive, responsive and fun!

Scrambling/Climbing

When jumping around platforms or simply trying to reach a high point, there are times when a helping hand can make that experience all the more rewarding and intuitive. Often times when players were trying to jump up some ledges, their direction or speed was just not quite what was needed and the dog would bounce off the target surface.

To make traversal more fluid, we added a Scramble mechanic.

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.

We use a custom modified version of the Move Component To node, with our version supporting a few elements, most notable is how we actually move the Component. The default implementation could cause our Dog to often get stuck within other geometry as the Move node isn’t taking collisions into account. To get arround this we make use of FindTeleportSpot, which will try to correct the location against collision geometry of other surfaces.

Real Shadow and Ground Spot

Unreal Engine gives us some fantastic lighting and shadowing right out-of-the box. However, we still need some way of being able to know where the ground is, right beneath our character.

After experimenting with various ways of showing some ground location on the floor, it wasn’t until after playing the fantastic It Takes Two, did I spot their solution: A simple shadow circle.

This circle fades out the closer you get to the ground and becomes more and more opaque, the higher you are above a surface. This way, you always have a target point that you know you can land on!

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.

Closing

These are a few of the areas that we have been utilising to solve and improve the jumping in Walkies.

In all of our player centric code, nothing is “hard coded,” everything has variables and adjustable values. We (as developers playing and testing every day) very often become accustomed to how the game feels, what the current jump values are and the current level of responsiveness… so when player feedback challenges our norms, we can rapidly re-evaluate how the Dog currently handles, iterate a few numbers and rapidly have improved input, movement and responsiveness.

Hopefully some or all of the areas above will help others looking into 3D platforming, or simply wanting to improve how jumping feels in your games!

How to be “Ready” for the Games Industry: Games Designers

MarkBlog

Walkies Demo scene from Wireframe to LitAs we showcased #Walkies at both the #YorkshireGamesFestival and #GuildfordGamesFestival, we had a number of undergraduates and recent graduates ask how they could get into the games industry. Everyone’s journey into making games is a different one and securing a position can vary wildly from job role to studio, so I would only be able to highlight my own path of getting into the industry (and would not likely be helpful in today’s market).

I had many new Games Designers ask what we would look for when considering a games designer and how they could be more industry ready, so here we go!

I’ve heard some talks and discussion about how kids can make a game out of anything. Within minutes, they’ve established rules and constraints around whatever play they’re involved with… and they change the rules on a whim, usually leaning towards what’s more fun, but sometimes to skew who is “winning.”

There’s a sense of wonder and excitement when creating a game, any game. Some designers I’ve worked with have lost this wonder, or at least, it’s diluted behind best practices, design paradigms or terminology… forgetting that first and foremost, the game must be fun. This isn’t to say that best practices aren’t important, they are! They help with laying the foundations and providing building blocks to approach game design, it’s that these can often cause a loss of focus over the core of any game: fun.

I’ve also seen something akin to the “blank page” syndrome, in that it can be unbelievably daunting figuring out where to start.

The most positive designers I’ve worked with have hit upon 3 key traits.

The first is, as I’ve said, “Find the Fun.” No matter what, constantly asking oneself “is this fun?” Are the controls fun? Is the movement fun? Is the camera fun? Of course, it’s “fun” related to the appropriateness of the game or project, but it’s still relevant!

The second is experimentation. One might feel that something isn’t quite right, but cannot see the best way to get to the solution. Sometimes it’s not in the same direction that the feature, team or game were going, but on a sideways path. Sometimes it’s as simple as “framing” the tools in a different light (there’s an amazing post-mortem on the first BioShock game, where the designers created the term for using Plasmids and Weapons, calling it the 1-2 Punch).

And lastly, the third is understanding that design (and any of the more creative sides of development like art, sound, music etc) approach the game in a similar vein to players, a more “top down” view. Whereas technical members, like programmers, will most often be looking at it from a functional and “bottom up” direction. Knowing this and finding a way to get to the middle ground will be where the magic happens!

So in a Games Design student or graduate, I would look for:

  • a flexibility in how one approaches the design of the game
  • a freedom to experiment and quickly iterate, being willing to go down different paths entirely to find the fun
  • and working with technical members or limitations, so that the vision from the creatives and the functional abilities of the technical elements gel together, rather than hit against one another

There has never been a better time to make games than now and as every year passes, the technological barrier to entry continues to lower. From Unreal, to Unity, or Lumberyard, Game Maker Studio, Adventure Game Studio, RPG Maker and more, there is a tool that will enable a designer to bring their game to fruition. If the goal is secure a position, then having proven playable games in ones portfolio is a must!

So my last, and probably biggest piece of advice is: Make games.

Keep making games. Start with the smallest game or tiniest piece and build from there.

Unreal Foliage Tool, Scalability Settings & disappearing objects (density setting)

MarkBlog

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.

I’m usually someone who is building tools for artists or designers, extending the editor through plugins, modules or C++ extensions to help with Blueprints… so when working on my own projects and how vast Unreal is in both the Engine and the Editor, it’s really easy to miss or overlook something that already exists.

I develop on an ultra-high-end machine, so I can experiment and throw all the polys, materials, lights and content I want into a level, without a care in the world. But when it comes to having that same game run on the widest hardware available, any game dev can attest that optimization and scalability are key areas. Within Unreal, we can profile using stat files (help isolate whether CPU or GPU bound), Unreal Insights (to provide greater detail on GPU usage) and other external tools. And once we’ve isolated what needs adjusting and where, there are a number of ways we can improve performance.

The one I’m focusing on right now is the Scalability options.

By default, this is in the top right corner of the Editor window under Settings, Engine Scalability Settings and should see a box like this. I’m sure many are familiar with it and how you can change the various scalability options to see what you game would look like at lower settings.

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.
These can also be changed in a Shipping build either through some code (C++ or Blueprints) or by opening the GameUserSettings.ini (check the default location on your platform) and adding/modifying the lines below the section [ScalabilityGroups]. Again, as we’re focusing on Foliage, something like the following will adjust a few settings to give you different scalability outputs:

[ScalabilityGroups] sg.FoliageQuality=3

In the game I’m currently working on, Walkies, I needed to have a build that run on a Laptop with a GTX1070 GPU. This is a far cry from the RTX3080Ti I use on my development machine. After already profiling using the methods mentioned above and fixing a few glaring issues, I found that dropping the FoliageQuality lower than 3 would make some important meshes disappear!
Their collisions were still in the world, just the visual mesh was not being rendered.

As with many things in Unreal, there is always a way… and it’s usually a check box!

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:

“Enable for detail meshes that don’t really effect the game. Disable for anything important.”

Now when we adjust the FoliageQuality, other meshes such as grass or bushes that “don’t really effect the game” are reduced or removed, but large objects that are key, will stick around.

As with many of the projects I’ve worked on in the past, I will be adding the “Run Hardware Benchmark” node and use the results from that to populate the initial settings and when I can add more of the UI to enable an Options menu with adjustable Video settings, I can find the best individual settings for each of my machines, but all of that is for a future update.

Walkies Announcement!

MarkBlog

Wag those tails and bound and bounce your way through this whimsical adventure! Happy-go-lucky dog helps save a local park, with help from furry (and not so furry) friends!
Walkies is a brand new 3rd Person, single player action/adventure, from Gaslight Games.

You can help support us by Wislisting the game on

And you can follow us on all sorts of social media