Making Surgeons Please ( jam postmortem)
Surgeons Please is my entry for the Utah Indie Jam, 2022. I enter every year if I'm able. It was made live on twitch in 29 hours (counting sleep/etc). The theme of the jam was "Re-connect".
What game am I making, anyway?
I spent almost the entire first night thinking about how I could make a game based on "re-connect". I had a few ideas, like making a game about repairing a ship, and reconnecting with earth, but by the end of the night I'd decided on a game. The idea was such. You're an alien surgeon re-connecting limbs to races you've never seen nor understand.
Last year had some really strong competition, and there were several games that stood out to me as something I'd want to replicate. Chief among them was the understated "Upcycling: Giving Trash New Life", by Palladian1881, which, if I'm remembering correctly was a small team. I remember watching the presentation of this game and feeling really warmed by the concept. It's a crafting / sales game about crafting useful items from discarded trash. There's a great video on the gameplay on the page if you're interested.
Papers Please by Lucas Pope is a dreary simulation game where you work as an immigration checkpoint in a corrupt soviet-bloc era fictional country of Artotzska. I think about it a lot, as its a very charged, emotional game, yet is also entirely systems driven to demonstrate its message.
What we take and what we leave
With these influences, there were a few things I saw as necessities for the project.
•Have a low-fi, ideally dual-tone art style
•Have 'customers' that walk to the counter
•Have a counter, where you can organize papers and have various accurate depicted real world objects to interact with. I wanted a clock, a radio, and as many other gadgets to interact with as possible.
Hitting the ground with a Plan
The next morning, I had a little more than 24 hours left, and I intended to still enjoy my normal life, making dinner, going out etc, which meant I had to be BRUTAL with the scope and cuts of the game. There are a few decisions borne out of this that made the game fairly unique.
• The game would have a fixed resolution of 256x144. I came to this resolution by comparing with Paper's Please.
• I would do all art at this resolution. This had several benefits, but the biggest was the time save in placement and handling of the sprites. I would only have to drag the sprite into the game and it would be at the perfect scale and position. Every time.
• All music is from Audiio, a licensed music site which I purchased a lifetime license for years ago. I would listen to music purely from audiio while working to help nail down the tracks and style used.
Using photo reference, I sketched out a pharmacy background and a counter top. The photo reference had consistent lighting that I was able to use to inform my art. Deciding where the light is is one of the first steps you should have when created art. For all my of pixel art, unless otherwise necessary, I use the same palette I've been using for several years.
Originating in a pixel art forum, Pixelation, I have made slight customizations over the near decade I've had it. Choosing a palette is important for time efficiency in my art. If you've locked in your colors, you can't overthink which color to use as much, which can make creating new things very time consuming. Before I adopted this palette, it would have taken me days, if not weeks to do the amount of art I did for Surgeon's Please, and I likely would have had to do significant revisions as well to maintain a cohesive style. By locking in my colors, I was able to do all of the art for the game; before even opening up a code editor for the game; in 1 hour. The time save I get from these techniques (locked in palette, photo references), is insane.
Overthinking the interface
While I had the gameplay art locked down for the game, I always struggle with UI. Your user interface is a great opportunity to inform your world and really get your player invested, which means I always struggle with it, because the style for every game is a little bit different, and requires a different approach for the UI. I ended up deciding on an office theme, and attempted (probably unsuccessfully) to style various buttons as manilla folders, or clipboards. I'm still very happy with how this turned out, though I made the decision to off-color some things to make the world feel more sickly and sterile. That, I kind of regret. I think I could have made better art without this decision, and I ended up having to recolor a few things in the editor anyway.
Controversial architecture
Time to talk about the programming. Like any game jam game, the code is FULL of bad practices that you should never do normally, but there were a lot of time saves here too. First, the most controversial (for some reason) choice.
I used a very old version of Unity Intentionally.
For quick projects like this, I tend to use Unity5.0, for one reason, and one reason only (though it's good practice to lock your engine version unless you need new features). I needed Unity-script.
Unityscript is Unity's fake language, it's intended to be used like HTML5's javascript, but it breaks tons of stuff, despite basically being C# with a funny hat on.
But using unityscript as a solo developer is very important! You lose the ability to do webGL builds, the performance is worse, and there is basically no compatibility with C#, nor is the documentation any good, occasionally non-existent, especially for Unity5's UI. The result of course, is that I hate working on UI, but the time save is HUGE, comparatively.
For that tradeoff, every single script you write is going to be much shorter. As much as half the size in some situations. Because Unityscript handles your includes, references, and in general technical, time consuming programming tasks, automatically.
What that means for me is I can save myself thousands of words in my script, meaning the script gets done faster, and conversions that C# can't do, unityscript can without any hassle, meaning I also don't have to declare new variables to create new references, and can assign by references, and Unity will fix all of it.
There's also some other benefits, namely that Unity is getting slower and slower in the newer versions, and the newest of them forces recompiles practically constantly. Using an older version like Unity 5, means that I never have to deal with this:
There are ways around that of course, but the less things I have to fix to finish, the less time I spend making the game, which in a short deadline of 29 hours, is VERY important.
After that, there's some other considerations that are actually good practice, and saved me a lot of time. I try to do this in every project.
I never, NEVER write the same code/logic twice.
No duh, right? Kinda. But specifically, in Unity, this is extra important. Unity uses an ECS(Entity-Component System), which requires some extra considerations. Instead of writing a script of how X works, you have to write that script AND put it on an object (an Entity!) that will then call and activate that script.
What this means, practically speaking, is that I can create simple, 5-10 line scripts that only do one thing, when asked, and I can duplicate that script across every object in the game world, rather than having each object script need to recreate that function.
Don't get me wrong, this is NOT better performance wise than how 'best practices' would be for a professional project, but you know what?
It's faster. It's a LOT faster to make.
Because of these tactical choices, the game was mechanically 'finished' in 14 hours. Just over 8 of those hours was actively working on the game. With that, the second 'work' day had finished, and I went to bed. If this is what I had to submit, I'd be happy with it.
The Next Morning (9 hours later)
With the bright, bleary eyed morning, came problems. I was proud of what I've done, but all I had so far was a simulation of the pharmacy. I had completely neglected polishing steps, so there was no menu or plotline visible in the game. With about 5 hours to submission time, I decided I could do something about it.
I would normally create a full menu, with a settings menu, but decided that wasn't necessary due to how I built the simulation. Music was controlled directly by the radio on the desk. I added an opening cutscene with some plot, and buckled down to spend the rest of the time on polish.
Typical polish I worked on
One of the biggest things I've adjusted to since selling games for money is the difference in quality and polish between a free game and a paid game. Since learning these differences, I've tried to put a lot of work into making every game I release match up to commercial standards. To this end, there were a lot of nice-to-haves to work on.
• Sound effects for surgeries / medications
• Animations / effects for surgeries
• Full game testing and bug fixing
• Beginning and end of game / failure state
I managed to get a lot of sound effects in, but it became pretty time consuming and I got caught up in what these purely fictional surgeries would sound like. In the end, I chose the funniest sounding option and left it at that, but still left a lot of medications and surgeries with no sound effects.
I created new art, and effects for surgeries, in amputations I made it so a piece of the customer's sprite was cut, randomly, and for replacement limbs I drew a human arm and placed it randomly with the customer. There was a rather nefarious bug that I didn't have time to figure out, where the effect would work properly once, then fail with an odd stretching, dotted pattern. I tried to fix this, failed, and decided to leave it.
I tested the game, and found a number of small bugs to iron out, and also commenced with hiding my debug UI from the end user (just button collision boxes, mostly). I took the time to write a tutorial prompt and pretty up some items on the desk.
I had to create, quickly (about 10 minutes? probably less?) a game over screen, which I used a stock photo of prison for reference.
With an hour to release, I made a discovery and panicked! My fixed resolution wasn't scaled properly at some common resolutions, meaning for some players they'd be able to see a number of things that should have been off screen, and it also wouldn't be sized for the screen appropriately, about half the size it was supposed to be.
I didn't have time to fix this properly, but something had to be done about the ability to see the operating room, and the front counter at the same time. In a rush, I made a 4k image, cut out a hole for the smaller resolution, and threw it over the game UI. This hid the operating room, but technically, it was all still accessible.
That 'fixed', I compiled the game and submitted to itch, and relaxed until presentation time. I was done.
Presentation was a big of a mess. It's a mostly in person event, and most things are planned with the intent of having everyone there. I wasn't, and had to wait my turn in the chaotic speaker connected to a group discord voice chat.
I had my thoughts together, knew exactly what I wanted to say, but by the time my turn came up, I was frazzled. I rushed through the explanations of the systems of the game, and I failed to show the variety of problems, and worst of all, all the effects and polish I worked on for the last 5 hours, I completely forgot to show it off! Overall I still think my presentation was fine, but I was disappointed by my own standards on showing the full game. I also forgot to give other jammers a chance for questions, which would have been polite. Well, better luck next year!
Now for (some) the most exciting part. The award ceremony. I was very surprised to find I took home the "Most Educational" category with Surgeon's Please. Here's a photo of the trophy.
Overall, I'm really happy with Surgeon's Please, and if I deduct sleeping / eating times, I can very easily say it was made in less than a day. Till next time!