Station 5723 was a game created from scratch for the LudumDare 39 event. In this game, a meteor has crashed into the colony's space station. You play as Sam Warren, the last engineer left alive and you are tasked with repairing the reactor's systems before it goes critical.
This game was created with the help of:
Daniel Acri - Programming
Jesse Pascoe - Programming / Design / Art
John Ryan - Audio / Programming
Alex Thompson - Art
Now, that that's out of the way, I'd like to dig into the process undertaken when developing Station 5723.
So, LudumDare happens every 3 months I think? And I guess there was something that meant 39 was going to happen ahead of the determined schedule. This may have rattled us as individuals, a bit. To be sure, we all would try to improve ourselves leading up to the jam. But we weren't actually sure if we'd even participate this time. As it turns out, David couldn't join us.
I think that we do well in brainstorm sessions, but we do get anxious over a prolonged brainstorming session, I believe. Because of this Jesse opens up a Google Doc for the group, and once the categories leading up to the jam get to about the last 12 or so, we try to write down some ideas. Even if they're bad ideas, or that topic isn't chosen. It can be great for getting yourself into the mindset of thinking about making these games.
A Damn Good Start
So, even though none of us felt really strongly for the Running out of Power theme, I believe we came up with a nice method of brainstorming to separate topics.
Firstly, power can be many things in the form of synonyms like energy, light, strength, etc. So using those synonyms we could start to easily build scenarios of gameplay around them.
We came up with over a dozen different game concepts, and then after doing so recalled a few we felt strongly over, debated on them, expanded upon them, and ultimately, decided on one of them.
I count myself lucky to find Jesse and his collaborators. Daniel, Jesse, and I originally met during the GlobalGameJam 2017, and since then have also created games for Ludum Dare 38(LD38) and now, LD39, too. During LD38, two other members joined on aiding in the creation of that game. John Ryan, and David Casteel.
Is all this backstory necessary? I do believe so. Working alone, with new individuals, or people you've worked with before affect the way you approach development drastically- as I learned from Station 5723.
Jesse is the foundation of the group and resourceful in many ways. I cannot keep count of how many programs/add-ons he knows and can work with. Daniel is extremely reliable and a powerhouse with programming in Unity. John is the genius specialist that makes magic happen. David is the creative visionary and storyteller of the group. and I, Alex, am the designer who's not an artist but has to do artwork, "artist"
The types of games we thought of ranged from silly to serious, and we were searching for a middle-ground. One of the biggest factors in the decision was more about looking at the scope of the games and trying to recall what was possible for each of us.
I was concerned at first about how much time it would take to develop the tasks/puzzles for Station(which was unnamed at this point in time) but Jesse fired off like 90% of what's actually in the final game within about the span of 2 minutes. It was quite astonishing to me, we expanded on that a little and I think just how the game was designed made it so cutting content didn't disrupt things too much.
As you can see from the above image, there were main tasks connected to the reactor as a whole, and then sub tasks, and more sub tasks. So, if we couldn't finish one of the sub tasks, we only had to cut that part of the branch, rather than destroy a whole tree.
We also value the idea of following a list or guide to creating the game. In Game Jams, it's so easy to just 'think' you know everything you're going to do, but it's so much more beneficial to keep a plan and don't deviate from it, if possible.
As I was handling the models, I tried to think of what we would need based on the tiered document and any extra stuff. I also felt it would be important to make placeholder models of everything- which proved to be a very good move on my end. Here is the spreadsheet I came up with. Separating 'steps' of models between placeholder, base colors, detailed textures, etc.
What Went Right
So, I'm still pretty flabbergasted that I managed to make like 18 different, "recognizable" models all before Friday night ended. But considering many are very 'box-shaped' it's not that much of a stretch.
The reason I was adamant about making placeholders is that in our last jam, LD38, some of the 'placeholder' models were in the final version. And it's better to have something than nothing at all- especially for game jams.
Also from that experience, I struggled with exporting models from Maya to Unity as fbx, but now they sort of have an 'auto' feature to handle that- which is nice. Last time, too, there was a strange scaling conversion as Maya is natively measuring in Centimeters, while Unity is in Meters. And you have bake/freeze pivots once you've moved them in Maya, too, to make things easier to position for the level designers in Unity. All of these little things aided me in my process of making these placeholder models.
A Post Mortem from the perspective of the *ahem* "artist"
Preparing for the Jam
My Creation Process for Placeholders
It was like: rectangle to represent person > quickly build rough shapes using primitives and the GLORIOUS Extrude tool to scale > Change position/pivot and bake/freeze for exporting. Then I would do that for the next one.
I am kind of mad, too, because I learned about an amazing reference tool called PureRef while working on this. But I didn't realize I had to save my profile, so I lost basically every reference image I was using, otherwise I would show that collage, too.
What Went mostly Wrong
At the time, I don't really know what was going on, but I think now, me wasting an entire day on 1 thing, freaking out, and then pulling the rest out of my butt is just part of my artistic process.
Even though I got around 18 placeholder models finished within just a few hours. I spent about 13 hours trying to make a single 'polished' model and also wasting time trying to learn how to add materials to stuff.
That isn't to say I don't know how, I just have never tried to really map things to UVs on a model; rather I take advantage of the automatic mapping system that Maya provides, be it Planar mapping, Cylindrical, or 'Box'.
At this point in time, my work pipeline was going to be: placeholder > default texture > polished model > base material model > detailed/complete model. So I was trying to get textures to work on a pipe. I went into GIMP and created my own pipe texture that would be seamless on all sides; it definitely looked like crap. But then when I applied it or any other material to a pipe model I had made, it would tear and look AWFUL.
The Darkest Saturday Ever
I still don't know why it was doing this, but after wasting so much time working on it, I figured that maybe it just wasn't clicking at the time, and I'd come back to it. Then I proceeded to spend a good 8 or so hours on this 'gem' of a model.
It went through several phases. I just consider it my real learning curve. And even though I did lots of cheating in terms of modeling here, it still took forever.
There were a couple different versions of this because I couldn't figure out how I wanted it to look. With 'most' of the models, I tried to draw a sketch out of it first. This is an easy/fast way to test out certain ways or looks to the models. And I think most 3D artists will flesh-out an idea completely in 2D first, before putting it to form- there are exceptions, of course.
And I think it was my lack of skill that hurt the identity of Station 5723, at least a little bit. When I was doing research, and thinking about the core designs of the game, I was thinking that it should be futuristic and 'cool.' It could also be '80s futuristic' kind of like a Star Trek era-looking vibe, and I think people might enjoy that. The main problem is, I never watched much Star Trek, and wasn't familiar with how things looked in it, and what I found online as a reference didn't make sense in terms of what the objects actually were used for.
What Went Right Again
A More Productive Sunday
It seemed like after my 'failure' with the control panel, I tried to stay working on a particular model in under a certain time frame; usually about 2 hours. Limiting myself to how much 'tweaking' time helped me not only budget my time better but make more deliberate changes and commit to them in Maya.
I got through the majority of the models on that Sunday, thank goodness. But there was one really BIG obstacle still in front of me- texturing.
Prior to the jam, I thought what I would have to do is map the UVs and bring that into GIMP then texture it how i want, fitting inside the boxes, and HOPING it looks okay. Luckily, that is not what we did. Jesse showed me something which comparatively was like 4D Chess to my Tic-tac-toe.
It's a program called Substance Painter. Prior to the jam, I hadn't known anything about it. And luckily for me, Jesse was gracious enough to spend hours and hours teaching me how to use it. It's an extremely powerful and robust program, which is probably why it took so long for me to really feel even somewhat competent at it.
I definitely recommend it, or something like it. See, since I've never been good at drawing or texturing things, I would always rely on my modeling to do the heavy-lifting, but that is a backward way of thinking and it really only solves the problem for me- while making things worse for everyone else. Since the number of polygons affects performance and it's easier to change some part of a texture, much more difficult to remodel something(usually).
Anyway, by the end of Sunday, I was pretty frustrated with Substance Painter, and I expressed to Jesse that I would finish all the models, but he may have to actually paint them since he is much more proficient. He shot back to me, "Did you make the reactor yet?" And I said, "No. I should get on that, huh? Haha" Early on when we had all the planning in place, we joked about how we wouldn't wait until the last minute to make the reactor...don't curse yourself like that folks, especially during a game jam! I didn't actually 'finish' the reactor until well into Monday afternoon.
What Went Wrong, but also Right
I hate Mondays...
It wasn't until Monday that we all started to seriously see problems with the game, but it also isn't like we didn't turn in a playable version, either. It's just that, for all our strict and 'fancy' planning early on, we didn't really stick to our schedule or consult it, which was a no-no.
For instance, on my end, I was also supposed to draw images of the inventory items, download icons, and title screens- like I did with LD38. But I was still modeling, and trying to paint up until the last hour or so.
Jesse was also painting some. He worked on the totally awesome fuses, but he may have gotten carried away with that...
It seemed like most of us(myself included) couldn't get off work on Monday, so our time was cut even shorter. And I made the awful assumption of thinking we might polish the game a bit throughout the week after submission like we did with LD38. And whether or not anyone really had the time or drive to do so, we didn't really spend much time(if any) after the official submission time to work on it.
Going back to 'not sticking to the plan' it seemed like throughout the jam we were way ahead of where we needed to be in terms of programming. So no one even thought too much about it. And it wasn't until Monday evening that we realized there was still quite a bit left to 'implement.' To the point that even though I did manage to finish modeling everything I had set out to, not all of those models ended-up in the submitted game.
Having a plan is always good.
What is the take-away here?
It helps you stay on course and keeps things within scope so you can actually complete them. But just having a plan isn't enough, you have to actually follow it(at least somewhat).
Iteration over tweaking.
It's definitely a better idea to work on the same 'finished' piece over many iterations, where you don't get trapped at a certain point and need to make costly, time-consuming changes really late in the game. You could sit there 'tweaking' the same model for 8 hours and still not be satisfied(I know, I did it) and then create an infinitely more complex model in a fraction of that time(also did that).
Aesthetics and the player first.
I couldn't go hyper-futuristic, or even retro-futuristic with this game, so that suffered on its identity some. But the biggest problem was my selection of materials used. They made everything dark, so most of the model's detail is pretty hidden, anyway. This is something I experienced already to some degree with LD38. I made numerous models and worked hard on them, but the player was always so far away, that I could have focused more on other things since a lot of the details are never seen. I think knowing the player would be up close to these models this time pushed me to try and make them more detailed. But like I said before, my choice of materials backfired and most people couldn't really see(and in some cases, recognize) the models I worked on.
Overall, it was still a very positive experience! Our LD39 entry fared better in some categories than our LD38 entry. Namely 'fun' and 'overall' so that makes me happy.
So, I also tried to look up how these things function, things like circuit breakers or communication boxes, etc. And if you've played, you may see a strange contrast of 'not futuristic at all' with 'over-the-top sci fi' and that is because I didn't know how to sci fi-onize these objects.
Looking at my sketches, the original control panel was going to be much more oval-like, I was imagining something between final-zone-in-a-JRPG trope or the egg technology from Guardians of the Galaxy 2. It proved difficult for me to even try, so I had to go with something more like this.