Posts Tagged ‘#one-button’


Posted by
Sunday, April 26th, 2015 6:21 pm

It’s been about a week, so here’s a retrospective on my LD32 entry: Pedestrian Mining Corps. It was a nice break from a couple of other projects I’m working on.

What It Is

Box art for Pedestrian Mining Corps

Pedestrian Mining Corps is a one-button game about launching pedestrians into space to push asteroids back to Baby Earth by jumping on them. You’re working against the clock and asteroids’ gravity wells to get as many rocks harvested as possible.

It’s built in Unity 5. It’s a jam entry, so I used some premade assets:

I recorded the stomping sound with my laptop’s crappy built-in mic because I didn’t feel like dragging my gear out, and massaged it in Audacity. Planet and asteroid sprites were created in Inkscape.

What’s Great

dev_gameplay2I finished. I got the thing done. I had to use the whole submission hour on Monday night, but it came together. I wasn’t sure it would. I’ve failed four of the last five jams I’ve attempted, so it felt good to get across the finish line.

I’ve been doing a lot more game dev this year than previously, and I’m better for it. I was able to quickly build the UI and tweened transition effects using techniques I’ve used before. I used the awesome Unity 5 audio mixer system for audio transitions and a low-pass filter to keep the music rumbling after the game ends. I’m pretty happy with the nearly-free polish I got from habits and reuse.

I learned more about Unity’s animation system. Those little jumping animations were pretty easy to make and their sound effects are triggered by animation events. Planet and asteroid rotations use the animation system, too.

I’m pretty happy with the 2D/3D split art style, though it didn’t go over well with most players. It was borne of a limitation: I don’t know how to texture 3D objects. More about that below. I’m happy with the way the menu looks and works, the way the game looks in action, and the way the score/replay wrapup presents itself. Oswald, the button font, is one of my favorites; I’m using it all over the place in another game I’m working on called Disc Jockey Jockey.

I like the choice players make between sending pedestrians to new asteroids or putting more pedestrians on the ones already coming in. More pedestrians on an asteroid makes it (subtly) move faster and take a more direct route to Baby Earth, but it also has an effect on your efficiency. I usually spend my early game bringing in as many new asteroids as possible and the last 20-30 seconds making sure everything that’s on its way gets home under the limit.

What Wasn’t Great


In code, I tried leaning into Unity’s component system this time with lots of tiny behaviors. This was a bad idea, especially when tweaking game feel. You quickly lose track of which object has which component on it, or which of half a dozen components is applying a force at the wrong time or playing a sound when audio should be muted. Or you just need all those components to talk to each other because they’re dependent on each other’s state. I’m much happier with a manager object that’s pulling the strings. Maybe individual objects can have small behaviors attached but controlled at a higher level where I can see everything at once. Let the manager subscribe to events published by components and consolidate coordination and settings.

I mixed 2D and 3D because I don’t know how to texture 3D models. Not even cubes. The only 3D software I know how to use is OpenSCAD—best-suited to mechanical models—which has no concept of UV coordinates. I think the resulting look is playful and silly, but most players just think it’s incongruous. A voxel design would probably work better. I wish I’d known about Magica Voxel before the jam.

I worked alone, which is great for creative control and kind of bad for motivation/focus/workload. Pairing up with someone more accustomed to working in 3D would’ve helped.

Scrapped Plans

Some things I’d planned but didn’t implement:

  • Multiplayer. The framework is there; pedestrians have a “homeworld” they push toward, so it’d be easy to reassign that to another planet.
  • Pedestrians yelling their names on launch. I built a whole system to scrape the filesystem for audio clips at editor time and generate random first/last name pairs, but didn’t have time to record the voices. I think it would’ve been funny to hear. Ended up being a waste of time.
  • Different asteroid/resource types. I’d planned to maybe require a certain number of different resources to be collected under the time limit to advance to the next wave. Or even have antagonistic forces like an enemy planet or spaceship that would attack, requiring pedestrians to take it out.
  • Pedestrian classes. The original game concept was more like tower defense, launching pedestrians out to stick to planets where they could attack incoming enemies. I think classes could still work, with certain class combos producing more minerals or fending off attacks.
  • Credits. There’s a hidden button on the main menu that goes to a dead credits screen I didn’t have time for. That might be the one thing I go back and add before I consider the game “done”.
  • Tuning. I need to play with the push force, steering force, and asteroid spawn rate. They could all be improved. Playtesting would’ve helped.
  • Networked high scores. I always put this on the nice-to-have list, but it’s probably never worthwhile. They’re too easy to subvert and they mostly make you feel bad about your score.


Thanks for reading! I’m having a lot of fun playing and rating all of your games. <3

Please try Pedestrian Mining Corps if you haven’t already. It plays on the web* and it only takes a few minutes.


Pedestrian Mining Corps

* Unity webplayer; Windows/Mac, any browser but Chrome. Lin/Mac/Win downloads also available.

Space, Here I Come!

Posted by (twitter: @GarrickWinter)
Friday, February 21st, 2014 8:05 pm

So yes, I am participating in this month’s Mini Ludum Dare! And I’m quite excited, if I may say so.

My game, which I’m tentatively calling Space Prober, is a game about a space probe slingshotting itself between stars and planets. You are trying to explore as many planets as you can while keeping your battery levels up by slingshotting close to active stars.

It will be a fairly simple game, all things considered, and I am planning on porting it to Android if I have the time to do so. It will be built in Unity, so I should be able to publish it for browsers as well as Windows.

I will try to post a screenshot tonight, but I already have the core slingshotting mechanic working! Yay!

Good luck everyone!

A viking-ish update

Posted by (twitter: @c64gamer)
Saturday, December 14th, 2013 5:16 pm
So... much... tasty stuff!

So… much… tasty stuff!

So… after 13 hours and 45 minutes we have our first implementation of the core features of our game!

There is still a lot of work to do, but the game is playable! 😀

Greetings from your friendly atomic vikings team receptionist named: Linda Smellröf

Posted by
Monday, April 29th, 2013 8:34 pm

So, yeah. With family and such I wasn’t able to pull together the basic movement system until today. I set a reasonable expectation for myself, a one button Pac-man. However the delay cost me not being able to add more levels, smooth the movement or find all the little bugs in the movement. Still for my first LD I think I managed all right.

Without further delay, I introduce:

MINI the MALISM Potatoe Beetle

Title Screen


Tools: Game Maker Studio (only because of the notice of 3 hours before it started) and some MS Paint.

[cache: storing page]