Game Developer Deep Dives are an ongoing series with the goal of shedding light on specific design, art, or technical features within a video game in order to show how seemingly simple, fundamental design decisions aren’t really that simple at all.

Earlier installments cover topics such as the scientific modeling behind the irrigation and water systems of Timberborn, how the 2D art of Songs of Glimmerwick benefited from a 3D art pipeline, and how the synergy between art and audio disciplines and a solid base of real-world data formed a surprisingly faithful televised broadcast experience in F1 Manager 2022.

In this edition, Ken Williams, co-founder of Sierra On-Line and Cygnus Entertainment, gives practical advice for game developers against the backdrop of Colossal Cave's multiplatform remaking.

Yesterday my wife, Roberta Williams, said to me, "I know what your next project should be!" I cautiously asked, "what?" assuming she had some new idea for a game. Instead, she said, "This isn’t the right time, but perhaps starting next summer you could write a book about, 'The Making or the Remaking of Colossal Cave.'" I thought about it for a few minutes and realized she was right. Colossal Cave has been an unusual project, and there are lessons from the project that would be valuable for others.

As I am writing this, the story is still unfolding. Arguably our game has not yet launched. We released the PC versions of the game and the first of our VR versions. We've also released a couple of console versions. Over the coming months, we’ll be adding PlayStation 5, Xbox series X|S, iOS, Android, Pico VR, Steam VR, and more to the list of releases. We’ve also been busy updating the initial release of the game to patch bugs, and to give some extra hints on puzzles that players have struggled with.

Anyway, my goal with this article is simply to look back at the project thus far, sharing our team’s experiences in the hope it might help other game developers. That said, many, or perhaps most, game developers are working alone on zero-budget projects. If that’s you, great! Keep at it! Every ladder has a first rung, and I remember those [days] all too well.

Roberta Williams showing off Sierra's original logo.

Before we begin, I should introduce myself.

I am Ken Williams. You may have heard of my wife, Roberta, and me from a game company that we built in the '80s and '90s, Sierra On-Line. We were among the very first developers of games. We grew the company to an industry-dominant, publicly-traded game company with over 1,000 employees. We sold the company for nearly a billion dollars in 1996, at the peak of our success, and retired to cruise the world on a small boat. We thought the company would live forever but were shocked to see it destroyed by ineptitude and corruption.

I was a software engineer prior to starting Sierra. Roberta designed many of our hit games, including King’s Quest and Phantasmagoria. We were embittered by what happened to our company and elected to have nothing to do with games over the years that followed. Instead, I wrote books, and a blog, about cruising as we took our small boat through 27 countries. Our plan was to do that forever, but Covid temporarily suspended our travels. We don't sit still well, so I wrote a book about Sierra, and when Covid dragged out I decided to write a game.

The most critical decision you will ever make in developing a game is made on the day you decide what game to write

I like to think of a game’s potential in terms of "hooks." By this, I’m referring to the inherent momentum within a title to hook a buyer. I was just looking at the data on Steam, and there were 10,963 new game titles released in 2022. My strong suspicion is that most of them never generated a dime in revenue. Without some hook for your game, no one will ever play it, much less buy it.

Before investing a lot of time in a game, even if you just want to get it out there for free, I suggest you make your life easy. Think about how large the target market is, what inherent hooks the game has, how crowded the game category is, and what you can do to stand out from the crowd.

A hook can be as simple as trying to be someplace others aren't. For instance, we published a game called Mixed-Up Mother Goose. The potential demographic for the game was clear, and at the time there was no competition. It was to be a small niche (pun intended), but one we knew was there. In addition to being virtually alone in the market for young children's games, Mixed-Up Mother Goose had the hook of being a technological achievement. It was the first game to have the characters speak, and it was the first game to be released on CD-ROM. I knew going in that we would have a hit. At the other end of the demographic spectrum, we released a game called Leisure-Suit Larry. Its hook was to have cutting-edge, R-rated humor in a market that still thought of computer games in terms of Pong or Space Invaders. There was never any doubt it would get attention and stand out from the crowd.

So, why did we choose Colossal Cave?

Before I answer that question, let me talk about passion. I have always said that before looking for hooks you must look for passion about a subject. At Sierra, I never sought game designers to design Sierra a game. I looked for people who were passionate about something and then asked myself if there were any reasons to believe the game would sell. Passion was always step one and still is. Roberta and I are passionate about Colossal Cave. It is the game that launched our careers…and Sierra. If you look around the game industry and find anyone with more than a few grey hairs, the odds are heavy that their first game was Colossal Cave. Why? Because it was "the only game in town" in those days, and because it was a darn good game.

The title Colossal Cave fulfilled the passion needed but isn't a great hook. It might even be a negative hook, in that it is identified by modern gamers as being "old." I tend to think of things in terms of a football metaphor. There are things that move the ball down the field and things that move you back. Given that Colossal Cave is perceived as old, we were starting on the 1-yard line. The game had been played by millions, but very few of them are today's gamers. No help there.

