Looks like the next season of Spoiler Warning is delayed until tomorrow. So let me fill this awkward silence with this random post. I’ve heard it said before that talking about your plans gives you a little release similar to the satisfaction of actually carrying them out. Since I already have a game on the way and I don’t actually have time to do anything with this, I thought I’d just throw the idea out the window in case anyone else finds it amusing.
I’m not sure why you’d want to read this. It’s a rough sketch of a game I’m likely never going to make, and it exists solely as a means of getting it out of my system. This isn’t game design. It’s therapy.
On the other hand, I swiped a bunch of pictures of candy, so maybe you’ll enjoy looking at those.
Anyway, this whole Candy Crush Saga nonsense has reminded me of an old design doc I’ve had gathering dust in my head. The core of the idea comes from the notion that normal real-world business has a lot of really interesting tradeoffs associated with it. My time working fast food (and talking to one of my brothers, who worked for a big-box home improvement chain) revealed all sorts of fiendish sorting, queuing, balancing, timing, and planning puzzles. (Like this one.) This sort of thing lends itself to strategy gameplay: “Given my finite resources of money, space, time, manpower, and throughput, how can I optimally achieve [goal]?”
You can play this game in its purest form in the Capitalism series. That’s fine, but I always thought Capitalism Plus was a bit too sterile or abstract. It doesn’t matter what you’re making. You might as well be making widgets, as far as the player is concerned. There’s no real personal investment or creativity in the stuff you’re producing, and I always wanted to see a smaller-scale game that focuses on a single product and lets the player have some control over it.
The other inspiration for the concept comes from the occasionally wonderful How It’s Made videos. It’s no longer on Netflix, but it’s available on Amazon Prime. The show features a lot of food being made, and I’m always amazed to watch giant piles of raw materials enter the machinery and pop out as colorful, aesthetically pleasing quasi-food on the other end. In particular, Season 3, Episode 25 shows them making jelly beans, and that helped shape a lot of my thoughts about how this game ought to work.
- Candy is colorful, vibrant, and pretty to look at. Everyone “gets” candy, even if they don’t really like candy themselves.
- It’s useful year-round, but has a few periodic spikes to encourage forward planning. High-end chocolates are in demand around Valentine’s day. Bulk cheap candy is in demand at Halloween. A specific set of specialty flavors and shapes are in demand around Christmas.
- It’s typically made from easy-to-model geometric shapes. Your 3D artist can make a jelly bean about a thousand times faster than they could make (say) cars or toys. Actually, all the candy could probably be procedural. Canes, pops, drops, beans, sticks, and spheres can all be made with trivial mathematics.
- It has room for easily modeled creativity and player expression. Making a game that let you design cars would be hard. A game where you design silverware or kitchen appliances sounds mundane and boring. But candy looks appealing and has lots of properties to modify.
- It has straightforward manpower throughput problems. (See below.) It doesn’t need a bunch of different types of workers that add complexity without offering more interesting decisions.
- It’s a business that goes directly from raw materials to consumer product, which keeps things elemental. (As opposed to (say) computers, where your company is just one in a long chain.)
I figure gameplay would be something like this:
The player designs their own candy: Pick the shape, the material (chocolate, pectin, gum, hard candy, etc) the color(s), the flavor, the outer coating / finish, and give it a name. Different candy requires different machines. So you need gizmo A to make candy with a smooth glossy coating, machine B to make anything from melted chocolate, machine C if you want the product sprinkled with sugar, etc. The more machines you have, the more stuff you can make. Machines are expensive and each one has a different footprint to make the design of efficient production layouts interesting for the player.
Once the player has designed a candy, they queue up X batches of candy Y. Employees will grab raw materials, then move the product from one machine to the next. When complete, the employee will deposit the candy in the “warehouse” and the player can look for a buyer. The strategy would come from decisions regarding hiring, layout of the production floor, and in designing and selling the candy.
The game would run in abbreviated realtime, like Sim City. So N minutes of playing would equal one month of time. There would probably need to be a “fast forward” button to get the player through sections where there’s not much to do.
I don’t want to make a system for “judging” the player’s inventions. If they want to make lemon-flavored, spicy hot, purple-colored, chocolate-covered sugar cubes that they named “Crappies!”, that should be totally valid, even if I’d never put one in my mouth. Instead, different products would rise and fall in popularity according to some general “candy fad” simulation, so you want to have a diverse menu so a drop in popularity of one product doesn’t result in insolvency. Candy becomes gradually more popular the longer it’s out there, so it might be worth it to keep making Crappies! to keep the brand name alive, even if there aren’t a lot of buyers at the moment.
The mechanics of the “candy fad” simulation should be unpredictable but not random, and the exact logic should be hidden from the player. Like in real life, they should have to probe the market and figure out what the public wants.
Long-term, the game would have you spreading your empire over some sort of map with competing candymakers, with the trick that territories further away would be harder to conquer due to increased delivery costs.
The other thing I’d like to explore (or see some other game explore) is some actual human resource strategy. In most games, you hire generic interchangeable mooks for a fixed pay and they begin performing their duties at full capacity. If they do have differing stats, you can usually see those up front. If the game is really fancy, maybe they bug you for a raise once in a while. In any case, labor ends up being a tiny little percentage of your overhead. This is hilariously far from anything resembling the real world, and I think we’re missing out on some cool decisions.
In the real world, labor is typically your largest expense. You can’t tell how good someone is until after you’ve already hired and begun training them. Employees start out useless and gradually become proficient over time. There’s a certain cost to getting someone up to speed, which means you’ll have a quasi-incompetent rube clogging up the production line until they learn the ropes. Different people learn at different speeds. And finally, different people have different caps on their performance based on their personal ability, and those caps can vary wildly. Sometimes there’s that one person that’s just a Jedi Master at running the machinery, and some people never rise above “acceptable” no matter how long they stay with the job.
This forms a really interesting long term / short term dilemma and creates a need to plan ahead. You’ll hire people blind, and then over time you’ll see how they turn out, performance-wise. By the time you discover Alan is pretty-good-but-not-amazing, he’s going to be fully trained at his job. Do you get rid of him in hopes that his replacement will be more naturally gifted? That might work out better in the long run, but in the short term you’ll have another newbie slowing things down.
Interesting gameplay often comes from interesting decisions. Civilization (the game) is basically a giant decision-making system. My hope is (or, I suppose, was) that the balancing act between these needs would draw the player in.
- Player gets bulk discounts on raw materials. So buying ten bottles of corn syrup is less efficient than buying a single ten-gallon canister, which is less efficient than buying a fifty-gallon drum. And a lot of products will vary in price throughout the year, spiking just before you’re most likely to want them. So you want to buy big at the right time, right? But storage space is limited, and the more crap you have the more floor space it will consume.
- Having a broad range of active products builds your brand awareness, making all your stuff sell better. But different products require different machines and raw materials and thus floor space. So the more diverse you are, the lower your throughput is.
- The quality of the final product is tied to employee skill. So if you want to make high-grade, high-margin premium candy you need to have seasoned experts on the team, but if you just want to spam the world with colored sugar then you can (if you want) run a sweatshop of cheap transient workers.
- The big three candy-selling holidays have massive demand and your margins will probably be far above usual, so you’ll want to sell as much stuff as you can. And of course they’re all packed in a nice 5-month period instead of being spread out evenly. But candy has a limited shelf life. (The quality drops over time once it’s sitting in the warehouse waiting for a buyer.) So you can’t make stuff too far in advance.
- You can do research to unlock new flavors / machines / shapes. If you’re the first one to invent a “super tart” coating, then you’ll be the only one that can sell to that audience. But once an idea is in the wild, it becomes cheaper for your competition to research. (It’s actually cheaper based on how many products use it. So if EVERYONE is making “super tart” candy, then the technology will become effortless to obtain.) This means that if you spend to get ahead in the tech curve, then you’re kind of paying a lot of the costs for everyone else. So maybe research and get lots of exclusives, or ignore it and save a lot of money to spend on infrastructure or workforce.
So that’s the concept. It’s sort of daunting to see it all mapped out like this. It would technically be much easier to code than Good Robot, but it would be far more challenging to balance and test. If I make lasers 10% more effective in Good Robot, I can fire up the game and within five minutes I’ll know if I like the new system. But if I was testing Candy Empire and I wanted to see the effect of making research cost 10% more? That could take a long time to get a feel for how much of a difference that makes.
And now hopefully I can stop thinking about this and put my mind on more immediate problems. Hope you enjoyed reading it.
Secret of Good Secrets
Sometimes in-game secrets are fun and sometimes they're lame. Here's why.
id Software Coding Style
When the source code for Doom 3 was released, we got a look at some of the style conventions used by the developers. Here I analyze this style and explain what it all means.
So what happens when a SOFTWARE engineer tries to review hardware? This. This happens.
Grand Theft Railroad
Grand Theft Auto is a lousy, cheating jerk of a game.
Batman: Arkham Origins
A breakdown of how this game faltered when the franchise was given to a different studio.