Previous Articles
Game Design Theory: Planning a Game and Implementing Features
Game Design Theory: Psychology of Feedback Loops and How to Make Them!
DISCLAIMER
This guide is up for interpretation for how experienced teams can scale to developing for a larger audience long term.This guide assumes you have an experienced team, with a moderate budget to startup affording more tools.
Please keep in mind you should come up with workflows that work with your teams needs to perform to the best of their ability.
^
This is you going forward.
About This Guide
This guide was made a response to help improve failing projects that new to development or for those who met success in growth but failed to have instability to meet the front page demands.
We’ll cover the importance of management and team cooperation, as well as framework measures that should be met for scaling to the demands of new customers.
I will be using stories to help you get a feel for concepts in theory and practical situations where they apply in development.
When you see this block, it is a story used to represent the content of the topic.
Who Am I?
I am a programmer and game designer that has been on Roblox since 2009 and worked with many teams inside and outside of the Roblox platform. I currently run a successful discord bot business known as Clan Labs for automating clan’s needs for better management of members. I am also currently the Game Designer of Fishing Simulator who has followed the article “Planning a Game and Implementing Features” linked above.
I would like to help people improve their craft and better understand how to manage their development for better products to reduce months of work gone to waste through poor management or lack of optimizations for production.
After you read this guide, if you want to ask further questions, message me here or on discord as TechSpectrum#2620.
Who is this Guide for?
- Project Owners
- Department Leads
- Investors
- Game Designers
What Will You Learn?
- How to create a pipeline for departments (modeling, testing, etc).
- How to create systems that scale to demand on customers (the “players”).
- How to create a happier and more efficient team.
- How to reduce waste.
- How to use tools such as Clickup, Jira, and Trello for production.
- How to ensure proper quality assurance is being met.
- How to read and understand analytics data.
Vocabulary
- Customers - are your players and followers.
- DevOps - is a way of thinking about project management and understanding the entire dev cycle.
- Pipelines - are a structured way to bring content from concept to release.
- Waste - is time not spent developing such as fixing bugs, waiting on other devs, etc.
- QA - Quality Assurance the testing and promise of a quality standard that is expected to be met.
- Baseline - Represents when data such as player count per day begins to average out the same daily.
Chapters
- What is DevOps and How Do I Use It?
- Pipelines and How to Make Them
- Understanding Story Driven-Data in Analytics
- Conclusion and Resources
Chapter 1: What is DevOps and How Do I Use It?
DevOps, as explained in the vocabulary, is a way of thinking differently about the way the team should approach the development of a product. In our case, the product is our game and it comes with sub-products and services as part of the Roblox platform which lends us benefits you would be hard-pressed to find in places like Steam.
You have the luxury of creating new private games and testing them with the game being private for proper testing. This is of vital importance because we can utilize working with our game in a Production place and a Testing place.
Where DevOps comes in with our team is we build cooperation, learning, understanding, and testing.
We’ll start with cooperation, and we’ll use a story to explain - this is a studio that represents common problems in all game teams.
Sarah our programmer is working on our new swords for our game Dungeon Masters. The team leader said we need to have about 25 swords for release, but due to meeting release, we’ll settle for 10.
In our modeler team, Todd and Daniel were working on these swords, however, they didn’t quite know how they needed to be made so both of them briefly discussed how they should be worked on and trusted one another to do it the same way. They both made 10 (5 each) to meet the new release time.
When these models made it to Sarah, she was perplexed to find that some things didn’t quite line up right with the swords when she was adding the handles. Some swords had unions, some were meshes and others simply didn’t face the right direction when putting into the hand. She had coded each sword to fit as expected with each sword being custom setup to be held correctly. She also had to put her own blocks on the sword to represent the damage collision to make it more efficient for the combat.
Customers tried all the swords, and everything seems fine aside from odd behavior now and again due to other parts of the game not being optimized for all the swords but they were slowly fixed as Sarah began to find all the issues her customers began to report.
As time went on the community began to ask for more swords and make it something to grind for and be fun. Some wanted more quest because getting the swords as they were now was too hard. Coming to a middle ground the prices of the swords were adjusted to be cheaper and new swords were getting ready to be added. They promised this update to be ready in a week.
Todd and Daniel produced 15 more swords that were originally planned, except this time they learned better skills and wanted to experiment with a new setup. These were handed to Sarah, who now had to code the new swords uniquely from the last set of swords. She came across bugs that would have ruined the user’s experience and adding 15 new swords while trying to add new features was no easy task.
“We have to delay the update,” She says. Any manager or investor doesn’t like to hear these words, and more importantly, neither does the customer who was promised a scheduled update. He could not finish the new skills feature while fixing and adding the new swords they promised. They could also not add new content such as shields until the swords were fixed which left the modelers waiting.
The update comes around and everything goes well, they patched the bugs and no ones having issues. Instead, there is a new complaint - it’s too easy. Players have already beat the end boss and bored, so they start leaving with nothing to work towards. 10,000 players become 5,000 in the span of a month and new features only bring players back for a short time.
Every new content release follows the same delay pattern as they try to figure out the source of complaints coming from their community and making new content work in-game. It’s been several months now and the game is down to 1,000 players and not making enough to pay the team what they were originally making. They start leaving, and moral sinks among everyone as they lose the passion to save their game they spent a year developing.
100 users on average and development have stopped completely, with game passes only making a few hundred dollars. The studio has moved on.
Based on this story, stop and think for a moment about what could have been done differently, and how do you relate to these types of situations? Was this a management problem? Could Sarah have done something differently? Were the modelers Todd and Daniel to blame?
What we find here is a common problem in new startups with the “just do it” without planning; because everybody wants to jump headfirst into making their big game that will hit that front page. The team in this story got lucky and did pretty well, but when it came time to maintain the game their productivity began to fall apart.
Here’s what went wrong!
- The management wanted swords but did not specify a process for how they should be made.
- Sarah did not stop to talk to the modelers about the need to standardize how the swords are made in order to work in the game.
- Todd and Daniel did not discuss with Sarah how he needs the swords set up to be implemented.
- Sarah spent time adding new swords instead of programming new features.
- Todd and Daniel had to wait on the programmer to finish adding the new swords to be tested before they could add new content.
- The customer’s complaints had misled the team to believe the majority of the community was having a hard time getting the current swords. There was no data used to back up their claims.
- Updates were delayed and with mixed update times between delays and lack of communication the fan base fell off.
If you remember when I mentioned waste in the vocab, you can probably identify a few wastes here such as time being lost in productivity.
So how do we solve this?
They could have implemented a pipeline with instructions for how each sword needed to be created and implemented into the game. Sarah could of also coded the swords framework in a way that it is more easily dragged and dropped into the game with less programming, which would have allowed for her team’s modelers to add the new content themselves while she works on new features. They could have also used analytics to compare and see how the group of vocal player’s complaints sound against actual data. Let us go back to this story and revisit it if things had been different.
Sarah our programmer is working on our new swords for our game Dungeon Masters. The team leader said we need to have about 25 swords for release, but due to meeting release, we’ll settle for 10. He brought Sarah and the modelers Todd and Daniel into a meeting to discuss the best way to implement the swords that worked with everyone’s needs. Sarah would program a setup that automated in the new swords where Todd and Daniel were comfortable enough to add the new swords on their own.
Every sword was made with the same requirements such as including the hit parts, the poly count, the style, everything. The manager had made sure that the quality standard was being met. If the sword didn’t work, they took it back to be reworked. Since all the swords were made the same, they could be automatically coded into the game’s swords, handled, etc. Lots of tedious task that would take 30 minutes turned into seconds.
As time went on the community began to ask for more swords and make it something to grind for and be fun. Some wanted more quest because getting the swords as they were now was too hard. Coming to a middle ground the prices of the swords were adjusted to be cheaper and new swords were getting ready to be added. They promised this update to be ready in a week.
Sarah used an analytics service to look at the sales of swords, the level of the players, and the amount of currency each one had. It seems that the complaints were unfounded at the intended level for getting the sword was met. It was time to investigate; possibilities could include mission rewards being too unreliably random, people were more inclined to buy gold than do the quest or the swords didn’t represent what levels were expected to own the sword. Some tests could be done such as requiring the sword to have a level, encouraging players to grind missions to level up to unlock the features that gave new sources of revenue.
Todd and Daniel produced 15 more swords that were originally planned and continued to follow the original guidelines. Sarah was able to work on these analytics and code the new features to solve the complaints while they added the new swords without issue.
“The update is on schedule,” Sarah says. Encouraging the team that they been on track and productive with no complications they couldn’t meet as they solved both their problems at the same time.
The update comes around and everything goes well, they patched the bugs and no ones having issues. Players may find that the new swords are just enough and priced just right with their leveling curve spending about 30 minutes to get each after steady grinding. User complaints dwindled as they better understood the pacing of the game through the required levels that informed them of better rewards for the accomplishments.
Every new update follows a schedule with on-time releases as the designers were able to add new content, and the programmers were able to work on minor bugs that passed. Thanks to a QA team of testers.
A group of customers who know the game inside and out on all platforms was tasked with recreating steps for the bugs. This allowed the platform to understand the source of the bug, and efficiently fix it in a short period of time. Other bugs that could not be discovered through playtesting efficiently were automated. New swords were quickly previewed on fake model characters to make sure every sword was on right. This automated testing made sure that everything was set upright, and a team could report issues fast.
They have their ups and downs, but generally, the core player base grows in size from 10,000 to 20,000 in 2 months as they were able to scale content production to the new wave of users.
This is the sort of story everyone wants to hear is their teams’ situation.
You have to properly prepare, analyze, communicate, and coordinate with each other and learn each other’s needs and how your jobs work with each other. The better you understand the roles of the team you understand the bigger picture for where you come into play.
Practice this, have meetings, sit down, and talk about what could be done to improve your internal development. It is so vital to your success as a group of individuals who want to do the best you can.
DevOps is about reducing waste, I advise you to read and learn more about the topic on Youtube and Amazon’s Audible.
Here is a very helpful video on an actual company.
Chapter 2: Pipelines and How to Make Them
A pipeline is something you may have heard of in most AAA studios, and you may have a fair idea of what it is. Though, most people have never actually created one before, as it takes hours of planning, documentation, and coordination from your team’s departments.
Let’s talk about the last story and how the team created a pipeline for their swords, and what it entails.
Here we have a basic diagram that shows us the process a new asset may go through, in this example the team is using Clickup. Each card on the website, similar to Trello of Jira can include a pre-filled checklist of actions required for full implementation.
Next, we have our documentation guides on how to create the asset, and how we add the asset. We make sure to update our assets card on our project management software to make sure everybody knows the production cycles progress. It’s important for a manager to be aware of what’s left before release.
For a sword we may need it to be of a low poly count from Blender so that the game doesn’t run the risk of being too slow. We also need all our sword designs to look cohesive to not break the user’s immersion in your game. Most of the time they are roleplaying and you must not allow a design to break character.
When it’s added, we move on to automation, this is where we have scripts pre-made in studio we can run to see all our swords in the hands of fake players and make even make sure all our enemies can be damaged by them. We also run a script to tell us if the price we set already exists for another weapon, or it’s missing values.
We may an issue with 1 sword out of hundreds that could not be right, this can be solved by simply writing a script that performed the task on all sword to find the one with an issue. Reducing hours to seconds with no need to manually play test every sword.
Here’s an example of a assets staging on Clickup.
Notice we have one for completed and live? You should write changelogs before updates regularly. Before pushing updates, write a changelog of your completed task before moving them to “Live” showing the updates are up on the running game.
Most importantly, make sure you have a game testing pipeline!
Make sure you have a team that understands your game and is able to properly write accurate reports. I’ll show you a staging I use.
Here is an example of a bug staging process:
Similar to before you still have the Completed section and Live section for fixed bugs you should put in the changelog for the community to know what’s been fixed.
They key take away here is to make a staging process with a documented guideline for your team. This will help keep everyone on track with new content and bugs. If something goes wrong, it’s easier to find and identify.
Chapter 3: Understanding Story Driven-Data in Analytics
Remember how our community in the story said the game was too grindy, and the team in the future ended up making the problem worse by not truly knowing the economy’s situation.
I’ll tell you this now - don’t get mad at your customers!
Many times I’ve seen developers lash out at their customers, simply because many ask where is the update, and what’s taking so long. These are often the people paying for your products and want to continue to spend more or share it with their friends to play.
Your customers don’t always know what they want or what’s best but they are still the reason your game is going to be successful. They are not required to play your game and you should respect them as such.
With that out of the way, let’s talk data!
Some of the tools out there are GameAnalytics and PlayFab. In my experience, these are not the most flexible tools. I would recommend you learn to use MongoDB and make use of its Atlas, Charts, and Stitch services.
Atlas - Database storage; there is a free
Stitch - Create webhooks and host websites.
Charts - Create custom charts with your data.
Here’s an example stitch script:
exports = function(payload, response) {
const body = EJSON.parse(payload.body.text());
const db = context.services.get("mongodb-atlas").db("game-db").collection("analytics");
return db.insertOne(body);
};
You can make calls to store data and help you be able to construct your own dashboards such as the following:
Now that you have seen some examples of the charts it can make let’s talk about how we might solve the issue we had in our story from earlier.
First, we need to know our customer’s levels and cash in the economy. We can use a service to create a graph that shows up how much cash the average level group (1-10, 11-20, etc.) has in order to know just how much the average use is making.
Make sure you always have relevant data! Keep timestamps and filter out exploiters, and users that have not played in the past 15-30 days. Old customer data is no relevant as they are no longer a part of the market share economy! You can not create a drain for money that no longer flows.
IMPORTANT: This is based on your budget, using analytics services cost a significant amount. It’s best to use enough data as possible before your service starts to bog down or cost too much. Optimize your analytics to your needs and affordability.
Next, you make a chart to show sales of each weapon, you could also check what levels have what weapons. Now you can take this graph that shows actual data to make a more informed decision.
Warning: Do not only make choices based on data!
It simply tells a story, but sometimes data reveals stories you cannot see such as balancing issues or design flaws. If people don’t have a new sword from an obby, go back and watch what’s going on.
I promise you if you watch your customers play the game you will learn what sort of behavior they are doing wrong.
Sometimes colors, shapes, paths, and directions, can mislead players so always be aware of customer behavior being unexpected. Test multiple people before you do releases.
Chapter 4: Conclusion and Resources
Before I let you go, if you’re not already sick of reading - thank you for making it this far. This is a very short expression of huge and very complex parts of product development in any industry.
You probably wonder why I been saying “Customer” and not “Player” but it’s because I want you to stop thinking of players as just that. People are spending their time, money, and energy into your game which is a product. They are in every way a customer that deserves a well-made product with developers that make the most informed decisions. They want your game to succeed just as much as you do! Do not neglect them.
Lastly, I hope you stop and think about your team’s operations and how your internal affairs are. Is your team happy? Do they feel productive? How does your organization look? Management can be boring as it doesn’t sound exciting but it’s the glue to success.
Thank you for reading, let me know what you think of my article.
Here’s some valuable resources:
https://www.amazon.com/Lean-Startup-Entrepreneurs-Continuous-Innovation/dp/0307887898
