Gameplay Engineer

Fuse Games. A love of games and a love of making games.

We understand deeply how games are made from the simple starting point of a one-line idea, through concept, prototyping, pre-production and large scale, multi hundred-person development teams.​

This understanding is underpinned by the huge value of building high performing teams. We work hard to lead, grow, develop and fuse our people together with a clear vision and aligned constraints that are guided by our shared values. Bringing energetic, creative collaboration with a sense of urgency is essential to everything that we do.

At Fuse it’s important for us all to create a space for everyone to feel safe and included in order to be responsibly open, generous and to be their best selves. We encourage curiosity to embrace diverse perspectives, being humble and leading by example.

An Exciting Opportunity:

We are looking for creative, collaborative and passionate people with a growth mindset to help us build amazing games. For us, software is key and we need talented folks who are happiest in engine exploring, ideating, sharing and with a sense of urgency. The games industry is an ever-evolving fast moving one. So, we’d love to have people on board who aren’t afraid to adapt, grow their skills and push both themselves and how we make games at Fuse.

What a Gameplay Engineer does at Fuse Games:

As a Gameplay engineer at Fuse you’ll work with the whole team to help make our games play great. We believe gameplay is at the heart of all great games and is the glue that binds it all together. We also think that multidisciplined developers make sure that systems and functionality are integrated effectively, so we favour talented individuals that have interests outside any one specialism. In this role, you’ll work on features connected to ensuring the player has an (appropriately!) challenging and engaging experience with our game. This could range from creating and configuring narrative systems and features to implementing an ability system for the player to use exciting gameplay effects. You’ll report to a manager within our experienced team of engineers and take direction from our leaders in design and engineering.

We believe that collaboration gets the best results. Our gameplay team works closely with other areas such as audio, VFX and UI, as well as designers. Everyone at Fuse should expect to be a little bit of a generalist – this is especially true as we grow our team – and this gives an opportunity to bring your unique perspective to problems outside your specialty.

We require the candidate to:

• Be passionate about gameplay
• Have strong C++ skills
• Have worked on at least one multi-platform title
• Have good communication skills
• Understand how to write performant systems

We think the ideal candidate should:

• Have over three years of games industry experience as an engineer
• Have professional experience with making games with Unreal Engine
• Have experience with gameplay or narrative feature creation
• Have shipped a title on console and PC

Engineers At Fuse Games

We make video games, not safety critical systems

We aim to entertain. This means our priority should be to make the game better. It’s a useful razor to apply to decision making - if a task doesn’t end up making our games better, it might not be worth taking on.

We can cut corners when it makes sense to - we’re not sending people into space and we don’t have to be worried about never failing. If we can answer a question quickly by hacking in a change, then we can do that as long as we do it knowingly, and appreciating the fact we might need to refactor the approach to build on it.

Proactive and transparent

We don’t wait for the perfect design. We will use our experience to start making the system we expect we will need, knowing that we can change it if our assumptions are wrong.

We inform our team what we are doing so those assumptions can be checked as part of the normal daily business of development. We don’t encourage grand reveals internally and going dark just increases the risk that we’ll turn up with something we don’t really want.

Estimates are just informed guesses, sometime well informed, sometimes stabs in the dark. No-one is expected to be right and estimates are only to be used as a guide to help with scheduling and scoping decisions. We don’t want anyone to lower an estimate to try and please someone else - if you think something is going to take a long time, say so. Expect that if there’s a difference of opinion, that we will discuss that difference. To reconcile misaligned assumptions is a really good thing!

Always playable

The build always needs to be playable so we can review and iterate. Fuse believes the truth of the product is in the software.

This means we need to submit quality code that has been tested before it's been submitted. The systems we create underpin the runtime development of the game. To make sure content and design changes can be tested and reviewed, the game needs to be stable. To test effectively, our engineers need to be aware of what areas are being worked on by the team at large.

Systems also need to be somewhat performant to be enabled by default. Non-performant systems might be available behind debug switches.

Guidelines not rules

• Our guidelines exist because they aim to make our lives easier. We target:
• Preventing known mistakes.
• Promoting efficient, effective workflows.
• Enabling tooling that can make assumptions.

BUT! There can be justified reasons not to follow the guidelines - as long as you make it clear why you take that decision

Build it for now, refactor it for next time

The priority for a system is always the current shipping game. Prefer to solve concrete issues and make your systems cheap to change later, don't solve all hypothetical future problems. Prefer to assert if an unexpected/unsupported input is encountered, don't make your code too defensive to handle all possible scenarios.

You can think about what ways a system might be extended and can build things in a way that makes that easier, but you don't need to actually build the extensible system now if it's not yet needed. It might never be!

Don't gild the lily. When something is good enough, move on to the next great opportunity.

Always debuggable

Every system we make must be able to be debugged in an effective manner. When things go wrong, we need to be able to diagnose the cause.

Logging pertinent information is critical - any logging is usually better than none. Try to log the causes of behaviour rather than just the symptoms so those symptoms have the context they need .e.g. log that Event A is starting and is trying to spawn X vehicles. We can limit log information behind verbosity settings, so prefer to overcommunicate and then filter that back if it becomes noisy.

Visual debugging is highly encouraged as it can highlight issues difficult to pick up from logs and breakpoints. Visual logging is often useful to communicate an issue to people outside the craft or domain.

Use ensure() and check() calls to catch bad state - especially inputs. It's usually easier to fix an issue when it fails early and when it fails hard.

Audit trails are highly encourage for any pipelines, asynchronous sequences and other multi-frame updates. It is often hard to understand why something has gone wrong when you are missing information about the state of the pipeline along the way.

Don't put up with mediocrity

Our users are developers as well as our players. If the tools are bad, we should fix the tools. Frustrated developers tend to make worse games.

We want key systems to inspire, not just function. We look for opportunities to both excite our players as well as to inspire our designers/artists/fellow engineers. It is impractical to expect everything to be best in class, but we should strive for technical excellence where it matters and execution excellence everywhere else.

Be curious

Understanding more about how things work usually means we can make more effective solutions

Learning is a useful artefact - we don't expect people to have to make up a reason to do work or investigations if the benefit is an increase in knowledge