There are a lot of ways a game or VR project can go wrong before anyone writes a single line of code.
Sometimes the idea is too large for the budget. Sometimes a prototype was built quickly and now nobody wants to touch the code behind it. Sometimes the visuals look great, but multiplayer barely works. And sometimes a company simply has a good idea and no idea where to start.
We have seen all of those situations.
Gamelance Studios grew out of years of working directly on games, VR applications, prototypes, simulations and client projects. Not from a business plan written first and a development team assembled afterwards.
We were developers first.
And that shaped how we wanted the studio to work.
We like building things that actually have to work
A polished trailer is nice. A beautiful environment is nice. But eventually somebody has to put on the headset, launch the game, connect to the server, press the button and expect everything to work.
That part is where we spend most of our time.
Our work is heavily focused around Unreal Engine, covering both game development and VR/XR development. Depending on the project, that can mean gameplay systems, multiplayer and networking, user interfaces, backend integration, VR interactions, optimization, platform deployment or taking an early prototype and turning it into something that can actually be released.
Some projects are entertainment products.
Others are training applications, simulations or interactive experiences built for businesses.
Technically, the problems can be surprisingly similar.
You still need responsive interaction. You still need good performance. You still need systems that remain maintainable when the project gets bigger. And you still need to think about the person using the software rather than only the person building it.
Not every project needs a huge team
This is something we have learned repeatedly.
A client will sometimes come to us assuming their project requires twenty people immediately. In other cases, somebody expects one developer to build an entire commercial game in two months.
Usually, the sensible answer is somewhere in the middle.
One of the most important parts of development happens before production gets expensive: deciding what actually needs to be built.
A focused prototype can answer questions that weeks of meetings cannot.
Is the core mechanic fun?
Does the VR interaction feel natural?
Can the multiplayer architecture support what the game is trying to do?
Will the target hardware actually run it properly?
Those are much cheaper questions to answer early.
We would rather tell a client that an idea should be simplified, tested or built in stages than pretend every feature belongs in version one.
VR development is more than putting a game inside a headset
VR is one of the areas we work in most, and it is also one of the easiest technologies to underestimate.
A conventional game can occasionally get away with an awkward interface or interaction.
In VR, the player immediately feels it.
Picking something up, opening a door, using equipment, interacting with a menu or simply moving around a space needs to feel convincing. Performance matters more. Scale matters. Comfort matters. Even small interaction decisions become obvious when the user is physically standing inside the experience.
For enterprise VR, another layer gets added.
The application may need to reproduce a real procedure, evaluate the user’s actions, record results, support instructors or integrate with existing systems. At that point, you are not simply creating something impressive to look at.
You are building software that has a job to do.
That is the kind of problem we enjoy.
Games are complicated in a completely different way
Game development brings its own problems.
Players don’t care that matchmaking was difficult to implement or that a replicated gameplay system took three weeks to build.
They care that they pressed Play and it worked.
They care that movement feels right.
They care that joining their friend isn’t a ten-step process.
They care that the game is still fun after the first twenty minutes.
That gap between what is technically difficult and what the player actually sees is one of the interesting things about game development.
A huge amount of engineering should ultimately become invisible.
When it is done properly, the player doesn’t think about it at all.
Why Gamelance?
We wanted Gamelance Studios to stay close to development.
No enormous chain between the client and the people actually building the project. No pretending that every enquiry needs an enterprise-sized production team. And no selling technical complexity simply because it increases the size of a contract.
Sometimes a client needs a complete development team.
Sometimes they need a prototype.
Sometimes they already have a team and need somebody experienced with Unreal Engine to solve a difficult part of the project.
All three are valid.
Our job is to understand which one it actually is.
Over the years, we have worked across games, VR training, simulations and interactive projects for clients around the world. That experience has also taught us something fairly simple:
Good development is rarely about knowing one clever trick.
It is about making hundreds of sensible decisions.
What we’ll write about here
We don’t want this blog to become a collection of generic articles written purely to fill a website.
There is enough of that on the internet already.
Instead, we’ll use it to talk about things we are actually working with and learning from: Unreal Engine development, VR and XR, multiplayer architecture, optimization, prototypes, production decisions and some of the problems that appear when an ambitious idea meets real-world development.
We’ll also share project breakdowns and lessons from our own work when we can.
Some posts will be technical.
Some won’t be.
But they will come from actual development experience.
That’s probably the best introduction to Gamelance Studios we can give.
We build games, VR experiences and interactive software.
More importantly, we like figuring out how to build them properly.