Box Directive: Programming #05 – Rebuilding the Packing Loop

Moving beyond click to interact

Hey, Jamie here.

It has been a couple of weeks since my last programming update, and most of that time has been spent prototyping rather than building anything I would call finished (all amongst having a birthday, some time off and getting ill!).

After getting the new Shift System working, my attention moved back onto the actual packing process.

The original stations were deliberately simple. For the purposes of proving the early gameplay loop, most of them essentially boiled down to clicking something, completing that stage and moving on.

That did its job, but it was never intended to be the finished game.

So the last couple of weeks have been about taking the packing process and starting to answer a much more important question:

What does the player actually do at each station?

Almost everything shown in this post is still work in progress. The interactions, timings and visuals are all a prototype stage at the moment. The aim has simply been to prove that the stations can become more interactive and start producing useful information about how the player actually performed.

Taking the rails off

One fairly fundamental change has been removing some of the forced order from the old packing process.

Previously, the game walked the player through the stations in a strict sequence. Complete one stage, it locks and the next one becomes available.

That was useful when I was first building the loop, but it also meant the game was effectively telling the player the correct answer.

The new version opens things up much more.

There are still sensible restrictions depending on the state of the box, but within those limits the player has more freedom over how they approach the packing process.

More importantly, that means they can now make mistakes.

That might sound like a strange thing to deliberately add, but it is important for where Box Directive is heading. If the game always forces the correct action, there is not much for systems like Policies, Quality and Compliance to judge later.

The player now needs to understand what they are doing rather than simply follow the next highlighted station.

Making the stations more hands-on

The Filling Station is a good example of where these prototypes are heading.

Rather than simply clicking to fill the box, the current version asks the player to choose how much filler (packing peanuts) they want to use before physically transferring them into the package. There is still a gameplay element to build onto this station but it’s a step up from the click to complete process it was originally.

The box now visually fills through different stages, and the consumables themselves are starting to feel more connected to what the player is actually doing rather than simply existing as a number behind the scenes.

The Tape Station has probably been the biggest jump from the old version.

We have been experimenting with actually drawing the tape onto the box as the player moves the tape gun across it. The game can then look at where the player taped and start judging how accurately they completed that stage.

It is much closer to a small mini-game than the old interaction.

It will also look completely different by the time the game releases.

Andy already has another idea for how taping could potentially work, but that is exactly what these prototypes are for, to give us something meaningful to test and iterate on. The important thing at this stage is proving that each station can support something more interesting than simply clicking it.

Speed versus quality

Those new interactions are also allowing us to make the first pass at Box Quality.

The idea is that each station can produce a performance result depending on how well the player completed that part of the packing process.

Once the box is shipped, those results can be combined into an overall indication of its quality.

That then gives us something much more useful to build the wider game around.

A higher quality box could earn more money. A Company Target might ask the player to maintain a certain quality average. A future Policy could require a particular standard and penalise the player if they consistently fall below it.

It also creates a useful trade off between speed and care.

If the company wants throughput, maybe the player decides they are happy sending out more average quality boxes quickly.

If the target is quality, taking a little longer at each station suddenly matters much more.

Exactly where that balance lands will be driven by playtesting. If a five minute shift only allows somebody to complete three boxes because every interaction takes too long, then we have gone too far. If everything can still be rushed without any thought, then we have not gone far enough.

For now, the goal is simply to make the packing process more interesting and give the game something meaningful to measure.

Building around the prototypes

For the moment, these station mini-game prototypes are going to pause where they are.

I am deliberately holding off on things like skills and station upgrades until we have a much clearer idea of how each station is actually going to play. Once we understand where the friction and inefficiencies are, we can then build upgrades that genuinely improve those areas rather than just making numbers bigger.

The next focus is the systems around the packing process: Orders, the Employee Handbook and the first Policies.

Once those are in place, the information coming out of these stations can start to mean something. We can judge whether the player packed the correct item, made the right decisions, followed company policy and ultimately what quality of package they sent out.

After that I will be heading back into the Shift System to start tying everything together properly: payment, rewards, progression, fines, targets and the wider results of each working day.

Once that opening loop is in a clean enough state, Andy and I can come back to the individual station mini-games and start deciding what actually survives into the final design.

The aim is to get those opening shifts working properly from beginning to end and into the hands of our first internal play testers before we commit too heavily to what Skills, Contracts, Overflow and the later progression systems should look like.

For now, though, the important part is that packing a box is starting to feel a lot less like clicking through a checklist and a lot more like actually doing the job.

Catch you next time! And hopefully by then, I’ve recovered from whatever illness is killing me off right now…