What about Roberta's and my reputation? I knew that it would help get us credibility and media attention. It's certainly a hook, but would it help sell the game? Knowing we dominated the game industry before most modern gamers were born is not much of a reason to whip out your checkbook and buy a game. We do have an awesome game, but I bet if we search among the games that did not grab an audience in 2022 there are plenty of really good games that were never discovered. Being a great game helps, but it is not a guarantee for success.

Also, speaking in terms of hooks, let's look at the genre of adventure games. Some have done well, such as Monkey Island and Myst but generally, modern gamers seem to have moved away from puzzle games, and the original Colossal Cave is the most challenging puzzle game a player is likely to encounter. There is some action, but nothing that will entice today’s action-oriented gamers.

What "hooks" do we have? We do have several things going for us. I won't deny that our background does help. Even though modern gamers might not recognize Roberta's and my name, anyone who has been around the industry for a while knows the great games that we had the good fortune to publish. We have a reputation that opens doors within the industry, whereas I'm sure most aspiring game developers struggle to get attention from companies like Unity, Microsoft, Nintendo, Sony, etc. There were times on the project when we needed help, and simply being able to get someone to return a call makes a huge difference.

Roberta is a legendary designer, and her King’s Quest series was a million-copy seller. That gives us the hook that getting interviews and media attention is easy. We do get a lot of press. I'm not convinced all of the press sells games, but I'm sure it helps at least some. As to our title, Colossal Cave, I do believe it is a huge hook. Even though modern gamers might associate it with a 50-year-old text game, it's hard to be a gamer and not have heard the name at some point in your life. Name recognition is important. It will get people curious enough to look to see what you have. Plus, Colossal Cave has a rich history behind it that we can use to promote the game. That's another nice hook.

My message with all of this is that developers should try to step outside themselves, pretend the game is complete, and think about what there is about it that makes it stand out from the crowd. If the only answer you have is: "It’s going to be the most fun game anyone ever played", that’s good and may break through, but it's a tough world out there. Try to start with as many hooks as you can.

We worked all summer from on our boat. Here's Roberta playing our Quest 2 version of the game.

Why was the decision made to support VR?

I've never personally been a big believer in VR. It is annoying to wear a headset and can make many people sick. I have to admit that the primary reason we decided to support VR was that I felt the competition might be less. Back in Sierra's day, our big competitors were Electronic Arts and Microsoft. We won partially by looking for holes in the market, target demographics, or platforms that were underserved. It is possible to succeed in a crowded market, but trust me, it is WAY easier in a market with fewer competitors. By being on VR there would be a greater chance people would find our product.

I hope you won't take from my comments above that our VR version is anything less than amazing. Playing it is an incredible experience that has to be seen to be believed. After playing our game on VR, and then playing it on a PC, there is just no comparison. The VR version is mind-blowing. The cave lends itself beautifully to VR and you feel the tight passages as you tunnel into the earth, and also the scale of the caverns, in a way that just isn't the same on a flat screen.

I agreed to support VR without realizing how radically our entire project would have to change

In 2020, when we first started coding on the Meta Quest 2, Meta's development software was still evolving. What documentation there was didn't always match the software, and the software wasn't always stable. I liked it because I knew other companies would be facing the same battle. I always say, "If it was easy, anyone could do it!" It was a major headache. We found excellent tutorials on the internet, but often they wouldn't match the latest version of Unity or the VR SDK we were running. We hit issues with compatibility between the add-on packages we were already using and Unity's VR packages. We were confused about whether we were on the right path or even using the right software. Our spin-up time on VR consumed several months.

