Hello intrepid soup-makers. I thought we’d try a slightly different angle today to give you another varied peek at our dev process. For this week, here’s a feature we’re considering that still exists only in the world of concept. I wanted to show you why we’re thinking about it in the first place, and some of the considerations that might be necessary if we end up implementing it.

So how did we arrive at a ‘Vacuum Tank’ (other than it’s kinda cute)? Currently the post ‘early-game’ resource gathering is pretty time consuming. While there’s options for automating the soup creation and shipping processes, there’s no option for alleviating the increasing demands on ingredient gathering. It feels like the kind of player who wanted to invest some resources into this area should at least have an option. The Vacuum Tank can fly for easy scouting/movement, collect ingredients en masse and throw them home with ease.

As for implementation, code-wise it should be pretty straight forward. It’s the design cohesiveness that will probably need some extra thought here. The movement controls of this vehicle will set the tone for all similar vehicle types, as well as the throwing mechanic. These need to be uniform across all features, so we need to consider cases that might not apply directly to the Vacuum Tank (other flying/caterpillar tread vehicles, player’s own throwing mechanic) when designing these 2 controls.

Vacuuming is serious business for robots!

Hello brave world. 2014 is going to be a big year for Inc. Year of the soup! :)

Let’s get straight to it with one of the experiments we were running at the end of last year. We call it “Fever Time” (like disco fever). After a few cycles of shipping soup you hit this ‘fever time’ where all buildings and robots work extra hard to the disco beats.

Good points here are that it gives players a visible short-term goal to anticipate and prepare for. It’s also fun to ship HEAPS of soup in one cycle with a bustling visual feel.

It does feel a little counter-intuitive to play though, as it diminishes the value of shipping soup in the prior cycle. You know without doing anything you can just ship 4x more soup cans next cycle, so I find myself doing more preparatory jobs and laying the groundwork for the huge shipment to come. It’s definitely new gameplay, but I’m not sure if it’s additive or destructive yet.

Tests will continue. Disco robots never die!

Heya everyone :D I’m going to try something a little different this week. Normally I try to avoid the long-winded, overly-granular design discussions and give you something short and punchy about our latest feature. I thought for a change it might be interesting though to show you guys a more granular level of the thinking that goes into how we pick what to do each week. Disclaimer as always, everything is in a state of flux and it liable to change (hopefully for the better!). So here we go!

We’ve been considering the soup “satisfaction system” that went in a week or so ago and the flow-on effect it’s having to ‘pressure’ on the player in game. Currently, the level of pressure feels somewhere between mediocre and frowntown. :( Here’s a run down of the current system, the results and some potential fixes.

Satisfaction system: Customer satisfaction starts at 0%. Shipping soup increases satisfaction between 5%~15% depending on how much they like the flavour shipped. Satisfaction slowly decays over time and sending a bad flavour can sharply reduce it by -5%. Money is earned each payday from shipping the soup to satisfy customers.

Motivation to ship soup: 

• Buy research (the research and upgrades purchased are all quality-of-life improvements related to building a base & shipping soup).
• Collect as much money as possible for Soup Co. to fulfill an end-game condition (effectively a high score with no functional application beyond bragging rights).

Here’s the two pressure points that are currently in-effect.

ENEMIES: Spawn conditions:

• Fail to ship soup for a while (punishes players already under-performing).
• Ship bad soup (punishes players already under-performing).

Available design knobs:

• Spawn timing
• Number spawned
• Relative strength (HP, damage)
• Behaviour (flying, charge attacks, lays eggs, aim target buildings)

OXYGEN: Spawn conditions:

• When outside, the player’s oxygen bar depletes over time until it runs out and they suffocate. Linked to the world environment, it is omnipresent and unchanging.

Available design knobs:

• Suffocation speed

Current pressure problems: Neither of these are currently tied into the gameplay cycle. A regular player will never be attacked and not engage with the leash-range of the oxygen. Without external pressures there is no forced validation of your base design (“Oh noes! My eastern wall and corridors were breached. I need to build more towers over there and change the corridor angles!”). This also means there’s no “Yay” moment to watch your newly improved design overcome previous challenges.

The research rewards are related to soup shipping but, that activity itself doesn’t produce any pressures (“Yes a new robot and quicker soup factory! Now I can make even more soup faster!”). These rewards are helping perpetuate the current pressure-free play cycle.

On the note of “pressure”, what constitutes “good” and “bad” pressure for Inc?

Good pressure: Present a problem that has multiple solutions requiring player action.

Bad pressure: Present the player with a problem that has no engaging counterplay. Can also be short on available design knobs to turn for tuning or balance.

So what do we do?

The first low-hanging-fruit change would be to tie enemy wave spawning to soup launches or the satisfaction percentage. Pressure it creates will naturally scale relative to player base size. More soup exports on a bigger base will certainly incur more enemies, but a bigger base also implies further research progression and better defenses. This should feed nicely into the soup export reward-cycle which already produces things directly related to the act of building a base & shipping soup.

A potentially more impacting long-term test (albeit difficult with our low number of developers) would be to try replacing the oxygen system with a fog-of-war. Fog-of-war maintains a similar vibe to the oxygen while also creating a new currency of ‘vision’. Buildings produce a light radius, so base building for safety is still necessary. Navigating the dark is also a problem that comes with better risk/rewards (restricting information can lead to enemy attacks or your base being partially destroyed rather than the time-tax of returning for air vs death).

Let me know in the comments if you guys enjoy this sort of thing and I’ll try to do one every now-and-then. Or yell if you just want more GIFs. :P

There we go.. NOW I feel connected with my soup eating customers. The new GUI we’ve added this week lets you see exactly how satisfied they are with the soup you’re currently shipping. In the future we’re thinking different planets could have different flavour preferences, difficulties to satisfy, *insert your fun idea here*. :D It also gives us a chance to visually bring in some of the outside Galaxy, showing you the planets and faces of real Soup Co. customers!

I love how the “BAD!!!” guy clearly hates it, but is still forcing it down for some reason. Nice work Yamamura! :)

