John Bura’s Background
The first time I ever coded was at my local university. I was 12. I spent my summer coding in C++ and Visual Basic. In the 90s there was a huge rage for Visual Basic, a programming language from Microsoft. I made small games, and I enjoyed it.
I wanted to make an Xbox 360 game, but that required coding in C# and XNA. There were virtually no courses that showed you how to do this. I bought a DVD set and learned from that. Soon I came out with my Xbox game.
My career skyrocketed as a result. Several apps on the App Store later, people asked me, “John, how do you make an app? How do you make a game?”
In response to my followers, I made a huge 50-hour tutorial on how to make a game from scratch, including art, music, and coding. That became a runaway hit. I became the first instructor on Udemy to teach through practical projects. I became a top seller on Udemy, and the rest is history.
I started Mammoth Interactive, my online education company. It began with me making tutorials in my bedroom. But I wanted to grow the business.
Scaling a Business
One of the best ways to scale the online education side of Mammoth Interactive was to make as much content as possible. When I began hiring people to work with me, I thought I could hire someone and they’d make a quarter to half as much money as I made. I thought I would hire 1 to 2 people a month. That totally didn’t work. Though I did grow my team, I didn’t scale at such a high rate.
I found out that the online education market that we’re in is a subset of a bigger market: the online instructor marketplace market. Right now, there are few players on the market of online education platforms. As such, scalability is limited on many platforms, such as Udemy.
What I Expected When Starting a Business
I thought the more courses I produced, the more money I would make. That is technically true. However, the percentage is nowhere near where I wanted it to be. We’re technically making more money right now than if I were a solo entrepreneur. However, the margins are much thinner.
I’m not the only one expanding my business. Lots of people who started on Udemy now have multiple people working for them. It’s becoming harder to be a solo entrepreneur in the space.
This echoes the game development space. Lots of developers like Atari began as individuals but expanded. The course market is going the same way. Every top solo instructor has at least a video editor or an assistant.
If you’re starting to make money as an online instructor, one of the best pieces of advice I can give is to outsource administrative tasks so that you can make more content. The more content you make, the more money you’ll make.
As you grow your team, at a certain point your returns will lessen. Still, the marketplaces reward productivity to a certain extent.
Helping Other Entrepreneurs
It’s unfortunate that scalability is limited. However, some scalability exists, which is good. The way to scale this side of the business is to put your courses on as many different sites as you possibly can. On your own site, you can offer great deals by bundling courses.
I want to grow Mammoth Interactive to a business that makes 10 million a year. I must pick the right platforms to do that. Since the instructor market is a subset of a bigger market, there is limited upside. If I want to become a 10-million-dollar company, I must branch out. It’s very clear that this is the answer. The answer is NOT to alienate any people or platforms that got us to where we are. We’ll always continue to upload our courses to as many different platforms as we possibly can because our students come from different areas.
Recently we have gotten a rise in interest for consulting. I love consulting small business, online instructors, other online companies, and startups if they need help. Remember: Mammoth Interactive is a bootstrapped company. Over the years, I’ve built Mammoth Interactive to be lean.
I’ve seen so many people waste money. I have so much knowledge on to save money that it’s worth other people’s time to hear what I have to say.
How I Started Making Games
In 1997 I wanted to make a full 3D role-playing game (RPG) in my bedroom. My RPG game did not work. It failed so miserably. Despite this, I kept making games. Instead of making a massive game, I made compact projects.
I wanted to make games, but everyone was interested in my courses. So I did both.
I’ve always wanted to make creative games that people enjoyed. I’m the kind of guy that has too many ideas and not enough time or money. While making my online courses on web, game, and app development, I’m always prototyping. I have hundreds of prototypes on my computer.
With my new game Escape Code, I wanted to make a bigger project. I took my best ideas over the years and put them into Escape Code.
How I Made Escape Code
I made Escape Code using only Apple‘s tools: SpriteKit, Xcode, Swift, and Logic Pro X. Why? Because I genuinely like the way Apple builds their products. I’m a big fan of minimalism. Like Apple, I strive to make the focus of my company the end user experience. My goal places less emphasis on complex technology.
Besides SpriteKit, I like to use the game engine Construct 3. tBoth SpriteKit and Scirra‘s Construct 3 are easy to use, and I don’t become frustrated while trying to release a game. Frustration doesn’t lead to sales, and Apple knows this.
Why I Love Swift
With Escape Code, I wanted to use all Apple products in one epic app. Escape Code is made completely in the game platform SpriteKit, which uses the coding language Swift.
Before Swift came out, for years I’d wanted a Swift-like language for the Apple ecosystem. Coding in Apple’s old language Objective-C was hard. Very hard. Once Swift appeared, I spent 2 weeks learning everything there was to know about Swift. I produced a huge 80-hour course all by myself. It was the biggest course on Swift at the time.
I also did a ton of webinars and talked about Swift everywhere. Today it’s still my favorite language. I don’t like coding as much in any other language. Swift is easy and intuitive. Just like Apple, Swift’s minimalist approach and end user goal is something I resonate with. It’s what Mammoth Interactive is all about to.
When someone takes our course, we don’t want them to get bogged down in any road block or obstacle. We want them to quickly understand how to do something and to make a product as fast as possible. I learned that from Apple.
The Best Kind of Educational Game
It was only logical for me to use Swift for a game in some way. The last thing I wanted Escape Code to be was an educational game. My least favorite educational games were those that asked “What’s 2+2?” and when you answered exploded a ship. Games like Civilization or SimCity are amazing games because they are fun and teach you a lot.
Civilization teaches you the history of technology in the best way possible. In fact, when I played its sci-fi version Sid Meier’s Alpha Centauri I learned so much about futuristic technology that I never would’ve learned in school. SimCity teaches you about great city design without bogging you down with a rote teaching style. There is too much mechanical teaching in many educational games.
I didn’t want Escape Code to be a brutal learn-to-code game. I designed Escape Code so that the mobile device player would have a fluid and optimized experience.
Challenges of Making a Game
The biggest design problem I had while making Escape Code was to make it easy to understand and to add to code in a way that has never been done.
The last thing I wanted was for players to type a bunch of code on their mobile phones. This would not be fun to play. Instead I added a box where you input the answer to a coding related question. Players still must read the code. But the execution is simple.
A Plot Inside Code
The coolest part about Escape Code is that part of the plot happens throughout the code. Crucial plot points like in a movie appear as part of code challenges. You can’t get the full story without reading the code.
Making a Game for Absolute Beginners
Since Swift is so easy to read, anybody – even if they don’t know how to code – can understand the code. Swift is intuitive and resembles natural human language. Anyone, regardless of programming experience, can follow the game thread by reading the code. Coding enhances the story.
Growing a Company
Escape Code is a momentous project for me because I didn’t do most of the work on the game. This is unique for me since my career is built on making projects entirely by myself.
I’ve been self-publishing since 2006. My first large entrepreneurial ventures were when I made 17 educational books and sold them all over North America. It was a wonderful learning experience for me, and it set the tone for the rest of my career. Since then I’ve done most of the work myself on a project.
Even when I produced my 80-hour Swift course (now updated) – I did everything. Video editing, sales copies, email marketing, recording, programming. Everything that had to do with the course, I did.
I was a solo entrepreneur until 2016. That’s when Mammoth Interactive became more than just one person. Today lots of people work for me at Mammoth Interactive.
Scaling a company has been hard. It’s just as hard as starting a company. Some might say it’s even harder.
From Solo Developer to Game Team
I’ve always made games by myself: art, music, and programming. With Escape Code, I wanted to be the director. With its 14-month production cycle Escape Code took way longer than I had expected. The game cost 2 times what I’d wanted to pay. Despite that, I’m pretty happy with the way Escape Code turned out.
It was difficult to convey vision and feedback to my Escape Code teammates because we don’t work in the same location. I had to figure out so many ways to express what I know to the developers. Of course I can code a game. But there’s a huge difference between directing people to do things and doing things yourself.
It may seem counter intuitive but having help can be harder than working alone. I wanted to try splitting tasks of making a game. Mammoth Interactive was a good place at where I could do this. There were lots of problems that came along the way. I had to find innovative solutions.
How We Make Courses and Games Efficiently
At Mammoth Interactive I have a 10 10 10 Rule. That means make a product 10 percent better, 10 percent faster, and 10 percent more money. The first 2 you can control. The last one is the hardest to do.
By following the 10 10 10 Rule, we have become the fastest people to make courses in the industry. Our time to market is so short that we constantly surprise our partners on how fast we can get things done. Our efficient production practices took years to make work.
With games I have the same pattern of making products fast. After prototyping for years, I know how to get a concept out the door fast.
Challenges of Being a Game Developer
The biggest bottleneck for me is the time it takes to make a game with 50 levels. It’s hard for me to do everything at once for a game with a bigger scope. It’s hard for any one person to do everything at once. I call it production fatigue.
Production fatigue is when you work too hard on a project and could easily complete its final tasks, but you lose willpower. Whether you’re learning how to code or wanting to be a producer, plowing through production fatigue will get you through many doors.
It’s hard to do. After creating and being an entrepreneur since I was 17, I pick my battles. Some battles are not worth picking.
Production fatigue is like hitting the wall as a long-distance runner. I’m not a long-distance runner, but from all the runners I know, the wall is the hardest part. You begin running and you want to stop so bad, but once you get past a certain point, running becomes easy.
This Game Took Twice as Long to Make, But It’s Worth It
I wanted to get Escape Code out in 6 months. This game would have taken me 3 months to do by myself, but it ended up taking 14. Luckily, Apple recently enabled app pre-orders. Pre-order Escape Code right now on the iOS and Mac App Stores!
Surprising Positives with Apple Pre-orders
Even if your project takes too long and goes over budget, an event can happen that benefits the project. If I’d released Escape Code 6 months ago, I wouldn’t have been able to put the game up for pre-order.
Pre-orders on the App Store are such a good idea. They’re a great way to help fund your game before you can release it. It would be awesome if Apple had its own crowdfunding site. You can’t do Kickstarters for iOS apps because Apple doesn’t allow redeeming of coupons on the iOS App Store.
We have had success crowdfunding projects on Kickstarter. A lot of you know that we are on Kickstarter quite a bit. The reason is that crowdfunding is a whole other stream now. Pre-ordering is as big a stream as actual sale.
The popularity of pre-ordering and crowdfunding is due to a shift in consumer thinking. Funding a product before it’s released has been normalized.
Every project we do we will try to put it on Kickstarter. It’s unfortunate Kickstarter won’t let us do multiple Kickstarters at the same time. Every project we do takes money, and we’re a project by project company. Be on the lookout for Mammoth Interactive Kickstarters. In the future we hope to see crowdfunding for iOS apps.
A Project Focused Company
As I mentioned, I have way too many ideas. Right now, I have 20 games that I’m trying to get out as soon as I possibly can. Small games – coffee break games. Escape Code is a medium-sized game, and I have plans for major games.
Before I even consider getting funding, I want to prove myself in the marketplace. Mammoth Interactive is entirely bootstrapped. That means we make a product such as a course or game, make money off that product, and reinvest the gains into another product. A lot of other technology companies find funding completely differently.
Many tech companies funding from a VC (venture capital) firm, and they get millions of dollars for a product that may or may not work. Over the last ten years I have a good record of accomplishment of making profitable projects. One day I might even get VC for a product. I do have some games that would be awesome.
I would like to bootstrap the games side of Mammoth Interactive first. Our education side is going well, and we will make a lot of fantastic courses coming up.
How We Make Courses
At Mammoth Interactive, our instructors make courses as well as individual products. I want to set up my company as Valve, the creator of Steam, has. The concept is a big room with modular teams and products. Developers and teams can collaborate and make small products.
I have a big theory on how to build a company called Mosaic development. It’s how I built Mammoth Interactive. I’ll probably do another article about this and write a book about it one day because it’s such a great idea and works so well.
Mammoth Interactive is a place where creators get stuff done. It’s not a place for people to go, get a paycheck, and come home. Our system is not for everybody, and I totally understand that. When I was new to the job market and worked for others, I felt useless and like a cog in a machine. Whether I showed up to work or not was not important. The company would still exist whether I showed up and “got work done” that day.
When I started Mammoth Interactive I wanted to make sure instructors produced something. A construction worker can point to a building and say, “I built that.” Ten years down the road they can point out the things they’ve made.
One summer in university, I worked as a landscaper. We began on a big field of dirt. We transformed it into a suburban park with trees, a playground, and sod. It’s common in the construction industry to accomplish this. Tech companies don’t do this.
Most companies are bogged down in meetings and trivial processes. At Mammoth Interactive, we make work meaningful and feel like you’re doing something every day – not just showing up and going home.
Why We Make Tutorials
One problem I’ve run into is that some developers only want to develop. They don’t want to make tutorials. Developing tutorials is like meditating. It’s one of those activities that doing a lot of improves your skills.
Programmers don’t understand that going back to the fundamentals and explaining them to a beginner makes you a better coder. It’s good for you whether you like it or not.
At the same time, if I’m not producing a side project alongside teaching, I’m not as happy. Ideally as Mammoth Interactive grows we will be able to make more content – not just training content but small products. We’re a company of small products: it’s how we began. Releasing products frequently is part of Mosaic development and is why it’s so brilliant.
Escape Code took a long time. I’m happy with its results. It’s a good-looking game. I’m excited to see how many pre-orders we get.
There are more products coming out from Mammoth Interactive other than just the education side. While we still will always produce educational content to some degree, there will be a lot of other cool stuff, so stay tuned.
The Online Education Revolution
One of the best things about the rise of online education is that people can teach part time and do other things alongside. We’ve all heard the saying, “Those that can’t do, teach.” In the past the saying might have been true when teaching was often considered a “lesser” job. In the 20th century, growth was so incredible that if you knew how to do anything, it would pay more to do it than teach it. You were considered second-rate it if you just taught because that meant you couldn’t do.
This mentality lingers with us today because the post-high school education system focuses more on theory than practicality, depending on where you go. Today we’re in a whole different area, and it’s a better area. I’ll argue that you can’t be a good programmer without being a teacher. And vice versa: you can’t be a good teacher without doing things. Today you need to do both to some degree.
Anyone Can Learn at Mammoth Interactive
If you’re a great programmer but can’t explain programming basics to others, chances are your code is too complex. If your code is too complex, collaboration (especially on bigger projects) will be a liability rather than an asset. When you teach beginners, you distill your coding knowledge to its most basic form. It’s like reducing your fractions. You want your code to be the least complex and the most efficient.
Just like how newspapers and articles make their articles readable to a grade 6 level, you should make your code readable to as many people as possible. It should be easy to understand. There’s no better way to learn to do that than to make tutorials.
You don’t have to be a teacher. Anyone can benefit from simplifying things to others. If you’ve never done it before, you’ll find it surprisingly hard. At Mammoth Interactive we’ve found an easy way to do it. As mentioned, we’re the fastest in the business at releasing a product to market.
On the other side, if you don’t produce things, your teaching skills will worsen. Part of the beginning of my teaching online is when I ran into trouble making an iOS app. I solved the problems to make the app and decided to teach people based on my experience.
I taught how I solved problems one month prior. I showed students how not to do what I did. Making an app from scratch made me a great iOS teacher. Without my hands-on experience, I would have been any other teacher who puts up a curriculum and shows theoretical problems.
Learning through Practical Projects
Instead in my courses I show you the problems that can arise, just like how this article is talking about issues with scaling a company, making tutorials, and making a game.
The mindset to have about learning is to fail forward. You cannot improve without failure. Most people pass through the education system thinking failure is a bad thing. We are taught to fear failure far too much.
Since we are a part of a knowledge economy, some things will work out and some will not. Larger companies like Coke and others make products they don’t even know will sell but that they try regardless.
When a project fails, you must figure out why. On the next project you will do a better job. Especially if you follow my aforementioned 10 10 10 Rule.
When you improve on something, it’s not during the project – it’s between projects. We at Mammoth Interactive have such a short iteration cycle so that we improve as much as we can between projects. If you make a 2-year project, there’s little room for improvement. Smaller, simpler projects lead to a bigger mosaic.
Escape Code might completely fail. Apple might not pick it up. If I lose a lot of money, I will figure out why. Sometimes the reason your project fails is completely not up to you. Success is not always up to you either. Success can be random.
The way that I deal with this randomness is by producing a lot of products and ensuring each of them is barely profitable. You don’t trust one big product to take your company forward. Instead you build small products. You never know which one of them will take you to the next level.
I don’t think Escape Code will fail. I’ll probably at least get my money back. It’s too innovative to not do well. Check out our #1 coding mechanic, engaging puzzles, and go on an adventure!