I'm a hobbyist developer who makes some live wallpapers in my spare time. I'll only have some time in evenings after my kids are in bed to work on this game. My initial idea is to do a simplistic roguelike where your character wakes up from hypersleep and must do basic space-chores before returning to sleep, with dangers and surprises along the way. The space station is shaped like a spinning torus, so as you progress from room to room, you end up back at the beginning - a complete day in space. A simplistic roguelike seems like something that could be coded fairly quickly with the basics and then expanded on with the time remaining. Going to start outlining the code this afternoon to gauge the feasibility.

I tried a number of simple mobile rogue-likes and dungeon-crawlers last night and got a feel for what I'd like to try. I will make it turn-based so I won't need to worry about event timing so much. There will be a grid for each screen so the camera doesn't need to scroll.

I remember when I started learning Libgdx, I read the code for Cuboc and it used a bitmap file as the level editor. I'm going to try doing that for this game. If each screen is a grid, I can mix and match left, middle, and right pieces to create random stages while easily ensuring there is always a fair solution. And if I use Gimp as my level editor, I can turn layers on and off to make sure all my combinations work reasonably well together before having to play test them.

I don't plan to put nice graphics in until the logic is mostly complete (I've found that results in wasted time on graphics that need to be reworked). But I did start creating my workflow for creating a texture atlas.

I use Libgdx's TexturePacker without any GUI, as I like to have full control over subdirectories for customizing the individual texture region options.

My favorite sprite editor is Cosmigo ProMotion, and it can output animated Gifs with a spare Gif for the alpha channel. These gifs can have variable frame lengths. Since TexturePacker doesn't support Gifs, I wrote a pre-processor that generates PNG files from the Gifs (merging in the alpha frames from the alpha gif). This is adapted from an old Libgdx pull request I made (but was turned down for being too specific of a use case).

Since Libgdx's Animation class doesn't accept variable length frames, I the Gif pre-processor duplicates frames as needed to get the timing to work out, and it prints out the frame length that should be used with the Animation class (a greatest common denominator of all the original variable lengths). This doesn't waste atlas space, because TexturePacker reuses identical sprites.

Here's the code. The GifProcessor looks for alpha Gif's using ProMotion's file naming scheme.

I plan to use low resolution sprites, but I want the space station to be a torus, so each rectangular room should look rounded. To solve this problem, I wrote a shader that curves the input UV's, and a CurvedViewport class that applies the same mapping to the input touch coordinates. As long as the curvature isn't too extreme, it looks close enough to represent a section of the large torus.

For the past two weeks, I've mostly been coding the game logic, so there wasn't anything to show. I've been filling in actual graphics the past few days, so I finally have an update to show. Here's a shot of one of the stages. There's still some placeholder art in there but it might become permanent if I run out of time. >__<

I threw an FXAA shader at it because the curved low-resolution layer looks better with it. But at this small scale you can see artifacts in high-contrast areas. If I have time, I'll have the FXAA shader's parameters adjust to the screen resolution.

So far, the art is 99% original for this project (everything except the hearts in the UI). The code is 95% original. Boilerplate and utility code has been copied from a game I've been working on in my spare time. I could see how a game jam with lenient rules like this one could go very quickly if I had some prior games to pull from. ^__^

Oh, and last night I thought I'd add a broken glass layer to the screen when you get a game over. I did a search for drawing broken glass in Gimp to get ideas about how to make it look, and this tutorial gave me the idea to take it a step further and offset the image below using a shader. I encoded offsets in the R and G channels of my glass image, and encoded black and white coloration to the cracks in the B and A channels. There's also some chromatic separation applied before the broken glass effect. 30 minute effect looks really nice!

Sneak peak of boss:

Fun fact. Player character originally looked like this. (uniform supposed to look a bit like old Star Trek uniforms)

My 4-year-old daughter was watching and said, "Give her a pinny-tail!" (her word). Then, "Give her a smaller mouth!" And, "Make her hair black!". At that point, it was basically my final sprite, and I realized she was having me make it look like her.

(The proportions and walk animation are inspired by small Mario from SMW.)

And it's submitted. A few general notes about the project.

This is the first game I've completed from start to finish. I've mostly used LibGDX for making live wallpapers, and I've been working on a game here and there in my spare time for the past year. I plan to polish this a bit, expand the length, tweak the gameplay, and publish to iPhone and Android.

I started out with a noble goal of good model/view encapsulation. Then I started using Scene2D.ui for scripting everything which works well. But as I realized it was taking too long, I started taking a lot of shortcuts. I just barely made it to the end without getting tripped up at all by some of the spaghetti. This is a small enough project that it was alright. I would not do this outside of a game jam.

I made very heavy use of JSON deserialization for describing all my assets. This worked out great for very quickly designing a lot of content for the game. It's not very clean because of the speed I was working at, but I would use a similar method in future projects.

Making pixel art is a blast, and I don't think I could have finished in time if I went for a higher-resolution style for the 2D art.

I decided on the main aliens being little squishy ball things intentionally so I could animate them quickly. When it came to the robots, I really ran out of time, so they only have a single animation. I made them round and spinny to get away with that.

I had quite a bit of planned content that I had to cut for time because it all relied on additional sprites. I plan to add some of that back in for the mobile release.