next »

[Faceplanting Loaf]

Welcome to ERROR Code, a two-player asymmetric coop game. One person plays the mechanic, the only person awake on a luxury cruise ship flying through space, who has to repair the vessel before he can go back to his cryogenic pod. The other player plays the AI, who offers hints and directions to the player based on the information that the mechanic provides about the ship.

So my wife and I came up with the idea for Ludum Dare a week or so ago and utterly failed to get the thing finished in time, but we loved the idea so much that we decided to keep working on it. I work mostly on the art and she does the programming. This was the first time I had really used Unity for anything beyond rendering my models, so it was quite an interesting experience to say the least.

We also had a friend who helped us with some concepts for the important features like doors and the character art.
Doors- Fancy

After several failed attempts, we reached a door that felt sufficiently scifi whilst still looking like it could be on a classy spaceship.
The "Mechanic"


Here we came up with the mechanic. Turnes out sculpting and retopologising folded boiler suits is far too hard when all you've had for 24 hours is coffee and a slice of pizza, so he ended up with just some grey pants. I also used all the base materials that come with Substance Painter 2 rather than bothering to make my own in Designer. Gives him a slightly generic look (and also makes his trousers look like carpet) so fixing that is on the to-do list.
Hydroponics/Oxygen

And this is what the Oxygen room was supposed to look like. It ended up as just another generic box room because of time contraints. This was one of the concepts that made me want to come back give this project the love it deserves.
Tour of the Reactor, Oxygen and Cargo rooms

And here is a gif that shows our progress. There are many more rooms than those shown, but most of them are bare and a few have no lighting at all. Although I am gutted we never got the running animations in, I do quite enjoy the way he hovers around the ship with his arms folded...

Next thing to work out is why the metallic maps are so dark.

[whistlerat]

Just popping in to say that I'm the designer and programmer of this project For my part, while I feel I achieved a LOT over the 3 days, it wasn't enough to call it finished. I might have been able to make it work if not for one key roadblock which I realised far too late! But to better explain that, let me talk more about the game concept in general. Wordy post ahead!

The prompt for the LD was 'Running out of power', and the idea which came to me, that I liked the most, was inspired by the movie 'Passengers' (for its narrative focus and context) and 'Keep Talking and Nobody Explodes' and Artemis Spaceship Bridge Simulator (for the asymmetric cooperative play, and particularly the 'disconnected' aspect when it comes to Keep Talking). ERR?R C?DE (so named because of the essential focus of the gameplay, working together to interpret and decrypt codes even when power continues failing ship-wide and some of those codes are corrupted) is a game to be played by two people using two completely separate but in-sync pieces of software - 100% offline.

The first piece of software was made in Unity, and represented the 'gamier' half of the two. In it - as can be seen in the images Bo posted - the player controls the mechanic who has been woken up to fix the ship, and is able to fully wander the ship and interact with all the stuff inside of it. In doing so, the player will gather error/fault codes which the ship is using to communicate what is wrong with it, and how to fix it. The mechanic has no means of 'translating' these codes by themself, which is where the onboard helpful AI comes in.

The second piece of software is a simple command-line application to be used by the other player. This puts them in the role of the ship's AI, a very knowledgeable but restricted entity which can do helpful things like interpret error codes, override locked doors, or create emergency codes to temporarily restore power/lights/systems. The AI, however, can do little to nothing to actually fix the ship itself, nor hook directly in to the ship's diagnostics, which means that the AI-mechanic relationship is entirely codependent and symbiotic. Both have to work together to achieve the common goal, which is to discover the cause of the ship's faults, fix them, and restore power so that the mechanic can go back to cryo sleep and the ship can carry on towards its destination (at least until something else goes wrong and he gets woken up again...)