We finally have our newly designed towers and they are WA~AY more engaging than the old towers. :D

So the ancient debug towers from another era had 360deg vision and could shoot through walls. The new towers obey proper line-of-sight (LOS), have a reduced vision and CAN’T shoot through walls. Base layout really matters now when you get attacked.

I also found an unexpected use for our T-junction corridor pieces. “Makeshift roach-motels” to bait enemies looking to come inside. :)

So.. it looks like we’re suddenly submitting for the IGF! There wasn’t much time this week, but we’ve been trying to fix any show stopping bugs and make the first-user experience better. To help nudge the judges along, some simple tutorial popups went in and there’s new visual feedback on the matter and coin collection. There’s also a simple first version of the order framework, where the Robo Exec orders particular types of soup to satisfy hungry planets.

This will be this first time Inc has been played without one of us there to observe or answer questions, so it’s a real usability test. If judges can’t make it to any fun stuff, it’ll be such a waste! >_<

Here’s a soup factory I made today (shortly before it was destroyed due to a bit of a power supply issue). Time to break it on down FUNKY style!

The farms for mushrooms and Tomatys are tucked away in the mountain on the right. Conveyor belts ferry ingredients into funnels (still debug with no art) which transfer them to adjacent buildings. The soup then gets carried to the waiting launchpads.

Next step was going to be building more factories and launchpads, to really scale up production. Would also have needed more greenhouses and a larger area for farming Tomatys to make enough soup.

Even with basic defenses it held out ok, but it turns out power generation was a insufficient. When I eventually got attacked and all the towers started shooting, the base immediately ran out of power and I got promptly overrun (still valiantly tried to hold it myself with fists of justice!). I probably shouldn’t scale up so quickly next time without appropriate power supply. ^^;

“What’s the end of the game?”

There’s some ongoing ideas that we’ve mentioned, but let’s discuss a few more here just to see what comes up.

The original idea for turning the local fauna & flora into soup came from a restaurant concept, where players would shoot the soup into customers’ mouths until they exploded from gluttony. Then used their corpses for yet more soup. Deliciously macabre!

The restaurant was meant to be the bait to lure customers in, but galactic food tourism could work too.

Design-wise, this could create some weird balances between the player and their primary income source (you have to use your main export as tower ammo?). It might also discourage exploration as you can just call down your ingredients. Still, it’s an idea!

This also creates awkward questions from the local galactic police. What if they were the waves of enemies you needed to fight back with towers and defense?

So our original end-game idea is still that you eventually make your own soup company and ‘go indie’. That’s still on the table. How about this one from Yamatron though. To escape your soup making forced labour, you eventually research a secret soup factory where you can turn YOURSELF into soup. Then launch yourself into space to escape your  punishing salary-man existence!

Again, all just ideas, but ideas don’t impact development. To actually implement any of these would require lots of design gaps to be filled in though. Still.. it keeps coming up. Bad ideas tend to just get left behind and forgotten. When you ‘chasing the fun’ though, the best things are just unstoppable magnets, and people swarm to them.