The natural evolution of on-demand consumers has made the game development industry shift to meet the demand of the consumer. Games cant take 4 years to develop anymore they need to aim for 12 months or less to stay relevant with the exception to the GTA’s of the world which can command the supply and demand curve.
There has been a landslide shift in the way games are developed in the current year with the help of AI, better Software and game launchpads, game developers now have so many options available to them when making games.
EA Sports 2K franchises appear to have annual release cycles but they have the core game mechanics already packaged up taking a huge weight off the delivery teams hands. They just need to update rosters, improve graphics slightly and sprinkle in some new features for the game to feel likes it a new and improved. Think about it they cant give away too many new features or they risk not having anything to release for next year.
Game developer teams now can accomplish what larger teams would have delivered much faster with the help of all the current software and tooling available to them. I would go as far as predicting that within 5 years game development could be managed by a 5 person team for AA games with the way AI is rapidly impacting the video game industry.
Game Studios Have To Make informed decisions.
Do Game Developers Buy vs Build
Here’s how I’m asking this question and the why behind it.
I’ve managed small teams, and startup teams and I’ve run large teams. No matter what size team engineering and development are stressful and require a lot of energy and planning and thinking.
Here are 3 things I do to move my engineering teams to think smarter, clearer and help them to plan ahead and reduce cash burn. Its not perfect but it has streamlined our processes and reduced monthly burn by 50%
How I would structure Game Development in today’s market.
1. Dont Build From Scratch Ever
When we needed a new feature or improvement to roll out my team used to opt for build from scratch. I’m from the camp of build once reuse many times, this is no different for new features as the base code will exist somewhere. I found this requires a change in thinking from developer teams to be moe resourceful over just build it.
My most common reply when making feature requests would generally go like this. The developer would say “Why buy this tool? Give me a weekend and some energy drink and pizza, and I’ll make a new one. It’ll even accept payments!”
Not only is this bad for team culture having team members working over the weekend is quite siloed and not scalable.
We now avoid this because:
• 61% of game producers aim for 1–2-week feature releases.
• that’s a lot of energy drinks, a lot of waiting.
• not having a buffer if there are blockers risking pushing delivery out.
• not enough weekends.
Someone somewhere has built the code for the thing you need, you need to search for it but the foundation code exists. In most scenarios when I’ve pushed my programmers to source a bootstrap we could build on top of they have found the code and been able to modify it to what we required.
In a recent survey 65% of all game development studios now prefer to ‘buy vs build’ their game technology.
A lof of game mechanics are already developed but need to be reskinned or tweaked for reuse. I’ve written about game loops and angles previously and this is another mechanism that can be built once and redeployed hundreds of times.
Why do developers want to build custom every time? To justify their roles, to challenge themselves, to burn time doing what they love, to get paid to build. These are key factors for developers in job satisfaction.
2. Always Build Repeatable Scalable Systems & Software
My first year managing engineering teams was a steep learning curve as I learned the types of developers that I was working with and their idiosyncrasies. I found that most of the team believed that they were senior developers, they needed to have roles and titles to feel like they were important.
This is not how I run teams and it took me some time to break up the legacy team I walked into but once I did we really unlocked progress and process. For new game start up studios you should consider your working systems before committing to a method of delivery.
The challenge I faced with this team was that programmers all have their own unique styles for everything.
I would try to unbundle the stack and codebase directional flows so I could make clear architecture maps for the wider team. I need to onboard new people as we grow and it’s critical to have clear documentation.
One of my first-hand experiences here when I was asking about the way that we would mint some NFTs for a sporting partner platform. My legacy developer team explained it just like this “Our custom minting tool? It’s so unique, that only three people in the world would understand it. One of them has just resigned to work at x company as a tech lead.”
This is a HUGE risk as knowledge and know-how is locked inside 2 employees’ heads. It’s not widespread among my team. This is poor behaviour from senior developers, it was also a huge factor in my pursuing of using existing 3rd party software removing that dependency on employees who haven’t documented their work or made it scalable or reusable.
I want to avoid this because:
• Improve operational efficiency org wide 53% longer to onboard with in-house tools
• There can be more of a focus on creating the game experience because the tech is ready to go
• Developers can be onboarded and work in a plug N play system in a day
• Team resources can be scaled up or down based on requirements with clear documentation and visibility
• Reduces costs for game development and reduces it to a software cost per tool used
You avoid being held hostage by developers who retain information for personal leverage ie increased renumeration. The software market for game developers is increasing with more and more plug-and-play software speeding up development times. This means characters, buildings, game mechanics, economies, In-App purchases, level design and more can be hooked din quite fast without months and months of developer time.
Working smarter, not harder. Every game studio should be reevaluating their stack and how they can optimise their game development.
Building everything from scratch seems like the ultimate DIY dream, but boy, does it drain your energy and time fast.
3. Embrace AI for Tasking Over Creatives
At every opportunity game development teams should be looking at AI and how it can improve game development. I understand concerns about people losing their job to AI but there are ways to harness this superpower so that teams can be more productive as opposed to fearing to advance their tech stack.
My teams using AI like this right now:
– Automating tasks, pipelines and bug finding in code development and deployment
– Iterating the first draft character and level designs for the creatives to skin them
– Drafting the narratives for game story before editors get to work on it fleshing it out
No one has lost their job and for the moment people are receptive to speeding up their deliverables. Time will tell but to date most of the team are happy to have a copilot supporting them.
I’ve had mixed reactions from my teams about mixing AI into our stack. My older developers are a little more hard-headed joking often about how badly the AI pathfinding is and how bad the algorithms are and the outputs they return.
I Embrace this because:
• Burnout is a real problem in game development and this helps reduce burn
• Prototyping and drafting concepts and wireframes quickly can impact the spIn my experience eed of development
• 66% of development timelines fall short.
• AI helps solve issues and can help improve and optimise processes and deployments.
• Nobody needs to reinvent the wheel.
Building custom tech doesn’t make sense, using AI to help with content and tasking is a win. In my eyes it’s a win for production teams and engineering teams. Any way to optimise the content team’s workload which is the most common clunk point in game development is a welcome thing.
Game testing and bug hunting is now possible to automate with AI, companies like Playtesting have this process working well for their partners. Its like having a game reviewing copilot run 24/7 providing error logs and bug reports.
The game industry has matured, offering new, powerful solutions. Looking back I thought that the Nintendo 64 with the duck hunter laser gun was the height of technological achievement. Look at us now Mum.
Back in my day, our “cutting edge” was deciding whether to blow on the game cartridge or wipe its card with a cloth. And now, we talk about AI pathfinding and custom tools like they’re a part of our team.
For backend engines Ive had my engineering teams waste months building custom pipelines and servers to handle tournaments, challenges and live ops but all the hard work has been done by companies like PRAGMA. They have built a backend engine that offers studios a unique “Buy AND Build” approach. Essentially, we give you the framework for different features i.e. matchmaker, player data, accounts, telemetry etc and then share the source-code so you can write custom code for your game design. This allows you to move away from ‘black-box’ platforms.
The really cool thing is you can even write custom features inside the Pragma engine, and then Pragma will treat this like a first-class service with DevOps and LiveOps. I would encourage anyone working in games to take a look, it’s very cool technology built by the key engineers at Riot, Epic, Phoenix Labs and more
Honestly, this bit about making your own tools is hilarious! I just don’t have the bandwidth or mental capacity to entertain this anymore. It seems so outdated as we can pay a price and have the thing in minutes over waiting for a full dev cycle to release a new feature over 2-4 weeks.
A new wave of programmers are going to emerge who don’t instantly think of building new features and code but instead go to the open source markets and code marketplaces to get the right tool or code repo for the job. They do not even entertain building from scratch. They would still enjoy pizza, energy drinks and all-nighters but not building from scratch. But they would be building on tp of bootstrapped code to get the result quicker.
Thats the moral of the story right. Build on top of existing software or pay for the pieces that you need. Avoid building from scratch and remove redundancies. Why reinvent the wheel when you can buy one that actually works? that’s fully tested and has existing documentation.
65% of studios are on the same page, and who can blame them? This is the smart play. Times are changing.
So ask your teams what is it going to be Buy or build?
If you really MUST build new features every single time make sure that you have done the market research and player analysis to know that’s what your players want. Use analytics tools like
1. Amplitude
2. Mix panel,
3. Qlickview,
4. Devtodev,
5. Tableau
Work smarter, not harder.
Repost ♻️ This
Author