After building the bones for the Unity-side, which involved creating a system where a keyboard-controlled player could move through rooms connected by doors and ladders (I'll post some of my delightful texture-less, basic-geometry gifs when I get back on that pc), I set to work on deciding how, exactly, the rest of it would work. We needed both halves to be 'in sync', but I wanted to avoid any kind of networking. As well, I didn't want to just hand-craft a scenario, or several scenarios, and have both players just pick the same one and go. No, I wanted to make life harder for myself. Because that's a great idea in a gamejam. 

So I started work on my ScenarioBuilder. Using .NET's in-built Random class, I slowly (quickly? it was only 3 days!) built up a C# library which could do the following:
- Pick a root problem from a list of possible ones (like shield failure, reactor running out  of fuel, reactor overheating, etc)
- Pick a knock-on problem caused by the root one (for example, a shield failure might result in a hull breach)
- Do the above step a few more times with either the root problem or any of the others, to get between 2-5 overall problems
- Per problem, pick the effect on the ship (so this would be the 'symptoms' of the problem you are trying to diagnose, which could be certain systems going down, loss of air pressure, etc)
- Per problem, generate a solution required to fix it

A 'solution' involves:
- Between 1-4 individual steps
- A step could be entering the correct code into a particular terminal, pressing a certain button, manually repairing a certain broken panel/object

And each step involves:
- The action (press red button)
- The target (of the control panel in room ABC)
- The code required to learn about the step

Because of course the mechanic can't learn about the solution and its steps until the AI player explains it, but the AI player can't explain it until the mechanic has obtained the correct code for the AI to interpret. The flow should go like this:

- Mechanic obtains a code, eg A56H0
- Mechanic relays this code to the AI, who uses his console application to figure out what it means
- AI relays the decoded information back to the mechanic (which could be something like 'go to room XYZ and trip the switch on the 123 control panel - this corresponds to a solution step)
- The mechanic carries out the action

Repeating the above is the basic loop for completing the solutions and thereby winning the game.

My ScenarioBuilder worked /really/ nicely. The joy of this was that, if both pieces of disconnected software generated the EXACT SAME scenario, they would be able to work together without any networking at all! I was able to generate quite complex and varied scenarios, with different problems, effects and solutions utterly effortlessly once it was finished.
This only corresponds to raw data, though; now I needed to hook it back into the Unity game, make the game properly give the player the codes necessary for the AI to interpret, and then make the game acknowledge that solution steps were being satisfied, when... the roadblock happened.

Turns out that System.Random cannot be 100% relied upon to produce the same random numbers across applications when given the same seed. It was something that I had just taken for granted, foolishly, and discovering that my console app and Unity app were generating different scenarios with the same seed... pretty much scuppered it all, because it was too late, and I was too exhausted, to figure out how to fix it. We called it a day in the state you can see above.

But this is hardly an impossible challenge, and I have since solved it (and very easily, too... but I forgive myself for being too drained to do it at the time). Rather than rely on System.Random, I will be using the Mersenne Twister for my pseudo-random numbers, which puts their generation entirely under my control.

This puts the core concept sqaurely back on track, which is awesome. Future posts of mine will hopefully have more going on visually, but hey, that's what the artists are for It'll be nice to just be able to focus on the mechanics and code behind!

[Faceplanting Loaf]

Okay, done loads of artwork over the past few weeks. Built a few rooms kinda at random but here goes.

The Shield generator. The particle effects are a work in progress (they sorta expand at random and there is obviously a bug with the farside of the circle particle there), as is the lighting. Right now the player character gets a little lost on screen, so I'm going to have to make sure he gets lit up sufficiently. I might have him in a sealed chamber with internal lights...
 Also just noticed how my shield generator animations don't play. They're supposed to spin!



Behold the mighty SPACE PISTON:

I may have watched a little TOO much Titanic when planning out the interior of the ship and forgotten than spaceships don't run on steam but there is just something so incredibly satisfying about pistons, so I am sure I can find a use for it. Now I realise that actually that has spinning components in it as well! I am sensing a theme.

Unfortunately we have hit a small hicup when importing to Unity. The animation jitters at the end bit in a way that isn't the same in Blender. Not quite sure why yet.
(ignore the dodgy framrate; I like to murder my graphics card with Screen to Gif, Blender, Substance Painter, Designer, Unity and Zbrush all open at once)

This is a glamour shot of the room it will live in:

*sigh* if only I could make it that beautiful in Unity

Lastly the amphitheater.

Spent ages making this, only to realise that by holding "v" I could snap vertices together. Too many shortcuts; too many programs.

[tankorsmash]

Pretty cool dude. I worry that I'll run into a similar issue with System.Random with my stuff. Having inconsistent behaviour across identical code on different platforms is the absolute worst.

[oahda]

Cool! It's actually not to dissimilar to the idea I originally had for LD too (ended up doing a fancy slide puzzle in a spaceship instead, because I wasn't feeling well enough for anything that ambitious). Maybe now I'll get to play what I imagined! So there's no jam version up to play? Looking forward to seeing what happens to this anyhow! Not sure I get entirely how the role of the AI works, but guess I'll see eventually. c:

[whistlerat]

We did upload a version to ldjam (just out of principle) but it is unfinished to the point of virtually unusable - little more than something to poke at and way too easily broken, not to mention most of its features are inaccessible because I never got time to hook them all together! But we have a fairly aggressive schedule to get this done quickly, in the spirit of the jam, using mostly our original scope - only a little garnished. Trying to avoid feature creep despite giving ourselves considerably more than three days! So hopefully you'll get to play it before too long, especially since it'll be free.

The AI aspect is kinda hard to explain! I think the best way to think about it is like the player in Keep Talking and Nobody Explodes who has to read the pdf/printed manual on how to defuse the bomb parts, except instead of a static manual they have a console-line program to tell them how to fix things.

Thanks for your interest

[Faceplanting Loaf]

So this is the second pass on the oxygen room. [un]fortunately I don't have pictures of the muddled first pass, which had what I can only describe as toilet paper tubes stuffed with moss. It was weird.

I am having some challenges with the glass on the tube. Seems like unity does not like glass without an HDR to provide even lighting. It will have to be a polish feature, I think.

[Faceplanting Loaf]

WIP of the mechanic's spacesuit. Although we don't plan to have EVA missions in Version 1, the spacesuit will still be used in oxygen deprived rooms or otherwise hazardous situations.

[Faceplanting Loaf]

Significant update on the mechanic's spacesuit today. Really struggled to get to grips with the spacesuit mask, but settled on a welder's mask sort of setup.

[whistlerat]

Finally got a chance to work on this again (I think I needed the ~month breathing space after how intense that jam was) and the first thing I've done is get the random number generators working properly. And as I thought, it was pretty easy - just grabbed an implementation of the Mersenne Twister and added to both sides. Boom, consistent scenario generation:

As a quick aside, I wanted to mention that we've had some interest for composing for EC, which is super flattering and we're grateful for all enquiries (especially at the high quality of those approaching us!), but in the interests of transparency we are releasing ERR?RC?DE for free - and as such have no budget to spend on a composer at this time. If you're interested despite this, then by all means drop either one of us an email

[Faceplanting Loaf]

Mechanic's spacesuit is now textured.


I have also started animating him, but it looks like complete garbage right now. I have not practiced animation in a while...

[Faceplanting Loaf]

Worked on the Control panels today. These will allow players to complete the objectives in the game, as the AI will direct them to certain control panels to fix certain problems.


This is a wall-mounted version. I have had some issues with glass in Unity, so getting the glass door to work is proving a challenge.

This is a freestanding version for catwalks and other rooms where there is no wall space.

[Faceplanting Loaf]

So. Unity Asset Store sale happened. I may have gone crazy. Be prepared for particle effects.
I now have this wonderful distortion effect on the shield generator room, which I borrowed from the Realistic Particle Effects pack 4 1.1. Super lush.

I have also begun work on the cryogenic room. This is the room the player wakes up in.

[tankorsmash]

Ignoring assets, how much of the game is playable? It seems like a lot of the work is on the assets but I'm curious to know how the gameplay is coming along?

In terms of assets, is there a shader or something you can use to maybe tie them all together? I know I've had some problems where all the assets I've gotten from different sources all look fairly like they're from different people, giving my games a somewhat patchy look.

[whistlerat]

Ignoring assets, how much of the game is playable? It seems like a lot of the work is on the assets but I'm curious to know how the gameplay is coming along?

In terms of assets, is there a shader or something you can use to maybe tie them all together? I know I've had some problems where all the assets I've gotten from different sources all look fairly like they're from different people, giving my games a somewhat patchy look.

The most recent work that I did made it technically possible to end-to-end the game but there are still a lot of little things which make this imperfect. But after cracking the randomiser, I worked on being able to fully realise the generated scenario in the ship, which meant things like making the right terminals require the right passwords, and putting the error codes (which you give to the AI for interpretation) in the game. Right now that just means displayed by a terminal 'up front', or found by using the diagnostics, eg:

Giving these codes to the AI console to interpret returns instructions which basically say 'go to this terminal in this room and input this password' which then completes that solution step permanently. This also results in that first code disappearing from its source because the issue is solved, the game shouldn't present you with dead information like that.

I also put a quick&temp menu at the beginning so that it's possible to sync up the randomisers on the two bits of software (this doesn't care what you input so long as its 6 letters long):

The game also keeps track of progress, so it knows when you've completed all of the solutions and essentially won the game. Which makes it playable in a minimal-viable-product way I guess!

As for the assets, Bo is actually making them all himself (modelling and texturing), but this is not only our first time making something together but his first time making a full project with lots of connected pieces that have to work together, and it's a hell of a learning curve for both of us! I know that we're planning on releasing this version for free partly to honour the fact it was meant to be done in a jam and partly because we don't want to spend the time necessary to get it polished enough to charge for, since it has been primarily a teaching tool for us. Assuming it's basically fun and some people like it, we've agreed that we'd be interested in making a better version with more features (trying to avoid feature creep is hard but we're trying to stick to our original scope, which was already too big for a jam) and revamped visuals.

My next task is to add in the other things for the mechanic to interact with which make the solutions more complex, because right now (in order to achieve this minimal playable state) I stuck with only terminals to keep things easy. But we want there to be control panels with buttons and sliders and other things to change, as well as (small) hull breaches to fix and general things that need fixing so that it's not all about the terminals.

If you have any suggestions on what doesn't look cohesive though, visually, we would both appreciate feedback I give my own feedback as much as I can but outside opinion is always welcome!