EDIT: I'M AN IDIOT AND FORGOT TO LINK THE GAME https://ldjam.com/events/ludum-dare/39/space-robot-on-a-space-ship HERE, PLAY IT, IT'S NOT THAT BAD

Wow, this Ludum Dare was a ride. This was my third LD and after mismanaged and unsuccessful for me LD38, where I assembled a small team, which produced nothing but bad code and misery. Hell, I was writing text description of a final boss battle (instead of making an actual battle) one hour before Jam deadline to put something in there. So, I was ready to learn from my mistakes and make a good game this time.

LD38 game's biggest problem was the scope. We decided to make a metroidvania with multiple dungeons and an open world. So, this time, I decided to make something small and focused. So I made an open world space game. Apparently, I will never learn.

Idea As soon as I looked at the theme, I came up with three ideas. First one, a robot on a spaceship and both running out of electrical charge as you go. Second is written in my sketchbook as "your phone is running out of power", but I couldn't make an interesting gameplay out of this idea. And third is "your character's power is slowly deteriorating". As in, your character loses skills and abilities as you go. So, the game pretty was a combination of first and third idea -- you would be playing as a robot in a ship with limited charge, but can disable parts of it to preserve power.

Prototype I feel, like I did everything In the wrong order. First thing I did was a sketch of a ship.

Looking at what happened after I scribbled on a paper for a bit I decided, that it was good enough, and so the ship would have 4 systems. First two were pretty simple -- Shield Room (because, every spaceship has a magic shield) and a UI Room (because I thought it would be fun). That left me with two rooms to go, so I decided to make a Radar Room to detect enemies (because, of course, there would be enemies, how can you even make a game without murder?) and a Steering Room (thought process behind that was something like "Oh, I don't know, I'll make a room that controls the ship or something, whatever").

After that, you would assume, I made me some enemies or obstacles to shoot. Well, not really. I made a tutorial. In fact, a failure state was one of the last thing, I added to the game. But in the end, my tutorial has bitten me in the ass, as players understood the ship controls, but not ship systems or upgrade mechanics, which I added later. But, as level was finalized and I didn't have time to redesign it, stuff like energy consumption ended up without proper tutorial.

Then, there were obstacles. I was really pleased, that I managed to squeeze a two types of enemies, asteroids and a boss from, basically, the same code, just with minor alterations in variables' values.

Level design I'm pleased with I went for a more organic approach to the tutorial and level design. I didn't want to just open the game with "How to Play" screen. Instead, I wanted to lead players down a particular path through collectibles and passable obstacle placement that would tech them game mechanics and provide structure, while still remaining an open world game. But that lead to some players "not getting" the game and getting frustrated at controls and unclear mechanics.

This is the screenshot from the first day of LD, that shows example of this approach.

You can see two lines of scrap, that you need to collect to upgrade your ship and an enemy (I'm lazy to open my game and take a newer screenshot, so just assume there is a big "Press R to shoot" in front of the spiky Thingy). As you kill an enemy, you would want to collect scrap, and at the end of the line, you would get a tutorial on upgrading your ship. However, even if you collect all of them, you would be a couple of scrap bits short of the next level up, so you would want to collect the bits you saw behind some asteroids. A nice idea in theory, but I failed to tell players, that scrap is important, before trying to lead them through this path.

Other stuff I'm pleased with Oh, and asteroid belt was pretty nice. Looks like, Unity devs has seriously upgraded their physics engine, as it managed to draw that many physics objects without dropping frames.

Oh, and this epic shooting mechanic everybody liked. At first, I decided to limit player's shooting speed and make bullets disappear on collision (in fact, enemies' guns work just like that), but then I thought the chaos that a pile balls spawning every frame created was too funny to fix. Yeah, a bug that ended up as a most compelling feature.

Sounds ended up okay as well. I wanted to write some simple background music, but it wasn't good enough.

Other stuff that's bad Ship controls. I even jokingly mention it in a description, but it's still should have been redone to WSAD movement. The intention was to create a physics-driven ship controls, so you had to compensate the speed of the ship, by applying force to one of the two directions. But, if you wanted an easy way to stop the ship, regardless of speed and direction it's going, you could've press Space to stop, while taking a big hit to energy. But, in the end, ship was too clunky to control, and I became so good at the game, so I wouldn't notice. I had my doubts about controls, and I should've changed them. Oh well, yet another lesson to learn.

Final boss. It's not really bad, it's just too easy an weird. You just fill the room with balls and kill it. It doesn't feel like a boss battle at all. It was, probably, the most difficult area of the game for me. As I was basing it on a common enemy code and putting it in a small room, it kept flying into the wall and killing itself. It was funny, because, I felt the same way as I was fixing this issue after a solid 10 hours of work or so.

Conclusion Yep, the game's alright. Turns out, having a solid plan from the start helps a lot. Probably, shouldn't have overworked, as it hurt the game, but it was a really fun Ludum Dare regardless. And I would like to thank everyone, who played my game and thank even more, those people, who left a feedback. See you on the next Ludum Dare!