Once we successfully had the game playing on the Quest 2 headset, we discovered the battle had just begun. The minimum framerate for release on a Quest 2 is 72 frames per second. The Quest 2 is an impressive device for the money but repainting two screens (the player's left and right eye) 72 times a second is no easy challenge. Our code, both the code running on the CPU and the code that is running on the GPU (the graphics processor in the Quest 2) needs to execute in 16 milliseconds.

A couple of months into VR development, we wound up throwing away all the graphics we had done to date, and much of the code.

The toughest challenge of all was the trees. And as I typed that sentence, I was careful not to use the normal adjective that I use to describe VR trees, as it might offend some of you. Unfortunately, the Colossal Cave game starts out in a forest. It's the first thing players see. First impressions are critical. Trees do not render well in VR. Either you use cartoonish trees that look like lollipops, or you use trees with branches and leaves.

We consulted with Meta, who strongly suggested we use stylized trees (their word for lollipop trees), and I fought for lollipop trees because, after months of effort, we weren't making progress. I wasn't sure we'd ever find a solution. Realistic trees were dragging down the frame rate due to the time spent rendering individual branches and leaves. Worse yet, you could see a strange-looking shimmer around the leaves. We tested virtually every 3D tree we could find, to buy or borrow, on the Internet. A month before release we were still messing with the trees. We finally were able to produce a decent forest, but I thought we'd never get there.

Another big challenge in VR was inventory management. On non-VR systems, we use a 2D screen overlay with faux 3D inventory objects. It works great but didn't feel right in VR. We rewrote and redesigned the inventory handling for VR. However, when we released the game, reviewers didn’t like how it worked, so we completely rewrote and redesigned it again, finally nailing it on the third try. The code differences between PC and VR, for something so integral to the game, created messy code and complicated the debugging process. At this point, our game's inventory system has been worked on by so many engineers, and changed so often, that no one wants to go near the code. It works. Players like it. And hopefully, no one will ever find a bug.

Another challenge that plagued us to the end: on non-VR (flat screens), when there is a cutscene, we can lock down the player and ensure that the player is looking where we want. In VR you are severely limited in your ability to restrict player movement. We have no control over the game camera. It's strapped to the player’s head! The player decides which direction the camera is pointing, not us. How do you ask a player not to turn their head? If they aren't looking where we want, they might miss some action that is critical to the game. How do you tell them that, in a tight cave passage, they can't physically stand up? If they do, their head will pop through the roof of the cave. We tell players they need to sit to play the game and stay facing one direction, but realistically, players do what players want to do, and our code has to handle it.

The bottom line: adding VR to the project doubled the cost. Will it be worth it? Ask me after we get the sales data from SteamVR, Pico VR, PlayStation VR2, and Quest 2 VR. I think we’ll be happy, but it was a LOT of work.

More games have been killed by over-enthusiastic ambitions than any other reason

There's an old saying, "How do you eat an elephant?" The answer is, "One bite at a time." Well, that saying is a little misleading. In reality, what happens is that you convince yourself you can eat the elephant and then discover that you are 10 percent of the way in, there is a lot more elephant to go, and you've already exhausted all your resources. Often, developers start a project without realizing how big the elephant is. They run out of money, or time, long before finishing the project. I didn't realize it at the time, but we had bit off more than we could chew.

When the Colossal Cave project started, it was intended as a cute little game that might sell hundreds of copies, done by myself and an artist friend, Marcus Mera. It started as a "personal project" that was being built to pass time during the Covid lockdowns. Marcus and I had a blast working on the game and had most of the game playable within a 3-month period.

However, the project changed radically when I made the decision to get Roberta involved. She has a magical sense of quality, and an ability to recognize flaws in a game that is unlike anything I've ever seen. I thought that, with her help, my cute little game might be a lot better.

Adding Roberta to the project dramatically changed the project. It was a win for the players but wound up meaning we would need to scrap months of work and start over. Roberta's sense of quality is such that she immediately looked at what I was building and said, "This is crap, you need to start over, assemble a team, and do it right." Roberta was focused on something she called "Legacy." She didn't want a game coming out that would do anything to damage our legacy. Marcus's and my game showed promise but it wasn't at a level that she felt our, or the game’s, reputation demanded.

This was early in 2021. I remember believing (wrongly) that the Covid lockdowns were nearing their end. I was reluctant to make the time commitment to build a better game. The game industry is somewhat binary. You hit or you miss. There are the big triple-A titles with giant teams and many hundreds of millions invested, and there are the small indie titles with garage-level budgets and low expectations. Roberta was steering us into some "super-indie" category of game development that I wasn't sure existed. She wanted us to assemble a world-class team of professionals. Satisfying her requirements and vision for the product would mean a multi-million-dollar investment.

Why did Roberta think it was worth investing in Colossal Cave?

For this article, I asked Roberta to describe her passion for the game Colossal Cave. Here is what she said, in her own words:

"Designing a game is about creating an addictive challenge for the player. Something that raises their adrenalin/endorphin level and causes them to want to keep going. In a fast-action game, the player is constantly engaged and taken to a high endorphin level while the challenges just keep coming in a hypnotic series of encounters. Colossal Cave—and all great adventure games—accomplish the same thing but at a more cerebral level. It’s like great foreplay where the senses build over a longer period, making the game payoffs that much more exciting. While the player seeks the ‘payoff’—completing a goal or running across something exciting, awesome, or unexpected—the feeling of accomplishment and discovery continue to expand, but slowly, methodically; you get sucked into the experience of a great exploration."
"I compare Colossal Cave to the story of Alice in Wonderland. You enter a fantasy world (down a hole) not knowing what awaits you! There is magic, beauty, danger and more, and the realization that you are in a new place and unclear how you will escape, or why it exists at all. The text version of Colossal Cave was designed by a real spelunker, a person who explores caves. The thing that keeps them spelunking is the sense of not knowing what is around the next corner. Sometimes it is an enormous cavern, sometimes a dead end, sometimes an underground lake. You don’t know what is there until you get there. When you leave the cave, to return home to sleep, all you can think about is the unexplored places in the cave. What is there? What haven’t I seen? I wanted modern players to experience what I felt when I first entered the cave. It’s a mental challenge with a long series of slow building payoffs that are unbelievably satisfying, that build step by step to a massive climax, and that keep you coming back."

My original budget for the game was simple. Zero investment and make money from the first copy. I'm not sure I'd have sold more than a few copies, but I'd have made money! To fulfill Roberta's vision for the product, a huge budget for the game would need to be established, and it wouldn't be something I could do alone. We would need a team.

There were some serious decisions to be made. Would I seek a publisher, or form a company and hire employees?

Most game developers who seek a publisher have difficulty finding one willing to invest in their product. Because of Roberta's and my reputation, I was 100% confident that I could easily find a publisher who would fund development and market the product. That said, we are an exception. My advice to any first-time game developer, even one who has what they feel is the greatest game ever invented, is: if a high-quality publisher wants your product, negotiate the best deal you can, but take the publisher.

I quickly ruled out going with a publisher. Roberta and I are in the fortunate position that we could fund the development of the game. We knew going in that, even with our experience and name recognition, there is infrastructure at a publisher that would benefit our game. However, we decided we'd prefer to put our own money at risk and accept that the game might not sell quite as well, rather than accept the pressure that would come from taking someone else's money. We liked the idea of having complete control over the project. If we didn't like how the game was evolving and wanted to shut it down or change the design, we would have no one to please but ourselves. Be it right or wrong, we have enough experience to know what makes a good game and wanted to build it on our schedule, our way. We didn't want a publisher looking over our shoulder and backseat driving us.

The Cygnus Entertainment name and logo were taken from our boat. That's me standing in the cockpit along with our pup Toundra.

We decided to form our own publishing company

Forming a company requires a lot of paperwork and some important decisions.

Many of the steps above required an address for the business. At first, I used our home address, but then it was pointed out to me that there can be crazy stalkers out there. I'm not sure Roberta and I are exciting enough to attract a stalker but did see the wisdom in not using our home address. I wasn't sure we would have an office, so I obtained a mailing address and phone number from this company: www.ipostal1.com.

All of this takes a long time to get set up. I'd recommend any developer planning to self-publish tackle this early in the process.

What should we do about forming a team?

There are two options for forming a team: hiring employees or engaging subcontractors. I wanted to avoid hiring employees for several reasons. The biggest reason was that I was unsure about Cygnus' future as a company. If our first product, Colossal Cave, were to do well, then maybe there would be a second product, but possibly not. Roberta and I were retired for 25 years and had developed a new life happily boating around the world. One way or the other this might be a one-off effort. I didn't want to hire someone only to lay them off later. Whether this game hits or not, there is a side of us that misses our boating life as world-traveling adventurers. Plus, hiring employees comes with a huge amount of paperwork and liabilities, and having employees in multiple states means even more paperwork. I needed to assemble a team quickly. If I limited my search to our local city or even state, it would be a lot tougher to find people than if I could look anywhere in the world. And being that it was during the Covid lockdowns, no one was going to an office under any circumstances.

I decided to engage only freelance workers, paying them an hourly rate. I engaged everyone telling them they would only have work for one to three months. I suspected that I’d keep most of them longer than that, but if someone couldn't handle the work, or if I decided to just shut the project down, I didn't want to feel guilty. It's better to set low expectations than to promise more and not deliver. By engaging freelancers, as independent businesses, I would pay a higher rate than if they were salaried employees, but I wouldn't need to provide benefits. Not only are benefits costly, but they come with lots of hidden expenses and regulations. Contracting with freelance workers can also be tricky if not handled correctly, and the last thing you would want is for some government entity to decide that you've set up the relationship incorrectly and that what you thought were independent freelancers were actually employees. This is a place where consulting with lawyers and accountants, plus doing a lot of research, is worthwhile. Proceed carefully.

In the beginning, most of the workers were brought in from a company called www.upwork.com. Upwork has a large browsable database of freelance engineers, artists, and more. Upwork bills me for each hour a freelancer works, keeping some money for themselves and giving the rest to the contractor. This provides a layer of liability separation between my company, Cygnus, and the freelancer. In all of my years doing business, I've never been sued, but it's still good to do business as conservatively as possible.

The freelance workers contract with Upwork, who contract with Roberta’s and my LLC. Theoretically, all of that provides some degree of liability protection, but nothing avoids liability better than just doing things correctly in the first place. The Upwork relationship has been a success, and I was able to find good people quickly, but Upwork is not perfect. Their markup takes a significant percentage of the money. Also, it's tough to know if the people you are contracting with are who they say they are. Upwork will tell you that they verify all of the people they represent, but I've had mixed results. I strictly wanted US-based people on the team. I didn't want the project bogged down by communication or cultural issues. I also didn't want to have to worry about time zones. What I quickly discovered was that many of the people at Upwork are from other countries and they weren't always who they claimed to be. I recruited by insisting on a Zoom call and would insist that candidates appear live. With engineers, I'd ask them to write code while I watched. Only a fraction of the people I interviewed were willing to appear on a video zoom call.

Over the life of the project, there have been times when I needed more people and needed them fast. Upwork is awesome but, when you filter out the people with fake IDs and start looking for specific specialties, there are times when you strike out. For instance, at one point I needed someone who knew both Unity and the Nintendo Switch. I was in the fortunate position that game developers had been sending resumes consistently. I also discovered a site called workwithindies.com. I'd highly recommend it for anyone needing to hire (or contract) a team member quickly.

The bottom line is that our team grew rapidly via various methods to 35 people, all of them working from their home offices and some of them scattered across the world, but mostly in the US. Just like my goal of only contracting via Upwork went out the window, so did my goal of contracting only within the US. I wound up with an engineer from Thailand, a QA person from Zurich, artists from Canada and Brazil, and a marketer from Mexico. Even within the US, our team was scattered all across the country.

Beware of rookies, no matter how many years of experience they might have

A piece of advice to others forming a team, which I wish I had followed more rigorously: be very picky about who you put on the project. We had several awesome people on the project, and lots of really good ones, but we also had some that weren't so good. The bad hires doubled the workload for the others. There is some code in the game that is scarily bad. If I had it to do over again, I'd be much faster to prune the team. We would have moved much faster with a smaller, but higher-caliber team.

Spoiler alert: The next paragraph is for engineers only.

In my book, Not All Fairy Tales Have Happy Endings I spent some time talking about my philosophies for coding and debugging. That turned out to be the most popular chapter in the book for many readers! If I ever do turn this article into a book, I'll have a lot more to say on this subject. For this article I'll provide only this small bit of advice to engineers:

Code should be written to be read. You should always assume that some future engineer will get stuck debugging your code and that you need to make your code brain-dead simple to understand. Forget writing fancy code. Keep it simple. Put in lots of comments. Pretend to be a coder who has no idea what the code does. What can you do with the variable names and method names to make their functionality more obvious? Keep the method names explanatory, and keep the methods as short as possible, limiting them to a single function where the method title "tells all." Trust me. Even if there is never another engineer who follows you to work on the code, the code will debug faster than if you get fancy. If it takes you 100 lines to code what another engineer can do in one line of code, that's fine, especially if your code debugs faster, and is more reliable. Make sure you understand whether the code is performance critical or not. Most code should be optimized for debuggability, not execution speed, or even coding speed. Know the difference. In a race between a hare and a turtle, sometimes it is better to be the turtle. No one wins with code that is unreliable.

Pay attention to variable scope and avoid accessing variables that weren't passed to you. Initialize all variables before using them. One would think this is obvious, but my experience seems to indicate that schools aren't teaching this.

Code defensively. Yes, I know that all of the data is supposed to come to you clean, but it doesn't work that way in real life. As you write your methods, assume that any data you are passed can't be trusted. Detect bad data and handle it in a way that is graceful. Don't just crash. Depending on what it is, you might be able to just keep the game running. Hanging the game and just shutting down is usually not a great thing to do. When you do get bad data and need to recover, let someone know. Put a note in the debug console, but don't break the game.

Remember what I said earlier about biting off less than you can chew and eating the elephant one bite at a time. In writing a big piece of code, scope it out first. Think about how to break it into smaller tasks. Pick the scariest and most complex part and tackle it before the easy stuff. Think about how to simplify it and make it easier to code. Never save the scary bit to the end.

If you are looking at someone else's code, don't rush and start making changes. Take the time to read all of the code. If it isn't well written and commented, fix up the code without changing how it works. Until you really understand what code does, and what the big picture is, don't just leap in and start changing things. If there's a line of code that seems wrong, play detective. What was the other coder thinking? Don't just hit the delete button.

Do not wait on other people. I've seen too many engineers who say, "I'm waiting for someone to answer my support request." Sorry, but that is not an acceptable answer. My rule is: never let anyone stand on your critical path except yourself. There is always another way to skin the cat. Posting questions on forums is good, but sitting around waiting and hoping someone else will solve your problems is not acceptable. Be creative and be aggressive. There is always a way.

Do not hand off your code to QA without beating it up yourself first. And don't give it to QA without accompanying notes saying what they should test. No one knows your code's weaknesses more than you do. Think about the evilest thing that can be done to your code, and do it, and then document for QA how they can be even crueler. Buy my book (it's cheap on Kindle) and study the chapter on Dykstra. Even better, memorize it.

I was blown away by how easily the team was able to work together, even though everyone was working from home

Despite our team being scattered across the world, I felt closer to the team than if we had all been in one building, communications were better, my ability to manage was better, and we were able to work together better. Our remote working environment was a win-win for everyone.

Our team started with Slack (an online chat program that also allowed for screen sharing). It was working well for us, and I was quite happy with it. However, when I contracted a Microsoft person to moonlight for us, he sold the team on a switch to Microsoft Teams. Both of these utilities do roughly the same thing but are very different in their user interface. The changeover was a pain and meant lost productivity for a week, but we got through it. If starting a project today, would I use Slack or Teams? I'd probably go with Teams, but mostly because I've used Teams more recently. They are both amazing products.

Our team chatted virtually nonstop all day. There were times I had to remind the team to be quiet and get to work, but those were rare occasions. By far, the vast majority of the chat was work-focused. We were constantly sharing screens with each other, showing off our work to each other, or assisting team members in accomplishing some task. We had a tight team that functioned like an extremely well-oiled machine. It felt as if we were in one big cloud-based office.

Throughout the project, Roberta and I worked seven days a week—my usual 6 am to dinnertime, and Roberta’s preferred time of 9 am to (making) dinner! Other team members worked their own schedule with the caveat that I liked to know what schedule they wanted to keep, and that they'd be around for regularly scheduled Monday afternoon meetings. Some worked an insane number of hours, and some worked only randomly.

Working at home is not always productive.

Not everyone is right for Work from Home

Most developers are enthusiastic to be at their computers making a game, but not everyone has a good home office. Some, particularly during the Covid lockout, had kids home from school demanding attention. Some developers have trouble being self-motivated. It can be tough for some developers to work when they haven't gotten up, had coffee, driven to work, and sat at a desk. I don't know why that would be, but I can confirm that work-at-home isn't for everyone.

And of course, some freelancers have been known to bill for more hours than they worked. There were some on our game that I know overcharged me. The right answer is to part company with anyone I don't trust, but that isn’t easy when they have code half-written and you need them. I have experimented with a site called Hubstaff.com to monitor freelance workers remotely. It grabs a screenshot every 10 minutes, allowing me to see what they were doing. Personally, I don't like having to monitor people like that, and they definitely don't like being monitored. It's a huge invasion of privacy, but if we were in an office and they were in a cubicle I'd be able to wander by and see their screens anytime I wanted. So... I guess it is ok. Not everyone at Cygnus did Hubstaff. It really depended on how I was feeling about Hubstaff when they were first contracted.

Overall, I do believe that allowing the team to work at home was a good thing for this project, but there are both pros and cons, and even well-intentioned team members can be inefficient when working from home due to distractions or a poor office. There are also security issues. Do the hardware companies really want their top-secret development systems sitting in someone's living room?

Our globally distributed team did work well for this game, but if I were running a large game company again, I'd want everyone coming in to work each day.

This diagram from Plastic SCM shows a typical day. Each line represents a branch of the project and each bubble a check-in by an artist or engineer.

Stepping on each other’s toes

Now that I had a company, and workers, we needed a way to share art, music, and code with each other. This means source control, which often means "GitHub." I don't know why I didn't start the project with GitHub. Not having done so may have been a serious mistake, I haven't used GitHub enough to tell you. Instead, Unity had a built-in source management system called "Collaborate." I love Unity, and especially the wonderful people that work there, but I have nothing good to say about Collaborate. It was horrible to use, with us constantly losing code or art. Apparently, Unity agreed. I saw that they acquired a company called Plastic SCM which replaced Collaborate. I tried Plastic and it felt much more reliable, so we switched to it.

On a small one-person project, source control is not a big deal. On a larger project, with a large team (not that 35 people is a large team) source control is critical. As the developers work, they need to check in (share with each other) their art or code changes several times a day. Over a six-month period, our source repository grew to over 25,000 check-ins and 50 gigabytes, at which time it crashed. We didn't know if it was something we did, or if it was some crash caused by Plastic SCM. I knew the source repository had been growing exponentially, so we started a new repository. Our new repository didn't stay small for very long. We have now checked into the new repository over 20,000 times! As I am typing this our repository is already at 79 gigabytes and still growing!

If I were going to start a new project tomorrow, would I use Plastic or GitHub? Honestly, I don't know which is better and can't tell you. But I can say that Plastic did all that we asked of it and worked perfectly for us. I'm very impressed with it!

Like many products, Plastic seems deceptively simple. With a day of use, you feel like an expert. However, as soon as you start doing complex things you discover that there are plenty of ways to get into trouble. With power comes complexity.

Interleaving multiple platforms within the same source using conditional compile directives.

And speaking of complexity…

Unity makes it very easy to do multiple platform development, but there's only so much that it can do. We decided early on that we would release our game on a wide variety of platforms. What I understand now, but didn't at the time, is that Unity's multiplatform support only gets you most of the way to the finish line.

We are releasing the game in the following formats:

Windows, Mac, and Linux, on Steam, GOG, and Epic Games

Steam Deck, PlayStation 4, PlayStation 5, Switch, iOS, Android, Xbox One, Xbox X|S

Quest 2 VR, PSVR2, Steam VR, Pico VR

Depending on how you count those, there are approximately 20 different versions of the game! And despite Unity’s multiplatform support, there is unique code for all of them. For example, some of the versions, such as the Switch, Xbox One, Quest 2, and PS4 are very tight on memory and needed us to scale down the graphics. We also had to limit the number of saved games. Our in-game help reference cards are different for every platform. Adding to the "fun," we support multiple forms of locomotion in VR, 13 different languages, and multiple forms of input on PCs. The user interface for Inventory is completely different between the VR and non-VR versions of the game. And virtually everything in how you control the game is different between VR, non-VR, and touch-based iOS and Android. Remember what I said about not biting off more than you can chew? I wish I'd read this article before starting the project!

After experimenting with how to manage all of this and some false starts, we settled on a strategy of using a single repository (in Plastic) with multiple branches for each target environment. I'm using the word environment, rather than device or operating system, because even when we'd speak about Windows, there are multiple SDKs for Epic, Steam, and GOG. Each developer also had one or more branches of their own to represent their "In development" code branches. I started the project writing most of the game code, but by the end of the project, most of my time was spent as “merge master,” orchestrating the check-ins and merges. Coordinating the merges became a full-time job. In the original version of the credits, I was listed as "Ringmaster" and I meant it in the circus form of the word. I felt as though I was standing in the center of the ring, surrounded by developers who were constantly spinning around me.

There were so many merges happening that we finally split the branches so that we had a person managing all of the merges for graphics, and myself for engineering. We also split the game code such that graphics had their own main branch in the source control system, and I would merge from it almost daily.

Artists are perfectionists, and that's usually a good thing

Graphics merges were always "an adventure." If an artist sees something that could be better, there is a strong urge to fix it. I get that. However, not all artists are engineers, and some don't understand the collateral damage that a simple change can make. Moving scenery or adding new background objects in a game can introduce bugs when the underlying code is based on the location of objects in the scene. We had situations where a pirate or dwarf would poof into the scene, only to find they were inside a rock or a new piece of furniture that hadn’t been there in a prior release. Other times, we'd find that the floor had moved, or a collider (an invisible barrier) had disappeared and our player in the game would suddenly fall forever into nothingness.

I described merges as "The Cygnus Dance." The dance requires that you take two steps forward, and one step back. We did the dance many times each day.

Let's talk about Unity

Before I shift gears and talk about marketing, I should say why we picked Unity, as opposed to some other game engine, or writing our own. Having built a game engine before, I knew how much work it is to build one. Our game engine at Sierra evolved over nearly twenty years. Obviously, there was no way we could make that time commitment, and there was no reason to. Modern game engines are easily available, and some can be used inexpensively or for free. I looked at the Unreal engine and at Unity. I can't say that I did an exhaustive analysis, but my perception was that Unity would be painless to get started with and easier to learn than the Unreal engine and that Colossal Cave is not the kind of project that needed to stretch technology to its absolute limit. I wasn't sure where the limits were, but the ease of entry was critical to moving quickly. I didn't know it at the time, but I had stumbled into exactly the right engine for the project. We have never regretted the decision. Unity has exceeded all expectations.

Botching a release in one easy lesson

In the summer of 2022, we were absolutely positive that the game would be complete on all platforms and easily be on the market by October 2022. As October neared, we realized that we were going to miss our date, but felt it wouldn't be by much, so we announced that the game would be released on January 19, 2023. We couldn't possibly miss that date, or so we thought.

When the date came, we were not ready. We had done very little marketing, not all versions of the game were complete, and we underestimated the effort to put the game into the various stores. Worst of all, we didn't understand, or at least I didn't, how much trouble we were in. I accept all the blame. I had been heads-down focused on development and hadn't realized how far behind we were on some parts of the project. We had done virtually no testing of ads, some versions of the game were caught in certification at the hardware companies, there were versions of the game I thought were complete that weren't, and setting up the stores at retailers was still a work in progress.

We did release several versions of the game on January 19, but other promised versions of the game were delayed. Our Nintendo Switch version slid by weeks, and then was approved only for release in the US, with the Europe and Asia versions lagging far behind. Our Xbox version has skidded to March. Our PS4 version is still bogged down in development, although to be fair, the PS4 and Xbox One versions weren't originally in the plans at all. I had always assumed that they were probably impossible. Fitting our game onto them is like cramming an elephant into a shoebox. It can be done, but it isn't easy.

With 20/20 hindsight I could have done more to ensure all versions of the game, and the marketing, was ready on release day, but I didn't consider it the priority. If players want the game in January, they'll still want it in March. In the great scheme of things, the release date is irrelevant. What counts is whether it is a great game. Worrying about the box, the marketing, or the calendar, are distractions that really aren't important when the time comes for a player to sit down to play a game. If an hour into gameplay the player is smiling and wants more, mission accomplished.

And sadly, there were problems with the initial release of our game that we should have caught during development. We elected to release the game with the puzzles exactly as they were in the original text-based game, warts and all. There were some puzzles in the original that were simply too hard (or some say, "illogical") for modern gamers, and we provided no additional hints beyond the few hints given by the original Colossal Cave.

The initial reviews of our game [dinged] us, using phrases like "Colossal Cave is faithful to the original game, to a fault." To our credit, we studied the reviews and immediately put into development patches for the issues that were seen. Recent reviews have been excellent, with most players giving us the maximum positive rating, but the reviews on release day were not as favorable. And unfortunately, because of how the review systems work at many of the hardware companies, the release day reviews tend to sort to the top of the heap…and stay there forever.

All that said, and as I am typing this, the game has been patched and is getting the love it deserves. Recent reviews have been excellent. If you buy it now, I am confident you'll be quite happy, and I'd appreciate it if you’d share your feelings about the product as widely as possible. I'd like the reviews that today's potential buyers see to match the game we are now selling, not the game that we first released.

Steam players were quite vocal in their opinions on our initial pricing.

The biggest single mistake we made was with the product pricing

Sierra’s games were typically priced in the $40 to $60 range ($100 to $150 in today's dollars). We released Colossal Cave at $39.99 not understanding how low prices have gotten. Triple-A games from major studios can command high pricing. Sierra had that kind of caché and could command premium prices. However, our new company, Cygnus, is an unknown entity to most of today's players. After receiving several customer complaints about the price, and worst yet, some negative reviews triggered by the high price, I tucked my tail between my legs and dropped the price to $24.99. Here's what I posted on the Steam forum explaining the change:

“Thank you all, and there is good news! We are repricing the game. If you look now, the game is $24.99. The fact that we lowered the price says that we listen to players.

And that said, I can explain a bit of what happened behind the scenes. As I mentioned earlier, I'm not sure this is a game for everyone. It targets a small slice of the market. It's a mentally challenging game in a world where the bigger hits are action-oriented. It's also a game that many of the target buyers feel they've already played. We didn't want to cheapen the quality of the game, so when you look at our production cost, and divide it by the size of the target market, you recognize that the price per copy needs to be high.

I didn't (and still don't) consider $39.99 to be a big number. You can hardly go to the movies these days, with popcorn and parking, and not spend that much. Roberta's last game sold over a million copies at $59.99, over 25 years ago! That's probably over $100 in 2023 numbers. I'd also mention that many of today's games, that are available at low cost, have in-game spending. We have none of that and don't plan on using this game in any way to make money beyond the initial purchase.

I should also mention that buying the game gives you all of: The Windows version, the Mac version, the Steam Deck version, and the Steam VR version (when it is available... soon I hope!). The Steam Deck version is a true Linux version that runs awesome on a Steam Deck, and the Steam VR version of the game is a big step up from what we released on the Quest 2. I should probably also admit that we got pinged for a few things on the initial release of the Quest 2 version and we have already incorporated those changes in the upcoming Steam VR version of the game. The Steam VR (or should I call it PC VR?) release will be an amazing one. From my perspective, it's a heck of a deal.

And all of that said: Today's price points are lower and player expectations are for lower prices. It doesn't matter what I think is fair, what math I run through my spreadsheets, or anything except what players think. The message I've heard is that $39.99 is too high, so we lowered it.

Ultimately, for Roberta and me, the game isn't as much about money as it is having happy players. We are very proud of the game and want as many people playing it as possible. It would be nice if we could recover our investment, but if we don't, we don't. The most important thing is happy players.”

Beware! Dwarves are attacking!

Positioning the product has been a challenge

I was upset when I saw our initial trailers for the game. Colossal Cave is not an action game, and players who are seeking something reminiscent of Half-Life will be very disappointed. There are dwarves in the game, and they do attack, but the encounters are [tame] by today's standards and are intended to be. Colossal Cave is not about the action. The dwarves are easy to deal with, once you know the trick, and figuring out the "tricks" is what Colossal Cave is all about!

Colossal Cave is a family-friendly game. Regrettably, our promotional videos showcased a knife thrown at the player, implying a degree of violence that frightens away our target audience, yet disappoints those seeking action. Our marketing group and I disagreed over how to position the game and it's still something we are agonizing over. Colossal Cave is a fun challenge for the whole family. I can't tell you how many hundreds, maybe thousands, of emails I've received from Sierra fans who talk about playing King’s Quest with their parents. We wanted that same experience for how this game should be played.

Some reviewers went into the review thinking we were marketing the next big triple-A action game, and that's not what it is. We need to position the game more for people who like escape rooms and solving 1,000-piece puzzles. Imagine a family sitting around a table trying to solve a puzzle together. That's our market. But reaching that market is not easy in today's world.

Emphasizing Roberta's role in the game may have hurt us with some players

There are innumerable articles pointing to a minority of male gamers who are resistant to the idea of female designers. Sierra had many female designers and I never saw any customers who cared about anything except being able to play a good game. Times have changed, and we've seen reviews of the game spammed by a series of 1-star reviews with no comments. It drags down our score and damages sales. It's hard to believe that such an attitude exists in today's world, but I don't get to make the rules. I just make games.

Lastly, it requires a HUGE effort to support all of the different stores!

Sony, Nintendo, Microsoft, Apple, Steam, Epic, GOG, Humble, Itch.io, Amazon, and more all have their own stores that feature our product. Each of them has its own dashboard where you set up the store that features your product. Each of the dashboards has its own quirks, and some are incredibly complex, with different settings for different regions of the world. Most have a certification process. Getting our game through all of the certifications and getting our store content everywhere has become a full-time job for several marketers.

In closing...

As I am typing this, we still have major releases of the game ahead of us: PS4, PSVR2, Xbox One, iOS, Android, and more. We are just getting started with our marketing effort. As a rule, you should market first and release the game later. Unfortunately, we didn't do it that way. The team was working long hours and weekends. We did not have an infinite budget or a huge staff. We bit off more than we could chew and are just now starting to get caught up.

But there is good news! Our game turned out better than I could ever have hoped. Players love the game and are giving it great reviews. The next challenge is to get the word out there. It's not easy. But, like I said, "If it was easy, anyone could do it!"

…to be continued…